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. 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" specifies zero-knowledge proofs that can verify a compliance statement without revealing its private witnesses. Next, it is qualified on Base Sepolia and, after an external audit, deployed on Base; it is not in the live trade path yet.

You sign an intent; settlement today goes to public wallets or stealth addresses on a trusted stealth chain (Ethereum or Base), and recipient-private settlement to your own Aztec account is next (not live yet; testnet first). The venue never trades against its own users. Attestation-based trust scoring is designed to lower fees and unlock deeper privacy; it is not live yet, so every wallet trades at the Standard trust tier today.

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 attestation providers (PoH for Proof of Humanity, KYC for Know Your Customer, or KYB for Know Your Business), select their privacy level, and the oracle produces risk signals at transaction time. Solvers and operators decide how to act on those signals. Routine checks are automated, but humans are not removed from the loop: a hosted KYC provider can route a case to manual review by its own staff, and SAR/STR decisions are made by provider or compliance staff. 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
                (raw identity data stays       (learns only: "compliant" or "not")
                 with you and your provider)

Raw identity data may reach the provider you select (a hosted KYC check, for example), but it does not enter Xochi, Riddler or the chain. What reaches them is the proof and its public inputs.

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) configurations specify 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 provides equivalent assurance to traditional compliance checks (reasonable suspicion) without revealing raw data.

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 produce structured evidence bundles (metadata and selectors, not raw transaction data) that operators may submit to regulators if they choose to. Planned, not yet live.

Go-to-Market Reality

Xochi's ZK Compliance Oracle is the long-term vision. The design routes users to jurisdiction-appropriate licensed solvers; as jurisdictions adopt Xochi's ZK Compliance Oracle proofs, the protocol shifts to cryptographic compliance, a multi-year transition. The first step is qualifying the Oracle on Base Sepolia, then an external audit and a production Oracle on Base (Section 11). Not live yet: no Oracle is deployed, compliance screening is not enforced in production, and trust scoring is off, so every wallet resolves to the Standard trust tier.

3. Architecture

Design Philosophy

We don't break Ethereum's transparency. We allow you as a user to control the opacity.

Ethereum-first: stealth settlement is live on Ethereum and Base. Shielded settlement on Aztec follows (shielded execution decision); it is not live yet.

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 7 chains)
• Sequencers: Aztec (since genesis)
• 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.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) will accumulate trust score, and trust is designed to unlock lower fees and deeper privacy. That is not live: every wallet trades at the Standard trust tier today. When it launches, self-serve verification reaches Premium at most; Institutional is awarded through institutional partnerships. You will never be required to verify. Identity verification is optional.

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 seven chains (Ethereum, Optimism, Base, Arbitrum, Polygon, Robinhood Chain, and Tron; on Tron the agent deposits TRC-20 to a per-intent address rather than signing a pull, because TVM has no EIP-712). 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).
• 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) is designed to set your fee; trust scoring is not live today, so every wallet resolves to Standard. 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 where the payout goes and what solvers see while they fill it. Higher trust earns lower fees. Private is the first trust-gated level to launch, with shielded settlement; Sovereign is not part of the first release. No privacy level deletes the trade record early; see what the protocol keeps below.

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 the protocol keeps. The trade record is the same at every privacy level: sender wallet, token pair, exact amounts, timestamps, intent ID and the transaction hashes of each leg. It is deleted 90 days after the trade's last update in a final state (completed, failed, refunded or expired). For a Stealth trade, the link between your wallet and the stealth payout (the payout transaction hashes) is cleared from it once the trade has been completed, failed or refunded with no further update for 7 days; an expired trade keeps it until the trade record is deleted. Either deletion waits while a retention hold applies, and a held trade reads as deleted from outside. The privacy policy is the authoritative statement: Data Retention (Section 12 on the published page) for the periods and holds, Transaction Data (Section 2) for the stealth link and what the solver keeps on its side.

During execution, solvers receive the minimum data needed to fill the order (see privacy policy Section 6.2).

