Notes & Commitments
Understand note openings, nullifiers and the point where outputs become spendable.
What a note contains#
A note opening holds the asset, amount, ownership fields and secret randomness. The Pool records a commitment to those values. Randomness hides their contents under the protocol's hash assumptions.
To spend, the holder proves tree membership under an accepted root and derives a nullifier from secret keys. The Pool records that nullifier and rejects any later attempt to spend it again.
Types of note#
| Kind | Origin | Spending and recovery |
|---|---|---|
| Pending | A public deposit | Ordinary screened admission checks its direct source policy |
| Active | A private transfer output | The recipient decrypts delivery; full input ancestry is not certified |
| Settled | A measured external action output | Public venue execution fixes the result before note append |
Find and decrypt a note#
Ownership uses Poseidon images and hash-derived nullifiers. X-Wing combines ML-KEM-768 and X25519 to derive the shared secret used for encrypted output delivery. The recipient decrypts the opening and checks that it matches the recorded commitment.
Delivery tags reduce the notes a client has to try decrypting. They do not authenticate a note by themselves. Keep the complete receiving descriptor and recovery keys in the format the client supports.
Inputs, outputs and reserved value#
The current relation has at most two inputs and two outputs. Inputs share one asset and controller. A spend can create private change and a public payout; an approved action can return one distinct output asset.
An action receipt reserves returned value before it becomes a note. Finalization must keep reserve and note accounting consistent. The account can spend the output only after its note is appended and recovered.
Roots and tree capacity#
The permanent-core candidate keeps completed known roots. Later appends therefore do not evict an old unspent note's membership root. The spend must still pass nullifier and current execution checks.
The tree has finite cumulative leaf capacity. Spent leaves do not free slots. New private outputs need space, while ordinary zero-output exits have their own liveness rules.