> For the complete documentation index, see [llms.txt](https://vayyl.gitbook.io/vayyl-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vayyl.gitbook.io/vayyl-docs/architecture/notes.md). # Notes, Commitments and Nullifiers ## Notes A note is a private claim to value. A production note format needs at least: ``` asset identifier value recipient spend key or diversified address randomness application domain version ``` Version and domain separation prevent a commitment valid in one context from being replayed as a different asset or application state. ## Commitments The wallet hashes the note into a commitment using the circuit's canonical Poseidon2 encoding. Contracts append commitments to a Merkle tree and retain accepted roots for a bounded period. The proof demonstrates membership in an accepted root without revealing the leaf position. The root history must be long enough for normal wallet synchronization while bounded enough to keep contract state manageable. ## Nullifiers A nullifier is deterministically derived from a spend-authorizing secret and note context. Revealing it does not reveal the note, but revealing it twice identifies a double-spend attempt. The pool stores used nullifiers permanently or for as long as the corresponding value can remain spendable. ## Output encryption Commitments alone do not tell a recipient which note belongs to them. Each output therefore needs an encrypted payload that the recipient can attempt to decrypt. The commitment, ciphertext, asset domain, and recipient key agreement must be bound consistently so a relayer cannot substitute an unreadable output. ## Circuit and contract parity Field encoding, endianness, hash parameters, point serialization, public-input order, and domain constants are consensus-critical at the application layer. Reproducible cross-language vectors are required before a production release. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://vayyl.gitbook.io/vayyl-docs/architecture/notes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.