A shielded payment, built with the network cut and carried across Murmur:
Mined in testnet block 4,550,000 after one broadcast.
Pay and talk when the network won't.
Murmur carries a real shielded Zcash transaction and a sealed note from device to device with no internet. Whoever reconnects first broadcasts it.
Payer writes:
Paid. Two bags, pickup at 5.
A relay sees:
9F3A C71E 04B2 E8D1 5A60 B7F2
Merchant reads:
Paid. Two bags, pickup at 5.
Illustration of one sealed note. The ciphertext shown is a placeholder, not real output.
Proof, straight from the logs.
Three numbers, each traced to a file in the project's evidence folder.
The transaction crossed the carrier between two processes:
5,222 bytes in, the same SHA-256 out.
Run from the project folder with Node 18.3 or newer:
52 tests pass. One needs a funded wallet.
Why Murmur
Private money shouldn't depend on a network someone can switch off.
Murmur carries a real shielded Zcash transaction and a sealed note from device to device.
Whoever reconnects first broadcasts it, and the payment confirms on chain.
Explore Murmur
Offline build, sealed notes, spend policy and payment requests: what a payment needs to move without a network.
networkNO CONNECTION
createok
proveok
signok
combine, extractok
raw transaction, 20,986 bytes. Only this leaves the device.
Offline build
The payer's wallet creates, proves and signs a shielded transaction with no connection at all. Only the final raw transaction leaves the device, never the partly built file that can hold viewing keys.
See the offline logsender keyin the derivation
9F3A C71E 04B2 E8D1
5A60 B7F2 11C9 3D80
E2A4 6B07 9C55 F1AE
5A60 B7F2 11C9 3D80
E2A4 6B07 9C55 F1AE
Placeholder bytes. A forged sender fails to open.
Sealed notes
Notes and receipts are sealed to one recipient. The sender's key is mixed into the key derivation, so a forged sender is rejected. Verified in tests.
Try the simulationPer payment1,000,000 zat
Offline total5,000,000 zat
Recipient allowlistoptional
Over a cap, the wallet is never asked to sign.
Spend policy
Caps per payment and while offline, plus an optional recipient list. The policy bounds double-spend risk. It does not remove it.
See the limitszcash:ztestsapling1…?amount=0.00003&memo=…
Example shape. A request like this was paid on the testnet, block 4,550,881. The memo was not observed on chain.
Payment request
A merchant shares a ZIP 321 request. The payer's command reads the address, amount and memo from it, then builds the payment. One was paid on the testnet in block 4,550,881; the memo did not show up on chain.
See the commandsRun it from the command line
Real commands from the project's CLI. The carrier needs only Node; payments also need the patched zcash-devtool. Testnet only.
Pick a role. The window shows the command that role runs.
simulation
See Murmur relay
Six devices in your browser, with the packet loss you choose. It follows the same flooding, hop limit, duplicate drop and retransmit rules as the real carrier, rewritten for this page. Select a device to see what it can read.
Pay.
The payer sends the transaction and a sealed note.
Relay.
Devices forward with a hop limit and retransmit lost packets.
Confirm.
The gateway broadcasts once and the merchant opens the receipt.
Press Send payment to run.
Select a device to see what it can read.
Delivery under packet loss
Each bar is 300 simulated runs with four retransmit rounds. A run counts as delivered when the merchant received both sealed packets and the gateway broadcast exactly once.
Run it yourselfWhat the logs say
Lines copied from the project's evidence folder.
{"kind":"sent","txid":"5110a458…","bytes":5222}
Payer · evidence/04
Mined: 4550000 (2026-10-28 6:21:42)
Wallet sync · evidence/04
{"kind":"broadcast","ok":true}
Gateway · evidence/04
probe offline ok · create offline ok · prove offline ok · sign offline ok · combine offline ok · extract offline ok
Network namespace · evidence/03
Failed to sign Sapling spend 0: MissingProofGenerationKey
An early failure, fixed · signing now uses the proven file
{"kind":"receipt","amountZat":1000,"policyHash":"b94caa29…"}
Merchant, receipt opened · evidence/04
1: dns error · 2: failed to lookup address information: Temporary failure in name resolution
Inside the no-network namespace · evidence/05
{"kind":"ack","of":"receipt","from":"fdc4b11c…","sender":"fdc4b11c…"}
Acknowledgement with the sender's key · evidence/05
Proof›Run log›Zcash testnet
From a cut network to block 4,550,000
Three runs, all logged. A builds a transaction offline. B carries one across and confirms it. C pays a ZIP 321 payment request end to end.
Run A: built with the network cut
The build ran in a network namespace with no connection. A lookup of the wallet server failed there first, as required. Then every step of the transaction build succeeded.
- create
- prove
- sign
- combine
- extract
- Raw transaction20,986 bytes, unified-address recipient
- BroadcastNo. This run stops before broadcast by design.
- Log folderevidence/03-acceptance-a
Run B: across the carrier and onto the chain
A payer process built the transaction and sent it with a sealed receipt. A separate gateway process received both, broadcast the transaction once and sent back a sealed acknowledgement. Both ran on one machine over UDP loopback, so this run did not use a radio.
- Transaction id5110a458bd641e5432fb6d11892dda2c70d55979bd360b09f7e13e48a4c8fd43
- Block4,550,000 · 2026-10-28 06:21:42 UTC
- Bytes carried5,222, Sapling recipient
- Log folderevidence/04-e2e-loopback
cbc99ff1fc8dbabf0ec230ed1d1c021117b37265f7f15c75168e32241bb0b70f
SHA-256 printed by the payer and by the gateway. Identical, so the bytes crossed unchanged.Run C: a payment request, paid
The merchant made a ZIP 321 request. The payer's wallet built the payment with every devtool step inside a no-network namespace (a probe there fails with a DNS error), handed it to a gateway over loopback UDP, and the gateway broadcast it once. The acknowledgement and the receipt carry the sender's key.
- Transaction id0efad38fd3d577779817d949caa695e4391adc4329b0700b6a4b37c5b66f96d7
- Block4,550,881 · 2026-10-28 12:20:12 UTC
- Amount3,000 zat (0.00003 TAZ) to the merchant account
- Bytes carried5,222, SHA-256 ad973801… on both sides
- MemoNot observed in either wallet's view of the transaction. Not verified.
- Log folderevidence/05-zip321-e2e
Context
- Funding transactione5ecdc13b8520a7b4d0fa25664388c1bb540bb53953a07ccd758ab961993cb3d
- Funded in block4,549,978 · 1 TAZ from a public testnet faucet
- Tests52 passing, 1 skipped (needs a funded wallet)
- Sealed notesSender key mixed into the key derivation. A forged sender and old-format packets are rejected in tests.
- Payment requestZIP 321 encode and parse, and the request command, are covered by tests. Run C paid one on the testnet.
- NetworkZcash testnet only
Reproduce
The carrier has no dependencies and needs Node 18.3 or newer. From the project folder:
node --test test/*.test.js
Honesty›Limits
What is proven,
and what is not.
See the logsverified
A real shielded transaction can be built with the network cut.
evidence/03-acceptance-averified, loopback
The transaction crossed the carrier unchanged and was confirmed on the testnet.
evidence/04-e2e-loopbackverified in tests
Devices cannot open sealed notes meant for someone else. The sender's key is in the derivation, so a forged sender and old-format packets are rejected.
test/mesh.test.jsverified, loopback
A merchant shares a ZIP 321 payment request and the payer's command reads it. One was paid on the testnet and mined in block 4,550,881: built offline, handed over on loopback.
evidence/05-zip321-e2esimulation
Delivery under loss: 93% of runs at 30% loss and 72% at 40%, four retransmit rounds, 300 seeds each.
Simulation on the home pagenot verified
The memo in a payment request. It was passed to the build, but did not show up in either wallet's view of the confirmed transaction. Whether it was dropped or just not displayed is not determined.
evidence/05-zip321-e2elimit
An offline transaction expires about 50 minutes after the wallet's last sync: the default expiry is 120 blocks since NU7, at 25-second blocks. One built against a stale tip carried expiry 4,550,721 and was refused at height 4,550,785. Sync before going offline.
Observed on the testnetnot supported yet
Offline signing through the devtool's PCZT path cannot spend change notes (SaplingVerify(WrongFvkForNote)). The native send can. The real run paid from an account holding an externally received note.
evidence/05-zip321-e2e/attempt-1-change-note-sign-failurenot run yet
A laptop and a phone exchange a message over a real Wi-Fi link.
scripts/acceptance-b.mdsimulation only
Relaying through several real devices.
Only two devices were availablenot built
Bluetooth transport. It needs a native app.
Out of scopewhat it does not give
Sender authentication is not proof that a key belongs to a person, and a relay can still drop, delay or replay a genuine packet.
Threat modeldouble-spend
A payer can still spend the same notes elsewhere before broadcast. The spend policy limits the loss. Nothing here makes offline settlement trustless.
Threat modelobserver view
Anyone watching sees packet sizes, timing and neighbors, and that a shielded transaction exists. Not the payer, the recipient or the amount.
Threat model