Occlusion Protocol: Shielded Intents and Ex-Post Verifiable Execution for Automated Market Makers
Occlusion Protocol
Draft specification — September 2026
Abstract
Existing approaches to MEV protection on automated market makers either hide a trade from public view entirely, at the cost of requiring participants to trust a centralized sequencer or enclave, or leave routing computation exposed to the public mempool, permitting the sandwich attacks such systems were meant to prevent. This paper describes Occlusion, a protocol that separates two properties commonly conflated in prior work: pre-execution confidentiality and post-execution accountability. Occlusion shields a trade intent using a note-commitment scheme derived from the Zcash Orchard protocol, computes routing privately via a threshold multi-party computation (MPC) committee drawn from a Bittensor subnet, and defers all correctness guarantees to an ex-post best-execution audit rather than a zero-knowledge proof of routing optimality, a problem that remains impractical to solve directly at scale. Solvers post collateral in the protocol's native token, $OCLU, which is slashed when the audit detects execution below a public benchmark. We describe the protocol's construction, its committee formation and secret-sharing scheme, its economic security assumptions, and its limitations.
1 Introduction
Intent-based solvers on automated market makers commonly discover optimal execution routes by simulating candidate paths against on-chain state. Where this simulation happens as public, revertible transactions rather than off-chain computation, the winning route becomes observable before the real trade executes, allowing an adversary to extract value by trading ahead of it. This pattern has been documented in production on Robinhood Chain, where solvers using naive on-chain route probing exposed their intended execution path for one to four blocks before settlement, a window sufficient for repeated, systematic sandwich extraction.
Removing on-chain probing addresses this specific failure but does not eliminate the underlying exposure: a pending swap transaction sitting in a public mempool, of known size and direction, remains attractive to generic sandwich strategies regardless of how its route was computed. A complete solution requires shielding the trade's contents, not merely its route-discovery process, until the point of settlement.
Shielding a pending trade introduces a harder problem than shielding a value transfer: a solver must still select a good execution route for an amount it cannot see, and someone must be able to verify, without access to the hidden amount, that the route chosen was reasonable. Occlusion's contribution is a construction that avoids requiring a proof of optimality before execution and substitutes a public, cheaply computed audit after execution, an approach that trades a small, bounded window of unaudited exposure for a dramatic reduction in cryptographic and computational complexity.
2 Background
2.1 Shielded commitments. The Zcash Orchard protocol represents a spendable note as a commitment over a Pedersen/Sinsemilla hash of its contents, accompanied by a Halo2 proof of validity requiring no trusted setup, and a nullifier that prevents double-spending without revealing which note was spent. Occlusion adapts this construction to represent a conditional trade authorization rather than a value transfer.
2.2 Threshold secret sharing. Shamir's (t, n) threshold secret sharing scheme allows a secret to be split into n shares such that any t shares reconstruct it, while fewer than t reveal nothing. Occlusion uses this to distribute a trade intent across a rotating committee such that no minority of committee members can recover it.
2.3 Mixed-protocol MPC. Frameworks such as ABY3 combine arithmetic secret sharing, suited to the additions and multiplications used in constant-product and concentrated-liquidity pricing formulas, with garbled-circuit evaluation, suited to the comparisons and branching required to select among candidate routes. Occlusion's committee uses this hybrid approach to compute a route decision without any single node reconstructing the plaintext intent.
2.4 Subnet consensus. Bittensor subnets coordinate a decentralized set of miners and validators using Yuma consensus, in which validator-weighted scoring determines miner reward and standing. Occlusion uses this mechanism both to select each epoch's MPC committee by stake weight and to run the ex-post audit described in Section 3.6.
3 Protocol Design
3.1 Intent commitment. A trader constructs a note N encoding the input asset, output asset, input amount, and maximum acceptable slippage, together with a nonce and blinding factor, and computes a commitment cm(N) over the Pallas curve scalar field used by Halo2. A range proof accompanies the commitment, demonstrating the input amount does not exceed the trader's shielded balance, without revealing the amount itself.
3.2 Committee formation. Each epoch, a committee of n subnet validators is selected by stake-weighted sampling, with a reconstruction threshold t set to a supermajority (t > n/2) to bound the cost of collusion. Committees rotate every epoch so that no fixed set of nodes accumulates visibility into a trader's history over time.
3.3 Threshold sharing of the intent. The trader secret-shares the plaintext note contents across the committee's public keys using (t, n) Shamir sharing. No individual committee member receives sufficient shares to reconstruct the intent.
3.4 Private route computation. The committee jointly evaluates a routing circuit over the secret-shared intent: arithmetic sharing computes candidate output amounts across available pools, and garbled-circuit evaluation selects the maximal output route. The committee outputs a threshold-signed attestation naming the selected route, without any party learning the underlying amount.
3.5 Atomic reveal and settlement. At execution, the intent's nullifier and its plaintext contents are revealed in the same transaction that executes the swap against the selected route. Because reveal and execution are atomic, there is no interval in which the amount is public but not yet settled.
3.6 Ex-post best-execution audit. Following settlement, the input amount and executed route are public. Occlusion's subnet continuously recomputes, from the pool states recorded at the settlement block, the maximal output achievable for that amount, and compares it to the amount actually delivered. Deviations within a tolerance band, accounting for legitimate latency and slippage, are treated as normal; deviations beyond it are flagged and contribute to the responsible solver's public integrity score.
3.7 Solver registry and bonding. Solvers register by posting collateral in $OCLU to the Solver Registry contract. Routing priority is weighted by a solver's integrity score and the square root of its bonded amount, a deliberately sublinear weighting intended to prevent pure capital size from dominating allocation. A withdrawal timelock delays unbonding, ensuring a solver cannot exit before a pending audit resolves. Confirmed audit failures slash a proportion of the offending solver's bond, distributed to the affected trader, with the remainder directed to a protocol treasury.
Separately from solver bonds, the protocol maintains an independent $OCLU staking pool open to any holder. Stakers receive a share of protocol revenue, namely a small routing fee levied on each shielded trade and the treasury's portion of slashed solver bonds. Stake in this pool is not a bond: it confers no routing priority, is never subject to audit-driven slashing, and carries no influence over routing or audit outcomes. The security argument of Section 4 therefore depends only on solver bonds and is unaffected by the pool.
4 Security Considerations
Occlusion's privacy guarantee is pre-execution only: once an intent settles, its contents are as visible as any other on-chain transaction, consistent with the behavior of Zcash's own shielded pool when value interacts with a transparent context. The strength of this guarantee before settlement further depends on the size of the active anonymity set; with low adoption, timing and size metadata may narrow the set of plausible traders even without recovering exact amounts.
The threshold MPC construction is secure against collusion by fewer than t committee members; a colluding supermajority can recover a trader's intent, a residual risk bounded, but not eliminated, by epoch rotation and stake-weighted committee selection. The protocol favors safety over liveness: if a committee fails to reach threshold participation within a bounded window, the intent times out and funds are returned rather than falling back to an unshielded execution path.
The economic security of the audit and bonding mechanism holds only where the cost of a successful attack, defined as the stake at risk to a colluding majority, exceeds the expected profit from an undetected leak. Parameterizing bond sizes and slash proportions to maintain this inequality under realistic trade volumes is left as an operational, rather than purely cryptographic, concern.
5 Related Work
This protocol builds directly on the Zcash Orchard shielded pool and its Halo2 proving system, on Shamir's threshold secret sharing scheme, and on mixed-protocol MPC frameworks such as ABY3. Its economic enforcement model is closer in spirit to optimistic, slashing-based systems such as EigenLayer's actively validated services than to purely cryptographic guarantee systems, and its intent-shielding goals overlap with threshold-encryption mempool designs such as Shutter Network and with batch-auction MEV mitigation approaches such as CoW Protocol, though Occlusion differs from both in deferring correctness enforcement to a public, post-hoc audit rather than a pre-execution cryptographic or auction-based guarantee.
6 Conclusion
Occlusion demonstrates that shielding a pending trade does not require solving the open problem of proving off-chain computation optimal in zero knowledge. By combining threshold MPC for private routing with a cheap, public, ex-post audit and collateral-backed enforcement, the protocol achieves practical protection against pre-execution front-running while remaining honest about the boundaries of what it does, and does not, guarantee.
References
- [1]D. Hopwood, S. Bowe, T. Hornby, N. Wilcox. Zcash Protocol Specification, Version 2022.3.8 [NU5]. Electric Coin Company.
- [2]S. Bowe, J. Grigg, D. Hopwood. Recursive Proof Composition without a Trusted Setup (Halo). IACR ePrint 2019/1021.
- [3]A. Shamir. How to Share a Secret. Communications of the ACM 22(11), 1979.
- [4]P. Mohassel, P. Rindal. ABY3: A Mixed Protocol Framework for Machine Learning. ACM CCS, 2018.
- [5]Y. Rao, J. Steeves, A. Shaabana, D. Attevelt, M. McAteer. Bittensor: A Peer-to-Peer Intelligence Market. 2021.
- [6]EigenLayer Team. EigenLayer: The Restaking Collective. Whitepaper, 2023.
- [7]Shutter Network. Threshold Encryption for MEV Protection. Technical overview, 2022.
- [8]CoW Protocol. Batch Auctions and Coincidence of Wants. Documentation, 2023.
- [9]P. Daian et al. Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges. IEEE S&P, 2020.