Shielded retention (at launch): shielded settlement is designed to keep bounded, encrypted recovery records on an approved schedule, plus minimal replay tombstones, and to keep an unresolved payout's record until it is resolved. Encryption does not hide runtime data from operators. The privacy policy will state the shielded periods before launch; shielded settlement is not live yet.

Open tier regulatory note: The Open tier's -0.02% rebate 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; stealth is open to all. Privacy is never separately priced. See Appendix C for the full fee breakdown.

Trust score design (not live; every wallet resolves to Standard today). Points per verified attestation, capped per category:

• 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%. The category caps sum to 120, but that is not a reachable score: the point table sets the reachable maximum, which is 93 under the current table. Policy v1 sets the reachable maximum and caps self-serve verification at Premium (75-99). Institutional (100+) is awarded through institutional partnerships, a separate credential source under a later policy version, not through self-serve attestations. Most retail users are expected to reach Trusted (25+) with 2-3 attestations.

Adaptive Provider Weighting

Not live, and not part of the current trust score. Two different quantities carry the word "weight" here. Trust Score points are the per-provider base points above; they are fixed by the policy table and change only with a new policy version. ERC-8262 provider weights ($w_i$ in the compliance circuits, Appendix I) weight screening-provider signals inside a risk score. The adaptive scheme below is specified for the ERC-8262 provider weights; no review cycle has run against production data, because no proof is verified in production.

Provider weights are designed to 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 (planned): Bi-annual (January/July). Adjustments published 14 days before effect. Weighting history will be public.

Trust Score base points for selected providers (current point table, not live; these are Trust Score points, not ERC-8262 provider weights). Full provider list in Appendix F.

Privacy Implementation

No remote TEE dependencies. 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. ZK proofs keep the underlying data away from Xochi, Riddler and the chain, but they do not remove trusted third parties: provider correctness (that a provider actually verified what it signs) and key custody (provider and gateway signing keys) are trust assumptions.

Stealth Addresses (Live on Ethereum or Base, as the solver serves it): 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 recipient-private settlement (next). The Private level is designed to settle to a recipient-owned Aztec account. You hold your own spending and viewing keys and backup; Xochi and the filling solver never hold them, but see the destination and amount. It is recipient-private, not amount-private: the source deposit, its amount and token, stays public. Rollout: a testnet tracer first (Base Sepolia to the Aztec v6 public testnet, test token). The first production corridor then runs design A on zk.money's enclave-backed DAI (OXDAI) on Aztec mainnet: you pay in USDC on Ethereum, and Riddler pays OXDAI to a recipient on Xochi's private allowlist, which is never published. It launches before the XSP custody contracts and before an independent security audit; both come later. Until then your payment rests on Riddler, not on escrow, and the integration is unaudited. zk.money's hosted signing enclave co-signs every OXDAI payment and withdrawal: it sees the recipient and the amount, its software is not published, so how it handles that data cannot be checked, and only zk.money can run it, so an outage stops payments and withdrawals. The other known debt: payment caps enforced by the bridge rather than on chain, zk.money's per-payment and shared daily deposit limits, hot keys, an Oxide client copied from zk.money's source, zk.money's terms of use, and a portal freeze if Aztec moves to a new rollup. A later rail has solvers pay private-to-private from their own shielded inventory, behind one shared XSP Depository and a randomized fill delay. Compliance is ERC-8262 admission proofs plus user-initiated disclosure; no regulator key or viewing-key escrow. A payout is complete when final on Aztec and your own wallet confirms it is spendable.

