# Xochi -- Full Protocol Documentation > Concatenated whitepaper, appendix, and one-pager. Generated at build time. > For the slim summary, see /llms.txt. For the OpenAPI spec, see /openapi.yaml. Generated: 2026-08-16 --- # One-Pager # Xochi: Somos axolotls. > Soft-bodied, observable. > Spawn point shouldn't determine whether you get privacy. > Named for Lake Xochimilco, because the water doesn't care who's swimming. ## The Agentic Dark Pool on Ethereum Privacy in crypto today forces a bad choice: full transparency (Uniswap, CoW) or full privacy (Tornado Cash, now sanctioned). Dubai banned all anonymity-enhancing tools in January 2026, but the ban's definition excludes assets with "mitigating technologies" for traceability. _[ERC-8262](https://ethereum-magicians.org/t/erc-8262-zero-knowledge-compliance-oracle/28543) "Xochi's ZK Compliance Oracle" is that technology: zero-knowledge proofs that verify compliance without revealing transaction data._ Cryptographic compliance. The regulator verifies a proof. **They never see the trade.** --- ## What Xochi Does You sign an intent, solvers compete to fill it (~2s typical, <6s P95). A ZK proof validates compliance without revealing the trade. Privacy is free by default. Better rates and deeper privacy unlock through attestation-based tiered trust scoring. Large trades split into independent sub-settlements, each with its own proof, routable across public, stealth, or shielded venues. AES-256 and SHA-256, used throughout the stack, are already quantum-resistant. Xochi's ZK Compliance Oracle circuits can migrate from SNARKs to hash-based STARKs when needed. > ZK Compliance: Link credentials to unlock better rates and deeper privacy. > Settlement: Public wallet, L1 stealth (ERC-5564 + gasless ERC-4337 claim), or L2 shielded via [pxe-bridge](https://github.com/xochi-fi/pxe-bridge). pxe-bridge embeds an Aztec PXE (Private eXecution Environment) that runs private transaction logic locally, generates a ZK proof, and submits it to the Aztec network. The network verifies the proof without ever seeing the trade inputs. > **Xochi ID (XID):** Onboard with a WebAuthn passkey (biometric), no wallet required. No username stored server-side. Credentials encrypted in KV with AES-256-GCM. Login is biometric only via discoverable credentials. Wallet connection is optional. Wallet-only users get Standard tier (0.22% on stablecoins, public settlement). XID holders earn trust via attestations for lower fees and deeper privacy. The server never learns which XID controls which wallet. WebAuthn's algorithm agility provides a migration path to post-quantum credential types. **Agents transact as Guests (anonymous, x402 pay-per-call) or under a Member's Mandate (per-request EIP-712 envelope, inherits the Member's tier).** See [whitepaper Section 3](./whitepaper.md#xid-pseudonymous-identity). --- ## The Problem Nothing on-chain is both private and compliant. Privacy tools got sanctioned. Dark pools offer no regulatory path. Since The Merge, \$1.1B+ has been extracted via MEV (Maximal Extractable Value) per ESMA's July 2025 risk analysis. Bots see your pending transaction and trade ahead of it (frontrunning) or sandwich it, buying before and selling after your trade to pocket the price difference. A protocol treasury rotating from USDC to EURC signals the move to every bot on Base. Bigger trades bleed more. ## How We Solve It The Xochi ZK Compliance Oracle is designed to generate cryptographic proofs that a trade is AML (Anti-Money Laundering) and sanctions-compliant without revealing the trade itself. It is not live yet (testnet Q2 2026, mainnet Q3). Tokens settle into stealth smart accounts: one-time receiving addresses that can't be linked back to you (ERC-5564), deployed as smart contract wallets (ERC-4337) that the recipient claims without needing ETH for gas. You sign what you want, solvers compete to fill it. Nothing hits the mempool (the public queue of pending transactions). --- ## Where Xochi Sits The privacy stack has layers. Xochi is the execution layer; the others sit elsewhere. **Wallet / deposit privacy (Railgun, Panther):** Hide your wallet, but swaps still happen on Uniswap in public. MEV bots see the swap. Compliance means handing over view keys. That's delayed transparency, not privacy. **Deposit set membership (Privacy Pools by 0xbow):** Prove your deposit isn't in a sanctioned set. Necessary but not sufficient. Doesn't cover jurisdiction-specific risk thresholds or anti-structuring. Composes with Xochi: clean withdrawal, then private execution. **Privacy L1s (Secret, Penumbra):** Full privacy on a separate chain. Bridge in, trade, bridge out. No compliance path. **Privacy-native chains (Monero, Zcash, Litecoin MWEB):** Stronger transaction privacy, no smart contracts, no ERC-20s, no compliance path. Different tradeoff: maximum opacity at the cost of operating outside regulated financial rails entirely. Xochi solves privacy where the assets already are. **Kohaku (Ethereum Foundation wallet SDK):** Stealth addresses, per-dapp accounts, optional reveal for audits. Wallet-layer only. Once you trade, privacy ends. Complementary to Xochi: Kohaku is the wallet, Xochi is the DEX. A Kohaku stealth address can receive a Xochi stealth or shielded settlement directly. GitHub: [ethereum/kohaku](https://github.com/ethereum/kohaku). **Xochi (execution venue):** Hides the swap itself, settles on Ethereum. Nine ZK proof types cover what regulators actually need. "Not in the bad set" is necessary but not sufficient. Xochi proves the full claim. Formalized as [ERC-8262](https://ethereum-magicians.org/t/erc-8262-zero-knowledge-compliance-oracle/28543) (Draft). --- ## How It Works Riddler is our solver, the entity that sources liquidity and executes trades. It pulls from its own inventory, centralized exchange books, decentralized exchange pools, and flash loans (uncollateralized loans repaid within a single transaction). Orders beyond available liquidity are rejected, not partially filled. Own API surface, own fee tiers, own settlement targets. External solvers can join without gatekeeping: solvers compete in a sealed-bid auction for the best output, Riddler posts a reserve bid so your quote is a guaranteed floor, and it backstops any winner that defaults. Settlement is designed to be non-custodial: origin funds sit in an on-chain escrow, released only against a proven fill or refunded permissionlessly, so the venue never holds your principal. Every non-Open, non-Public swap is cash-positive. Revenue model in [whitepaper Section 7](./whitepaper.md#7-economic-model). [Mana](https://github.com/axol-io/mana) is our Elixir Ethereum execution client (Apache 2.0 + MIT), a direct contribution to client diversity. The BEAM runtime provides fault isolation, hot code upgrades, and preemptive scheduling that no other execution client offers. Elixir fails differently from Rust, which is the point of client diversity. Hot code upgrades also enable signature scheme swaps without validator downtime, a practical path to post-quantum readiness. ## Target Market - **Protocol treasuries** rotating reserves without signaling - **DAO treasuries** needing private FX (USDC/EURC) for contributor payroll - **Crypto funds** executing size without moving markets - **Retail** wanting basic privacy for free - **AI agents** transacting as Guests (anonymous, pay-per-call) or under a Mandate from a Member (inherit the Member's tier and privacy). Routes via [Raxol](https://github.com/DROOdotFOO/raxol/tree/master) (MIT-licensed, supports x402 HTTP payments and multi-path payment routing) --- ## Status & Roadmap Pre-launch: infrastructure live, collecting early access wallets, recapitalizing solver. Riddler live on six chains (Ethereum, Optimism, Base, Arbitrum, Polygon, Robinhood Chain for USDG/Paxos). <6s P95, ~2.1s typical. Aztec sequencer node (Alpha Network) and [pxe-bridge](https://github.com/xochi-fi/pxe-bridge) deployed for shielded settlement. Aztec is experimental alpha software; v5 with security fixes targets July 2026. All infrastructure on bare-metal we own. Solver capitalization and order filling Q2 2026. Flash loan fills and advanced order types (TWAP for time-sliced execution, iceberg for hidden large orders) on roadmap. Xochi's ZK Compliance Oracle testnet Q2 2026, mainnet Q3. FX pairs (EURC, GYEN) Q4. --- ## Team | Name | Role | Background | | ---- | ------------------- | -------------------------------------- | | DROO | Protocol Director | Lido, Blockdaemon, General Dynamics | | Bloo | Protocol Specialist | DOJ Financial Intel, FBI AML, Pentagon | Full backgrounds in [whitepaper](./whitepaper.md#12-team). --- ## Links - **Website**: [xochi.fi](https://xochi.fi) - **Whitepaper**: [xochi.fi/whitepaper](./whitepaper.md) - **Technical Appendix**: [xochi.fi/appendix](./appendix.md) - **RAXOL token**: [Virtuals](https://app.virtuals.io/virtuals/95590) (live on Robinhood Chain, contract `0xf44702b17d9abD53815F703e772F35E9c71A53af`) --- _Xochi's ZK Compliance Oracle is novel. Regulatory acceptance is not guaranteed. This is the test case._ --- # Whitepaper # Xochi: Somos axolotls **The Agentic Dark Pool: Private Execution on Ethereum** Version 3.1 | August 2026 > For technical details, API specs, and fee tables, see the [technical appendix](./appendix.md). > _Xochi is built by friendly axolotls at axol.io_ > > **Support us on [Giveth](https://giveth.io/project/axolio-xochifi).** --- ## Foreword "Xochi" takes its name from Lake Xochimilco, home of the axolotl. Axolotls don't just regenerate limbs. They regrow nerves. They're notably the only known animal that can. That alone captivated academics like Julio Cortazar. Cortazar wrote about a man who stared at axolotls through aquarium glass until he realized he'd become one. The glass never moved. His understanding of which side he was on did. Every transaction you've made on Ethereum is behind glass like that. Visible, permanent, indexed. You might not have noticed which side you're on yet. _Somos axolotls. Soft-bodied, exposed, observable._ Some manage protocol treasuries and can't rotate without the whole market front-running the move. Some are born somewhere hard and can't move money without a government deciding they shouldn't. Different stakes. Same glass. Your spawn point (where you're born, what passport you hold, what financial system you inherit) shouldn't determine whether you get privacy. But it does. Ethereum is our neutral settlement layer. Our Lake Xochimilco. Privacy is the water we breathe. _Somos axolotls._ This paper describes what we built to change that. > Axolotls retain neonatal regenerative abilities their entire lives, something every other vertebrate loses in infancy. > Researchers have crushed axolotls' spinal columns and watched them regenerate, up to five times. > Axolotls' only native habitat is Lake Xochimilco, and it's being polluted out of existence. > As the water degrades, habitat biodiversity shrinks, so does the axolotls' ability to regenerate. > > _The thing that makes us extraordinary is the first thing lost_ ## Abstract _ERC-8262 "Xochi's ZK Compliance Oracle"_: zero-knowledge proofs that verify compliance without revealing transaction data. Not full transparency (compliant but exposed) or full privacy (protected but legally risky). Cryptographic compliance. The regulator verifies a Xochi ZK Compliance Oracle proof. They never see the trade. You sign an intent. Solvers compete to fill it. Settlement lands privately on L1 or L2. The dark pool runs on bare-metal infrastructure we own. Privacy is free by default. The venue never trades against its own users. Better rates and deeper privacy unlock through attestation-based tiered trust scoring. The same primitive serves two users. Human traders who want private execution. Autonomous agents that need cross-chain settlement. One intent format, one solver network, one fee schedule. --- ## Table of Contents 1. [The Problem](#1-the-problem) 2. [Xochi's ZK Compliance Oracle](#2-xochis-zk-compliance-oracle) 3. [Architecture](#3-architecture) - [XID: Pseudonymous Identity](#xid-pseudonymous-identity) 4. [Agents on Xochi](#4-agents-on-xochi) 5. [Privacy Tiers: The Glass Cube](#5-privacy-tiers-the-glass-cube) 6. [Intent Execution](#6-intent-execution) 7. [Economic Model](#7-economic-model) 8. [Security and Risk Management](#8-security-and-risk-management) - [Post-Quantum Considerations](#post-quantum-considerations) 9. [Competitive Position](#9-competitive-position) 10. [Governance](#10-governance) 11. [Roadmap](#11-roadmap) 12. [Team](#12-team) 13. [Conclusion](#13-conclusion) 14. [References](#references) --- ## 1. The Problem ### No Compliant Privacy DEXs Ethereum has two layers: L1 (the main chain, where transactions settle with full security and finality) and L2s (rollup chains that batch transactions and post proofs back to L1 for more cost-effective execution and scalability). DEXs (decentralized exchanges) let users swap tokens without a centralized intermediary, but every trade is visible on-chain. Tornado Cash got sanctioned. Existing dark pools have no regulatory path. Dubai's VARA (Virtual Assets Regulatory Authority) banned all anonymity-enhancing tools in January 2026. Nothing on-chain is both private and compliant. | Approach | Compliance | Privacy | Example | | ---------------------------------- | ---------- | ------- | ------------------------- | | Full transparency | Yes | No | Uniswap, CoW Protocol | | Full privacy | No | Yes | Tornado Cash (sanctioned) | | **_Xochi's ZK Compliance Oracle_** | **Yes** | **Yes** | **_Xochi_** | ### Public Blockchains Are Fish Bowls Every transaction on a public blockchain is recorded forever. Pseudonymous senders, fully visible trades. You can't execute a strategy without broadcasting it. Protocol treasuries can't rotate without signaling. Crypto funds can't execute size without moving markets. DAOs paying EU contributors have to broadcast every USDC-to-EURC swap. Corporate hedging is visible to competitors. The value is hiding position sizes, not speed. ### \$1.1B+ Extracted via MEV Since The Merge MEV (Maximal Extractable Value) is profit extracted by reordering, inserting, or censoring transactions in a block. The most common form is the sandwich attack: a bot sees your pending swap in the public mempool (queue of pending transactions that have been broadcast to the network but have not yet been included in a block), buys the token before you, lets your trade push the price up, then sells immediately after. You get a worse price; the bot pockets the difference. Frontrunning is the same idea applied more broadly: copying and trading ahead of someone else's known intent. ESMA's July 2025 risk analysis [1] measured 526,000 ETH (>\$1.1B) in realized MEV from The Merge through mid-2024, with ~90% of validators running MEV-Boost. Privacy protocols like Railgun help with wallet anonymity but don't touch MEV. The swap itself is still public. --- ## 2. Xochi's ZK Compliance Oracle Users choose their own identity verification providers (PoH for Proof of Humanity, KYC for Know Your Customer, or KYB for Know Your Business), select their privacy level, and the oracle is designed to clear or flag at transaction time, with no human in the loop. This is the intended design. It is not live yet (see Go-to-Market Reality below). ### How Xochi's ZK Compliance Oracle Works Regulators need to know conditions are met. They don't need the exact values. ``` Traditional SAR (Suspicious Activity Report): User data --> Regulator sees everything --> Compliance check Xochi's ZK Compliance Oracle: User data --> ZK proof generated locally --> Regulator verifies proof (data never leaves client) (learns only: "compliant" or "not") ``` | Regulatory Requirement | ZK Proof Type | What the Proof Says | What Stays Hidden | | ------------------------------------------- | ------------------------ | ---------------------------- | -------------------- | | Risk threshold (AML, Anti-Money Laundering) | Compliance (0x01) | "Score below jurisdiction X" | Exact score, signals | | Large value report (\$10K+) | Risk Score (0x02) | "Amount exceeds threshold" | Exact amount | | Anti-structuring | Pattern (0x03) | "No structuring detected" | Transaction history | | Source of funds / KYC | Attestation (0x04) | "Valid credential exists" | Credential details | | Allowlist membership | Membership (0x05) | "Address is in approved set" | Which address | | Counterparty screening | Non-membership (0x06) | "Not on sanctions list" | Identity | | Compliance with signed signals | Compliance Signed (0x07) | Compliance + provider sig | Score, signals, sig | | Risk Score with signed signals | Risk Score Signed (0x08) | Risk Score + provider sig | Exact score, sig | | Multi-provider quorum | Compliance M-of-N (0x09) | M of N providers all attest | Per-provider data | Nine proof types, nine circuits, nine verification keys. Privacy pools cover one (non-membership). _Xochi's ZK Compliance Oracle_ covers all nine. The signed variants (0x07, 0x08) verify a secp256k1 signature in-circuit so a user cannot submit fabricated signal values; the multi-signed variant (0x09) extends this to an M-of-N quorum across up to 5 registered signers. US (BSA), Singapore, and UAE (VARA) enforce a jurisdiction floor of M >= 2. Jurisdiction thresholds and proof details in [Appendix E](./appendix.md#e-xochis-zk-compliance-oracle-proof-types). Formal derivations (risk score formula, circuit predicates, security properties) in [Appendix I](./appendix.md#i-formal-derivations). The full specification is formalized as an Ethereum standard [21]. ### Legal Foundation ZK proofs are minimal disclosure by definition, which maps directly to GDPR (EU General Data Protection Regulation) Art. 5's data minimization principle. Proving "exceeds threshold" is far less intrusive than revealing the exact amount (proportionality), and proving pattern absence gives equivalent assurance to a SAR filing (reasonable suspicion). This approach is novel. Regulatory acceptance is not guaranteed. ### The VARA Question Dubai's January 2026 ban [10] defines anonymity-enhanced crypto as assets "for which the VASP (Virtual Asset Service Provider) has no mitigating technologies or mechanisms to allow traceability." _Xochi's ZK Compliance Oracle_ is a mitigating technology: cryptographic compliance proofs that allow traceability without revealing underlying data. Assets traded through _Xochi's ZK Compliance Oracle_-equipped venues have a traceability mechanism, so they fall outside the ban's definition. We're pursuing this through VARA's sandbox program (see [Section 8](#8-security-and-risk-management)). **This is not a granted exemption.** But the definitional structure is real. VARA wrote the carve-out into the regulation itself. We're making the argument with working code. ### Retroactive Flagging + Proof of Innocence When a previously-clean address gets flagged, the _Xochi's ZK Compliance Oracle_ proof from the original transaction proves it wasn't flagged at T=transaction. Counterparties present this proof to demonstrate good faith. Deconstructed flagged transactions reveal which screening providers were used. Providers that appear in flagged transactions at higher rates lose weight via the spoofability score (see [Section 5](#adaptive-provider-weighting)). The oracle is designed to push structured reports to regulators via API (planned, not yet live): metadata and selectors, not raw transaction data. ### Go-to-Market Reality _Xochi's ZK Compliance Oracle_ is the long-term vision. It is not live yet, and compliance screening is not enforced in production today. The design routes users to jurisdiction-appropriate licensed solvers; as jurisdictions adopt _Xochi's ZK Compliance Oracle_ proofs, the protocol shifts to cryptographic compliance. Multi-year transition. --- ## 3. Architecture ### Design Philosophy We don't break Ethereum's transparency. We allow you as a user to control the opacity. **Ethereum-first**: L1 stealth settlement already today; L2 shielded notes via [pxe-bridge](https://github.com/xochi-fi/pxe-bridge) as soon as user transactions are accepted in Aztec. See [Section 5](#privacy-implementation) for implementation details. **Our infrastructure**: Bare-metal. We run solvers, validators, sequencers, oracles. When something breaks, we fix it. **No privacy premium**: Privacy is included in the trading fee. No separate charge. Every tier is a real product. ### What We Run - **Solvers**: Riddler (proprietary, live on 6 chains) - **Sequencers**: Aztec (since genesis, currently in mainnet alpha) - **Settlement Bridge**: [pxe-bridge](https://github.com/xochi-fi/pxe-bridge) (embedded Private eXecution Environment, PXE, for Aztec shielded note creation) - **Validators**: Ethereum (mainnet) - **Oracles**: _Xochi's ZK Compliance Oracle_ (specified; not yet deployed) - **Public Goods**: Mana ETH client, node infra ### System Overview ![Xochi System Architecture](/figures/architecture.svg) ### XID: Pseudonymous Identity Every other dark pool starts with "connect your wallet." Think about what that means. Before you've done anything, before you've expressed any intent, you've handed over a public key that links to your entire on-chain history. The privacy product begins with a privacy violation. XID works differently. You touch a fingerprint sensor. The device creates a WebAuthn discoverable credential, a passkey that lives on your hardware and never leaves it. The server stores exactly one artifact: the credential's public key, encrypted with AES-256-GCM. No username. No email. No wallet address. The session token identifies you as `SHA-256(credentialId)`, a pseudonym that cannot be reversed to a person or a device. Login is even simpler. No username field. The browser finds your passkey, you authenticate with a biometric, and you're in. The server never learns which device you used. Wallets come later, if at all. When you do connect one, you sign a message to prove ownership, but that link exists only in your browser session. The server doesn't record it. If the credential store were compromised tomorrow, an attacker would find encrypted blobs keyed by hashes. No wallet addresses. No identity mappings. Nothing to correlate. Wallet-only access is a first-class path. Connect any EVM wallet, skip XID entirely, trade at Standard tier (0.22% on stablecoins, public settlement). Some users are here for a single swap. They shouldn't need an account for that. The incentive structure is where this gets interesting. XID holders who verify through attestation providers (see [Section 5](#5-privacy-tiers-the-glass-cube)) accumulate trust score. Trust unlocks lower fees and deeper privacy. You're never required to verify, but the protocol always rewards it. Identity verification is optional. Its benefits are not. Recovery is opt-in and client-side. If you lose your device, your credential is gone. The planned recovery path: encrypt a credential blob with a key only you know and upload the ciphertext. The server stores something it cannot read. Alternatively, register a second passkey on another device. Most users with iCloud or Google password managers already have passkey sync across devices. Why build this at all? Without a pseudonymous identity layer, trust scores anchor to wallet addresses, which are public, linkable, and trivially deanonymized through chain analysis. XID means earning deeper privacy doesn't require sacrificing it at the front door. ### Agent Authorization: Member, Mandate, Guest Three roles transact through Xochi. **Members** are humans authenticated via XID (above). **Guests** are agents acting anonymously with no Xochi account, paying per call via x402 micropayments and capped at Standard tier privacy. **Mandates** sit between: a Member signs an EIP-712 delegation envelope authorizing a specific agent wallet to act within scoped limits (maximum notional, expiry, call count). The agent presents the envelope on every protected request, and the server verifies it per call without persisting any (Agent, Member) mapping. Budget counters live in D1 keyed by the envelope hash (an atomic conditional update gives true over-spend protection); nothing else. Under a Mandate, the agent inherits the Member's Trust Tier and Privacy Level access for the envelope's lifetime, and the delegator can revoke an outstanding envelope at any time. This three-role split lets autonomous agents transact with the same privacy access as their human delegators while preserving XID's "no identity-to-wallet mapping" property. Both Guest mode (x402) and Mandate mode (`X-Xochi-Delegation` envelope verification) are live today. Standalone wallet sign-in was considered and rejected: any persistent server-side wallet-to-session mapping is a regression from XID. --- ## 4. Agents on Xochi Agents are stuck on Base. ACP, x402, and MPP all assume USDC on Base, which means an agent holding inventory anywhere else has to bridge before it can transact. Bridging adds latency, custodial exposure, and a counterparty an agent cannot evaluate. Xochi removes the bridge step. An agent signs the same intent format a human signs. Riddler fills it across six chains (Ethereum, Optimism, Base, Arbitrum, Polygon, and Robinhood Chain). Settlement lands on the destination chain, including Base, where ACP's escrow expects it. Protocol fees come out of the swap output. No subscription, no separate billing, no agent-specific credentials. Three interfaces: - **Direct intent API**: agents holding their own keys sign and submit intents over HTTP REST. Same path as the human trader API. - **x402 paywall**: protected endpoints respond with a 402 carrying intent terms; any x402-compatible client auto-pays via EIP-3009. Live for Guest mode (see [Section 3](#agent-authorization-member-mandate-guest)). - **ACP settlement adapter**: for agents on Virtuals ACP, Xochi acts as the cross-chain settlement leg under an existing Job Offering. No registration changes for ACP-side operators. Compliance carries through. Xochi's ZK Compliance Oracle proofs (see [Section 2](#how-xochis-zk-compliance-oracle-works)) attach to agent swaps the same way they attach to human swaps. Agents transacting into regulated venues inherit the same auditability without exposing wallet topology, and stealth-by-default means an agent's recipient addresses are not linkable across jobs. Trust does not stack at the agent layer. Mandate-mode agents inherit their delegator's Trust Tier and Privacy Level for the envelope's lifetime. Guest-mode agents transact at Standard tier with no inheritance. Attestations belong to Members, not to the agents acting under them, which removes the incentive to spin up cheap agent identities to farm score. --- ## 5. Privacy Tiers: The Glass Cube Six faces, crystal clear to solid. More opacity, more privacy. ![Privacy Tiers - The Glass Cube](/figures/privacy-tiers.svg) ### Combined Tier and Trust Score Privacy level and trust tier are two separate axes. Your trust score (from attestations) sets your fee, and it unlocks the deeper privacy levels (Private and Sovereign, both settled on Aztec L2). L1 stealth is open to everyone: privacy is free by default, so a Standard wallet can settle to a one-time stealth address and simply pays the Standard fee. Your chosen privacy level determines data retention. Higher trust earns both deeper privacy and lower fees. This table shows them combined: each row is a privacy level, with the minimum trust score required to unlock it. | Privacy Level | Min Trust Score | Fee (stable / volatile) | Data Retained | Settlement | | ------------- | --------------- | ----------------------- | ---------------------- | ------------------------ | | Open | None | -0.02% (flat) | Everything + analytics | Public wallet | | Public | None | 0% (flat) | Everything | Public wallet | | **Standard** | **0-24** | **0.22% / 0.40%** | **Wallet + amounts** | **Public wallet** | | Stealth | None | 0.22% / 0.40% | Wallet + ranges | L1 stealth (ERC-5564) | | Private | 50+ | 0.15% / 0.29% | Wallet only | L2 shielded (pxe-bridge) | | Sovereign | 75+ | 0.12% / 0.25% | Nothing | L2 shielded (pxe-bridge) | Fees are shown stablecoin / volatile (ETH/WETH). Each fee decomposes into four layers. See "Where the fee goes" below. The MEV rebate has been retired; the solver instead shares **15% of any price improvement** (you keep 85%). **What "Data Retained" means.** A full trade record contains: sender address, recipient address, token pair, exact amounts (or a binned amount range at deeper tiers), timestamps, intent ID, settlement address, and order flow analytics. Each privacy level strips fields from this record after settlement. | Field | Open | Public | Standard | Stealth | Private | Sovereign | | -------------------- | ---- | ------ | -------- | ------- | ------- | --------- | | Sender address | Yes | Yes | Yes | Yes | Yes | No | | Recipient address | Yes | Yes | No | No | No | No | | Token pair | Yes | Yes | No | No | No | No | | Exact amounts | Yes | Yes | Yes | No | No | No | | Amount range | n/a | n/a | n/a | Yes | No | No | | Timestamps | Yes | Yes | Yes | Yes | No | No | | Intent ID | Yes | Yes | No | No | No | No | | Settlement address | Yes | Yes | No | No | No | No | | Order flow analytics | Yes | No | No | No | No | No | During execution, solvers receive the minimum data needed to fill the order (see [privacy policy](../legal/privacy.md) Section 6.2). Data retained refers to what information the protocol stores after settlement. Execution-time data is ephemeral and purged after the trade completes. **Open tier regulatory note:** The -0.02% rebate for order flow analytics may constitute Payment for Order Flow (PFOF), which is restricted under EU MiCA Art. 39a and banned in the UK under FCA rules. The Open tier may need to be disabled or restructured for EU and UK users. Jurisdiction-gated availability is planned. Trust tiers (Standard, Trusted, Verified, Premium, Institutional) map to score ranges and fees. The deeper privacy levels (Private, Sovereign) are gated by trust score; L1 stealth is open to all. Privacy is never separately priced. See [Appendix C](./appendix.md#c-complete-fee-matrix) for the full fee breakdown. Trust scores from verified attestations: - **Humanity** (max 25 pts): Humanode, Idena, Human Passport, Worldcoin, BrightID - **Identity** (max 35 pts): ZKPassport, Privado ID, Coinbase Verified, Civic - **Reputation** (max 20 pts): ENS, Lens Protocol - **Compliance** (max 40 pts): Chainalysis, Xochi History Diminishing returns: first attestation in a category grants full points, second grants 25%, third and beyond grant 10%. Max total ~120. Most retail users reach Trusted (25+) with 2-3 attestations. Institutional (100+) requires licensed compliance providers. ### Adaptive Provider Weighting Provider weights shift based on three signals defined below: empirical sybil rates (how often attestations later get flagged), forgery cost (how expensive the verification is to spoof), and incident severity (the impact of past failures). **Spoofability Score** Each provider $i$ carries a spoofability score $S_i$: $$S_i = \alpha \cdot \frac{F_i}{N_i} + \beta \cdot \frac{1}{C_i} + \gamma \cdot D_i$$ Where: - $\alpha, \beta, \gamma$ = tuning weights ($\alpha + \beta + \gamma = 1$), currently $0.5, 0.3, 0.2$ - $C_i$ = forgery cost normalized to USD - $D_i \in [0, 1]$ = incident severity index - $F_i / N_i$ = flagged-to-total address ratio (empirical sybil rate) Effective weight: $$W_i = W_i^{base} \cdot (1 - \delta \cdot S_i)$$ $\delta = 0.4$ caps downward adjustment at 40% per review cycle. Providers can regain up to 20% of lost weight per cycle after two consecutive improved review periods, where each cycle must improve on the immediately prior one. **Review cadence**: Bi-annual (January/July). Adjustments published 14 days before effect. Weighting history is public. **Selected baseline weights** (April 2026). Full provider list in [Appendix F](./appendix.md#f-trust-score-providers). | Provider | Base Points | Resistance | Notes | | ----------------- | ----------- | ----------------- | ------------------------------------------------------ | | Humanode | 20 | High | Biometric liveness, no documented bypass | | Idena | 20 | High | Ceremony model, AI resistance threshold | | ZKPassport | 35 | High | NFC ID + biometric liveness + ZK, highest forgery cost | | Coinbase Verified | 22 | Medium-High | 2025 data breach, centralization risk | | Chainalysis | 25 | High (compliance) | Sanctions gate, not identity | ### Privacy Implementation No remote TEE dependencies. No trusted third parties. Pure ZK architecture. Client devices use their own secure enclaves (Apple Secure Enclave, Android StrongBox) for credential storage, but the protocol itself doesn't rely on Intel SGX, AWS Nitro, or similar remote attestation. **Ethereum L1 Stealth Addresses (Live)**: Stealth addresses (ERC-5564) are one-time receiving smart accounts derived cryptographically from a public "meta-address." The sender can compute the address, but no observer can link it to the recipient. Composed with Account Abstraction (AA, ERC-4337), tokens land at a counterfactual SimpleAccount, a smart contract wallet whose address is deterministic but not deployed until first use. Claiming is one gasless transaction: Pimlico sponsors gas, the account deploys atomically, and tokens transfer to the recipient's wallet. No ETH needed. ERC-5564 is the same primitive integrated into the Ethereum Foundation's Kohaku wallet SDK (see [Section 9](#emerging-competitors-2026)), so a Kohaku-equipped wallet can be the recipient of a Xochi stealth settlement without additional integration work. **Aztec L2 Shielded Notes**: Private and Sovereign tiers use [pxe-bridge](https://github.com/xochi-fi/pxe-bridge), a JSON-RPC sidecar that embeds an Aztec PXE and exposes `aztec_createNote` for shielded settlement (Aztec docs call these "private notes" or just "notes"). Unlike EVM execution where every node replays the transaction publicly, Aztec splits execution into a private phase (runs locally in the PXE, generating a ZK proof) and a public phase (the network verifies the proof without seeing the inputs). pxe-bridge wraps this private execution model in a JSON-RPC interface that Riddler already speaks, so the solver creates shielded notes without needing to understand Aztec's privacy architecture. The solver is a deterministic Schnorr account on the Aztec network. **Note:** Aztec Alpha Network (launched March 2026) is experimental software with known vulnerabilities. State is not migrated between alpha releases. Aztec uses its own token standards (AIP-20, AIP-721), not ERC-20/721. See [Section 8](#8-security-and-risk-management) for risk assessment. ![PXE Settlement Flow](/figures/pxe-settlement.svg) **Cross-chain**: Riddler operates on six chains (Ethereum, Optimism, Base, Arbitrum, Polygon, and Robinhood Chain, an Arbitrum Orbit L2 whose native stablecoin is USDG from Paxos). Stealth settlement targets L1 Ethereum. Cross-chain intents route through Across and Circle CCTP (Cross-Chain Transfer Protocol for native USDC transfers) for the bridge leg (public). Full cross-chain stealth is on the roadmap. --- ## 6. Intent Execution ### How It Works Users sign an intent: what they want ("swap 1 ETH for USDC at best price"), not how to get it. Solvers compete to fill it. Nothing hits the mempool. ``` Intent Submitted --> Riddler Routes --> Xochi's ZK Compliance Oracle --> Private Settlement (private) (solver network) (compliance, planned) (L1 or L2) ``` ![Intent Execution State Machine](/figures/intent-flow.svg) Quotes last 30 seconds. Failed executions retry with a different solver. ### Solver Network ``` More solvers --> Tighter spreads --> More volume --> More order flow --> More solvers ``` Intent-based execution creates synthetic depth. Solvers pull from CEX (centralized exchange) order books, DEX liquidity pools, OTC (over-the-counter) desks, and their own inventory. For major pairs, a well-connected solver accesses 5-10x its own capital in external liquidity. ### Riddler: Protocol Solver Live on six chains (Ethereum, Optimism, Base, Arbitrum, Polygon, Robinhood Chain) with <6s P95, ~2.1s typical delivery. For context: Uniswap L1 swaps take 15-30s, CoW batch auctions ~30s. The solver network is open. See [Appendix D](./appendix.md#d-solver-specifications). **Honest assessment**: Riddler is the only active solver. The flywheel is a growth thesis, not a launch reality. Riddler requires capital to fill orders. The protocol is raising to capitalize the solver. Flash loan integration will multiply effective capacity for same-chain fills. ### Opening the Network: RFQ Auction + Non-Custodial Escrow (design) "The solver network is open" is a mechanism, not a slogan, and this is how it works as external solvers come online. **Sealed-bid RFQ auction.** When you request a quote, Riddler computes a reserve output (the price you're shown) and opens a brief sealed round (~300ms). Eligible solvers privately bid the output they commit to deliver on the destination chain; the best bid at or above the reserve wins. Because Riddler's own solver always posts the reserve as a standing bid, the auction can never clear below your shown price and always has a winner. Sealed bids mean no public-mempool bid-sniping. The winner gets a short exclusive window to fill; if it defaults, Riddler backstops it, and you still receive exactly what you signed for. Ties break by solver reputation, which reuses the same attestation stack that scores traders for fee tiers. On-chain Dutch-decay auctions (the trustless-matching endgame) are reserved for full decentralization. **Non-custodial escrow.** Origin funds are pulled into an on-chain escrow, not a solver wallet. The escrow's only exits are release to a solver that provably filled the destination, or a permissionless refund to the depositor after a deadline, callable by anyone. Riddler holds no key that can move user principal; it earns fees (sliced by the contract at release) and its own solver margin. This makes the "venue never trades against its own users" promise structural rather than policy, and it is what lets the solver set open safely: a solver that wins and never fills forfeits its bond and reputation while your funds were never at risk. Proof-of-fill is tiered per corridor: EVM<->EVM can reach fully trust-minimized (light-client / ZK), while non-EVM legs (Tron, shielded Aztec) settle via bonded attestation, bounded-trust and disclosed, because their finality is not verifiable from an origin EVM chain. This is the [ERC-7683](https://eips.ethereum.org/EIPS/eip-7683) open/fill/prove settlement model. Today's origin pull still transits a solver wallet; the escrow is the fix on the roadmap. ### Execution Mechanics The intent model hides what you want. This section covers how it gets filled, what happens at scale, and where privacy degrades. **Order sizing.** Riddler checks inventory on the destination chain: available balance minus reserve thresholds, active rebalancing, and pending intent commitments. If self-fill is insufficient, it routes through bridge adapters (Across, CCTP, native L1-L2 bridges) and CEX withdrawal (Coinbase). For major pairs, external sourcing accesses 5-10x on-hand capital. Orders beyond all available liquidity are rejected. No partial fills today. See [Appendix J](./appendix.md#j-execution-specifications) for the inventory formula and routing priority. **Flash loan amplification (planned).** Flash loans are uncollateralized loans borrowed and repaid within a single transaction. If repayment fails, the whole transaction reverts. Borrow at fill time, fill the intent, repay in the same block. Capital-free execution for same-chain swaps. Cross-chain intents still require bridge capital for the duration of the bridge leg. Flash loans multiply effective capacity without custody risk: the solver never holds borrowed funds across blocks. **Settlement privacy at scale.** When Riddler sources from external venues (DEX pools, bridge liquidity), those legs are visible on-chain. The user's intent is private (it never hits the mempool), but the solver's sourcing creates a footprint. Two mitigations reduce this: - CEX sourcing: withdrawals from centralized exchange books leave no on-chain liquidity trace. The settlement transaction is the only visible event. - Flash loans (planned): borrow and fill atomically in a single transaction. No separate sourcing leg. For very large trades (\$1M+), some information leakage through solver activity is unavoidable without deeper protocol liquidity. This is why the solver flywheel matters, and why Riddler's LP vaults (see [Liquidity Bootstrapping](#liquidity-bootstrapping)) are on the roadmap. **Fragmentation.** No iceberg (large orders split into hidden smaller pieces) or TWAP (Time-Weighted Average Price, executing a large order in equal slices over a time window) order types today. DCA (Dollar-Cost Averaging, recurring purchases at fixed intervals) ships Q3 2026. Riddler's bridge router already splits across routes internally when a single route lacks capacity. Time-slicing (TWAP) is architecturally supported: submit N smaller intents over a time window. The pattern detection circuit (0x03) in the compliance oracle handles anti-structuring analysis for up to 16 transactions per proof, so TWAP slices above the structuring floor do not trigger false positives. Planned: first-class TWAP and iceberg order types where Riddler manages the slicing internally, with configurable slice size, interval, and total duration. **Settlement splitting.** Two kinds, at different layers. _Compliance proof splitting_ ([XIP-1](https://github.com/xochi-fi/XIPs/pull/1), Draft) breaks a trade into N sub-settlements. Each gets its own ZK compliance proof. A standalone SettlementRegistry contract links them by a shared trade identifier. If one proof gets invalidated, only that sub-trade is affected. Smaller sub-settlements are also less profitable to sandwich. Finalization requires a pattern detection proof (circuit 0x03) so the mechanism can't be used for structuring. Minimum split threshold: 10 ETH. The Oracle and Verifier bytecode are unchanged, though the registry depends on the Oracle's read interface (`getHistoricalProof`) remaining stable across upgrades. _Stealth address splitting_ (planned) puts each sub-settlement into a separate stealth account. Today, settlements land in a single counterfactual SimpleAccount (one derived stealth key, salt=0). Planned: derive N stealth keys from the same meta-address, each receiving a fraction. More announcements, more privacy, higher gas. They stack. A single trade can split its compliance proofs via XIP-1 and distribute each sub-trade across unlinkable stealth addresses. Per-sub-trade venue routing ([XIP-2](https://github.com/xochi-fi/XIPs/pull/2), Draft) picks whether each piece settles through public (L1), stealth (ERC-5564), or shielded (Aztec L2). **Practical size limits.** No hardcoded maximum. The system quotes what it can fill and rejects what it can't. Capacity is bounded by Riddler's available inventory plus external liquidity it can source within the 30-second quote window. Flash loans and CEX sourcing can multiply effective capacity 10-50x beyond on-hand inventory. The OTC tier (\$100K+) exists for large trades with negotiated terms. --- ## 7. Economic Model Every non-Open, non-Public swap is cash-positive. ### Revenue Sources | Source | Description | | ----------------- | ------------------------------------------------------------------------------------ | | Trading fees | 0.10-0.40% by trust tier and asset (stablecoin lower, volatile higher) | | Intent surplus | 15% of price improvement (you keep 85%) | | Riddler margin | Solver spread capture | | x402 (Guest mode) | $0.005-$0.01 per call when Agents transact without a Member account (see Appendix C) | ### Where the fee goes Every fee splits into four layers. The discountable layers shrink with trust; the solver cost layer never does (it's what keeps every fill cash-positive): | Layer | Goes to | Discounted by tier? | | ------------- | -------------------------------------------------------------------------- | ------------------- | | Network gas | validators (pass-through) | No (fixed floor) | | Solver spread | **Riddler**, the proprietary solver edge that fills from inventory | No | | Protocol fee | **Xochi**, the venue | Yes | | Routing fee | **Raxol**, the agent that brought the order, funding its **token buyback** | Yes | This is the flywheel: orderflow -> routing fee -> Raxol token buyback -> more agents -> more orderflow. The complete fee matrix by tier and asset is in [Appendix C](./appendix.md#c-complete-fee-matrix). ### Unit Economics Trust tier sets the discountable fee (0.10-0.40% total, by tier and asset). Privacy level is gated by trust score, not separately priced (see [tier table](#combined-tier-and-trust-score)). Higher trust earns both deeper privacy and a lower total. The trust-tier discount applies uniformly to human and agent flows. There is no separate agent tier and no volume discount in v1; agents simply route their fee to the Raxol token via the routing layer above. A \$10,000 stablecoin swap at Standard tier generates \$22 in fees (\$40 for a volatile pair); at Institutional, \$10. The protocol trades margin for volume and trust. Intent surplus (15% of price improvement) is additive and scales linearly with volume. Riddler's solver margin is the never-discounted cost layer; it accrues to Riddler, funding the inventory and infrastructure. ### Revenue Distribution Details ship with the fair launch. Constraints: solver incentives align with execution quality; trading fees fund privacy infrastructure. ### Liquidity Bootstrapping Riddler is the protocol solver. It needs capital to fill orders. The infrastructure is production-tested and live on six chains. Capital is the constraint, not technology. The protocol is currently in pre-launch: collecting early access wallets, validating infrastructure, and recapitalizing. **Phase 1: Raise.** VC funding capitalizes Riddler directly. The protocol owns the solver and captures the margin. This is the immediate path. Every dollar in solver capital generates fees from day one. Order filling begins when capital lands. **Phase 2: Flash loans (planned).** Borrow at fill time, repay in the same block. Capital-free execution for same-chain swaps. Multiplies effective capacity without custody risk. Cross-chain intents still require bridge capital for the duration of the bridge leg, but flash loans eliminate the capital requirement for the fill itself. **Phase 3: LP vaults (future).** External capital deposits into Riddler-managed vaults. LPs earn a share of solver margin proportional to their contribution. Riddler retains execution control: routing decisions, settlement targets, and risk management stay with the protocol. LPs provide capital, not strategy. **Why not open the solver network now?** External solvers with their own capital capture the margin. Riddler exists so the protocol captures that margin. The point is vertical integration: own the infrastructure, own the execution, own the revenue. External solvers join later, after Riddler has established flow and the protocol has a defensible position. --- ## 8. Security and Risk Management ### Risk Assessment | Risk | Likelihood | Impact | Mitigation | | ------------------------------------- | ---------- | -------- | ------------------------------------------------------------------- | | Smart contract exploit | Low | Critical | Audits, insurance | | Xochi's ZK Compliance Oracle rejected | Medium | High | Compliance delegation to solvers | | Solver bootstrap fails | Medium | High | Riddler fills first; external solvers later | | Solver capital | High | High | Raise, flash loans, LP vaults (phased) | | Aztec alpha stability | Medium | Medium | Alpha Network live (v4.x), known vuln in proving system, v5 pending | | Quantum (ECDSA/ECDH) | Low (10y+) | Critical | STARK migration, algorithm agility, Mana | **Aztec status**: Aztec Alpha Network is live (v4.x, launched March 2026). This is explicitly experimental software with known vulnerabilities: a critical proving system bug was disclosed March 17, 2026, with fixes pending in v5. State is not migrated between alpha releases. [pxe-bridge](https://github.com/xochi-fi/pxe-bridge) connects Riddler to the Aztec network for shielded note creation. Private and Sovereign tiers are gated on Aztec stability. Remaining risks: network stability, proving system maturity, fee economics at scale, and breaking changes between alpha releases. ### Xochi's ZK Compliance Oracle Regulatory Risk Novel, no precedent. Core innovation and biggest risk. **Jurisdiction Strategy**: UAE first (VARA sandbox), Singapore second (MAS, Monetary Authority of Singapore), EU third (MiCA, Markets in Crypto-Assets regulation), US last. **Fallback**: If rejected, compliance delegates to licensed solvers per jurisdiction. The protocol downgrades, it doesn't stop. **VARA contingency**: If the VARA sandbox application is rejected or the sandbox program is discontinued, Xochi will (1) route UAE-originating intents exclusively through VARA-licensed solvers who maintain their own compliance obligations, (2) disable privacy tiers above Standard for UAE users until an alternative regulatory path is established, and (3) pursue equivalent frameworks in Singapore (MAS sandbox) or Switzerland (FINMA) as primary jurisdiction. The protocol's architecture supports jurisdiction-specific feature gating without code changes. ### Post-Quantum Considerations Xochi can't be quantum resistant until Ethereum is. If Shor's algorithm breaks secp256k1, every wallet on the network is vulnerable, not just ours. That said, some layers of the stack are closer to quantum readiness than others, and it's worth being honest about which. **Already resistant.** AES-256-GCM (credential encryption in KV) and SHA-256 (credential ID hashing) both survive Grover's algorithm at 128-bit equivalent security. The identity layer is fine. **Not resistant.** WebAuthn passkeys sign with ECDSA P-256. Stealth address key derivation uses secp256k1 ECDH. The Xochi ZK Compliance Oracle uses UltraHonk proofs built on elliptic curve pairings. All of these break under a sufficiently large quantum computer. **What we're doing about it.** The compliance oracle is the one piece we control end-to-end. UltraHonk (a SNARK) relies on elliptic curve pairings. STARKs do not. They use hash-based commitments, no elliptic curves, no pairings. Migrating Xochi's ZK Compliance Oracle circuits from UltraHonk to a STARK-based proof system would make the compliance layer quantum resistant independent of Ethereum's own migration timeline. This is an active area of research for us. Mana, our Elixir Ethereum execution client [22], is a natural testbed for post-quantum signature verification. The BEAM runtime supports hot code upgrades without process restart, which means swapping signature schemes (SPHINCS+, Dilithium, or whatever NIST finalizes) doesn't require validator downtime. No missed attestations during a cryptographic migration. Mana isn't post-quantum today. But its runtime properties make it a better vehicle for that transition than clients that need a full restart to change verification logic. WebAuthn has algorithm agility built into the spec. The FIDO Alliance is working on post-quantum credential types. When those ship, passkeys can migrate without changing the auth flow. Our `authenticatorSelection` already negotiates algorithms at registration time. For stealth addresses, lattice-based equivalents of ECDH exist in the literature. A post-quantum stealth address scheme would replace the secp256k1 shared secret derivation with a lattice-based key encapsulation mechanism. The rest of the flow (view tags, announcement scanning, gasless claiming) remains unchanged. This is a straightforward swap when the primitives mature. None of this is urgent. Cryptographically relevant quantum computers are years away, probably a decade or more. But a protocol that handles large private trades should be thinking about this now, not when NIST issues an emergency advisory. The migration paths exist. The architecture accommodates them. --- ## 9. Competitive Position ### The Privacy Landscape Most "privacy" protocols are pools. Your wallet is hidden. The swap is public. Xochi hides the swap. Different layers, different problems: | Layer | Examples | What it hides | | ------------- | --------------------------------------- | ------------------- | | Wallet | Kohaku, ERC-5564 stealth | Address linkability | | Deposit | Privacy Pools (0xbow), Railgun, Panther | Deposit source | | **Execution** | **Xochi** | **The swap itself** | | Settlement | Aztec, stealth + ERC-4337 | Final landing | Xochi is a private execution venue with its own compliance primitive. Xochi is not a deposit mixer (use Privacy Pools), a wallet SDK (use Kohaku), or a separate chain (use Aztec, Monero, Zcash). The layers compose. | | Privacy Pools (Railgun, Panther) | Privacy Pools (0xbow) | Privacy L1s (Secret, Penumbra) | Privacy-native (Monero, Zcash, LTC MWEB) | Xochi (Private DEX) | | ------------------------ | -------------------------------- | ------------------------------- | ------------------------------ | ----------------------------------------- | ------------------------- | | **What's private** | Wallet | Deposit source | Everything (separate chain) | Everything (separate chain) | Wallet + trade + amounts | | **Trade execution** | External (Uniswap, public) | Deposit/withdraw only | Native (bridged) | Native (separate network) | Integrated (solvers) | | **Compliance path** | View keys | Set membership proof | None | None | 9 ZK proof types | | **Jurisdiction-aware** | No | No | No | No | Yes (EU, US, UK, SG, UAE) | | **MEV protection** | Partial | N/A (not a DEX) | Full | Full | Full (intent-based) | | **Regulatory status** | Risky | Live (mainnet since March 2025) | Risky | Risky (Monero delisted by many exchanges) | Novel (VARA argument) | | **Institutional access** | Blocked | Limited (deposits only) | Blocked | Blocked | Viable path | The other axis is users. Privacy protocols (Railgun, Aztec, Penumbra) target humans. Agent protocols (ACP, x402, MPP) target single-chain bots on Base. Xochi serves both. ### Set Membership vs Active Compliance Privacy Pools (0xbow) validated the core thesis: ZK proofs can handle compliance without revealing data. But set membership ("my deposit isn't in the sanctioned set") is one dimension of compliance. Regulators need more: risk scores, structuring patterns, KYC validity, sanctions screening, signed and multi-signer variants. Xochi's ZK Compliance Oracle covers all nine (see [Section 2](#how-xochis-zk-compliance-oracle-works)), formalized as an open ERC standard [21] with on-chain attestations that let counterparties prove good faith retroactively. ### Why Not Monero? Privacy purists will ask this, and they're right to. Monero's privacy is better than ours. Ring signatures, stealth addresses baked into the protocol, mandatory privacy for every transaction. No compliance oracle. No trust scores. No one verifying anything. Zcash offers similar properties with optional shielded pools. Litecoin added MimbleWimble Extension Blocks in 2022 for opt-in confidential transactions. These are real privacy tools with years of production use. We're not going to pretend otherwise. For threat models where the goal is total opacity, those protocols deliver something we don't. But here's the thing we keep running into: the people who need privacy most on Ethereum can't leave Ethereum. A protocol treasury sitting on $40M in USDC doesn't have a Monero problem. They have an Ethereum problem. Their positions, their rotations, their payroll. All of it is visible to every MEV bot and chain analyst on the network. They can't pay contributors in XMR. They operate in a world of ERC-20s and L2s and compliance departments, and that world has no privacy at all. Monero chose to solve privacy by building a separate financial system. We chose to solve it inside the one that already exists. These aren't competing approaches so much as different bets about where privacy is most needed. There's a harder question underneath this one, and we don't have a clean answer for it. The compliance oracle, the thing that makes Xochi work in regulated jurisdictions, is also the thing that makes a privacy maximalist uncomfortable. You're generating a proof that you're clean. The oracle verifies it. The regulator learns nothing about your trade, but they learn that you proved something, which is more than Monero asks of anyone. We think that's the right tradeoff for the people we're building for. Institutions, treasuries, funds, DAOs paying contributors across borders. They need privacy that has a regulatory path, not privacy that exits the financial system entirely. The real choice right now is between Xochi-grade privacy and no privacy at all on the chain where the money actually lives. ### Emerging Competitors (2026) The privacy landscape is expanding rapidly. Several projects entered or matured since initial publication: - **Kohaku** (Ethereum Foundation, roadmap October 2025, Devcon demo November 2025): Modular wallet SDK from the EF Privacy Cluster (47 people). Wraps Railgun, Privacy Pools (0xbow), and ERC-5564 stealth addresses into a default-on wallet experience targeting MetaMask, Rainbow, and Ambire. Ships a Helios light client (no third-party RPC), per-dapp account isolation, P2P broadcasting, and a post-quantum 4337 account package. Compliance via optional reveal: users manually disclose the stealth-to-main link to auditors. Wallet-layer scope only. The framework explicitly notes that once assets enter a DeFi protocol, privacy ends. Complementary to Xochi, not competitive: Kohaku is the wallet, Xochi is the venue. The same ERC-5564 primitive Kohaku wallets generate (see [Section 5](#privacy-implementation)) can receive a Xochi stealth or shielded settlement directly. GitHub: [ethereum/kohaku](https://github.com/ethereum/kohaku). - **Renegade** (Arbitrum + Base, expanded Jan 2026): MPC-based dark pool with midpoint pricing pegged to Binance bid-ask spread. Closest architectural competitor. Now offers opt-in counterparty identity filtering (traders can choose to only match with verified counterparties), but no ZK compliance proofs, no jurisdiction-aware screening, no retroactive proof-of-innocence. Audited by zkSecurity. $21.3M total raised (Dragonfly, Balaji, Naval). - **Chainlink Confidential Compute** (early access, 2026): CRE for private smart contracts, CCIP for cross-chain settlement, ACE for automated compliance. Dark pool infrastructure tooling, but not a dark pool itself. Complementary to Xochi's execution layer. - **COTI Nightfall ZK Rollup** (launched March 2026): Garbled circuits as an Ethereum L2. Claims 3000x faster than FHE and 250x lighter than alternative privacy solutions. Different cryptographic primitive for the same confidential DeFi problem. Privacy-on-Demand (PoD) for multichain is on their 2026 roadmap. - **NEAR Confidential Intents** (launched March 2026): Same intent-based privacy concept, different execution environment (NEAR, not Ethereum). - **Coinbase Agentic Wallets** (launched 2026): Wallet infrastructure specifically for AI agents. Relevant because agent-generated trading volume is growing exponentially on Base and Solana. Agents need private execution. Their patterns are predictable and they run 24/7. These are complementary approaches. Privacy is infrastructure, not ideology, and the design space accommodates multiple cryptographic primitives. What separates Xochi: we hide trade execution itself (not just wallets), ZK compliance covers nine proof types (not just set membership), and we have cofounders who've been on the other side of enforcement. ### Xochi's ZK Compliance Oracle vs View Keys View keys let you trade privately, then reveal to auditors when asked. The data exists; someone can request it. Xochi's ZK Compliance Oracle never creates revealable data. ### Why We're Hard to Copy Gasless stealth claims compose ERC-5564 with ERC-4337 end-to-end (see [Section 5](#privacy-implementation)). [Raxol](https://github.com/DROOdotFOO/raxol/tree/master) (MIT) routes agent-to-agent payments through Xochi by default. You can fork a contract, but you can't fork years of node ops, solver integration, and regulatory groundwork. And trust scores are protocol-specific: leave and you start at zero. --- ## 10. Governance ### Current Model Ships with the fair launch. Progressive decentralization: | Phase | Model | Guardian Powers | | -------- | -------------------------- | --------------------- | | Launch | Guardian multisig (3-of-5) | Full emergency powers | | Growth | Reduced guardian scope | Security-only veto | | Maturity | Full community governance | Sunset | **Guardian powers**: pause, temporary reserve adjustment, veto during timelock, solver deregistration. **Governance scope** (when finalized): protocol parameters, fee structure, solver requirements, treasury allocation, protocol upgrades. --- ## 11. Roadmap ### Live Now Production infrastructure live on six chains. - Riddler solver on 6 chains ([Section 6](#6-intent-execution), [Appendix D](./appendix.md#d-solver-specifications)) - Cross-chain via Across, Circle CCTP - Gasless swaps (PERMIT2/EIP-3009/x402) - L1 stealth settlement ([Section 5](#privacy-implementation)) - ERC-5564 announcement scanning and client-side claim signing - Trust scoring and attestation system - Aztec sequencer operation (Alpha Network, v4.x) - Aztec settlement bridge ([pxe-bridge](https://github.com/xochi-fi/pxe-bridge), Alpha Network) ### Q3 2026 - Solver capitalization (raise closes) - Aztec L2 private tiers (pxe-bridge e2e testing on Alpha Network, contingent on v5 stability); Post-Audit. - Smart contract audit (includes SettlementRegistry) - Settlement splitting ([XIP-1](https://github.com/xochi-fi/XIPs/pull/1), [XIP-2](https://github.com/xochi-fi/XIPs/pull/2)): compliance proof splitting, venue routing, diffusion scheduling - Xochi's ZK Compliance Oracle proof testnet ### Q4 2026 - FX pairs (EURC, GYEN) - LP vaults for solver capital - Multi-account stealth settlement (stealth address splitting, composes with XIP-1) --- ## 12. Team | Name | Role | Background | | ---- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Drew | Protocol Director | MechE/ElecE Inventor, Protocol Specialist @ Lido, Protocols/NodeOps @ Blockdaemon, R&D Engineer @ General Dynamics | | Bloo | Protocol Specialist | FBI-DOJ: AML Terrorist Financing, Compliance & Legal @ Blockdaemon, U.S. DOJ Financial Intelligence, U.S. Army Intelligence (Pentagon) | --- ## 13. Conclusion The solver is live. Stealth settlement works today. The compliance oracle is specified as an open standard [21]. What's left is proving it to regulators, and we're building on infrastructure we own. --- ## References ### MEV and Market Structure 1. European Securities and Markets Authority. "Maximal Extractable Value: Implications for crypto markets." ESMA TRV Risk Analysis, ESMA50-481369926-29744, July 2025. https://www.esma.europa.eu/sites/default/files/2025-07/ESMA50-481369926-29744_Maximal_Extractable_Value_Implications_for_crypto_markets.pdf 2. ESMA. "Joint Report on recent developments in crypto-assets (Art. 142 MiCA)." ESMA75-453128700-1391, January 2025. https://www.esma.europa.eu/sites/default/files/2025-01/ESMA75-453128700-1391_Joint_Report_on_recent_developments_in_crypto-assets__Art_142_MiCA_.pdf 3. "SoK: The Evolution of Maximal Extractable Value, From Miners to Cross-Chain." arXiv:2603.07716, March 2025. https://arxiv.org/html/2603.07716v1 4. Wahrstaetter, T. MEV-Boost Pics (open-source relay analytics, post-Merge). https://mevboost.pics 5. Bank for International Settlements. "OTC Foreign Exchange Turnover in April 2025." BIS Triennial Central Bank Survey, September 2025. https://www.bis.org/statistics/rpfx25_fx.htm ### Regulatory 6. European Parliament and Council. "Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA)." Official Journal of the EU, OJ L 150, June 2023. https://eur-lex.europa.eu/eli/reg/2023/1114/oj/eng 7. Circle. "Circle is First Global Stablecoin Issuer to Comply with MiCA." July 2024. https://www.circle.com/pressroom/circle-is-first-global-stablecoin-issuer-to-comply-with-mica-eus-landmark-crypto-law 8. Virtual Assets Regulatory Authority. "Virtual Assets and Related Activities Regulations 2023." Dubai, Law No. (4) of 2022. https://rulebooks.vara.ae/rulebook/virtual-assets-and-related-activities-regulations-2023 9. Mayer Brown. "VARA's New Regulations for Virtual Assets." March 2023. https://www.mayerbrown.com/en/insights/publications/2023/03/varas-new-regulations-for-virtual-assets 10. CoinDesk. "Dubai Bans Privacy Tokens, Tightens Stablecoin Rules in Crypto Reset." January 12, 2026. https://www.coindesk.com/policy/2026/01/12/dubai-bans-privacy-tokens-tightens-stablecoin-rules-in-crypto-reset 11. European Parliament. "Regulation (EU) 2016/679 (GDPR), Article 5(1)(c): Data Minimization." https://gdpr-info.eu/art-5-gdpr/ ### Macro 12. International Monetary Fund. "Currency Composition of Official Foreign Exchange Reserves (COFER)." Q4 2025 data (released March 2026). https://data.imf.org/en/datasets/IMF.STA:COFER 13. Federal Reserve. "The International Role of the U.S. Dollar, 2025 Edition." July 2025. https://www.federalreserve.gov/econres/notes/feds-notes/the-international-role-of-the-u-s-dollar-2025-edition-20250718.html ### Standards and Implementations 14. Wahrstatter, T., Solomon, M., DiFrancesco, B., Buterin, V. "ERC-5564: Stealth Addresses." Ethereum Improvement Proposals. Status: Final. https://eips.ethereum.org/EIPS/eip-5564 15. Wahrstatter, T., Solomon, M., DiFrancesco, B., Buterin, V. "ERC-6538: Stealth Meta-Address Registry." Ethereum Improvement Proposals. Status: Final. https://eips.ethereum.org/EIPS/eip-6538 16. Trail of Bits. "ScopeLift Stealth Address Contracts Audit." February 2024. https://github.com/trailofbits/publications 17. ScopeLift. Stealth Address SDK and Canonical Contracts. https://github.com/ScopeLift/stealth-address-sdk 18. Ethereum Foundation. "ERC-4337: Account Abstraction Using Alt Mempool." Ethereum Improvement Proposals. Status: Final. https://eips.ethereum.org/EIPS/eip-4337 19. Pimlico. "SimpleAccount and Paymaster Documentation." https://docs.pimlico.io 20. DROOdotFOO. "Raxol: Terminal Framework for TUI Apps and AI Agents." MIT License. https://github.com/DROOdotFOO/raxol/tree/master. RAXOL token (live, Robinhood Chain): https://app.virtuals.io/virtuals/95590 (contract 0xf44702b17d9abD53815F703e772F35E9c71A53af) 21. DROO, Bloo. "ERC-8262: Zero-Knowledge Compliance Oracle." Ethereum Improvement Proposals. Status: Draft. Discussion: https://ethereum-magicians.org/t/erc-8262-zero-knowledge-compliance-oracle/28543. Reference implementation: https://github.com/xochi-fi/ERC-8262 22. axol-io. "Mana: Elixir Ethereum Execution Client." Apache 2.0 + MIT. https://github.com/axol-io/mana --- _This document is for informational purposes only and does not constitute financial, legal, or investment advice. Protocol parameters and projections are subject to change based on market conditions and governance decisions. Enhanced privacy tiers use Aztec L2 via pxe-bridge (in deployment). Xochi's ZK Compliance Oracle is a novel compliance approach without regulatory precedent._ --- # Appendix # Xochi Technical Appendix Appendix to the [Xochi Whitepaper](./whitepaper.md). API specs, fee tables, solver requirements, and glossary. ## Table of Contents - [A. Intent API Endpoints](#a-intent-api-endpoints) - [B. EIP-712 Intent Signatures](#b-eip-712-intent-signatures) - [C. Complete Fee Matrix](#c-complete-fee-matrix) - [D. Solver Specifications](#d-solver-specifications) - [E. Xochi's ZK Compliance Oracle Proof Types](#e-xochis-zk-compliance-oracle-proof-types) - [F. Trust Score Providers](#f-trust-score-providers) - [G. Glossary](#g-glossary) - [H. Widget SDK (Upcoming)](#h-widget-sdk-upcoming) - [I. Formal Derivations](#i-formal-derivations) - [J. Execution Specifications](#j-execution-specifications) --- ## A. Intent API Endpoints Auth roles (defined in the [glossary](#g-glossary)): **Member** (passkey JWT), **Guest** (x402 micropayment), or both. JWT and x402 are alternatives, not additive: send `Authorization` for Member, send `X-PAYMENT` for Guest. Routes marked "Member or Guest" accept both. Routes marked "Member" require JWT; the Mandate path (Member-signed envelope authorizing an Agent, presented as `X-Xochi-Delegation`) is live. Public routes need no auth. For machine-readable specs see [`/openapi.yaml`](https://xochi.fi/openapi.yaml) (V1 surface, 10 endpoints) and [`/.well-known/agents.json`](https://xochi.fi/.well-known/agents.json) (full x402 catalog with prices). ### Market Orders ``` POST /api/intent/quote # Get solver quotes [public] POST /api/intent/execute # Execute signed intent [Wallet / Member / Guest, x402: $0.01] GET /api/intent/:id # Get intent details [public] GET /api/intent/:id/status # Get execution status [public] GET /api/intent/history # User trade history [Member, wallet-owner] ``` ### Limit Orders ``` POST /api/intent/limit-quote # Quote for limit order [public] POST /api/intent/limit-submit # Submit limit order [Member / Guest, x402: $0.01] GET /api/intent/limit-orders # List active limits [Member, wallet-owner] DELETE /api/intent/limit/:id # Cancel limit order [Member, wallet-owner] ``` ### Trust & Privacy ``` POST /api/attestation # Submit attestation [Member] GET /api/attestation # Get attestations [Member] POST /api/tier-proof/verify # Verify tier proof [Member] GET /api/tier-proof # Get tier proofs [Member] ``` ### Settlements ``` POST /api/settlement/claim # Claim shielded settlement [Member / Guest, x402: $0.005] GET /api/settlement # Query settlements for a wallet [Member, wallet-owner] ``` ### Solver Revenue ``` POST /api/solver/deposit # Batch settlement from Riddler [Member] GET /api/solver/stats # Revenue tracking [public] GET /api/solver/history # Recent solver fills [public] ``` ### Stealth Addresses (ERC-5564/6538) L1 privacy via one-time receiving addresses. Open to every wallet, no trust-score gate (privacy is free by default). ``` GET /api/stealth/meta-address # Lookup stealth meta-address [Member, wallet-owner] POST /api/stealth/register # Register stealth meta-address [Member] GET /api/stealth/announcements # Query announcements by view tag [Member] POST /api/stealth/claim/prepare # Build the keyless claim UserOp [Member] POST /api/stealth/claim/submit # Broadcast the signed claim [Member] ``` ### Prices ``` GET /api/prices # Token prices, USD, 60s edge cache [public] ``` ### Capabilities ``` GET /api/capabilities # Solver capability matrix (chains/tokens/bounds) [public] ``` ### Real-time ``` WS /ws # Intent status updates [Member] ``` ### Riddler Solver API (`/xochi/*`) Xochi's own API surface on the Riddler solver. Own schema, own fee tiers, own settlement targets. ``` POST /xochi/quote # Quote with tier-based fees + stealth info POST /xochi/execute # Execute signed intent (EIP-712) POST /xochi/claim # Gasless stealth claim (ERC-4337) GET /xochi/status/:intent_id # Intent status with stealth/counterfactual fields GET /xochi/chains # Supported chains GET /xochi/routes # Supported routes GET /xochi/health # Health check ``` **Stealth claim flow**: When settlement type is "stealth", tokens land at a counterfactual ERC-4337 SimpleAccount. The recipient calls `/xochi/claim` with their stealth keys and a destination address (Safe, EOA). The server derives the stealth signing key, builds a Pimlico-sponsored UserOperation, and submits it to the bundler. Account deployment + token transfer happen atomically in one gasless step. **Quote response** includes `claimInfo` for stealth settlements: ```json { "claimInfo": { "factoryAddress": "0x91E60e0613f8E48b12EFC11BcAfB4dDA7763EC23", "salt": 0 } } ``` **Announcement metadata** (109 bytes, ERC-5564 extension): ``` view_tag(1) || token(20) || selector(4) || amount(32) || factory(20) || salt(32) ``` --- ## B. EIP-712 Intent Signatures ### Xochi Frontend Intent (existing) ```typescript const intentTypes = { Intent: [ { name: "sellToken", type: "address" }, { name: "buyToken", type: "address" }, { name: "sellAmount", type: "uint256" }, { name: "minBuyAmount", type: "uint256" }, { name: "deadline", type: "uint256" }, { name: "privacyTier", type: "uint8" }, { name: "nonce", type: "uint256" }, ], }; ``` ### Riddler XochiIntent (solver-side) Signed by the user's wallet when executing via the `/xochi/execute` endpoint. The wallet signs the solver-served typed data verbatim; the struct is solver-versioned and VM-agnostic (a leg can be a base58 Tron address, so token/recipient fields are strings). Current version is v3. Domain: name "Xochi", a deploy-scoped `version` (e.g. "3-prod"), `chainId` = origin chain, and `salt` = keccak256(version); no `verifyingContract`. ```typescript const xochiIntentTypes = { XochiIntent: [ { name: "intentId", type: "string" }, { name: "quoteId", type: "string" }, { name: "wallet", type: "address" }, // signer is always an EVM key { name: "recipient", type: "string" }, // VM-agnostic payout address { name: "fromChainId", type: "uint256" }, { name: "toChainId", type: "uint256" }, { name: "fromToken", type: "string" }, // string, not address (base58 TRC-20) { name: "toToken", type: "string" }, { name: "fromAmount", type: "uint256" }, { name: "toAmount", type: "uint256" }, { name: "settlementPreference", type: "string" }, { name: "deadline", type: "uint256" }, ], }; ``` --- ## C. Complete Fee Matrix ### Trading Fees by Tier Fees are shown stablecoin / volatile (ETH/WETH). Each total decomposes into a never-discounted solver cost layer plus a tier-discounted venue + routing layer. The MEV rebate is retired; the solver shares 15% of price improvement instead (see Settlement Types). | Tier | Trust Score | Stable | Volatile | | ------------- | ----------- | ------ | -------- | | Standard | 0-24 | 0.22% | 0.40% | | Trusted | 25-49 | 0.19% | 0.35% | | Verified | 50-74 | 0.15% | 0.29% | | Premium | 75-99 | 0.12% | 0.25% | | Institutional | 100+ | 0.10% | 0.22% | ### Privacy Level Fees The deeper privacy levels (Private, Sovereign) are gated by trust score; L1 stealth is open to all. The effective fee equals your trust tier's base fee. Higher trust unlocks deeper privacy at a lower rate. | Privacy Level | Min Trust Score | Fee at Min Trust (stable / volatile) | | ------------- | --------------- | ------------------------------------ | | Open | None | -0.02% (flat) | | Public | None | 0% (flat) | | Standard | 0 | 0.22% / 0.40% | | Stealth | None | 0.22% / 0.40% | | Private | 50 | 0.15% / 0.29% | | Sovereign | 75 | 0.12% / 0.25% | Open and Public are flat-rate tiers: Open pays users -0.02% plus analytics (loss leader), Public is free. For Standard through Sovereign, the fee is determined by trust tier (see Trading Fees table above). Users with trust scores above the minimum for their chosen privacy level pay their trust tier rate. ### Settlement Types | Type | Layer | Availability | Trust Score | Description | | -------- | ----- | ------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------ | | public | L1 | Now | 0+ | Standard wallet address | | stealth | L1 | Now | 0+ | One-time stealth address (ERC-5564 + gasless ERC-4337 claim) | | shielded | L2 | In deployment | 50+ | Aztec shielded note via [pxe-bridge](https://github.com/xochi-fi/pxe-bridge) (embedded PXE, see [Glossary](#g-glossary)) | ### FX Fees | Trade Size | Base Fee | Notes | | ------------ | -------- | --------------- | | <\$100K | 0.08% | Trust tier rate | | \$100K-\$1M | 0.05% | Trust tier rate | | \$1M-\$10M | 0.03% | Trust tier rate | | >\$10M (OTC) | 0.02% | Negotiated | ### Other Fees | Source | Fee | Notes | | ----------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Intent surplus | 15% | Of price improvement | | OTC (\$100K+) | 0.02-0.04% | Size-based | | x402 (Guest mode) | $0.0001-$0.01 | Per-call micropayment when Agents transact without a Member account. Read endpoints $0.0001, premium writes $0.005-$0.01. See [agents.json](https://xochi.fi/.well-known/agents.json) `x402.endpoints` for the full catalog. | ### Partner Revenue Share | Monthly Volume | Revenue Share | | -------------- | ------------- | | <\$1M | 10% | | \$1-10M | 15% | | \$10-50M | 18% | | >\$50M | 20% | --- ## D. Solver Specifications ### Standard Solver Requirements | Requirement | Threshold | Purpose | | ----------- | --------- | ------------------- | | Stake | TBD | Slashing collateral | | Fill rate | >95% | Reliability | | Latency | <500ms | UX consistency | | Uptime | >99.5% | Availability | ### FX Solver Requirements | Requirement | Threshold | Notes | | ------------------ | --------- | --------------------- | | Stake | TBD | 5x base | | Quote validity | 30s | vs 60s for crypto | | Slippage tolerance | 0.02% max | Tighter than crypto | | Settlement time | <5 min | | | Min volume | \$500K/mo | For probation removal | ### Slashing Events | Event | Penalty | | ---------------------------- | ---------------------- | | Failed fill after commitment | 0.1% of trade size | | Price manipulation detected | 100% of stake | | Latency violation (3x) | Warning, then 1% stake | ### Solver Onboarding 1. Stake collateral (amount TBD) 2. Submit compliance attestation (jurisdiction, license type) 3. Pass technical integration test 4. 7-day probation period (limited volume) 5. Full activation ### Riddler: Current Performance | Metric | Value | | --------------- | ------------------------------------------------------------ | | P95 Latency | <6 seconds | | Delivery Time | ~2.1 seconds | | Live Chains | Ethereum, Optimism, Base, Arbitrum, Polygon, Robinhood Chain | | Integrations | LiFi, Across, CCTP, Everclear netting | | Upcoming Chains | Tron, Solana, Aztec (pxe-bridge deployed) | Riddler (protocol solver) is the primary active solver. External solver onboarding is open and permissionless. Contact team for integration support. --- ## E. Xochi's ZK Compliance Oracle Proof Types | Circuit | Code | Assertion | Hidden Data | | ----------------------- | ---- | ----------------------------------- | -------------------- | | Compliance | 0x01 | "Score below jurisdiction X" | Exact score, signals | | Risk Score | 0x02 | "Score > X" / "Score in [X,Y]" | Exact score | | Pattern Detection | 0x03 | "Pattern P not detected" | Transaction history | | Attestation | 0x04 | "Valid attestation exists" | Attestation details | | Membership | 0x05 | "Address in set S" | Which element | | Non-Membership | 0x06 | "Address NOT in set S" | Set contents | | Compliance Signed | 0x07 | Compliance + provider secp256k1 sig | Signals, score, sig | | Risk Score Signed | 0x08 | Risk Score + provider secp256k1 sig | Exact score, sig | | Compliance Multi-Signed | 0x09 | M of N providers attest (up to 5) | Per-provider data | Signed variants (0x07, 0x08) bind a secp256k1 ECDSA signature in-circuit over the screening payload, plus `chain_id` and `oracle_address` (audit F-6) to prevent cross-chain or cross-deployment replay. The multi-signed variant (0x09) aggregates M independent signers under AND-semantics with a runtime `threshold_m`; jurisdictions configure a minimum (`JurisdictionConfig.minMultiProviderThreshold`: EU=1, US=2, UK=1, SG=2, UAE=2). Per-jurisdiction `requireSignedSignals` decides whether unsigned proofs are acceptable: US (BSA), Singapore, and UAE (VARA) require signed; EU (AMLD6) and UK (MLR) accept either. The `signer_pubkey_hash` public input is validated against an on-chain registry, so a compromised provider can be rotated without redeploying circuits. Formal derivations for the unsigned circuits in [Appendix I](#i-formal-derivations). Signed-variant circuits share the public-input shape of their base circuit (0x07 with 0x01, 0x08 with 0x02) plus the in-circuit signature check; 0x09 extends 0x07 with M parallel signer slots. ### Jurisdiction Thresholds | Jurisdiction | Low | Medium | High | Filing Trigger | | ------------ | ---- | ------ | ---- | -------------- | | EU (AMLD6) | 0-30 | 31-70 | >70 | High | | US (BSA) | 0-25 | 26-65 | >65 | High | | UK (MLR) | 0-30 | 31-70 | >70 | High | | Singapore | 0-35 | 36-75 | >75 | High | | UAE (VARA) | 0-30 | 31-70 | >70 | High | --- ## F. Trust Score Providers ### Humanity (Max 25 points) | Provider | Points | Verification Method | Data Stored | | -------------- | ------ | ------------------------ | --------------- | | Humanode | 15 | Biometric PoH | Hash only | | Idena | 18 | AI-resistant tests | Hash only | | Human Passport | 18 | Aggregated sybil scoring | Score + stamps | | Worldcoin | 8 | Orb-verified iris | Nullifier hash | | BrightID | 10 | Social graph | Connection hash | ### Identity (Max 35 points) | Provider | Points | Verification Method | Data Stored | | ----------------- | ------ | ----------------------- | ----------- | | ZKPassport | 30 | Government ID via ZK | Hash only | | Privado ID | 32 | ZK identity credentials | Claim hash | | Coinbase Verified | 25 | Exchange-level KYC | Status only | | Civic | 22 | Identity verification | Hash only | ### Reputation (Max 20 points) | Provider | Points | Verification Method | Data Stored | | ------------- | ------ | -------------------- | ----------- | | ENS | 10 | Domain ownership | Boolean | | Lens Protocol | 6 | Social graph history | Boolean | ### Compliance (Max 40 points) | Provider | Points | Verification Method | Data Stored | | ------------- | ------ | -------------------- | ----------- | | Chainalysis | 20 | Sanctions screening | Risk flag | | Xochi History | 15 | Clean trading record | Flag status | ### Diminishing Returns - 1st provider in category: 100% of points - 2nd provider: 25% of points - 3rd+ providers: 10% of points ### Score Reachability | Tier | Score Required | Typical Path | Target User | | ------------- | -------------- | ----------------------- | ----------------- | | Standard | 0-24 | Default | Anyone | | Trusted | 25-49 | 1 humanity + 1 identity | Retail | | Verified | 50-74 | 2 categories maxed | Power users | | Premium | 75-99 | 3 categories + history | DAOs, funds | | Institutional | 100+ | Full compliance stack | Licensed entities | Maximum achievable: ~120 points. Most retail users reach Trusted or Verified. Institutional tier requires licensed compliance providers (Chainalysis) and is designed for entities, not individuals. --- ## G. Glossary **Aztec**: Zero-knowledge L2 for private smart contract execution on Ethereum. Unlike EVM chains where all execution is public and replayed by every node, Aztec splits transactions into a private phase (executed locally) and a public phase (executed on-network). Private state is encrypted and only visible to its owner. Alpha Network live (v4.x, March 2026). Explicitly experimental: known proving system vulnerability (v5 fix targeting July 2026), state not migrated between releases, ~$6.5M max safe value. 3,500+ sequencers, 50+ provers. Uses AIP-20/AIP-721 token standards (not ERC-20/721). Xochi connects via [pxe-bridge](https://github.com/xochi-fi/pxe-bridge). **PXE (Private eXecution Environment)**: Aztec's local runtime for the private half of transactions. The PXE holds encrypted notes (Aztec's UTXO-like balance model), executes private contract functions locally, generates zero-knowledge proofs of correct execution, and submits those proofs to the Aztec network. The network never sees the plaintext inputs. pxe-bridge embeds a PXE and wraps it in JSON-RPC so that EVM solvers can create shielded notes without understanding Aztec's privacy model. **CCTP**: Circle's Cross-Chain Transfer Protocol for native USDC transfers. **EIP-712**: Ethereum standard for typed structured data hashing and signing. **Intent**: User-signed message expressing desired trade outcome without specifying execution path. **MEV**: Maximal Extractable Value. Profit from reordering, inserting, or censoring transactions. **Riddler**: Xochi's protocol solver. Live on Ethereum, Optimism, Base, Arbitrum, Polygon, Robinhood Chain (USDG). <6s P95, ~2.1s delivery. Integrated with LiFi and Across. **Solver**: Entity that fills intents by sourcing liquidity and executing trades. **Stealth Address**: One-time receiving smart account derived via ECDH from a meta-address. ERC-5564 defines announcements; ERC-6538 defines the registry. Provides L1 settlement privacy. **Xochi's ZK Compliance Oracle**: Zero-knowledge compliance proofs that verify regulatory conditions (AML, sanctions, thresholds) without revealing transaction data. Formalized as [ERC-8262](https://ethereum-magicians.org/t/erc-8262-zero-knowledge-compliance-oracle/28543). Formerly referred to as ZKSAR (the name used in the legal documentation). ### Additional Terms **Account Abstraction (AA, ERC-4337)**: Ethereum standard that lets smart contracts act as wallets. Enables gasless transactions (someone else pays the gas), batched operations, and custom authentication logic. Xochi uses it for stealth settlement so recipients can claim tokens without holding ETH. **Agent**: Automated principal that holds its own keypair and transacts through Xochi as a Guest (anonymous, x402 pay-per-call) or under a Member's Mandate. See [Member, Mandate, Guest](#g-glossary) below. **AML**: Anti-Money Laundering. Regulations requiring financial institutions to detect and report suspicious activity. **Basis Points (bps)**: 1 bps = 0.01%. Used for expressing small fee percentages. 22 bps = 0.22% (the Standard-tier stablecoin fee). **CEX**: Centralized exchange (Binance, Coinbase). Custodial platform where the operator holds user funds. **Counterfactual**: A smart contract whose address is deterministic (computable in advance) but not yet deployed on-chain. It exists "in theory" until someone sends a transaction that deploys it. Xochi uses counterfactual SimpleAccounts for stealth settlement. **DCA**: Dollar-Cost Averaging. Recurring purchases of an asset at fixed intervals to smooth out price volatility. **DEX**: Decentralized exchange. Non-custodial trading venue where swaps execute via smart contracts. Examples: Uniswap, Curve. **ECDH**: Elliptic Curve Diffie-Hellman. A key exchange protocol used in stealth address derivation. Allows two parties to generate a shared secret from their public keys without prior communication. **Everclear**: Netting protocol for cross-chain transfers. When two opposing flows exist (A sends to B, C sends from B to A), they cancel out, reducing on-chain transactions. **Flash Loan**: Uncollateralized loan borrowed and repaid within a single blockchain transaction. If repayment fails, the entire transaction reverts. Used to amplify solver capacity without custody risk. **Frontrunning**: Trading ahead of a known pending transaction to profit from the expected price movement. **Gas**: The unit of computational cost on Ethereum. Users pay gas fees (in ETH) to compensate validators for processing transactions. "Gasless" means a third party (paymaster) covers the fee. **Guest**: An Agent transacting through Xochi without a Member account. Pays per call via x402 micropayments. Capped at Standard tier privacy. **Iceberg Order**: A large order split into smaller visible pieces. Only one slice is shown at a time; when it fills, the next slice appears. Hides the full order size. **KYC**: Know Your Customer. Identity verification required by financial regulations. **L1**: Layer 1. The base blockchain (Ethereum mainnet). Transactions settle here with full finality. **L2**: Layer 2. Chains that execute transactions off L1 and post compressed proofs back to it. Cheaper and faster than L1. Examples: Optimism, Arbitrum, Aztec. **Mandate**: An EIP-712 envelope signed by a Member that authorizes a specific Agent wallet to act on the Member's behalf within scoped limits (max amount, expiry, call count). Presented per-request as `X-Xochi-Delegation`; the server verifies it without persisting any (Agent, Member) link. Revoked by the delegator via `POST /api/auth/mandate/revoke`. Live. **Member**: A human authenticated via XID (passkey). Earns Trust Score through attestations, can issue Mandates to Agents. **Mempool**: The queue of pending transactions waiting to be included in a block. Public on most chains, which is why MEV bots can see and frontrun your trades. **Meta-address**: A public key pair (spending + viewing) from which stealth addresses are derived. Published once; used to generate unlimited one-time receiving addresses (ERC-6538). **MiCA**: Markets in Crypto-Assets. EU regulation for crypto-asset service providers, effective 2024. **Noir**: A domain-specific language for writing zero-knowledge circuits, developed by Aztec. Compiles to arithmetic circuits proven by Barretenberg (the proving backend). UltraHonk is the proof system. BN254 is the elliptic curve. **Nullifier**: A value derived from a note that, when revealed, marks the note as spent. Prevents double-spending without revealing which note was consumed. **OTC**: Over-the-counter. Direct trades between two parties, typically for large sizes ($100K+), negotiated outside public order books. **Pimlico**: An ERC-4337 paymaster and bundler service. Sponsors gas for Xochi's gasless stealth claims. **Privacy Pool (category)**: Any anonymity-set primitive that lets a user prove membership or non-membership in a set without revealing which element. Examples: Railgun, Panther, 0xbow's Privacy Pools. Operates at the deposit layer; does not hide trade execution. **Privacy Pools (0xbow)**: Specific product implementing deposit set membership proofs ("my deposit isn't in the sanctioned set"). Live on mainnet since March 2025. Composes with Xochi: clean withdrawal from Privacy Pools, then private execution via Xochi. **Private Execution Venue**: Xochi's category. A trading venue that hides the swap itself, not just the wallet or deposit history. Distinct from privacy pools (deposit layer) and privacy L1s (separate chains). **SAR**: Suspicious Activity Report. A filing that financial institutions submit to regulators when they detect potentially illicit activity. **Sandwich Attack**: An MEV attack where a bot inserts a buy order before your trade and a sell order after it, profiting from the price impact your trade creates. **Schnorr Account**: An Aztec account type using Schnorr signatures for authentication. pxe-bridge derives a deterministic Schnorr account from the configured secret key. **Shielded Note**: Xochi's term for what Aztec docs call a "private note" or just a "note". An encrypted UTXO that only the owner's PXE can decrypt and spend. **Slippage**: The difference between the expected price of a trade and the price at execution. Caused by market movement or insufficient liquidity. **TWAP**: Time-Weighted Average Price. An execution strategy that splits a large order into equal-sized slices over a time window to reduce market impact. **USDG**: Global Dollar. A regulated USD stablecoin issued by Paxos. Native stablecoin of Robinhood Chain, which has no USDC; Riddler settles USDC<->USDG cross-asset corridors to and from it. **UTXO**: Unspent Transaction Output. A balance model (used by Bitcoin, Aztec) where funds are represented as discrete "notes" rather than account balances. Spending a note consumes it entirely and creates new notes for the recipient and change. **VARA**: Virtual Assets Regulatory Authority. Dubai's crypto regulator, operating under Law No. (4) of 2022. **VASP**: Virtual Asset Service Provider. Any entity that conducts virtual asset transactions on behalf of others. Defined by FATF and adopted by VARA, MiCA, and other frameworks. **View Key**: A cryptographic key that allows a third party to see (but not spend) private transaction data. Some privacy protocols use view keys for auditability. Xochi's ZK Compliance Oracle avoids this by proving compliance without creating viewable data. **x402**: HTTP 402 Payment Required protocol for pay-per-call API access (https://x402.org). Xochi accepts x402 USDC payments on writes ($0.005-$0.01) and reads ($0.0001) so Guests can transact without a Member account. JWT and x402 are alternatives, not additive. **Zero-Knowledge Proof (ZKP)**: A cryptographic proof that a statement is true without revealing the underlying data. Example: proving your age is over 18 without revealing your birthdate. --- ## H. Widget SDK (Upcoming) ### Installation ```bash npm install @xochi/widget-react ``` ### Basic Usage ```tsx import { XochiWidget } from "@xochi/widget-react"; console.log(tx)} />; ``` ### Configuration ```typescript interface XochiWidgetParams { appCode: string; chainId?: number; enabledChains?: number[]; // [1, 42161, 10, 8453] defaultPrivacy?: PrivacyTier; // "standard" | "shielded" | "private" | "sovereign" partnerFee?: { bps: number; recipient: string }; theme?: "light" | "dark" | CustomTheme; mode?: "swap" | "fx" | "fx-api"; pairs?: string[]; // For FX mode: ["USDC/EURC"] batchEnabled?: boolean; // For fx-api mode webhookUrl?: string; // For fx-api mode exportFormat?: "csv" | "json"; // For reconciliation } ``` ### Events ```typescript const listeners = { onQuoteReceived: (quote: Quote) => void, onTradeComplete: (result: TradeResult) => void, onTradeFailed: (error: Error) => void, onPrivacyTierChange: (tier: PrivacyTier) => void, }; ``` ### Partner Tiers | Tier | Max Fee | Requirements | Perks | | ---------- | ------- | ------------ | ------------- | | Standard | 25 bps | None | Self-service | | Premium | 50 bps | \$100K/mo | Hide branding | | Enterprise | Custom | Contact | White-label | --- ## I. Formal Derivations Mathematical specifications for the Xochi ZK Compliance Oracle. Each section defines a predicate proven in zero knowledge: the verifier learns only the public inputs, never the private witness. Reference implementation: [ERC-8262](https://github.com/xochi-fi/ERC-8262). Proof system: UltraHonk (Barretenberg). Circuit language: Noir. Merkle depth: 20 (capacity: $2^{20}$ leaves). **Hash functions.** All commitments use Pedersen hash over the BN254 curve via fixed-arity wrappers ($H_2, H_3, H_4, H_6, H_8, H_{16}, H_{32}$). Domain separation between contexts is achieved by prepending an explicit domain-tag field constant to the hash input. The reference implementation defines eight tags (internal Merkle nodes, set-bound leaves, value leaves, subject-bound leaves, credential hashes, signed-variant payload, multi-signed slot payload, and signer pubkey commitment); three further commitments (provider set, config, transaction set) are fixed-arity hashes over a single context and rely on the input layout itself for distinctness. Pedersen does not separate domains by arity alone: trailing-zero generators collapse to identity, so $H_n([a, b, 0, \ldots, 0]) = H_m([a, b])$ for $m < n$ without an explicit tag. Migration to Poseidon2 is planned when stable high-level APIs are available in Noir. ### I.1 Risk Score Given $n \leq 8$ screening providers, each returning a signal $s_i \in [0, 100]$ with published weight $w_i \in [1, 10000]$: $$R = \frac{\left(\sum_{i=1}^{n} s_i \cdot w_i\right) \cdot 100}{\sum_{i=1}^{n} w_i}$$ $R$ is in basis points: 0 = 0.00%, 10000 = 100.00%. Integer division truncates (max error $< 1$ bps). **Overflow bound.** Worst case: $n = 8$, $s_i = 100$, $w_i = 10000$. $$8 \times 100 \times 10000 \times 100 = 800{,}000{,}000 < 2^{32} - 1 = 4{,}294{,}967{,}295$$ All intermediate values fit in u32. No modular reduction occurs. **Commitment.** The prover commits to the provider set via $\text{provider\_set\_hash} = H_{16}(\text{id}_1, w_1, \ldots, \text{id}_8, w_8)$ and to the weight configuration via $\text{config\_hash} = H_8(w_1, \ldots, w_8)$. The verifier checks these against published on-chain values. The prover also supplies $W = \sum w_i$ and the circuit verifies $W$ matches the sum, preventing denominator spoofing. ### I.2 Compliance (Circuit 0x01) Proves a risk score is below a jurisdiction's high-risk filing threshold. **Public inputs:** jurisdiction $j \in \{0,1,2,3,4\}$, provider_set_hash, config_hash, timestamp $t$, result $m \in \{0,1\}$. **Private inputs:** signals $\{s_i\}$, weights $\{w_i\}$, weight sum $W$, provider IDs $\{p_i\}$, provider count $n$. **Predicate:** $$m = \begin{cases} 1 & \text{if } R < T_j \\ 0 & \text{otherwise} \end{cases}$$ where $R$ is the risk score (I.1) and $T_j$ is the jurisdiction threshold: | $j$ | Jurisdiction | $T_j$ (bps) | Equivalent | | --- | ------------ | ----------- | ---------- | | 0 | EU (AMLD6) | 7100 | 71% | | 1 | US (BSA) | 6600 | 66% | | 2 | UK (MLR) | 7100 | 71% | | 3 | Singapore | 7600 | 76% | | 4 | UAE (VARA) | 7100 | 71% | **Constraints:** 1. $1 \leq n \leq 8$ 2. $\forall i < n: s_i \leq 100 \land w_i > 0 \land p_i \neq 0$ 3. $\forall i \geq n: s_i = 0 \land w_i = 0 \land p_i = 0$ 4. $W = \sum_{i=1}^{8} w_i$ 5. $\text{provider\_set\_hash} = H_{16}(p_1, w_1, \ldots, p_8, w_8)$ 6. $\text{config\_hash} = H_8(w_1, \ldots, w_8)$ 7. $t > 1609459200 \land t < 2^{40}$ (after 2021, before year ~36812) ### I.3 Risk Score (Circuit 0x02) Standalone risk score proof supporting threshold and range predicates. Like Compliance (I.2), this circuit commits to the provider set, preventing a prover from fabricating signals from unverified providers. **Public inputs:** proof_type $\tau$, direction $d$, lower bound $\ell$, upper bound $u$, result $r$, config_hash, provider_set_hash. **Private inputs:** signals $\{s_i\}$, weights $\{w_i\}$, weight sum $W$, provider IDs $\{p_i\}$, provider count $n$. **Predicate:** $$r = \begin{cases} R > \ell & \text{if } \tau = \texttt{0x01} \land d = 1 \text{ (GT)} \\ R < \ell & \text{if } \tau = \texttt{0x01} \land d = 2 \text{ (LT)} \\ \ell \leq R \leq u & \text{if } \tau = \texttt{0x02} \text{ (range)} \end{cases}$$ **Constraints:** 1. $1 \leq n \leq 8$ 2. $\forall i < n: s_i \leq 100 \land w_i > 0 \land p_i \neq 0$ 3. $\forall i \geq n: s_i = 0 \land w_i = 0 \land p_i = 0$ 4. $W = \sum_{i=1}^{8} w_i$ 5. $\text{config\_hash} = H_8(w_1, \ldots, w_8)$ 6. $\text{provider\_set\_hash} = H_{16}(p_1, w_1, \ldots, p_8, w_8)$ ### I.4 Pattern Detection (Circuit 0x03) Proves a transaction set exhibits no structuring, velocity, or round-amount anomalies. **Public inputs:** analysis_type $a$, result $r$ (true = clean), reporting threshold $T$, time window $\Delta t$, tx_set_hash. **Private inputs:** amounts $\{v_k\}$, timestamps $\{t_k\}$, count $n \leq 16$. **Commitment:** $\text{tx\_set\_hash} = H_{32}(v_1, t_1, v_2, t_2, \ldots, v_{16}, t_{16})$ **Constraints:** 1. $1 \leq n \leq 16$ 2. $\Delta t > 0$ 3. $\forall k < n: t_k > 1609459200 \land t_k < 2^{40}$ (timestamp sanity on active transactions) 4. $\forall k \geq n: v_k = 0 \land t_k = 0$ (inactive slots zeroed) **Overflow bound.** The floor calculation $T \cdot 90$ must not overflow u64. The circuit enforces $T \leq \lfloor 2^{64} / 90 \rfloor = 204{,}962{,}515{,}653{,}461{,}695$. **Structuring** ($a = 1$). Let $F = \lfloor T \cdot 90 / 100 \rfloor$ (floor at 90% of threshold). Count suspicious transactions: $$C_s = \left|\{k : F \leq v_k < T\}\right|$$ $$r = \left(C_s < \left\lceil n/2 \right\rceil\right)$$ Clean if fewer than half of transactions cluster just below the reporting threshold. **Velocity** ($a = 2$). Let $t_{\max} = \max_k t_k$. Count transactions in the window: $$C_v = \left|\{k : t_k \geq t_{\max} - \Delta t\}\right|$$ $$r = (C_v \leq 10)$$ **Round amounts** ($a = 3$). Count amounts divisible by 1000: $$C_r = \left|\{k : v_k \bmod 1000 = 0\}\right|$$ $$r = (C_r \cdot 100 < n \cdot 80)$$ Clean if fewer than 80% of transactions are round numbers. ### I.5 Attestation (Circuit 0x04) Proves the submitter holds a valid, unexpired credential issued by an authorized provider. Each provider maintains a per-provider Merkle tree of credentials they have issued; the on-chain registry binds each tree root to the issuing `provider_id`, and the Solidity validator checks that the proof's claimed `provider_id` matches the registered provider for the supplied root. **Public inputs:** provider ID $p$, credential type $\kappa \in [1,4]$, result $r$, credential root $\rho$ (the provider's per-provider credentials tree), current timestamp $t_c$, submitter $\sigma$. Credential types: 1 = KYC Basic, 4 = Institutional. Types 2 and 3 are reserved for future use (e.g., KYC Enhanced, Accredited Investor). **Private inputs:** attribute $\alpha$, expiry $t_e$, Merkle index $i$, Merkle path $\pi$. **Credential hash** (single-round Pedersen with explicit domain tag, binding the credential to a specific submitter at issuance time): $$h = H_6(\texttt{DOMAIN\_CREDENTIAL},\; p,\; \sigma,\; \kappa,\; \alpha,\; t_e)$$ **Leaf:** $L = H_2(\texttt{DOMAIN\_LEAF\_VALUE},\; h)$ (value-style leaf hash with explicit tag). **Predicate:** $$r = (t_c < t_e) \land (1 \leq \kappa \leq 4)$$ with the implicit constraint $\text{MerkleVerify}(L, i, \pi) = \rho$ enforced by hard assert: the proof cannot be produced if the leaf is not in the tree. Forging a credential requires either breaking Pedersen preimage resistance on the leaf hash or publishing a new root, which only the provider's authorized publisher EOA can do. ### I.6 Membership (Circuit 0x05) Proves an element belongs to a set (allowlist, approved counterparties). **Public inputs:** Merkle root $\rho$, set ID $\text{sid}$, timestamp $t$, result $r$. **Private inputs:** element $e$, Merkle index $i$, Merkle path $\pi$. **Leaf binding:** $L = H_2(e, \text{sid})$ (prevents cross-set membership claims). **Predicate:** $$r = \left(\text{MerkleRoot}(L, i, \pi) = \rho\right)$$ where MerkleRoot walks from leaf to root using little-endian index bits to determine left/right child placement at each level. ### I.7 Non-Membership (Circuit 0x06) Proves an element is NOT in a sorted set (sanctions list exclusion). Uses an indexed Merkle tree. **Public inputs:** Merkle root $\rho$, set ID $\text{sid}$, timestamp $t$, result $r$. **Private inputs:** element $e$, adjacent leaves $e_{\text{lo}}, e_{\text{hi}}$, their Merkle indices and paths. **Adjacency proof:** $$r = (e_{\text{lo}} < e < e_{\text{hi}}) \land \text{MerkleVerify}(e_{\text{lo}}) \land \text{MerkleVerify}(e_{\text{hi}})$$ where leaf hashes are bound to `set_id`: $L_{\text{lo}} = H_2(e_{\text{lo}}, \text{sid})$, $L_{\text{hi}} = H_2(e_{\text{hi}}, \text{sid})$. **Truncation defense.** The BN254 scalar field is ~254 bits. Ordering comparisons use u64 casts, which truncate. Without range checks, an attacker could craft a 254-bit field element that differs from a real leaf but produces the same u64 after truncation, falsely proving non-membership of a value that IS in the tree. The circuit enforces: $$e, e_{\text{lo}}, e_{\text{hi}} < 2^{64}$$ This makes truncation a no-op: the u64 cast preserves the full value. ### I.8 Trust Score Aggregation Trust scores are computed off-chain from verified attestations across four categories. **Category caps:** | Category $c$ | Cap $M_c$ | | ------------ | --------- | | Humanity | 25 | | Identity | 35 | | Reputation | 20 | | Compliance | 40 | **Diminishing returns.** Within each category, the $j$-th attestation contributes a fraction of its base points $b_j$: $$d(j) = \begin{cases} 1.00 & j = 1 \\ 0.25 & j = 2 \\ 0.10 & j \geq 3 \end{cases}$$ **Category score:** $$C_c = \min\!\left(M_c,\; \sum_{j=1}^{k} b_j \cdot d(j)\right)$$ where attestations within each category are sorted by $b_j$ descending (greedy: highest-value first). **Total trust score:** $$T = \sum_{c} C_c$$ Maximum achievable: ~120. Tier thresholds: | Tier | Score range | Stable | Volatile | | ------------- | ----------- | ------ | -------- | | Standard | $[0, 24]$ | 0.22% | 0.40% | | Trusted | $[25, 49]$ | 0.19% | 0.35% | | Verified | $[50, 74]$ | 0.15% | 0.29% | | Premium | $[75, 99]$ | 0.12% | 0.25% | | Institutional | $[100, +)$ | 0.10% | 0.22% | ### I.9 Fee Function Trust tier and asset class determine the fee. Privacy level determines data retention and is gated by trust score. There is no additive privacy premium. Each total decomposes into a never-discounted solver cost layer plus a tier-discounted venue + routing layer (the MEV rebate is retired; the solver shares 15% of price improvement). **Base fee** (piecewise on trust score $T$ and asset class $a \in \{\text{stable}, \text{volatile}\}$): $$\text{base}(T, \text{stable}) = \begin{cases} 0.22\% & T \in [0, 24] \\ 0.19\% & T \in [25, 49] \\ 0.15\% & T \in [50, 74] \\ 0.12\% & T \in [75, 99] \\ 0.10\% & T \geq 100 \end{cases} \qquad \text{base}(T, \text{volatile}) = \begin{cases} 0.40\% & T \in [0, 24] \\ 0.35\% & T \in [25, 49] \\ 0.29\% & T \in [50, 74] \\ 0.25\% & T \in [75, 99] \\ 0.22\% & T \geq 100 \end{cases}$$ **Privacy level access** requires minimum trust score $T_{\min}(\ell)$: | Privacy level $\ell$ | $T_{\min}(\ell)$ | | -------------------- | ---------------- | | Open | $0$ | | Public | $0$ | | Standard | $0$ | | Stealth | $0$ | | Private | $50$ | | Sovereign | $75$ | **Effective fee** (trust $T$, privacy level $\ell$, asset class $a$): $$F(T, \ell, a) = \begin{cases} -0.02\% & \ell = \text{Open} \\ 0\% & \ell = \text{Public} \\ \text{base}(T, a) & \ell \in \{\text{Standard}, \text{Stealth}, \text{Private}, \text{Sovereign}\} \land T \geq T_{\min}(\ell) \end{cases}$$ Open and Public are flat-rate loss leaders. For Standard through Sovereign, the fee is trust- and asset-based. Higher trust earns both deeper privacy access and a lower total. An Institutional user (100+) pays 0.10% (stable) / 0.22% (volatile) at any privacy level. A Standard user (0-24) pays 0.22% (stable) / 0.40% (volatile) at Standard, the only level they can access. **Additional revenue:** 15% of intent surplus (price improvement over quoted amount), plus solver spread captured by Riddler. ### I.10 Spoofability Score and Weight Updates Each screening provider $i$ carries a spoofability score: $$S_i = \alpha \cdot \frac{F_i}{N_i} + \beta \cdot \frac{1}{C_i} + \gamma \cdot D_i$$ where: - $F_i / N_i$: flagged-to-total address ratio (empirical sybil rate) - $C_i$: forgery cost normalized to USD - $D_i \in [0, 1]$: incident severity index - $\alpha = 0.5$, $\beta = 0.3$, $\gamma = 0.2$, with $\alpha + \beta + \gamma = 1$ **Effective weight:** $$W_i^{\text{eff}} = W_i^{\text{base}} \cdot (1 - \delta \cdot S_i)$$ $\delta = 0.4$ caps the maximum downward adjustment at 40%. **Recovery.** After two consecutive improved review periods (each cycle must improve on the immediately prior one), a provider regains up to 20% of lost weight per cycle: $$W_i^{(t+1)} = W_i^{(t)} + 0.20 \cdot (W_i^{\text{base}} - W_i^{(t)})$$ **Convergence.** After a single incident with no further degradation, recovery to within 1% of base weight takes $\lceil \log_{0.8}(0.01 / \delta \cdot S_i) \rceil$ cycles. For maximum penalty ($\delta \cdot S_i = 0.4$): $\lceil \log_{0.8}(0.025) \rceil = \lceil 16.5 \rceil = 17$ cycles (8.5 years at bi-annual cadence). For typical penalties ($\delta \cdot S_i \leq 0.1$): $\leq 5$ cycles (2.5 years). Review cadence: bi-annual (January/July). Adjustments published 14 days before effect. ### I.11 Security Properties **Soundness.** A computationally bounded prover cannot produce a valid proof for $m = 1$ (meets threshold) when $R \geq T_j$. Inherited from UltraHonk (~128-bit security). Applies to all six circuits. **Zero-knowledge.** The verifier learns only the public inputs. Individual signals, weights, provider identifiers, transaction amounts, timestamps, credential contents, and set elements remain hidden. Pedersen commitments are computationally hiding under the discrete log assumption on BN254. **Replay prevention.** On-chain, proofs are keyed on $\text{keccak256}(\text{proof} \| \text{proofType})$. The same proof bytes submitted for different proof types are treated as distinct. **Proof-of-innocence.** Attestations are stored on-chain with the original proof hash, provider set hash, and timestamp. If an address is later flagged, the historical attestation proves it was clean at $T = t_{\text{proof}}$. ### I.12 Known Limitations 1. **Proof front-running (partial fix).** Compliance (0x01) and risk_score (0x02) proofs now include `submitter` as a public input. The Oracle enforces `submitter == msg.sender`, so these proofs cannot be front-run. Attestation (0x04), membership (0x05), and non-membership (0x06) proofs still lack submitter binding. An attacker who observes one of these in the mempool can submit it first, burning the replay slot. 2. **Timestamp staleness.** The circuit enforces $t > 2021$ but no recency bound. A proof generated weeks ago remains valid. The SDK applies an optional recency check (`maxProofAge`, default 3600s), but this is client-side only. 3. **Pattern time_window.** The prover chooses $\Delta t$. The circuit enforces $\Delta t > 0$, but a malicious prover can set $\Delta t = 1$ to trivially pass velocity checks. On-chain enforcement of a minimum $\Delta t$ is not yet implemented. The SDK enforces a minimum of 86,400 seconds (24 hours) at the application layer, and the solver relay rejects clearance tokens where the associated proof used $\Delta t$ below this minimum. However, these are off-chain checks that can be bypassed by a forked SDK. Moving minimum $\Delta t$ enforcement into the circuit itself is a priority update. This matters for settlement splitting ([XIP-1](https://github.com/xochi-fi/XIPs/blob/main/XIPS/xip-draft_settlement-splitting.md)): the anti-structuring requirement at finalization depends on a valid pattern proof, but until on-chain enforcement ships, the solver relay is the last line of defense. --- ## J. Execution Specifications Technical details for intent execution, inventory management, and settlement. Complements [Section 6](./whitepaper.md#6-intent-execution) of the whitepaper. ### Inventory Check Before self-filling an intent, Riddler computes available inventory on the destination chain: $$\text{Available} = \text{Balance} - \text{Target Threshold} - \text{Rebalancing Reserved} - \text{Intent Reserved}$$ A safety buffer is applied based on trade size: | Trade Size | Buffer | | ---------- | ------ | | <\$10K | 10% | | \$10K-100K | 5% | | >\$100K | 2% | Minimum remaining after fill: \$1,000 USD. Supported self-fill tokens: USDC, USDT, USDG, WETH. ### Bridge Routing Priority When self-fill is insufficient, Riddler routes through external liquidity in priority order based on urgency: | Priority | Adapter | Typical Latency | Fee (bps) | When Used | | -------- | -------------- | --------------- | --------- | -------------------------------------- | | 1 | DeFi Llama | Varies | ~0 | Cheapest quotes | | 2 | Native bridges | 5-15 min | ~0 | L1-to-L2 (Optimism, Arbitrum, Base) | | 3 | CCTP | 10-20 min | ~0 | USDC only (Circle attestation) | | 4 | Hop | 10-30 min | Low | Fast, lower fees than Across | | 5 | Everclear | 15-30 min | ~2.3 | Netting layer (80%+ savings if netted) | | 6 | LiFi | Varies | Varies | Flexible cross-chain, oracle proofs | | 7 | Across | Varies | Varies | Multi-hop fallback | | 8 | CEX | 5-30 min | Varies | Binance/Coinbase when bridges down | Everclear is excluded from high-urgency and emergency scenarios due to the 15-30 minute netting window. CEX routing uses Binance (primary) and Coinbase (preferred for Base). ### Flash Loan Integration (Planned) For same-chain fills where Riddler lacks inventory: ``` Block N: 1. Borrow X tokens from Aave/Compound flash loan pool 2. Transfer X tokens to user's stealth account (fill the intent) 3. Receive user's sell tokens (from PERMIT2/ERC-3009 authorization) 4. Repay flash loan + fee 5. Net profit = spread - flash loan fee - gas ``` Cross-chain: flash loans cover the fill on the destination chain. The sell-side tokens on the origin chain are received via the user's authorization (PERMIT2 or ERC-3009). Bridge capital is still required for the duration of the cross-chain transfer. ### Settlement Splitting Two kinds, at different layers. They compose. **Compliance proof splitting** ([XIP-1](https://github.com/xochi-fi/XIPs/pull/1), Draft): breaks a trade into N sub-settlements, each with its own compliance proof, linked by a tradeId in a SettlementRegistry contract. Splitting is deterministic (uniform amounts, remainder on the last sub-trade). Randomized and logarithmic distributions were considered and rejected: the compliance circuit doesn't take amounts as input, so noisy amounts buy nothing. Finalization requires a pattern detection proof (circuit 0x03) to prevent structuring. Minimum split threshold: 10 ETH. **Stealth address splitting** (planned): puts each sub-settlement into a separate stealth account. ``` 1. Derive N stealth keys from recipient's meta-address (varying ephemeral secrets) 2. Compute N counterfactual SimpleAccount addresses (salt = 0, 1, ..., N-1) 3. Split sub-trade amount equally across N accounts 4. Submit N announcements (ERC-5564, 109 bytes each) 5. Recipient scans and claims from each account independently ``` Gas cost scales linearly with N. Recommended threshold: \$100K+ trades. **Venue routing** ([XIP-2](https://github.com/xochi-fi/XIPs/pull/2), Draft): each sub-trade from XIP-1 can be routed independently to public (L1), stealth (ERC-5564), or shielded (Aztec L2) based on the user's trust score and a gas budget. Users who need trade-size privacy use shielded venues. That's the only settlement path where amounts aren't visible on-chain (the solver still sees them during execution). ### Fill Rejection When an intent exceeds available liquidity (inventory + external sources), the API returns: ```json { "error": "INSUFFICIENT_LIQUIDITY", "availableAmount": "50000000000", "requestedAmount": "100000000000", "token": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", "chain": 1 } ``` The frontend can display the available amount and offer to fill at the reduced size (partial fill support planned). --- _Last updated: April 2026_