# Compliance Pools Source: https://docs.yona.cash/concepts/compliance Admin keys, approved addresses, per-pool trees, and user-signed transactions Compliance pools are Yona pools that enforce access control and auditability while keeping the same privacy guarantees. Each compliant pool has its own configuration, approved-address list, and state. **Inside, it’s full Yona** — same protocol, same cryptography, same UX benefits. Compliance only adds access control and auditability on top; it does not replace or weaken the core. *** ## 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](#user-signs-every-transaction); 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](./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 receives `sender` 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](./technical) and [Relayer](./relayer). # Fees Source: https://docs.yona.cash/concepts/fees Understanding Yona's fee structure and slippage handling ## Important Note on Fee Structure **Yona protocol itself does not charge or collect any fees.** All withdrawal and swap fees go directly to independent relayer operators, not to the protocol. ## Nullifiers Each private transaction requires 2 nullifiers to prevent double-spending. **Nullifiers are rent-free** thanks to [Light Protocol's ZK Compression](https://www.zkcompression.com/). Unlike traditional Solana accounts that require rent-exempt balances, compressed accounts store state as call data on Solana's ledger without per-account rent costs. This means: * No 0.0019 SOL nullifier initialization cost per transaction * No accumulating rent costs for nullifier storage * Nullification happens through compressed state queues processed by Forester nodes ## Deposit Fees **0%** of the deposited amount. No additional costs. ## Withdrawal Fees **0.3%** of the withdrawn amount goes to the relayer. ## Swap Fees The relayer charges **0% - 0.3%** fees on swaps. When you perform a private swap through our protocol, the relayer doesn't take a percentage of your input amount, but takes the difference between minimum amount out and actual output. ### Slippage Mechanism However, due to the technical constraints of fully private swaps in the UTXO model, we implement a unique slippage handling mechanism: #### How It Works When you execute a swap with a **0.3% slippage tolerance**, here's what happens: 1. **You receive the minimum amount out** - Your transaction is guaranteed to complete, and you'll receive at least the minimum output amount based on the slippage tolerance 2. **Relayer takes the remaining tokens** - Any difference between the actual swap output and the minimum amount goes to the relayer 3. **Relayer absorbs the slippage risk** - By taking the remaining tokens, the relayer assumes all slippage risks #### Why This Design? This mechanism is **necessary for UTXO-based privacy**. In a UTXO system with zero-knowledge proofs, it's technically impossible to create a fully private swap where the exact output amount is unknown at proof generation time. The alternative approaches would either: * Reveal transaction information, breaking privacy * Require trusted parties or complex multi-round interactions * Make swaps impossible in certain market conditions By guaranteeing you the minimum amount and absorbing the difference, we enable truly private swaps while maintaining the security guarantees of the UTXO model. #### Example If you swap 100 SOL for USDC with 0.3% slippage: * Expected output: 10,000 USDC * Minimum guaranteed: 9,970 USDC (0.3% slippage) * Actual output: 9,985 USDC * **You receive**: 9,970 USDC * **Relayer receives**: 15 USDC (the slippage buffer) In market conditions where slippage works in your favor, the relayer captures that upside. In conditions where slippage exceeds the tolerance, the relayer absorbs those losses. This design ensures your swaps are always private, predictable, and complete without revealing any transaction details on-chain. # Relayer Service Source: https://docs.yona.cash/concepts/relayer Optional service for gasless transactions and enhanced privacy > The relayer is **not part of the core Yona protocol**. It is an *optional external service* designed to boost privacy. The relayer network is fully permissionless - anyone can run a relayer to process transactions and earn fees. The protocol facilitates matching between users and competing independent relayers, remaining neutral and non-custodial. ## Overview A relayer is an intermediary service that: * Submits transactions on behalf of users * Pays transaction fees and nullifier costs in SOL * Collects a service fee (see [Fees](./fees)) * Enhances privacy by decoupling submission from wallet address This is particularly useful for users who want to withdraw or swap funds without first acquiring SOL or revealing their withdrawal address. Check out [relayer](https://github.com/Yona-Labs/yona-privacy-app/tree/main/indexer) repository for more details. *** ## How It Works ### Transaction Flow ``` User generates ZK proof using frontend and secret message(can do it locally) ↓ User sends proof + withdrawal details to relayer ↓ Relayer validates proof structure ↓ Relayer submits transaction to blockchain ↓ Relayer pays gas fees in SOL for the transaction and nullifier costs ↓ User receives funds minus relayer fee ``` ### Privacy Benefits * **No SOL Required:** Withdraw without pre-funding an address * **Address Unlinking:** Relayer's address submits the transaction, not yours *** ## Relayer Limitations The relayer **cannot**: * Steal your funds (proof is cryptographically bound to the transaction data) * Modify transaction data (proof validates exact data) * Link deposits to withdrawals (zero-knowledge property) * Access your private keys or UTXOs He only can **reject** the transaction if its economically unfeasible to process it. See [Public Inputs & Data Integrity](./technical#public-inputs--data-integrity) for more details. # Technical Architecture Source: https://docs.yona.cash/concepts/technical Deep dive into Yona protocol architecture, smart contract design, and key technical features Yona implements a **UTXO-based privacy model** with **Groth16 zk-SNARKs** on Solana, providing strong anonymity guarantees while maintaining full on-chain verifiability. Program uses a modified version of the Tornado Nova circom circuits, adapted for Solana's architecture. A modified version of the circom is used to create a dual-token circuit. The circom schemes are currently undergoing a security audit, and we will publish details soon. **Program:** [`yonaMBw7KLYvQSspboB2GGAt5EsQqV28dZZasKhKGqC`](https://orb.helius.dev/account/yonaMBw7KLYvQSspboB2GGAt5EsQqV28dZZasKhKGqC) Code for the program is open source and available [here](https://github.com/Yona-Labs/yona-privacy-app/tree/main/program/programs/zert). *** ## UTXO Model Yona uses a **Unspent Transaction Output** model similar to Bitcoin/Zcash: ### Structure ```typescript theme={null} interface UTXO { amount: bigint; // Token amount mintAddress: string; // SPL token mint blinding: bigint; // Random value for privacy publicKey: bigint; // Owner's public key (BN254 curve) } Commitment = Hash(amount, mintAddress, blinding, publicKey) Nullifier = Hash(commitment, privateKey, merkleProofPathIndex) ``` #### Privacy Properties * **Hiding:** Commitments reveal nothing about contents * **Binding:** Cannot change UTXO after commitment * **Unlinkability:** Cannot link commitments to nullifiers without private key #### Transaction Logic Every instruction consumes **2 input UTXOs** and creates **2 output UTXOs**: *** ## Public Inputs & Data Integrity All transaction data is cryptographically bound to the zero-knowledge proof through **10 public inputs**. This means no transaction data can be modified without invalidating the proof: ### Public Inputs to Proof Verification ```typescript theme={null} publicInputs = [ root, // Merkle tree root publicAmount0, // Token A amount (deposit/withdraw) publicAmount1, // Token B amount (for swaps) extDataHash, // Hash of external data mintAddressA, // SPL token mint A mintAddressB, // SPL token mint B inputNullifier[0], // First spent UTXO nullifier inputNullifier[1], // Second spent UTXO nullifier outputCommitment[0], // First new UTXO commitment outputCommitment[1] // Second new UTXO commitment ] ``` ### External Data Hash The `extDataHash` itself is computed from additional transaction parameters: ```typescript theme={null} extDataHash = Hash( recipient, // Withdrawal address extAmount, // External amount encryptedOutput, // Encrypted UTXO data fee, // Relayer fee feeRecipient, // Fee collector address mintAddressA, // Token mint A mintAddressB // Token mint B ) ``` **Security Guarantee:** Since all this data is part of the proof's public inputs, any attempt to modify transaction parameters (amounts, recipients, fees, nullifiers, commitments) will cause proof verification to fail. This ensures complete data integrity without revealing private information. ## Program Components The Yona program serves as the core verification system that stores all private transaction data and validates zero-knowledge proofs. It maintains the complete state of the privacy pool, including all commitments and nullifiers, while ensuring that only valid proofs can modify this state. ### Merkle Tree State * **Height:** 26 levels * **Capacity:** 67 million commitments * **Structure:** Sparse binary tree with Poseidon hashing * **Purpose:** Stores cryptographic commitments of all UTXOs without revealing amounts or owners ### Nullifier Registry * **Function:** Prevents double-spending using [Light Protocol's ZK Compression](https://www.zkcompression.com/) * **Mechanism:** Each spent UTXO generates a unique nullifier stored as compressed state * **Rent-Free:** Nullifiers are stored without rent-exempt balance requirements thanks to ZK compression ### Proof Verification System * **Provider:** Light Protocol's Groth16 verifier * **Curve:** BN254 elliptic curve * **Proof Size:** 256 bytes (compressed) ## Private UTXO Storage Yona stores all private UTXOs in on-chain events with highly optimized compression. This approach allows efficient retrieval through the indexer while minimizing on-chain storage costs. The protocol achieves exceptional efficiency through multiple compression techniques: #### Commitments Compression We store encrypted Commitments in on-chain events using highly optimized serialization: * **Minimal Serialization:** Data is compressed to the smallest possible size using custom binary packing * **Dual UTXO Optimization:** Two UTXOs are packed into a single on-chain record, reducing storage costs by 50% * **Partial Mint Storage** **Result:** Each commitment entry uses only \~100 bytes instead of traditional 200+ bytes #### Data Retrieval Private UTXO data is stored in Solana events and can be efficiently retrieved through the Yona indexer. The indexer monitors on-chain events, decrypts relevant UTXOs for users, and provides fast access to transaction history without requiring full chain scanning. If needed, you can send transactions directly through the local frontend with any custom `encryptedOutput` format that suits your requirements. *** ## Audit Status Protocol is **experimental** and under active development. No formal audit completed yet. Use with caution. # FAQ Source: https://docs.yona.cash/faq Frequently Asked Questions about Yona Privacy Protocol ## General Questions Yona is a non-custodial protocol, meaning you always control your funds through your wallet. The protocol uses audited Groth16 zkSNARKs cryptography and is open source for public verification. However, like any DeFi protocol, you should: * Keep your wallet private key AND [signature](/faq#what-is-a-wallet-signature-and-why-is-it-critical) secure * Understand that smart contract risks exist in any blockchain protocol Yona is not a traditional mixer - it's a permissionless privacy layer: * Uses zero-knowledge cryptography instead of mixing pools * You can make multiple transactions from one deposit without losing privacy * Supports swaps directly in the privacy pool * More secure against timing analysis attacks * Integrated with DeFi (Jupiter) for real utility **Fully permissionless**: * Anyone can run their own relayer and earn fees * Anyone can implement custom signature schemes * Yona only provides the privacy layer infrastructure * No central control over who can participate It's a complete privacy layer for DeFi, not just a mixing service. Your wallet signature is the encryption key that protects your funds in Yona: **How it works**: 1. When you first connect, you sign an authentication message with your wallet: ``` Sign this message to authenticate with Yona Wallet: ``` 2. This key is used to encrypt/decrypt your UTXO data on-chain 3. The signature is stored in your browser's localStorage **Security warning**: * **NEVER** sign this authentication message on other websites or untrusted applications * Without this signature, you **cannot** decrypt your funds permanently * Only sign messages starting with "Sign this message to authenticate with Yona" on the official Yona website * Signing the same message on phishing sites gives attackers the ability to decrypt your funds Your "private note" is actually encrypted UTXO data stored on-chain. When you deposit: 1. Yona creates encrypted outputs containing your balance information 2. These encrypted outputs are stored publicly on Solana blockchain 3. Only **YOUR** wallet can decrypt them using a signature you create when connecting 4. The decryption key is derived from your wallet's signature No. When you use Yona: * Your deposits are mixed with other users' deposits in the privacy pool * Withdrawals and swaps cannot be linked back to your original deposit * External observers can see that *a* transaction happened, but not *who* initiated it * Even if someone knows you deposited 100 USDC, they cannot track where those specific tokens went If your balance is not showing in the app, don't panic - your funds are safe on-chain. Balance display issues are very rare and usually caused by: * Nullifier synchronization errors * Abrupt page refresh during UTXO decoding * Browser cache corruption * LocalStorage data conflicts **Solution**: 1. Go to the Portfolio section on the website 2. Click the "Refresh" button 3. This will reload all your on-chain UTXOs directly from the blockchain 4. Your balance will be restored once the sync completes The refresh process re-fetches and decodes all your encrypted UTXOs from the Solana blockchain, ensuring your actual on-chain balance is correctly displayed. The transaction flow is identical to a regular Solana transaction, with one additional step: zero-knowledge proof generation on the frontend. It takes 15-25 seconds for Mac M2 devices. Note: Withdrawals and swaps use an asynchronous job queue system. During high network activity or relayer congestion, times may be longer. Yona supports: * **Native SOL** (automatically wrapped to WSOL) * **All SPL tokens** including USDC, USDT, and other standard tokens * **Any token pair** available on Jupiter for swaps Technically, any SPL token is supported on-chain through direct contract calls without admin approval. If a token isn't listed in the interface, it simply means we haven't added it to the frontend/relayer yet due to lack of demand. **Adding new token pools**: Pools can be added upon request, but pool creation makes sense only with a minimum initial deposit to ensure sufficient liquidity and cover protocol initialization costs. ## Usage Questions There's technically no minimum, but, very small deposits may be uneconomical due to fees Check current fee [Fees](/concepts/fees) structures in the app before depositing. **Partially, but not directly**. Here's how UTXOs work in Yona: * Each transaction (deposit, swap, withdraw) creates 2 UTXOs: one with your balance, one empty (for circuit constraints) * You can make multiple transactions from your total balance * Each transaction spends up to 2 existing UTXOs and creates 2 new ones * If you withdraw part of your balance, the remainder becomes a new UTXO (change) **Example**: * Deposit 100 USDC → Creates 1 UTXO with 100 USDC * Withdraw 40 USDC → Spends the 100 USDC UTXO, creates new 60 USDC change UTXO * Withdraw 30 USDC → Spends the 60 USDC UTXO, creates new 30 USDC change UTXO So yes, you can make multiple withdrawals from one deposit by spending the change UTXOs. Yes! This is a core privacy feature: * Deposit from Address A * Withdraw to Address B (or C, D, E...) * No on-chain connection between the two addresses This breaks the transaction graph and protects your privacy. If a transaction fails: * Your funds remain safe as encrypted UTXOs on-chain * Your existing UTXOs are not consumed * No nullifiers are created, so UTXOs remain spendable * Check the error message for details * You can retry the transaction * Contact support if the issue persists Common reasons for failures: * Insufficient UTXO balance for amount + fees * Network congestion * Invalid withdrawal address * Relayer issues (for withdrawals/swaps) * Stale Merkle root (outdated UTXO cache) ## Advanced Questions Currently, Yona operates with a single relayer during the initial launch phase, but this is temporary: **Current status**: * One official relayer operated by the Yona team * Ensures smooth user experience during early adoption * Allows us to monitor and optimize the system **Decentralization coming soon**: * **Anyone can become a relayer** after our security audit is complete * Relayers earn fees for processing transactions (incentivized participation) * Multiple relayers will increase decentralization and resilience **Security by design**: * Relayers work with cryptographic proof verification * They **cannot** steal funds or access your private data * They only submit verified zero-knowledge proofs to the blockchain * Even a malicious relayer cannot compromise user funds **After audit completion**: * We will publish open-source relayer implementation code * Detailed setup documentation and guides * Public relayer registry for users to choose from * Economic incentives for running reliable relayer nodes This approach ensures security first, then progressive decentralization. Yona uses Jupiter's aggregator for swaps: * Your swap happens inside the privacy pool * Jupiter finds the best route across DEXs * The swap is executed atomically * External observers see a Jupiter swap, but not who initiated it This combines DeFi liquidity with privacy protection. ## Troubleshooting Steps to resolve: 1. Check Solana network status (is there congestion?) 2. Verify your wallet has SOL for fees 3. Wait 1-2 minutes and refresh the page 4. Try clearing browser cache 5. Contact support on [Discord](https://discord.gg/yonaprivacy) with transaction details Your funds are safe even if the interface appears stuck. Common causes: * **Important**: Trying to spend more than a single note contains * **Balance is incorrect**, see [My balance disappeared](/faq#my-balance-disappeared-what-should-i-do) for refresh instructions * Not accounting for relayer fees and network fees * Cache/sync issues with the interface For support: * **Discord**: [Join our community](https://discord.gg/yonaprivacy) * **Twitter**: [@YonaPrivacy](https://x.com/YonaPrivacy) When reporting issues, include: * What you were trying to do * Error messages (if any) * Transaction signature (if applicable) * Job ID (for relayer transactions from console logs) * **Never** share your wallet private key or signature ## Still Have Questions? Can't find what you're looking for? Get help from the community and team Get the latest updates and announcements # What is Yona? Source: https://docs.yona.cash/index We enable private trustless DeFi on Solana. Yona is a privacy protocol on Solana that lets you shield SOL and any SPL token into our privacy pool and trade any pair privately on Jupiter. Any action done through our protocol is fully untraceable by any external observer. They will see that the Jupiter swap happened, but they will not know who executed the trade. Using zero-knowledge proofs, you can prove a transaction is valid without exposing amounts or participants. It only relies on ZK cryptography, no trusted parties, no questionable TEEs. ## How It Works Send tokens to the protocol and receive a private note. This note represents your balance but doesn't reveal any information on-chain. Use your notes to transact privately. The protocol verifies you have the funds without revealing which deposit you're spending from. Withdraw to any address or swap to different tokens. The recipient can't trace back to your original deposit. ## Supported Tokens Automatic WSOL wrapping/unwrapping USDC, USDT, and any standard token Powered by Jupiter Aggregator ## Security & Trust * **Non-custodial**: You always control your funds * **Audited Cryptography**: Uses industry-standard Groth16 zkSNARKs * **Open Source**: All code is publicly verifiable Dive deeper into how Yona protects your privacy # $YONA Tokenomics Source: https://docs.yona.cash/token Tokenomics and vesting schedule for the YONA token YONA Token ## Fair Launch \$YONA is launched with a **fair launch model** on [Surge](https://app.surge.xyz/trade/GF8ysB8rF9WjhrK5uVhRReubJtWpPzbztB7gVfAgsurg). Initial dev buy is 70% of the total token supply, that is distributed to the community, ecosystem, core contributors, foundation, and early investors. Community Incentives, Ecosystem, Core Contributors, Foundation, and Investors - all with vesting schedules aligned for long-term growth. Fully in the market from day one. Accessible entry for all participants. ## Token Allocation | Allocation | % | \$YONA | TGE Unlock | Cliff (M) | Vesting (M) | | ------------------------- | ------ | ----------- | ---------- | --------- | ----------- | | **Liquidity Pool** | 30.00% | 300,000,000 | 100% | 0 | 0 | | **Community Incentives** | 25.00% | 250,000,000 | 10% | 0 | 48 | | **Ecosystem** | 25.00% | 250,000,000 | 10% | 0 | 24 | | **Core Contributors** | 10.00% | 100,000,000 | 0% | 12 | 36 | | **Liquidity & Exchanges** | 5.00% | 50,000,000 | 100% | 0 | 0 | | **Foundation Treasury** | 2.85% | 28,500,000 | 0% | 6 | 24 | | **Investors** | 2.15% | 21,500,000 | 3% | 3 | 24 | CA: **GF8ysB8rF9WjhrK5uVhRReubJtWpPzbztB7gVfAgsurg** Vesting dashboard on Streamflow: [https://app.streamflow.finance/contract/solana/mainnet/747m2J8kvQFyziU7iNoRaZPZYFY6GMtb8W6cSt3UxkkL](https://app.streamflow.finance/contract/solana/mainnet/747m2J8kvQFyziU7iNoRaZPZYFY6GMtb8W6cSt3UxkkL)