Main site

Deposits

How liquidity enters a reserve and stops being anyone's.

A deposit is the only moment money crosses into the protocol. It's also the moment it stops being attributable to anyone, so everything the rest of the docs promise starts here.

What happens

You supply assets to a reserve. The reserve gets bigger. No record is created saying you hold a particular amount, because the protocol has no such record type. As far as everything downstream is concerned, the reserve is simply deeper than it was a moment ago.

Depositing isn't the same as holding a position

Worth saying plainly, because it's the thing people assume: supplying a reserve is not the same as having a balance in it. There's no per-depositor claim recorded inside the protocol, and that's exactly what keeps the reserve unattributed.

Supply side who supplied the reserve, and what they are owed tracked somewhere, because it has to be Spending side rights granted, proofs checked, reserve pays knows nothing about who supplied what never joined

The line that has to hold. Any reserve that rewards its suppliers must track supply somewhere, so that record exists. What matters is that it is never joined to spending: a depositor's record says nothing about who spent what, and a spender has no relationship with the supply side at all.

Not decided yet, and this is the big one. How depositors get paid, and how a supplied position is tracked and redeemed. That has to be recorded somewhere, and it necessarily sits outside the unattributed reserve. Exactly where that line falls is the most important thing missing from this page. See The NULL token for the rewards side.

Why that line matters so much

Any system that reserves money and rewards the people who supplied it has to track supply somewhere. The question isn't whether that tracking exists. It obviously does. The question is whether it's connected to spending.

NULL's answer is that it isn't. Supply accounting and spending are kept apart: a depositor's relationship with the protocol tells you nothing about who spent what, and someone spending has no relationship with the supply side at all. Keeping those two separate is what makes the rest of this work.

Chains and assets

Reserves run on EVM chains. Which chains are live, and whether reserves are per-chain or bridged, is a deployment question rather than something baked into the design.

Not decided yet. Supported chains, supported assets, minimum deposits, and contract addresses.