Notes and ownership
A note binds its value, asset, application domain, and ownership material. Its public commitment hides those fields while allowing the protocol to verify that they have not changed. Ownership is tied to a private-address key, not to the Stellar account that submits the transaction. This allows a relayer to submit on behalf of the owner without acquiring the ability to spend the note. A payment that spends a note larger than the requested amount creates a recipient output and a change output. The input note cannot be spent again.Public state
Membership and double-spend prevention are different checks. A proof establishes that an input belongs to the stated tree. Settlement checks that the root is accepted and that the input’s nullifier has not already been consumed.
Shared pools and application domains
Within a shared pool, participating applications use common commitment state, nullifiers, and asset custody. Application separation is represented inside notes rather than by a separate pool for every application. An application domain identifies the policy and audit context for a note. Its identifier is bound into the note commitment. It is not simply a routing label that an application can change after the note is created.
Sharing pool state does not give one application access to another application’s audit keys. Nor does an application ID give the application ownership of its users’ notes.