Private Preconf Demo

Protocol

Payment and payout

A payment includes a shielded merchant output and a service fee. The merchant checks its output; the service validates the transaction and checks its fee.

Payment and payoutMessages run from top to bottom between labeled participants. Solid arrows are requests or actions; dashed arrows are responses and chain observations.MerchantServiceMinerChainSubmit raw paymentValidate transactionReserve spends; persist receiptSigned receiptGetPendingAccepted pending transactionsValidate against local tipPrioritize over mempool conflictsMine payment in block HObserve inclusion · 1 confirmationRemove payment from pendingAssign miner’s fee shareObserve block H + 1 · 2 confirmationsBuild 98% payoutPersist signed transactionBroadcast payout via ordinary mempoolMine payout in a later blockObserve payout confirmation

Merchant requests use JSON-RPC. Miners fetch the pending set over Zakura v2 QUIC every 500 ms. Acceptance is signed before inclusion; payout waits for the inclusion block and one successor.

Conflicting payments

A and B spend the same shielded note. A higher network fee or earlier mempool arrival does not override the service’s acceptance.

Conflicting paymentsMessages run from top to bottom between labeled participants. Solid arrows are requests or actions; dashed arrows are responses and chain observations.SenderServiceParticipating minerPayment B reaches the mempool first (higher network fee)Submit payment AAccept A; reserve its nullifierReceipt for ASubmit conflicting payment BReject: nullifier already reservedGetPendingPayment AInclude A; exclude B

This priority applies to participating miners. An outsider can mine B instead; A then fails and earns no payout. The receipt is not a consensus guarantee.

Accounting and recovery

Each included transaction earns its miner 98% of its service fee. Fees are summed per block, rounded down to whole zatoshis, and paid in one transaction. For example: 30 payments × 10,000 zat = 300,000 zat collected; 294,000 zat goes to the miner. The service funds the payout’s network fee separately.

Blocks are attributed to configured Ironwood coinbase receivers using the public zero outgoing viewing key. Unknown or ambiguous recipients receive no automatic payout.

Duplicate submissions return the original receipt. Payout assignments and signed transaction bytes survive restarts. If inclusion is rolled back before signing, its payout is canceled and still-valid payments return to pending. Reorgs affecting a signed payout are held for inspection rather than paid again.

RPC methods and receipt format
preconf_infoService public key, fee address, readiness, chain tippreconf_submitRaw transaction → signed receipt and statuspreconf_getTransaction ID → pending, included, or failed

The Ed25519 receipt signs the exact persisted payload containing the chain ID, transaction ID, and service fee. It does not sign the mutable inclusion status.