Deposits

A deposit turns an ordinary bitcoin coin into a note in the pool. The rule the design holds to: nobody holds your coin on the way in.

How it works

1. Your wallet proves a deposit. It is a contribution with no input notes and one new note for the deposit amount. Its record carries the amount in the data word. The note’s secrets come from your seed and a counter, so you can find it again from the seed alone. The deposit pays its fee out of its own value, inside the proof.
2. You fund a deposit coin. This is a taproot output paid from any Bitcoin wallet (the iOS app can fund it from its own coins, or show an address an exchange can pay). It has two ways to be spent:
   • a merge path that lets anyone move it into a deposit group, but only into one whose catalog lists your exact record and your refund terms;
   • a refund path that lets you, with a key from your seed, take it back at any time before it is picked up.
3. A node merges waiting deposit coins into a group. Merging publishes a catalog of the entries: each one’s funding coin, its 92-byte record, and its refund terms. The group is then converted into the deposit inbox, one coin that pays to the pool’s address.
4. The next settlement spends the inbox. The pool’s leaf checks that the deposit records it publishes are exactly the inbox’s, in one block, and adds the deposit total to V' = V + deposits − ….

 your coin ──▶ deposit coin ──merge──▶ group ──convert──▶ deposit inbox ──▶ settlement
                    │                    │                                   (your note)
                    └─ cancel (you,      └─ whole-group return to every owner,
                       any time before      after about 2 hours if not settled
                       pickup)

Getting your coin back

• Before pickup, you can cancel at once with your refund key. Nobody else can.
• Once in a group, there is no single refund. If the group is not settled in time, the whole group is returned: one transaction pays every entry’s exact amount back to its owner’s refund address. It becomes valid at a deadline carried from the first merge: the merge’s block height plus 12 blocks on a 10-minute chain, about two hours (on gsr-net’s 30-second blocks, 240 blocks). Re-merging and converting cannot restart that clock. A service input, not your coin, pays that transaction’s miner fee.

Merging is a public service any node may run, paid from its own wallet. A node only builds a group once it has checked that the batch can be planned and proved in time. A finite window is still not a guarantee: if proving or confirmation fails, the group comes back whole.

Cost

A deposit costs its record in the settlement (29 vB), a share of the inbox’s input in the settlement (about 370 vB per inbox, shared by every deposit in it), and its share of the merge transactions outside the settlement. A group holds up to 32 deposits in today’s software (the scripts allow up to 250).

What is visible

A deposit is visible as a deposit: its amount is in the record, and its funding coin is on chain. What is not visible is which later payments spend it. This is the same boundary Zcash has between its transparent and shielded pools. The wallet makes each deposit one standard “chip” by default (1-2-5 from 1,000 sat to 1 BTC), so amounts repeat across users. Privacy says what is left.

Why lineage matters here

The inbox pays to the pool’s address. So every pool leaf checks that the coin it spends descends from the pool’s genesis transaction. Without that, a fake “pool coin” at the same address could take an inbox meant for the real pool.

Status

The deposit inbox has run with real proofs (four deposits in one settlement, 2026-10-29, and again on 2026-11-04). The catalog group format, with cancel-before-pickup and whole-group returns, ran with real proofs on 2026-10-30. A drain that also carries the deposit inbox ran with stand-in verifiers only (2026-11-07).