Reply bounties

For the concept behind reply bounties — why they exist and how the escrow rides the message account — see Reply bounties. This page is the full command reference: attaching a bounty, linking a reply, claiming, and reclaiming an unanswered bounty.

sithbit mail send <to> … --bounty <lamports> [--bounty-window <seconds>]
sithbit mail send <to> … --reply-to <message account address>
sithbit mail claim-bounty <message_id> <reply_message_id> <SENDER_ADDRESS>
sithbit mail refund-bounty <message_id> <RECIPIENT_ADDRESS>

End users normally never type these: a mail client sending through a sithbitd daemon gets the reply linkage for free (see Replying to a bountied message). The commands are the low-level primitives, exactly as mail send is for delivery.

Attaching a bounty

Two extra flags on sithbit mail send:

--bounty <lamports> — the amount to escrow on the message account. 0 (the default) is a plain send, byte-identical to a send without the flag.
--bounty-window <seconds> — how long the recipient has to reply and claim, counted from now. Defaults to 7 days (604 800 seconds); only meaningful together with --bounty. The window must end in the future — a bounty that would be born expired is rejected on-chain.

sithbit mail send [email protected] \
  --path ./question.eml \
  --bounty 5000007

The sender fronts the bounty at send time, on top of the message rent: the message account is created holding rent + postage + bounty. Note the send’s output — Sent message #7 … — because that message id is what a later refund-bounty needs.

The trustless webmail compose authors the same two fields client-side — a SOL amount and a claim window in days behind its Attach a reply bounty control, with the same 7-day default — and its reader’s Reply on-chain action carries the --reply-to linkage automatically. Bounty authoring is a direct-signed surface: the CLI and the trustless compose write it; sends composed through a mail server stay bounty-less.

Replying to a bountied message

To make a reply claimable, the reply’s send must carry an on-chain link back to the bountied message:

sithbit mail send [email protected] \
  --path ./answer.eml \
  --reply-to <message account address>

--reply-to takes the bountied message’s account address — the base58 address sithbit mail get prints next to each id (Email #7: <address>), not the numeric id.
The linkage is privacy-preserving: what reaches the chain is only the blake3 hash of that account address — no sender or recipient address appears, consistent with what a plain send reveals.
--reply-to works without a bounty too, if you want the threading link on-chain for its own sake.

Through a mail server, this is automatic. When the reply travels through a sithbitd daemon (the normal path for anyone using an ordinary mail client), the spooler resolves the reply’s In-Reply-To header to the original message’s chain coordinates and sets the linkage itself — just reply in your mail client and the claim evidence takes care of itself.

Claiming the bounty

Once the reply is on-chain, the recipient of the bountied message collects:

sithbit mail claim-bounty <message_id> <reply_message_id> <SENDER_ADDRESS> \
  [--keypair <keypair>] \
  [--skip-preflight]

<message_id> — the bountied message’s id in your own mailbox.
<reply_message_id> — your reply’s id in the original sender’s mailbox (a reply is itself a message, delivered to them).
<SENDER_ADDRESS> — the original sender’s wallet address (or keypair path); their mailbox is where the reply lives.
--keypair (short -k) — the claimant’s signing keypair; only the bountied message’s recipient may claim.

sithbit mail claim-bounty 7 12 7Xh…q4M
Claimed the bounty on message #7 with reply #12 from 7Xh…q4M
https://explorer.solana.com/tx/…

The claim pays out 90/10: for a 5 000 007-lamport bounty, 4 500 007 lamports go to you, and the 500 000 operator share goes to your domain’s authority (the operator running your mail host) — or to the postoffice, if your mailbox doesn’t name an active domain — see Economics for the exact split rules. A claim is legal through the exact expiry instant; at the deadline itself, the claim still wins.

Reclaiming an unanswered bounty

If the window closes with no claim, the sender takes the bounty back:

sithbit mail refund-bounty <message_id> <RECIPIENT_ADDRESS> \
  [--keypair <keypair>] \
  [--skip-preflight]

<message_id> — the bountied message’s id in the recipient’s mailbox (the id mail send printed).
<RECIPIENT_ADDRESS> — the recipient’s wallet address (or keypair path), which the message account is derived from.
--keypair (short -k) — the sender’s signing keypair; only the original sender may reclaim.

sithbit mail refund-bounty 7 9aF…2kD
Refunded the expired bounty on message #7 to 9aF…2kD
https://explorer.solana.com/tx/…

The refund is strictly after expiry — one second past the deadline, not at it — and returns the bounty in full: unlike a claim, a refund pays no share to anyone. The message itself survives; only the bounty moves.

What deleting the message does

Deleting a message with a still-riding bounty returns the bounty to the sender, folded into the sender-refund leg of the normal settlement. No reply, no payout: an unclaimed bounty is the sender’s money and never converts into recipient postage. This holds for the auto-settle worker’s deletes too — a recipient who ignores a bountied message until the settle window sweeps it earns the postage but not the bounty.

What you can and can’t trust

The escrow is the message account. The bounty sits on the same on-chain account as the message’s rent and postage from the moment of the send — there is no third party holding it and no separate account to audit.
Only a real reply claims. The claim must present a message that (a) sits in the original sender’s mailbox, (b) was sent by the claimant, and (c) names the bountied message via the on-chain reply linkage. A routine unrelated message from the recipient satisfies (a) and (b) but not (c) — it cannot claim.
One payout, ever. Claiming zeroes the bounty on the message account, so the same reply — or any other — cannot claim twice, and a claimed bounty cannot also be refunded (and vice versa).
The deadline is exact. Claims win up to and including expires_at; refunds open strictly after it. The two windows cannot overlap.

Sending mail — the send primitive these flags extend.
Getting mail — where to read a message’s id and account address.
Deleting mail — settlement, and the delete path a riding bounty takes.
Economics — the exact money flow: who pays, who collects, and when.

Keyboard shortcuts

SithBit Mail