Other events published by Mostro
Each Mostro instance publishes several types of events to Nostr relays. These include identity metadata, instance status, relay lists, and development fee records. Below, we provide details on each of these events.
Node Identity (NIP-01 Kind 0)
Each Mostro instance publishes a NIP-01 kind 0 metadata event on startup so that Nostr clients can display the node's profile information. This is the standard Nostr profile mechanism — every relay-aware client already knows how to fetch and display kind 0 metadata.
The event is a replaceable event, meaning relays keep only the latest version. It is re-published on every restart, ensuring the profile stays fresh.
The content field contains a stringified JSON object with the following optional fields:
{
"name": "Mostro P2P",
"about": "A peer-to-peer Bitcoin trading daemon over the Lightning Network",
"picture": "https://example.com/mostro-avatar.png",
"website": "https://mostro.network"
}
The full event looks like this:
[
"EVENT",
"RAND",
{
"id": "<Event id>",
"pubkey": "<Mostro's pubkey>",
"kind": 0,
"tags": [],
"content": "{\"name\":\"Mostro P2P\",\"about\":\"A peer-to-peer Bitcoin trading daemon over the Lightning Network\",\"picture\":\"https://example.com/mostro-avatar.png\",\"website\":\"https://mostro.network\"}",
"sig": "<Mostro's signature>",
"created_at": 1731701441
}
]
Fields
name: Human-readable name for the Mostro instance (e.g., "LatAm Mostro", "Bitcoin Munich Exchange").about: Short description of the instance and the community it serves.picture: URL to an avatar image. Recommended: square, max 128×128 pixels, PNG or JPEG.website: Operator's website URL.
All fields are optional. If no metadata fields are configured, no kind 0 event is published. These fields are configured in the [mostro] section of settings.toml:
[mostro]
name = "Mostro P2P"
about = "A peer-to-peer Bitcoin trading daemon over the Lightning Network"
picture = "https://example.com/mostro-avatar.png"
website = "https://mostro.network"
This allows clients like Mostro Mobile to display meaningful information about each Mostro instance — its name, description, avatar, and website — so users know which node they are trading on.
Mostro Instance Status
Each Mostro instance periodically publishes events with relevant information about its status, such as the code version it is using, the latest commit, the fees it charges, allowed exchange limits, the relays it publishes to, and much more. Below, we provide details on these events.
Mostro Instance Status
This event contains specific data about a Mostro instance. The instance is identified by the d label.
[
"EVENT",
"RAND",
{
"id": "<Event id>",
"pubkey": "<Mostro's pubkey>",
"kind": 38385,
"tags": [
[
"d",
"<Mostro's pubkey>"
],
[
"mostro_version",
"0.12.8"
],
[
"mostro_commit_hash",
"1aac442058720c05954850bcffca6bcdfc87d150"
],
[
"max_order_amount",
"1000000"
],
[
"min_order_amount",
"100"
],
[
"expiration_hours",
"1"
],
[
"expiration_seconds",
"900"
],
[
"fiat_currencies_accepted",
"USD,EUR,ARS,CUP,VES"
],
[
"max_orders_per_response",
"10"
],
[
"fee",
"0.006"
],
[
"pow",
"0"
],
[
"pow_first_contact",
"0"
],
[
"maintenance_mode",
"false"
],
[
"protocol_version",
"1"
],
[
"escrow_mode",
"lightning"
],
[
"hold_invoice_expiration_window",
"120"
],
[
"hold_invoice_cltv_delta",
"144"
],
[
"escrow_deadline_margin_blocks",
"24"
],
[
"invoice_expiration_window",
"120"
],
[
"lnd_version",
"0.18.4-beta commit=v0.18.4-beta"
],
[
"lnd_node_pubkey",
"0220e4558a8d9af4988ef6c8def0e73b05403819e49b7fb2db79d322ac3be1547e"
],
[
"lnd_commit_hash",
"ddeb8351684a611f6c27f16f09be75d5c039f08c"
],
[
"lnd_node_alias",
"alice"
],
[
"lnd_chains",
"bitcoin"
],
[
"lnd_networks",
"regtest"
],
[
"lnd_uris",
"0220e4558a8d9af4988ef6c8def0e73b05403819e49b7fb2db79d322ac3be1547e@172.26.0.2:9735"
],
[
"bond_enabled",
"true"
],
[
"bond_apply_to",
"take"
],
[
"bond_slash_on_waiting_timeout",
"false"
],
[
"bond_amount_pct",
"0.01"
],
[
"bond_base_amount_sats",
"1000"
],
[
"bond_slash_node_share_pct",
"0.5"
],
[
"bond_payout_claim_window_days",
"15"
],
[
"serbero",
"<Serbero's pubkey>"
],
[
"reputation_import_issuers",
"<Trusted issuer key>",
"<Another trusted issuer key>"
],
[
"reputation_issuer",
"<This instance's issuer key>"
],
[
"y",
"mostro",
"[Mostro instance name]"
],
[
"z",
"info"
]
],
"content": "",
"sig": "<Mostro's signature>",
"created_at": 1731701441
}
]
The info event says that an instance is alive and how it is configured. It does not say whether the instance is working: an instance whose Lightning node has stopped syncing keeps publishing a normal info event while every buyer payout fails. That is what the health event (kind 38389) is for.
Below is an explanation of the meaning of some of the labels in this event, all of which can be modified by anyone running a Mostro instance.
mostro_version: The version of the Mostro daemon running on the instance.mostro_commit_hash: The ID of the last commit used by the instance.max_order_amount: The maximum amount of Satoshis allowed for exchange.min_order_amount: The minimum amount of Satoshis allowed for exchange.expiration_hours: The maximum time, in hours, that an order can remain inpendingstatus before it expires.expiration_seconds: The maximum time, in seconds, that an order can remain inwaiting-paymentorwaiting-buyer-invoicestatus before being canceled or reverted topendingstatus.fiat_currencies_accepted: Fiat currencies accepted by the Mostro, which may include stablecoin codes and the codes of bitcoin on other networks. If no currency is specified, all are accepted.max_orders_per_response: Maximum complete orders data per response in orders action.fee: The fee percentage charged by the instance. For example, "0.006" means a 0.6% fee.pow: Proof of work (NIP-13) required of every event a client sends the instance, expressed as the number of leading zero bits the event id must have. Measured on the outer event (the gift wrap on protocol v1, the kind-14event on v2) and checked before anything else, so an under-powered event is discarded without any reply."0"means no work is required. See Proof of work.pow_first_contact: Proof of work required of a first-contact event — one whose visible sender is a trade key the instance does not currently associate with an active order or dispute: a new order or a take, and any request sent from a key with no active order or dispute, such asexport-reputationorimport-reputation. Always at leastpow, and typically higher: it is the anti-spam toll on the only lane an unknown sender can arrive through. Read this tag, notpow, before mining the first event of a trade or such a request. Daemons that predate the tag omit it; absence means the difficulty is unknown, not that it equalspow. See Proof of work.protocol_version: The Mostro protocol (wire transport) this node speaks —"1"for NIP-59 gift wrap (kind1059, DEPRECATED) or"2"for NIP-44 direct messages (kind14). A node speaks exactly one, and the two are incompatible; clients read this tag before sending anything to pick the matching wire format, or to refuse a node whose protocol they do not speak. Nodes running mostrod v0.19.0 or later always publish"2". See the client migration guide.escrow_mode: The escrow backend this node runs:"lightning"or"cashu". See Escrow mode tags.hold_invoice_expiration_window: The maximum time, in seconds, for the hold invoice issued by Mostro to be paid by the seller. When the node requires a taker bond, it is also how long a taker has to pay the bond hold invoice: that invoice expires after this many seconds (see Pay bond invoice).hold_invoice_cltv_delta: The number of blocks in which the Mostro hold invoice will expire.escrow_deadline_margin_blocks: How many blocks before the hold invoice's CLTV expiry Mostro acts on a trade whose escrow it still holds, so that LND does not refund the seller first: it cancels anactivetrade and opens a dispute on afiat-sentone. Clients can estimate that moment as abouthold_invoice_cltv_delta - escrow_deadline_margin_blocksblocks after the seller paid the hold invoice (120 blocks, about 20 hours, with144and24), for example to show the buyer how long they have to send the fiat. The value is always at least18and belowhold_invoice_cltv_delta. It does not apply to a trade that is already indispute. Daemons that predate the tag omit it: from v0.18.3 they act on the trade with a margin clients cannot know (24by default), and older daemons do not act on it at all.invoice_expiration_window: The maximum time, in seconds, for a buyer to submit an invoice to Mostro.lnd_version: The version of the LND daemon running on the instance.lnd_node_pubkey: The pubkey of the LND node running on the instance.lnd_commit_hash: The ID of the last commit used by the LND node.lnd_node_alias: The alias of the LND node.lnd_chains: The chains supported by the LND node.lnd_networks: The networks supported by the LND node.lnd_uris: The URIs of the LND node.y: Platform identifier tag values. Mostro publishes"mostro"and MAY include a second value with the Mostro instance name from settings.z: The type of event.
Anti-abuse bond policy tags
These tags advertise the node's anti-abuse-bond configuration so clients can show users — before they enter a trade — whether a bond is required, how much it will cost, and under what conditions it can be slashed. bond_enabled is always emitted on daemons that support the feature; the remaining six tags are present only when bond_enabled = "true".
bond_enabled:"true"if the node enforces an anti-abuse bond on at least one trade side, otherwise"false".bond_apply_to: which side must lock a bond —"take","make", or"both".bond_slash_on_waiting_timeout:"true"if a bonded user's bond is slashed when a waiting-state timeout elapses,"false"if such timeouts only release the bond.bond_amount_pct: bond size as a fraction of the trade amount (e.g."0.01"= 1%). The actual bond ismax(bond_amount_pct × order_amount_sats, bond_base_amount_sats).bond_base_amount_sats: minimum bond size in satoshis. Floor applied tobond_amount_pct × order_amount_satsso small trades still carry a non-trivial bond.bond_slash_node_share_pct: fraction of a slashed bond the node retains. The remainder is paid out to the winning counterparty as a Lightning payment. Always within[0.0, 1.0].bond_payout_claim_window_days: number of days the winning counterparty has, from the slash moment, to submit a Lightning invoice for their share of a slashed bond. After this window the share is forfeited to the node. Clients use this together with theslashed_atfield carried onadd-bond-invoicemessages (see Bond payout invoice) to render the forfeit deadline locally.
Disambiguation. When bond_enabled is absent from the event, the daemon predates the bond feature; treat the node as not enforcing bonds. When bond_enabled = "false", the daemon supports the feature but the operator has not enabled it on this instance. When bond_enabled = "true", the remaining six bond tags are present and clients should expect bond messages on this node — pay-bond-invoice for the bonded user and add-bond-invoice for the payout recipient on a slashed trade.
Serbero tag
Serbero is a dispute assistant a node operator can run: it takes a dispute first, helps the parties establish the payment facts, and hands the case to a human solver when needed.
serbero: the hex public key of the node's Serbero. Present only when the operator configured one.
The node registers that key as a read solver (see Add solver), and refuses to start if the key is a read-write solver, a user that is not a solver, or its own key. The tag therefore also tells clients that this solver cannot settle or cancel.
Clients compare the tag with the solver pubkey in admin-took-dispute to tell the assistant from a human solver, for example to label the dispute chat "Serbero" instead of "Solver". When the tag is absent, clients cannot identify a Serbero from this event. It does not mean every solver is a person: a node that predates the tag may still run one, registered through admin-add-solver.
Escrow mode tags
A node escrows every trade with exactly one backend, fixed by its operator: Lightning hold invoices on its LND node, or Cashu ecash locked with a NUT-11 2-of-3 spending condition on the mint each order names. The info event tells clients which one, so they can pick the right trade flow, or refuse a node whose backend they do not support, before they create or take an order.
escrow_mode:"lightning"or"cashu". Always emitted by daemons that know the tag. Older daemons omit it, and clients should treat its absence as"lightning".
Lightning nodes (escrow_mode = "lightning") publish hold_invoice_expiration_window, hold_invoice_cltv_delta, escrow_deadline_margin_blocks, invoice_expiration_window and the lnd_* tags described above. A Cashu node has no LND node and issues no invoices, so it omits all of them and publishes these instead:
cashu_mint_url: The mints this node accepts for new orders, one URL per tag value. The maker of each order chooses one of them (Cashu escrow mint). The tag is absent when the node accepts any mint with a public host. A client that reads only the first value still gets a mint the node accepts.cashu_escrow_locktime_days: The seller-recovery locktime floor, in days. The seller's escrow token must carry a locktime of at least now + this many days; a longer locktime is accepted, a shorter one is rejected.
The remaining tags (fees, limits, pow, pow_first_contact, protocol_version, maintenance_mode, y, z, and so on) keep their meaning in both modes. An anti-abuse bond is paid as a Lightning hold invoice, so a Cashu node never enforces one and always publishes bond_enabled = "false".
The escrow tags of a Cashu node look like this:
[
["escrow_mode", "cashu"],
["cashu_mint_url", "https://mint.example.com", "https://mint.example2.com"],
["cashu_escrow_locktime_days", "15"]
]
Reputation tags
These tags say whether the node takes part in reputation export and import. Clients read them before offering either, and never send export-reputation or import-reputation to a node that does not advertise it.
reputation_import_issuers: the hex keys of every issuer whose attestations the node imports, one value per key, across all the entries of its trust list. Present only when import is enabled; an enabled node with an empty trust list publishes the tag with no values.reputation_issuer: the hex key the node signs attestations with. Present only when export is enabled. It is a key dedicated to issuance, never the node's own key, and an operator who trusts this node adds it to their trust list. When the node rotates it, the tag names the new key.
A key in reputation_import_issuers is never the node's own reputation_issuer: a node does not import its own attestations.
Maintenance mode tag
maintenance_mode:"true"while the operator has put the instance in maintenance mode, otherwise"false". Always emitted on daemons that support the feature; daemons that predate it omit the tag, which clients should treat as"false".
While maintenance_mode = "true" the instance rejects new-order, take-sell and take-buy with a cant-do whose reason is maintenance_mode (see Cant Do Reasons). Every other action keeps working under the same rules as always: what an existing order's current status allows — paying the hold invoice, fiat-sent, release, cancel, disputes, ratings, adding invoices — is still accepted, so open trades can finish normally. Maintenance mode only removes the actions that open new escrow; it does not make a completed or canceled order accept anything new. The typical use is draining open escrow before the operator migrates the instance to a different Lightning node.
Clients SHOULD read this tag and warn the user before they compose or take an order on an instance in maintenance mode, rather than letting the user mine proof of work for a request that will be rejected. The tag flips back to "false" when the operator re-opens the instance; the info event is republished immediately on each change and then at the usual interval.
Information about the Relays Where Events Are Published
The operator of a Mostro instance decides which relays the events from that instance are published to. This information can be accessed in events kind 10002, which are published by the Mostro instances.
[
"EVENT",
"RAND",
{
"id": "<Event id>",
"kind": 10002,
"tags": [
["r", "wss://relay.mostro.network/"],
["r", "wss://nos.lol/"]
],
"content": "",
"sig": "<Mostro's signature>",
"pubkey": "<Mostro's pubkey>",
"created_at": 1731680102
}
]
The r label indicates the relays through which the Mostro instance is publishing its events.
Exchange Rates
Each Mostro instance publish Bitcoin/fiat exchange rates to Nostr relays as addressable events (kind 30078):
Event Structure
[
"EVENT",
"RAND",
{
"id": "<Event id>",
"pubkey": "<Mostro's pubkey>",
"kind": 30078,
"tags": [
["d", "mostro-rates"],
["published_at", "1732546800"],
["source", "yadio"],
["expiration", "1732550400"]
],
"content": "{\"BTC\": {\"USD\": 50000.0, \"EUR\": 45000.0, \"VES\": 850000000.0, \"ARS\": 105000000.0, ...}}",
"sig": "<Mostro's signature>",
"created_at": 1732546800
}
]
Tags
- d:
"mostro-rates"— NIP-01 identifier that makes this event replaceable. Each new rate update replaces the previous one. - published_at: Unix timestamp when the daemon published the event (daemon time, not source timestamp).
- source: Rate source identifier (e.g.,
"yadio"). - expiration: Unix timestamp for event expiration (NIP-40). Prevents stale rates from being served.
Content Format
The content field contains the full rate response in JSON format matching the source API structure (Yadio format):
{
"BTC": {
"BTC": 1,
"USD": 50000.0,
"EUR": 45000.0,
"VES": 850000000.0,
"ARS": 105000000.0,
"AED": 260491.35,
"..."
}
}
Rate semantics: Each value under "BTC" represents the price of 1 BTC in that currency.
A node that quotes stablecoins includes their codes, each at the price of the fiat it is pegged to: "USDT" carries the same value as "USD". A code that is missing means the node does not price market orders in it.
A node that quotes bitcoin on other networks includes each code it quotes among BTC, LBTC and RBTC, at 100000000: 10⁸ units per BTC, a unit being a sat. On-chain bitcoin is the inner "BTC" entry, so an inner "BTC" of 100000000 means the node quotes it, while 1 is a source's self-rate and not a quote.
Development Fee
The development fee mechanism provides sustainable funding for Mostro development by automatically sending a configurable percentage of the Mostro fee to a lightning address on each successful order, this a regular event with kind 8383 which is expected to be stored by relays.
[
"EVENT",
"RAND",
{
"id": "<Event id>",
"tags": [
[
"order-id",
"<Order id>"
],
[
"amount",
"8" // sats amount
],
[
"hash",
"ca2f47b7c2169b8c42ef135e8ee32706e1fd3722b65e5a16f21ce675d2affb6b"
],
[
"destination",
"dev@mostro.network"
],
[
"network",
"mainnet"
],
[
"y",
"mostro",
"[Mostro instance name]"
],
[
"z",
"dev-fee-payment"
]
],
"content": "",
"sig": "<Mostro's signature>",
"pubkey": "<Mostro's pubkey>",
"created_at": 1768256716,
"kind": 8383
}
]