Cross-chain: Riddler operates on seven chains (Ethereum, Optimism, Base, Arbitrum, Polygon, Robinhood Chain, an Arbitrum Orbit L2 whose native stablecoin is USDG from Paxos, and Tron, which trades both directions: a TRC-20 payout as destination, and a per-intent deposit address as origin, since TVM cannot sign the EIP-712 pull). Stealth settlement targets a trusted stealth chain (Ethereum or Base), as the solver serves it. 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 --> Private Settlement
    (private)       (solver network)    (L1 or L2)
                         |
                   ZK Compliance Oracle (optional compliance layer, planned)
                         |
                   Evidence bundle available for operator use

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 seven chains (Ethereum, Optimism, Base, Arbitrum, Polygon, Robinhood Chain, and Tron) 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.

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, and shielded Aztec once it is live) settle via bonded attestation, bounded-trust and disclosed, because their finality is not verifiable from an origin EVM chain. This is the ERC-7683 (opens in new tab) open/fill/prove settlement model. Today's origin pull still transits a solver wallet; the escrow is the fix on the roadmap.

Shielded settlement adopts this custody model later. The first production shielded corridor (design A on zk.money's OXDAI) launches under Riddler collection before XSP, as recorded tech debt; later production corridors settle through the XSP custody contracts (Depository, Ledger, Allocator, Attestor). The capped testnet tracer uses bounded Riddler collection of testnet funds. XSP is specified and not deployed yet.

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 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) 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 seven 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: not live. The tracer targets the Aztec v6 public testnet; production follows the gates in Section 5. No launch date is committed.

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 recipient (stealth, or shielded when live), and says exactly what stays public: the source deposit and its amount, always.

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

Production infrastructure live on seven chains.

• Riddler solver on 7 chains (Section 6, Appendix D)
• Cross-chain via Across, Circle CCTP
• Gasless swaps (PERMIT2/EIP-3009/x402)
• Stealth settlement on Ethereum or Base, as the solver serves it (Section 5)
• ERC-5564 announcement scanning and client-side claim signing
• Aztec sequencer and settlement bridge (pxe-bridge (opens in new tab)) operation. Shielded settlement is not live.

Next: Trust and Compliance

The trust system launches in stages, each behind a server-side flag served as features on GET /api/capabilities: a verification beta, then credentials that set the fee and privacy tier, then proof-required actions. All three flags are off in every environment today.

• Trust scoring and attestations. At launch, self-serve verification reaches Premium at most; Institutional is awarded through institutional partnerships. The attestation issuer allowlist (ATTESTATION_ISSUERS, a Worker secret) is provisioned at G2 activation and names Xochi's attestation issuer so Verified attestations can be recorded; under G2 the shielded Verified gate and the fee tier read the live score, and wallets without an attestation resolve to the Standard trust tier. A promotional discount, where offered, is separate from the trust tier.
• Xochi's ZK Compliance Oracle (ERC-8262). Next, the Oracle is deployed and bootstrapped on Base Sepolia (84532), 0x04 credential proofs, signed 0x07 and 2-of-3 0x09 are qualified there, and Xochi staging verifies a Base Sepolia proof. After an external audit the production Oracle deploys on Base (8453), with proof-required actions enforced behind ERC8262_ENFORCEMENT_LIVE. Not live yet: no Oracle is deployed and no action requires a proof.
• Sanctions screening. Designed to run as ERC-8262 compliance proofs; none runs in production today.

Launch jurisdictions are EU, US, UK and SG (IDs 0-3); UAE is drafted. Strict multi-provider proofs wait for at least two independently controlled provider trust domains.

Next: Private Settlement on Aztec

• Testnet tracer: Base Sepolia to the Aztec v6 public testnet with a test token, end to end through independent recipient discovery and a private spend.
• First production corridor: design A on zk.money's enclave-backed DAI (OXDAI) on Aztec mainnet, launched before the XSP custody contracts and an independent security audit (recorded tech debt, shielded execution spec §15).
• Later production rail: solver-held private inventory, a shared XSP Depository and a randomized fill delay, with the XSP custody contracts and an independent security audit.

Q3 2026

• Solver capitalization (raise closes)
• 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

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 are planned to use Aztec L2 via pxe-bridge and are not yet live. Xochi's ZK Compliance Oracle is a novel compliance approach without regulatory precedent.