Confidential Intent Routing: COTI & NEAR
Technical architectural reference for developers: How Interphase decouples liquidity requesters from market maker solvers using COTI L2 Garbled Circuits as a confidential control plane, while utilizing NEAR Intents native multichain vaults for fund custody and threshold settlement.
#Architectural Core: Native NEAR Vaults + COTI Control Plane
A core design constraint of the Interphase Protocol is zero custom custody escrow contracts on source and destination chains. We do not deploy or maintain custom asset bridges, omnibus pool contracts, or custom custody vaults on Ethereum, Base, Solana, Bitcoin, or Sui.
2. COTI L2 (The Confidential Control Plane): We deploy our smart contract (
InterphaseCotiRouter.sol) exclusively on COTI L2 to evaluate intents inside Garbled Circuits, screen compliance, and completely unmask source identities before orders reach solvers.
The Mental Model ("The Blind Courier"):
Imagine Alice places $5,000 in a standardized bank vault on Ethereum and receives a cryptographic ticket. She writes her secret delivery instructions inside a sealed envelope and hands it to a group of blindfolded examiners inside a secure room (COTI Garbled Circuits). The examiners check that the money is clean, permanently shred Alice's name and signature off the ticket, and push an anonymous work order out the door: "Deliver 5,000 USDC to single-use address P_stealth on Solana, get reimbursed on Ethereum." An independent courier (The Solver on NEAR Intents) fulfills the delivery without ever knowing Alice exists.
#End-to-End System Topology
Alice deposits Asset X into the native NEAR Intents Deposit Vault with a 32-byte blind commitment hash H_intent.
InterphaseCotiRouter.sol receives the encrypted intent via a Gasless Paymaster. Garbled Circuits verify compliance and strip Alice's identity.
The sanitized intent is emitted into the intents.near solver pool. Solvers bid blind; winning solver fronts liquidity to P_stealth on destination.
Destination inclusion verified by NEAR Chain Signatures. The NEAR source vault releases Asset X directly to the solver.
#Step-by-Step Cryptographic Protocol
-
Phase 1: Source Vault Deposit with Blind Commitment Hash
When Alice initiates a transfer (e.g. from Ethereum to Solana), her client does not write plaintext routing details to the blockchain. Instead, she deposits into the standard NEAR multichain deposit vault with a cryptographic commitment:
H_intent = Keccak256(nonce ‖ nullifier ‖ encryptedPayloadHash)On-Chain Trace: On Etherscan or block explorers, observers only see that
0xAlicetransferred 5,000 USDC into the NEAR Multichain Vault matchingH_intent. It is mathematically impossible to infer the target chain (Solana), the destination asset, or the recipient. -
Phase 2: Soda Labs Metadata Privatization on COTI L2
Alice’s client encrypts the intent parameters using the COTI Network MPC Public Key (
@coti-io/coti-ethers). To solve the EVM metadata leak confirmed by Soda Labs (where standard EVM headers exposetx.origin):- Oblivious HTTP (OHTTP) Relay: The client dispatches the encrypted JSON-RPC request through an OHTTP gateway, completely stripping Alice’s IP address and ISP fingerprint.
- Gasless Paymaster Envelope: The transaction on COTI L2 is broadcast by our Paymaster relayer account. The EVM header permanently records:
from: 0xInterphasePaymaster. Alice’s personal wallet address never appears in the COTI block header. - Calldata Homomorphic Padding: Payloads are uniformly padded to 512 bytes to defeat packet-length timing analysis.
-
Phase 3: The Garbled Circuit "Blind Sanitizer" (InterphaseCotiRouter.sol)
Inside our deployed contract on COTI L2 (
InterphaseCotiRouter.sol), the MPC validator cluster evaluates the encrypted payload inside Yao's Garbled Circuits:// Pseudocode of Garbled Circuit MPC Logic inside InterphaseCotiRouter.sol function evaluatePrivateIntent( bytes calldata encryptedPayload, bytes32 depositCommitment ) external returns (SanitizedOrder memory order) { // 1. Decrypt inputs into private wire labels inside MPC (address sourceSender, uint32 destChain, bytes32 pStealth, uint256 amount) = mpcDecrypt(encryptedPayload); // 2. Blind Sanctions Screening (ComplianceSMT.sol) bool isClean = complianceSMT.verifyNonInclusion(sourceSender); require(isClean, "Sanctions Violation"); // 3. Stateful 24-Hour Rolling Identity Velocity Limiter enforceRollingVelocityLimit(sourceSender, amount); // 4. Identity Stripping: Only output wires are revealed! // sourceSender is permanently erased from memory. order = SanitizedOrder({ destChainId: destChain, stealthRecipient: pStealth, payoutAmount: amount, depositCommitment: depositCommitment }); emit PrivateIntentEvaluated(order); } -
Phase 4: Solver Bidding & Destination Stealth Settlement
The sanitized order is emitted into the NEAR Intents solver market (
intents.near/ Defuse).What the Solver Sees:
The market maker only sees: "Deliver 5,000 USDC to Solana stealth addressP_stealth. Claim reimbursement forH_intentfrom NEAR Ethereum Vault." The solver has zero visibility into who deposited on Ethereum.Destination Address Derivation (ECDH Math):
The recipient’s addressP_stealthis generated client-side using non-interactive Elliptic Curve Diffie-Hellman:Ephemeral Public Key: R = r · G
Shared Secret Point: S_shared = r · V_recipient = v_recipient · R
One-Time Stealth Address: P_stealth = S_recipient + Keccak256(S_shared) · GThe solver transfers 5,000 USDC + an atomic native gas subsidy (e.g. 0.005 SOL) to
P_stealth. The recipient sweeps the funds locally using their private spending keyp_stealth = s + Keccak256(S_shared). -
Phase 5: Solver Reimbursement via NEAR Chain Signatures
Once the settlement transaction finalizes on Solana (32-slot commitment gate):
- The solver presents the Solana block inclusion receipt to the NEAR Intents engine.
- NEAR’s decentralized validator network (Chain Signatures TSS MPC) validates the destination receipt against
H_intent. - NEAR MPC issues a cryptographic signature instructing the NEAR Multichain Deposit Vault on Ethereum to release Asset X directly to the solver’s authenticated reimbursement wallet.
#Data Visibility & Isolation Matrix
Below is the exact data matrix showing what each actor knows vs. what is mathematically concealed from them:
| Information Field | Alice (Requester) | Solver (Market Maker) | NEAR Intents Vaults | COTI MPC (Soda Labs) | Public Observers |
|---|---|---|---|---|---|
| Source Depositor Address (0xAlice) | Known | 100% HIDDEN | Known (Deposit only) | STRIPPED IN MPC | Sees Vault Deposit |
| Target Destination Chain & Token | Known | Known (To fulfill) | 100% HIDDEN | Processed in Dark | 100% HIDDEN |
| Destination Stealth Address (P_stealth) | Known | Known (Payout target) | Verified in proof | Emitted output wire | Sees random burner |
| Real Identity of Recipient | Known | 100% HIDDEN | 100% HIDDEN | 100% HIDDEN | 100% HIDDEN |
| Link between Alice & P_stealth | Known | 100% HIDDEN | 100% HIDDEN | 100% HIDDEN | 100% HIDDEN |
| COTI Transaction Envelope (Metadata) | Masked by OHTTP | Never touches COTI | N/A | Sees Paymaster only | Sees Paymaster only |
#Developer Checklist & Code References
When building out or integrating with this architecture, focus exclusively on these key boundaries:
#1. COTI L2 Router Contract
Deployed on COTI L2 (Testnet: chainId: 7082400).
- Imports
@coti-io/coti-contractsfor Garbled Circuit precompiles. - Maintains
ComplianceSMT.sol(Sparse Merkle Tree for sanctions). - Implements
evaluatePrivateIntent()to emit sanitized orders. - Code:
packages/contracts-coti/src/InterphaseCotiRouter.sol
#2. Client SDK & Cryptographic Core
Runs locally in browser/mobile WASM.
- ECDH key derivation via
@noble/curves(secp256k1 & ed25519). - Constructs
H_intentdeposit memo for the NEAR vault. - Encrypts payload via
@coti-io/coti-ethers. - Code:
packages/sdk/src/client.ts