Admin and Pool Configuration
Each compliant pool is operated with admin state that control:- Approved addresses — only wallets on the approved list can shield (deposit) into that pool. Withdrawals and other actions may also be gated by the same list, this list can be onchain or offchain.
- Pool-specific parameters — fee recipient, relayer configuration, and which indexer/tree the pool uses.
- One tree per compliant pool — the indexer and relayer for a pool maintain a single Merkle tree for that pool’s commitments.
All Transactions Through the Relayer
User proves and signs; relayer submits to the chain and pays fees (deposits, withdrawals, swaps). The relayer cannot change or steal anything — inside it’s the same ZK Yona: proofs bind all data, and only the user’s keys can spend their UTXOs. The relayer can refuse to submit (e.g. if not on the approved list or policy fails). See Relayer for the base relayer model.Events and Dual Encoding (User + Admin)
On-chain output events (encrypted UTXOs from deposits, withdrawals, swaps) carry a single encrypted payload that is encoded for both the user and the admin. Format: one blob per output event, e.g.[user_encrypted 72 bytes][ephemeral 32 bytes][admin_encrypted 72 bytes]. The user’s client uses only the first 72 bytes to decrypt and display balance; the admin uses the ephemeral key and the last 72 bytes with their key.
This is needed e.g. for UTXO consolidation: on-chain nothing is visible in the clear; one blob lets both user and admin decrypt with their own keys.
User Signs Every Transaction
For compliance, the user signs a canonical message that uniquely encodes the request. The wallet produces an Ed25519 signature; the relayer receivessender and senderSignature, verifies the signature, and stores both for audit. The program does not verify this signature; validity is from the ZK proof only.
So each transaction is explicitly authorized by the user via this off-chain signature.
For technical details on proofs and data binding, see Technical Architecture and Relayer.