Xochi: Somos axolotls

The Agentic Dark Pool: Private Execution on Ethereum

Version 3.0 | April 2026

For technical details, API specs, and fee tables, see the technical appendix. Xochi is built by friendly axolotls at axol.io

Support us on Giveth (opens in new tab).

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
2. Xochi's ZK Compliance Oracle
3. Architecture
   • XID: Pseudonymous Identity
4. Agents on Xochi
5. Privacy Tiers: The Glass Cube
6. Intent Execution
7. Economic Model
8. Security and Risk Management
   • Post-Quantum Considerations
9. Competitive Position
10. Governance
11. Roadmap
12. Team
13. Conclusion
14. 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.

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 clears or flags at transaction time. No human in the loop.

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")

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. Formal derivations (risk score formula, circuit predicates, security properties) in Appendix I. 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).

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). 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 (opens in new tab) as soon as user transactions are accepted in Aztec. See Section 5 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 (opens in new tab) (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

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.24% 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) 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. Xochi offers encrypted recovery: you 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 WebSocket. 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).
• 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) 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.

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.

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.

During execution, solvers receive the minimum data needed to fill the order (see privacy policy 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 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.

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), 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 (opens in new tab), 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 for risk assessment.

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)

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.

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.

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 (LiFi, Across, CCTP, native L1-L2 bridges, Everclear netting) and CEX withdrawal (Binance, 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 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. Three mitigations reduce this:

• Everclear netting: opposing flows (A-to-B and B-to-A) cancel out, leaving no on-chain trace for the netted portion. ~80% savings when bidirectional flow exists.
• 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) 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 (opens in new tab), 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 (opens in new tab), 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

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):

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.

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). 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

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 targeting v5 (July 2026). State is not migrated between alpha releases. pxe-bridge (opens in new tab) connects Riddler to the Aztec network for shielded note creation. Private and Sovereign tiers are in deployment. 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.

Bug Bounty

Immunefi-hosted:

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:

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.

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), 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) can receive a Xochi stealth or shielded settlement directly. GitHub: ethereum/kohaku (opens in new tab).
• 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). Raxol (opens in new tab) (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:

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 (Pre-Launch)

Infrastructure live, collecting early access wallets, recapitalizing before public launch.

• Riddler solver on 6 chains (Section 6, Appendix D)
• Cross-chain via Across, LiFi, Circle CCTP, Everclear
• Gasless swaps (PERMIT2/EIP-3009/x402)
• L1 stealth settlement (Section 5)
• Trust scoring and attestation system
• Aztec sequencer operation (Alpha Network, v4.x)
• Aztec settlement bridge (pxe-bridge (opens in new tab), Alpha Network)
• Early access drop pool (wallet collection + community building)

Q2 2026

• Solver capitalization (raise closes)
• Aztec L2 private tiers (pxe-bridge e2e testing on Alpha Network, contingent on v5 stability)
• Smart contract audit (includes SettlementRegistry)
• Settlement splitting (XIP-1 (opens in new tab), XIP-2 (opens in new tab)): compliance proof splitting, venue routing, diffusion scheduling
• Xochi's ZK Compliance Oracle proof testnet
• ERC-5564 announcement scanning
• Client-side claim signing

Q3 2026

• Xochi's ZK Compliance Oracle proofs mainnet
• Limit orders + DCA + TWAP/iceberg
• Flash loan fills (same-chain)

Q4 2026

• FX pairs (EURC, GYEN)
• LP vaults for solver capital
• Multi-account stealth settlement (stealth address splitting, composes with XIP-1)

12. Team

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 (opens in new tab)

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 (opens in new tab)

3. "SoK: The Evolution of Maximal Extractable Value, From Miners to Cross-Chain." arXiv:2603.07716, March 2025. https://arxiv.org/html/2603.07716v1 (opens in new tab)

4. Wahrstaetter, T. MEV-Boost Pics (open-source relay analytics, post-Merge). https://mevboost.pics (opens in new tab)

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 (opens in new tab)

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 (opens in new tab)

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 (opens in new tab)

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 (opens in new tab)

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 (opens in new tab)

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 (opens in new tab)

11. European Parliament. "Regulation (EU) 2016/679 (GDPR), Article 5(1)(c): Data Minimization." https://gdpr-info.eu/art-5-gdpr/ (opens in new tab)

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 (opens in new tab)

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 (opens in new tab)

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 (opens in new tab)

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 (opens in new tab)

16. Trail of Bits. "ScopeLift Stealth Address Contracts Audit." February 2024. https://github.com/trailofbits/publications (opens in new tab)

17. ScopeLift. Stealth Address SDK and Canonical Contracts. https://github.com/ScopeLift/stealth-address-sdk (opens in new tab)

18. Ethereum Foundation. "ERC-4337: Account Abstraction Using Alt Mempool." Ethereum Improvement Proposals. Status: Final. https://eips.ethereum.org/EIPS/eip-4337 (opens in new tab)

19. Pimlico. "SimpleAccount and Paymaster Documentation." https://docs.pimlico.io (opens in new tab)

20. DROOdotFOO. "Raxol: Terminal Framework for TUI Apps and AI Agents." MIT License. https://github.com/DROOdotFOO/raxol/tree/master (opens in new tab). RAXOL token (live, Robinhood Chain): https://app.virtuals.io/virtuals/95590 (opens in new tab) (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 (opens in new tab). Reference implementation: https://github.com/xochi-fi/ERC-8262 (opens in new tab)

22. axol-io. "Mana: Elixir Ethereum Execution Client." Apache 2.0 + MIT. https://github.com/axol-io/mana (opens in new tab)

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.