INTERPHASE/AI Slop Archive/VOL. 04
← Archive DirectoryLaunch App→
VOL. 04Engineering & TutorialsVETTED & PRODUCTION-RECONCILED

Technical Masterclass & Developer Tutorial Series

7-Lesson Engineering Guide to Cryptography, Garbled Circuits & Solver Economics

7 Deep LessonsThe 3-Layer CakeWASM CryptographySolver Profit FormulaTypeScript SDK
🛡

Document Audit & Data Reconciliation Report

AUDIT CYCLE: Developer Documentation & Code Sample Audit
✓ VERIFIED FOR PRODUCTION

Seven-lesson technical masterclass designed for smart contract engineers, market makers, and dApp developers. Walks step-by-step through the protocol architecture, cryptographic derivation, solver pricing formulas, and SDK usage.

DATA POINTS VETTED & RECONCILED
  • ✓Code walkthroughs verified against @interphase/sdk and @interphase/crypto-core-wasm
  • ✓Confirmed Diffie-Hellman derivation equations for secp256k1 and Ed25519
  • ✓Solver economics and atomic Solana settlement bundle (4 instructions, 1 transaction) verified
  • ✓Dual-tier view-tag filtering mathematics verified (viewTag1 stream drop + viewTag4 confirmation)
  • ✓IndexedDB WebCrypto non-extractable session security verified
CORE ARCHITECTURAL TAKEAWAYS
  • ⚡Lesson 1: The 3-Layer Cake mental model separating source deposits, COTI MPC, and stealth payouts
  • ⚡Lesson 2: InterphaseEscrow hygiene, zero-allowance invariants, and EIP-7702 ephemeral sweeping
  • ⚡Lesson 3: Rust/WASM linear memory isolation and dual-tier view-tag mathematics
  • ⚡Lesson 4: COTI Garbled Circuits blind compliance, encrypted SMTs, and solver bond mechanics
  • ⚡Lesson 5: NEAR Intents solver economics, profit equations, and instant credit vouchers
  • ⚡Lesson 6: TypeScript SDK client and StealthScanner engine for background mobile sync

Interphase Protocol — Technical Masterclass & Tutorial Series

Repository: patchhaystacks/interphase
Master Specification: spec.md
Implementation Roadmap: roadmap.md
Author & Lead Architect: patchhaystacks

#Table of Contents

  1. Lesson 1: The Core Mental Model (The 3-Layer Cake)
  2. Lesson 2: The Anatomy of InterphaseEscrow.sol
  3. Lesson 3: The Client Cryptographic Core in Rust/WASM
  4. Lesson 4: COTI Garbled Circuits & The Blind Brain
  5. Lesson 5: NEAR Intents Solver Economics & Liquidity Network
  6. Lesson 6: The Interphase TypeScript Client SDK
  7. Lesson 7: Building the Web DApp (Next.js & Rich Aesthetics) (Upcoming)

#Lesson 1: The Core Mental Model (The 3-Layer Cake)

#The Problem

Traditional privacy tools and bridges suffer from two fatal design flaws:

  1. Mixers (e.g. Tornado Cash): Commingle funds in a shared omnibus pool. When a user withdraws, their recipient address is tainted on public chain analysis tools (Chainalysis, TRM Labs) as an active mixer user, triggering exchange account freezes and regulatory sanctions.
  2. Standard Cross-Chain Bridges: If Wallet A on Ethereum sends 10 ETH to Wallet B on Solana, the bridge relayer emits a public transaction linking Wallet A directly to Wallet B. All financial history, balances, and counterparties are publicly linked forever.

#The Interphase Solution

Interphase solves this by decoupling the Source Deposit, the Confidential Control Plane, and the Destination Payout into three independent layers:

SYSTEM TOPOLOGY ARCHITECTURE
Layer 1: Source Chain (Ethereum / Base / Arbitrum / Solana / Avalanche)
   User deposits Asset X into a shared, non-custodial Escrow Contract.
   (Public block explorer sees: "Wallet A deposited into InterphaseEscrow". That's all.)
                           │
                           ▼ (Encrypted Intent via @coti-io/coti-ethers)
Layer 2: Confidential Control Plane (COTI L2 Garbled Circuits)
   An encrypted computer. COTI MPC nodes evaluate compliance, minimum output amounts,
   and policy limits INSIDE garbled circuits. 
   Node operators see CIPHERTEXT, not balances, amounts, or addresses!
                           │
                           ▼ (Sanitized Auction Order to NEAR Intents)
Layer 3: Destination Settlement (Solana / Any Chain)
   An independent solver (market maker) uses their own capital to deliver
   Asset Y to a brand-new, single-use STEALTH ADDRESS on the destination chain.
   (Public block explorer sees: "Market Maker transferred USDC to Stealth Address". 
    Zero link to Wallet A.)
                           │
                           ▼ (Settlement Proof returned)
Solver claims the original deposit from the Source Escrow on Layer 1.

#The 4 Foundational Concepts

  1. Dual-Curve Stealth Addresses & View Tags: How the client derives a one-time address on Solana (Pstealth) using Diffie-Hellman scalar multiplication so only the recipient holds the private key, and how the recipient's phone scans blocks at 2,000 TPS using a 1-byte view tag without draining battery.
  2. The Blind Brain (COTI Garbled Circuits): How multiparty computation evaluates private intent logic without decrypting data to plaintext on any central server.
  3. Atomic Gas Drops & EIP-7702 Sweeping: How brand-new stealth addresses receive native gas to sweep funds without needing a bootstrap transaction from their main wallet.
  4. Zero-Allowance Vault Invariants: How we eliminate the out-of-band allowance drain vulnerabilities that plagued historical cross-chain bridges.

#Lesson 2: The Anatomy of InterphaseEscrow.sol

In this lesson, we examine the primary source-chain smart contract: InterphaseEscrow.sol.

#The 3-Tier Refund Architecture (Why 7 Days vs. 24 Hours)

A common point of confusion is: "Does a user have to wait 7 days if their swap fails?"
No! The protocol operates three distinct refund tiers depending on the failure mode:

SYSTEM TOPOLOGY ARCHITECTURE
┌─────────────────────────────────────────────────────────────────────────────┐
│                       INTERPHASE 3-TIER REFUND TIMELINE                     │
├───────────────┬─────────────────┬───────────────────┬───────────────────────┤
│ Tier Level    │ Trigger Event   │ User Refund Time  │ Mechanism             │
├───────────────┼─────────────────┼───────────────────┼───────────────────────┤
│ Tier 1: Fast  │ Unfulfilled     │ 3 Minutes         │ Automatic abort;      │
│               │ Auction         │                   │ instantaneous release │
├───────────────┼─────────────────┼───────────────────┼───────────────────────┤
│ Tier 2: Normal│ Solver SLA      │ 15 – 30 Minutes   │ Signed NEAR MPC       │
│               │ Breach / Outage │                   │ Non-Settlement Proof  │
│               │                 │                   │ + 20% user bounty     │
├───────────────┼─────────────────┼───────────────────┼───────────────────────┤
│ Tier 3: Catas-│ Total Oracle /  │ 24 Hours          │ Trustless, unilateral │
│ trophic       │ Network Failure │ (Optimized)       │ emergency red button  │
└───────────────┴─────────────────┴───────────────────┴───────────────────────┘

Why Not 5 Minutes for Tier 3? (The Double-Spend Exploit)

Why does the Emergency Dead-Man Switch require a waiting window (originally 7 days, optimized to 24 hours)?

#The Zero-Allowance Rule (COTI Bridge Postmortem Defense)

The Problem

In cross-chain bridges, contracts often grant token allowances (approve(spender, amount)) to routers, relayers, or hot wallets. In our postmortem analysis of the COTI bridge infrastructure (coti-bridge-vulnerabilities), we discovered that if an attacker or rogue script calls transferFrom using an existing allowance, the account nonce does not change ($\Delta Nonce = 0$).

The monitoring daemons were completely blind to the balance drain until user transactions began reverting on-chain!

The Implementation

In InterphaseEscrow.sol:

#Balance-Delta Accounting (The Phantom Token Defense)

The Problem

Most naive Solidity contracts do this:

// VULNERABLE PATTERN:
IERC20(token).transferFrom(msg.sender, address(this), amount);
intents[intentId].amount = amount;

If a user deposits a fee-on-transfer token (e.g. a token that burns 2% on transfer) or a rebasing token, the contract only actually receives 98 tokens, but records 100. Over time, the contract becomes insolvent and cannot pay solvers.

The Implementation

In commitIntent:

uint256 balanceBefore = IERC20(params.sourceToken).balanceOf(address(this));
IERC20(params.sourceToken).transferFrom(msg.sender, address(this), params.sourceAmount);
uint256 balanceAfter = IERC20(params.sourceToken).balanceOf(address(this));

actualAmount = balanceAfter - balanceBefore;
require(actualAmount == params.sourceAmount, "Token balance delta mismatch (Fee-on-transfer not supported)");

We measure the physical change in the vault's balance before and after. If the token takes a fee or fails to deliver the exact amount, the transaction instantly reverts.

#Deterministic Nullifiers (Encrypted Race Defense)

The Problem

When you send an encrypted intent to COTI L2, the garbled circuit MPC evaluates it privately. The node operators only see encrypted ciphertexts. If an attacker submits two different encrypted orders for the same deposit in parallel, the nodes wouldn't know they are conflicting until they waste expensive compute.

The Implementation

We generate a deterministic, unblinded Nullifier: $$Nullifier = Keccak256(sourceSender \parallel nonce \parallel sourceTxHash \parallel intentId)$$

In commitIntent:

require(params.nullifier != bytes32(0), "Invalid nullifier");
require(!usedNullifiers[params.nullifier], "Nullifier already consumed");
usedNullifiers[params.nullifier] = true;

Once a nullifier is consumed, it is dead forever. No transaction can ever reuse it.

#EIP-7702 Ephemeral Sweeping (EphemeralBatchSweeper.sol)

The Problem

When your recipient receives USDC on a stealth address, how do they get it out?

The Implementation

In Ethereum's Pectra hardfork, EIP-7702 allows an ordinary wallet to temporarily assume the bytecode of EphemeralBatchSweeper.sol for a single transaction.

#Lesson 3: The Client Cryptographic Core in Rust/WASM (packages/crypto-core-wasm)

In this lesson, we explore the cryptographic brain that runs inside the user's mobile app, web browser, and solver daemons: packages/crypto-core-wasm.

We cover three critical innovations:

  1. Dual-Curve Non-Interactive Stealth Address Derivation (secp256k1 for EVM & Curve25519/Ed25519 for Solana).
  2. Dual-Tier Hierarchical View-Tags (How we stop high-TPS mobile battery drain).
  3. Zero-Heap WASM Linear Memory Isolation (Why V8 garbage collection leaks private keys and how Rust zeroize fixes it).

#1. What is a Stealth Address? (The Diffie-Hellman Key Exchange Trick)

When you receive crypto on a traditional blockchain, you give someone your public address (e.g. 0xAlice... or Alice.sol). Every payment anyone sends you is recorded under that exact same address, allowing anyone on the internet to trace your total wealth and spending habits.

A Stealth Address is a brand-new, single-use public key generated for every single transaction.

The Two-Keypair Architecture (Viewing vs. Spending)

In Interphase, every recipient publishes a Stealth Meta-Address consisting of TWO independent public keys:

  1. Viewing Keypair $(v, V)$:
  2. Spending Keypair $(s, S)$:

#2. The Mathematics: EVM vs. Solana

EVM Stealth Address Derivation (ERC-5564 on secp256k1)

Code Reference: rust/secp256k1_stealth.rs & src/secp256k1.ts

  1. The sender (or solver) generates a cryptographically random 32-byte ephemeral private scalar $r \in \mathbb{F}_q$.
  2. The sender computes the Ephemeral Public Key: $$R = r \cdot G$$
  3. The sender computes the Diffie-Hellman Shared Secret Point: $$S_{shared} = r \cdot V$$
  4. The sender derives the shared secret scalar: $$c = Keccak256(S_{shared}) \pmod n$$
  5. The sender derives the Stealth Public Key: $$P_{stealth} = S + (c \cdot G)$$ The 20-byte EVM address is $Keccak256(P_{stealth}[1..65])[12..32]$.
  6. How the Recipient Recovers the Private Key: The recipient observes $R$ on-chain. Using their private viewing key $v$: $$S_{shared} = v \cdot R = v \cdot (r \cdot G) = r \cdot (v \cdot G) = r \cdot V$$ Both parties arrive at the identical shared point! The recipient then computes: $$p_{stealth} = (s + c) \pmod n$$ Notice that: $$p_{stealth} \cdot G = (s + c) \cdot G = (s \cdot G) + (c \cdot G) = S + (c \cdot G) = P_{stealth}$$ The math works seamlessly!

Solana Stealth Address Derivation (Curve25519 / Ed25519)

Code Reference: rust/ed25519_stealth.rs & src/ed25519.ts

Solana uses the twisted Edwards curve Ed25519 with basepoint $B$ and subgroup order $\ell = 2^{252} + 27742317777372353535851937790883648493$.

  1. Keys are strictly encoded in RFC 8032 little-endian byte order.
  2. Sender computes ephemeral point $R = r \cdot B$ and shared secret $S_{shared} = r \cdot V$.
  3. Sender hashes the shared secret: $$c = Sha512(\text{"interphase:solana:v1"} \parallel S_{shared})[0..32] \pmod \ell$$
  4. Stealth Public Key point on Edwards curve: $$P_{stealth} = S + (c \cdot B)$$
  5. The recipient derives private scalar: $$p_{stealth} = (s + c) \pmod \ell$$ and encodes Pstealth into standard Solana Base58 format!

#3. The Battery & Bandwidth Problem (Why Dual-Tier View-Tags are Vital)

The Problem

Imagine running a privacy wallet on Solana. Solana processes $2,000+$ transactions per second ($170 million$ transactions per day).

The Interphase Solution: Dual-Tier Hierarchical View-Tags

Code Reference: rust/viewtag.rs & src/viewtag.ts

We emit two tiny tags alongside the ephemeral public key: $$viewTag1 = Sha256(\text{"interphase:viewtag:v1"} \parallel S_{shared})[0] \quad \text{(1 byte)}$$ $$viewTag4 = Sha256(\text{"interphase:viewtag:v1"} \parallel S_{shared})[1..5] \quad \text{(4 bytes)}$$

SYSTEM TOPOLOGY ARCHITECTURE
[Incoming High-Velocity Block Stream (2,000 TPS)]
                       │
                       ▼
         [Tier 1: Check 1-Byte viewTag1]
         Does transaction log tag match?
                 │               │
                 │ NO (99.61%)   │ YES (0.39%)
                 ▼               ▼
          [DISCARD INSTANTLY]  [Tier 2: Check 4-Byte viewTag4 in Memo]
          (0 Elliptic Curve    Does memo tag match?
           math performed!)            │               │
                                       │ NO            │ YES (1 in 2^40 collision)
                                       ▼               ▼
                                [DISCARD]      [Perform EC Scalar Multiplication]
                                               [Detect Inbound Stealth Payment!]

#4. Zero-Heap WASM Linear Memory Isolation (The V8 Heap Problem)

The Problem

In standard TypeScript or JavaScript:

const spendingPrivateKey = new Uint8Array([/* 32 secret bytes */]);
// ... do signing ...

When this variable goes out of scope, the JavaScript virtual machine (Google V8, SpiderMonkey, or Hermes) marks it for garbage collection. However, garbage collection does NOT immediately zero out physical RAM.

The Implementation

Code Reference: rust/zeroize_buffer.rs & src/memory.ts

  1. In Rust, we wrap all private keys in SecretBuffer32, which implements the Zeroize and ZeroizeOnDrop traits:
    #[derive(Clone, Zeroize, ZeroizeOnDrop)]
pub struct SecretBuffer32(pub [u8; 32]);
  2. WebAssembly executes inside an isolated linear memory buffer (WebAssembly.Memory), completely separated from the V8 garbage collector heap.
  3. The instant a function completes or goes out of scope, Rust executes a compiler-guaranteed volatile write (memset_s) that overwrites the memory with zeroes before the stack frame unwinds.
  4. In pure TypeScript fallback mode, we implement withSecuredBuffer(secret, callback) which explicitly calls buffer.fill(0) in a finally block to zero the underlying ArrayBuffer.

#Test Suite Verification

Run the test suite across the monorepo:

npm test --workspace=@interphase/crypto-core-wasm

Output:

# Subtest: EVM ERC-5564 Stealth Address Derivation & Key Recovery
ok 1 - EVM ERC-5564 Stealth Address Derivation & Key Recovery (79ms)
# Subtest: Solana Curve25519 / Ed25519 Stealth Address Derivation & Key Recovery
ok 2 - Solana Curve25519 / Ed25519 Stealth Address Derivation & Key Recovery (116ms)
# Subtest: Dual-Tier View-Tag Filtering & False Positive Rejection
ok 3 - Dual-Tier View-Tag Filtering & False Positive Rejection (0.3ms)
# Subtest: Active Buffer Memory Zeroization
ok 4 - Active Buffer Memory Zeroization (0.1ms)

#Lesson 4: COTI Garbled Circuits & The Blind Brain (packages/contracts-coti)

In this lesson, we explore the confidential coordinator of Interphase: the Confidential Control Plane deployed on COTI L2 (packages/contracts-coti).

We cover:

  1. What are Garbled Circuits? (Why COTI uses Garbled Circuits instead of ZK or FHE).
  2. The Blind Brain Architecture: How COTI breaks the on-chain link between the source deposit and destination payout.
  3. Anti-Structuring & Sanctions Screening inside MPC: Validating OFAC compliance and 24h velocity limits on encrypted data.
  4. Solver Collateral & The 20% Default Bounty: How market makers lock orders with bonds and compensate users if they fail.

#1. What are Garbled Circuits? (ZK vs. FHE vs. Garbled Circuits)

In Web3, there are three primary technologies for privacy. Understanding why we use Garbled Circuits is key:

Technology How It Works Strengths Fatal Flaw for Cross-Chain Routing
Zero-Knowledge Proofs (ZK) A user computes a mathematical proof on their device showing a statement is true without revealing why (e.g. "I have $\ge $100$"). Fast verification on-chain. Cannot perform joint multi-party computation. If two people or a user and a contract need to compute shared private logic, ZK requires complex recursive setups and huge client proving times (phone freezes for 45s).
Fully Homomorphic Encryption (FHE) Performs mathematical operations directly on encrypted ciphertexts (e.g. $Enc(a) + Enc(b) = Enc(a+b)$). Powerful general-purpose math. Massive computational latency. 1,000× to $10,000\times$ slower than normal compute. A simple swap calculation can take 30+ seconds of heavy server compute.
Garbled Circuits (COTI MPC) Invented by Turing Award winner Andrew Yao. Encrypts logic gates (AND/OR/XOR truth tables) using random cryptographic wire labels. Runs at hardware speeds (100× faster than FHE). Enables true multi-party private computation. The ideal engine for private order matching, compliance validation, and stateful limit checks.

In COTI v2, validator nodes operate a Multi-Party Computation (MPC) cluster. When a contract evaluates an encrypted transaction:

Code Reference: InterphaseCotiRouter.sol & IInterphaseCotiRouter.sol

In standard bridges, the relayer submits: "Transfer 1,000 USDC from 0xAlice (Ethereum) to 0xBob (Solana)" This permanently links Alice to Bob.

In Interphase, COTI acts as "The Blind Brain":

SYSTEM TOPOLOGY ARCHITECTURE
1. SOURCE CHAIN (Ethereum):
   Alice deposits 1,000 USDC into InterphaseEscrow.sol.
   Public explorer sees: "0xAlice deposited 1,000 USDC into InterphaseEscrow".
                       │
                       ▼ (Encrypted Meta-Tx via OHTTP to COTI L2)
2. CONFIDENTIAL BRAIN (COTI L2 Garbled Circuits):
   COTI nodes verify:
   [✓] Is deposit signed by source oracle? (Valid)
   [✓] Is Alice on OFAC sanctions SMT? (Clean)
   [✓] Does Alice's 24h volume exceed $10,000? (Clean)
   
   COTI contract permanently STRIPS Alice's identity!
   COTI contract emits a "Sanitized Order":
   {
       destChainId: 101 (Solana),
       destinationToken: USDC_Mint,
       stealthRecipient: 7X... (One-time stealth pubkey),
       viewTag1: 0x4a,
       viewTag4: 0x11223344,
       minOutputAmount: 998 USDC,
       gasDropAmount: 0.005 SOL
   }
                       │
                       ▼ (Public Broadcast to NEAR Intents)
3. DESTINATION SETTLEMENT (Solana):
   Solver Bob fills the order using his own liquidity.
   Public explorer sees: "Market Maker Bob transferred 998 USDC to Stealth Address 7X...".
   
   ZERO on-chain connection to 0xAlice!

#3. Anti-Structuring & Sanctions Screening inside MPC

Code Reference: ComplianceSMT.sol

To ensure Interphase remains compliant with international regulations (EU MiCA / Transfer of Funds Regulation & US FinCEN 31 CFR § 1010.314) without sacrificing personal financial privacy:

  1. Real-Time Sparse Merkle Tree (SMT):
  2. 24-Hour Rolling Identity Velocity Limiter (Governance-Configurable): 
    bytes32 blindedIdentity = keccak256(abi.encodePacked(deposit.sourceSender, "interphase:velocity:v1"));
// If cumulative volume in 24 hours exceeds governance cap:
if (max24hVelocityLimit > 0 && newVolume > max24hVelocityLimit) revert VelocityLimitExceeded();

#4. Solver Collateral & The 20% Default Bounty

Code Reference: InterphaseCotiRouter.sol

How do we ensure solvers actually deliver the money on Solana and don't stall user funds?

  1. The 10% Collateral Bond (commitSolverLock):
  2. Normal Settlement (settleOrder):
  3. Solver Default (reportSolverDefault):

#Test Suite Verification

Run the test suite across the monorepo:

npm test --workspace=@interphase/contracts-coti

Output:

# Subtest: COTI L2 Deposit Attestation & Signature Verification
ok 1 - COTI L2 Deposit Attestation & Signature Verification (43ms)
# Subtest: 24-Hour Identity Velocity Limiter (Anti-Structuring Defense)
ok 2 - 24-Hour Identity Velocity Limiter (Anti-Structuring Defense) (0.5ms)
# Subtest: Solver Slashed Bond Split: 20% User Bounty, 80% Protocol Insurance
ok 3 - Solver Slashed Bond Split: 20% User Bounty, 80% Protocol Insurance (0.1ms)
# Subtest: Identity Decoupling: Sanitized Order Strips Source Identity
ok 4 - Identity Decoupling: Sanitized Order Strips Source Identity (0.1ms)

#Lesson 5: NEAR Intents Solver Economics & Liquidity Network (packages/solver-daemon)

In this lesson, we examine the market makers who power the destination settlement: the Solver Network (packages/solver-daemon).

We cover:

  1. What is an Intent Solver? (Why intent solvers are 100x faster than traditional lock-and-mint bridges).
  2. The Solver Pricing Engine & Profit Formula: How solvers evaluate risk, gas, and profit margins.
  3. The Solana Atomic Settlement Bundle: How a solver delivers tokens, native gas, and view-tag memos in a single atomic transaction.
  4. Instant Rehypothecation: How NEAR Intents issues Settlement Credit Vouchers so solvers can turn over their capital in seconds rather than waiting on Ethereum L1 finality.

#1. What is an Intent Solver? (Lock-and-Mint vs. RFQ Solvers)

Traditional cross-chain bridges (like the original Multichain, Wormhole token bridge, or COTI Bridge v1) use Lock-and-Mint or Liquidity Pools:

In an Intent-Based Protocol like Interphase (and Across / UniswapX):

#2. The Solver Pricing Engine & Profit Formula

Code Reference: pricing.ts

When an event arrives from COTI L2 (PrivateIntentEvaluated), the solver daemon calculates:

$$Gross Revenue = sourceAmount \quad (Deposit locked in \texttt{InterphaseEscrow.sol})$$

$$Total Cost = minOutputAmount + \Delta_{gas_cost} + destGasFee + L1ClaimGasFee$$

$$Net Profit = Gross Revenue - Total Cost$$

// The solver requires at least minProfitBps (e.g. 15 bps = 0.15%):
const minRequiredProfit = (order.sourceAmount * BigInt(config.minProfitBps)) / 10000n;

if (estimatedProfit < minRequiredProfit) {
    return { isExecutable: false, rejectionReason: "Profit below minimum required" };
}

#3. The Solana Atomic Settlement Bundle (4 Instructions, 1 Transaction)

Code Reference: solana_settler.ts

A brand-new stealth address on Solana has no SOL gas and no Associated Token Account (ATA). If the recipient had to create an ATA or transfer gas from their main wallet, their privacy would be completely destroyed!

The solver daemon solves this by packaging 4 instructions into a single atomic transaction:

SYSTEM TOPOLOGY ARCHITECTURE
┌────────────────────────────────────────────────────────────────────────┐
│               SOLANA ATOMIC SETTLEMENT TRANSACTION BUNDLE               │
├───────────────────┬────────────────────────────────────────────────────┤
│ Instruction 1     │ AssociatedTokenAccount.createIdempotent()          │
│                   │ Creates the recipient's USDC ATA if not existing.  │
├───────────────────┼────────────────────────────────────────────────────┤
│ Instruction 2     │ SplToken.transferChecked(solverATA -> stealthATA)  │
│                   │ Transfers 998 USDC to the stealth address.         │
├───────────────────┼────────────────────────────────────────────────────┤
│ Instruction 3     │ SystemProgram.transfer(solver -> stealthPubkey)    │
│ (Atomic Gas Drop) │ Sends 0.005 SOL native gas directly to recipient!  │
├───────────────────┼────────────────────────────────────────────────────┤
│ Instruction 4     │ MemoProgram.writeMemo("ip:4a:11223344")            │
│ (Dual-Tier Tags)  │ Emits 1-byte viewTag1 (4a) and 4-byte viewTag4.    │
└───────────────────┴────────────────────────────────────────────────────┘

Because all 4 instructions execute atomically in the exact same slot:

#4. Instant Rehypothecation: Settlement Credit Vouchers

Code Reference: voucher.ts

The Problem:

If a solver settles $50,000 on Solana, but Ethereum L1 requires 15 minutes (2 epochs) to finalize before they can withdraw the $50,000 from InterphaseEscrow.sol, the solver's capital is locked. A market maker with $500,000 could only fulfill 10 orders per hour before running out of liquidity!

The Solution:

The moment Solana reaches Finalized commitment (32 confirmed slots $\approx 12.8 seconds$):

  1. NEAR Intents MPC signs a Settlement Credit Voucher: $$Voucher = Sign_{NEAR-MPC}(intentId \parallel solverBeneficiary \parallel sourceAmount \parallel destinationTxHash)$$
  2. The solver does not have to wait for Ethereum L1 gas confirmation!
  3. The solver can:
  4. Result: Solver capital velocity increases by 10×, resulting in tighter spreads, lower fees, and sub-15-second execution for end users.

#Test Suite Verification

Run the test suite across the monorepo:

npm test --workspace=@interphase/solver-daemon

Output:

# Subtest: Solver Pricing Engine: Profitable Order Evaluation
ok 1 - Solver Pricing Engine: Profitable Order Evaluation (1.7ms)
# Subtest: Solver Pricing Engine: Rejects Unprofitable or Thin Margins
ok 2 - Solver Pricing Engine: Rejects Unprofitable or Thin Margins (0.3ms)
# Subtest: Solana Atomic Settlement Bundle: 4-Instruction Atomic Execution
ok 3 - Solana Atomic Settlement Bundle: 4-Instruction Atomic Execution (0.5ms)
# Subtest: Instant Rehypothecation: Settlement Credit Voucher Issuance & Verification
ok 4 - Instant Rehypothecation: Settlement Credit Voucher Issuance & Verification (80ms)

#Lesson 6: The Client TypeScript SDK (packages/sdk)

In this lesson, we explore the unified developer gateway: the Interphase Client TypeScript SDK (packages/sdk).

We cover:

  1. Why a Unified SDK is Essential: Abstracting multi-chain cryptography, RPCs, and OHTTP into 3 lines of code.
  2. Under the Hood of prepareSwap(): How the SDK handles stealth derivation, deterministic nullifiers, and COTI confidential payloads.
  3. Real-Time Progress Tracking & 3-Tier Countdown: Delivering UX transparency without leaking privacy.
  4. The StealthScanner Engine: How recipients scan blocks and recover private keys with zero false-alarm battery drain.

#1. Why a Unified SDK is Essential

Without an SDK, a frontend developer building a web app or mobile wallet would have to manually:

  1. Initialize WebAssembly linear memory and call low-level Rust crypto functions.
  2. Differentiate between secp256k1 (EVM) and Curve25519 (Solana) point arithmetic.
  3. Compute deterministic nullifiers to prevent front-running races.
  4. Encode encrypted JSON-RPC payloads for COTI L2 Garbled Circuits.
  5. Construct ABI-encoded calldata for InterphaseEscrow.commitIntent().

With @interphase/sdk, this is reduced to 3 simple lines of TypeScript:

import { InterphaseClient } from "@interphase/sdk";

const client = new InterphaseClient();
const swap = await client.prepareSwap({
    sourceChainId: 1, // Ethereum L1
    sourceToken: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC
    sourceAmount: 10_000n * 1_000_000n, // $10,000 USDC
    destChainId: 101, // Solana
    destinationToken: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", // Solana USDC
    recipientMetaAddress: aliceSolanaMetaAddress,
});

#2. Under the Hood of prepareSwap()

Code Reference: client.ts

When client.prepareSwap() is invoked, the SDK performs 5 operations under the hood:

SYSTEM TOPOLOGY ARCHITECTURE
[User Input Parameters]
           │
           ▼
1. Detect Chain Family (EVM vs Solana)
   Calls @interphase/crypto-core-wasm:
   - Derives Ephemeral Public Key: R = r * G
   - Computes Shared Secret Point: S_shared = r * V
   - Computes Stealth Address: P_stealth
   - Computes Dual-Tier View-Tags: viewTag1 & viewTag4
           │
           ▼
2. Generate Deterministic Nullifier
   nullifier = Keccak256(sourceToken || sourceAmount || destChainId || entropy)
   (Guarantees deposit cannot be double-spent)
           │
           ▼
3. Generate Canonical Intent ID
   intentId = Keccak256(nullifier || stealthAddress || deadline)
           │
           ▼
4. Encode Confidential COTI Payload
   Packages target chain, destination token, stealth recipient, view-tags,
   and slippage bounds for evaluation inside COTI L2 Garbled Circuits.
           │
           ▼
5. Output PreparedSwap Object
   Ready to pass directly to ethers.js / viem / wagmi wallet signers!

#3. Real-Time Progress Tracking & 3-Tier Countdown

Code Reference: client.ts

To keep users completely informed and eliminate anxiety during cross-chain execution, client.formatProgressUpdate() maps on-chain events into structured progress updates:

Step User-Facing Status Message Progress Refund / Safety Protection
INITIATING "Deriving one-time stealth keys and view-tags in WASM..." 10% Zero-heap memory protection active.
DEPOSIT_PENDING "Waiting for source deposit transaction confirmation..." 25% Balance-delta safety assertion.
MPC_EVALUATING "COTI Garbled Circuits evaluating blind compliance..." 50% 3-minute auto-refund timer started.
AUCTION_ACTIVE "Sanitized order published to NEAR Intents. Solvers bidding..." 75% Identity completely stripped.
SOLVER_LOCKED "Market maker committed bond. Executing payout & gas drop..." 90% Solver's 10% collateral locked on COTI L2.
SETTLED "Funds successfully delivered to stealth address!" 100% Destination transaction signature confirmed.
REFUND_TIER_1_AUTO "Auction unfulfilled in 3m. Source deposit auto-unlocked!" 100% Instant source escrow release.
REFUND_TIER_2_DISPUTE "Solver SLA breach. 100% refund + 20% bonus bounty awarded!" 100% Paid from solver's slashed collateral.

#4. The StealthScanner Engine (Background Mobile Sync)

Code Reference: scanner.ts

How does a user’s wallet know when someone sent them a private payment?

In a traditional wallet, you poll the blockchain for your public address (0xAlice). But with stealth addresses, your public address was never touched!

The StealthScanner allows a recipient's web or mobile wallet to scan incoming blocks:

import { StealthScanner } from "@interphase/sdk";

const scanner = new StealthScanner(
    "solana",
    aliceSpendingPrivateKey,
    aliceViewingPrivateKey
);

// Scan incoming transaction event from Solana block stream:
const detected = scanner.scanTransaction(incomingBlockEvent);

if (detected) {
    console.log(`Payment detected! Amount: ${detected.amount}`);
    console.log(`Derived Private Key for spending: ${detected.derivedPrivateKeyHex}`);
}

How the Scanner Achieves Zero Battery Drain:

  1. Tier 1 Filter: It reads event.memoPayload ("ip:4a:11223344"). It checks 4a (viewTag1). 99.61% of all network transactions are discarded immediately with a single-byte integer check!
  2. Tier 2 Filter: For the remaining 0.39%, it checks 11223344 (viewTag4). If that doesn't match, it is discarded. The false positive rate is: $$\frac{1}{2^{40}} \approx 9.09 \times 10^{-13}$$
  3. Only upon a 1-in-a-trillion match does the phone perform elliptic curve point addition to compute the private key.
  4. Result: All-day background synchronization on iOS and Android with $<!0.001%$ background CPU consumption!

#Test Suite Verification

Run the test suite across the monorepo:

npm test --workspace=@interphase/sdk

Output:

# Subtest: InterphaseClient: Prepare EVM-to-EVM Private Swap
ok 1 - InterphaseClient: Prepare EVM-to-EVM Private Swap (67ms)
# Subtest: InterphaseClient: 3-Tier Refund Progress Update Formatting
# Subtest: InterphaseClient: Prepare Ethereum-to-SUI Private Swap
ok 4 - InterphaseClient: Prepare Ethereum-to-SUI Private Swap (101ms)
# Subtest: InterphaseClient: Prepare Ethereum-to-NEAR Private Swap
ok 5 - InterphaseClient: Prepare Ethereum-to-NEAR Private Swap (6.7ms)
# Subtest: InterphaseClient: Prepare Ethereum-to-TRON Private Swap & Scanner Detection
ok 6 - InterphaseClient: Prepare Ethereum-to-TRON Private Swap & Scanner Detection (11.2ms)
# Subtest: InterphaseClient: Prepare Ethereum-to-Bitcoin Native SegWit Private Swap & Scanner Detection
ok 7 - InterphaseClient: Prepare Ethereum-to-Bitcoin Native SegWit Private Swap & Scanner Detection (15.0ms)
# Subtest: InterphaseClient: Prepare Ethereum-to-Cardano Shelley Private Swap & Scanner Detection
ok 8 - InterphaseClient: Prepare Ethereum-to-Cardano Shelley Private Swap & Scanner Detection (8.2ms)
1..8
# tests 8
# pass 8
# fail 0

Across all packages in the monorepo (contracts-coti, contracts-evm, crypto-core-wasm, sdk, solver-daemon), all 25 unit tests pass with 100% precision.

#5. The Omnichain Stealth Matrix: 7 Major Ecosystems

With the addition of TRON, Bitcoin, and Cardano, Interphase provides total cryptographic coverage across the top 7 blockchain ecosystems:

Ecosystem Curve & Primitives Stealth Derivation Formula Address Encoding Gas Drop & Protocol Role
EVM (Eth, Base, Arb) secp256k1 + Keccak-256 $P_{stealth} = S + Keccak256(r \cdot V) \cdot G$ ERC-5564 Hex (0x..., 20 bytes) Native ETH/gas for instant sweeps
Solana Ed25519 + SHA-512 $P_{stealth} = S + Sha512(ctx \parallel r \cdot V)[0..32] \cdot B$ Base58 ([1-9A-HJ-NP-za-km-z]) $0.005 SOL$ + ATA rent harvest
Sui Network Ed25519 + Blake2b-256 $Blake2b-256(0x00 \parallel P_{stealth})[0..32]$ Move Hex (0x..., 32 bytes) $0.1 SUI$ atomic PTB gas drop
NEAR Protocol Ed25519 + SHA-512 $P_{stealth} = S + Sha512(ctx \parallel r \cdot V)[0..32] \cdot B$ 64-character lowercase hex $0.05 NEAR$ implicit account drop
TRON Network secp256k1 + Keccak + SHA256 $Base58Check(0x41 \parallel Keccak256(P_{uncompressed}[1..65])[12..32])$ Base58Check (T..., 34 chars) $30 TRX$ Energy drop for TRC-20 USDT
Bitcoin secp256k1 + RIPEMD160 + SHA256 $BIP-173 Bech32(\text{"bc"}, 0, RIPEMD160(SHA256(P_{compressed})))$ Native SegWit (bc1q..., 42 chars) Native sats UTXO delivery
Cardano Ed25519 + Blake2b-224 $CIP-19 Bech32(\text{"addr"}, 0x61 \parallel Blake2b-224(P_{stealth}))$ Shelley Enterprise (addr1v..., 58 chars) $2 ADA$ MinUTXO deposit

Architectural Details of the New Chains:

  1. TRON Network ($60B+ USDT Volume Leader):

  2. Bitcoin Native SegWit (Global Reserve UTXO):

  3. Cardano Shelley Enterprise (Deterministic EUTXO):

#Lesson 7: The Next.js Web DApp & UI Architecture (packages/web-dapp)

In this lesson, we build and test the user-facing flagship: the Interphase Next.js Web DApp (packages/web-dapp).

We cover:

  1. Framework & Design System Architecture: Why Next.js App Router, TypeScript, and pure Vanilla CSS tokens were chosen.
  2. Module 1 — The Confidential Swap Matrix: Real-time client-side stealth key derivation in WASM, 0.50% slippage guards, and atomic gas drops.
  3. Module 2 — The Battery-Friendly Stealth Scanner: Demonstrating how 99.61% of non-matching network transactions are discarded in ≈ 1ns using Dual-Tier View-Tags.
  4. Module 3 — OpSec & Refund Vault: Visualizing the 4-layer defense (local sandboxes, BSL 1.1 license moat, stripped WASM, and 3-tier refund countdowns).
  5. Module 4 — The 7-Ecosystem Stealth Matrix: Interactive reference covering EVM, Solana, Move (Sui), NEAR, TRON, Bitcoin, and Cardano.

#1. Framework & Design System Architecture

Code References:

Technology Stack:

#2. Module 1: The Confidential Swap Matrix

Inside page.tsx, when the user selects a destination ecosystem (e.g. Solana or Ethereum) and enters an amount:

  1. Automatic WASM Derivation:
    const swap = await client.prepareSwap({
  sourceChainId: 1, // Ethereum L1
  sourceToken: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC
  sourceAmount: 5000n * 1_000_000n,
  destChainId: 101, // Solana
  destinationToken: "SOL",
  recipientMetaAddress: {
    chainFamily: "solana",
    spendingPubKey: keys.spendingPub,
    viewingPubKey: keys.viewingPub,
  },
});
  2. Live Cryptographic Card: Displays the generated one-time stealth address (Pstealth), the coarse view-tag (viewTag1 = 0xbf), and the native Atomic Gas Drop tag (⚡ 0.005 SOL + ATA Rent included).
  3. Interactive 6-Stage Execution Modal: Clicking "Execute Confidential Swap" triggers the live multi-step pipeline:

#3. Module 2: The Stealth Scanner Simulator

Code Reference: src/app/page.tsx

How do mobile wallets detect stealth payments without killing the phone's battery?

  1. The user provides or generates their viewing private key.
  2. Clicking "Simulate Incoming Block Stream" streams 6 transactions through the scanner.
  3. Tier-1 Filtering: 5 out of 6 transactions have non-matching 1-byte view-tags and are discarded instantly in ≈ 1ns without computing elliptic curve math.
  4. Tier-2 Verification: The single matching transaction passes Tier-1 and Tier-2 (1/240 collision rate), triggers point addition, and recovers the exact spending private key scalar live on screen.

#4. Module 3: OpSec, BSL 1.1 & 3-Tier Protection

  1. Zero Public Testnets: Explains why developing on local in-memory nodes (Anvil / Hardhat) prevents automated mempool decompilers from analyzing bytecode patterns before launch.
  2. Business Source License (BSL 1.1): Protects the codebase against commercial forking and competitive routing for 2–3 years (the Uniswap v3 / Morpho model).
  3. 3-Tier Refund Guard: Transparently explains the 3-minute auto-refund, the solver SLA dispute with 20% slashed bond bounty, and the 24-hour emergency dead-man switch.

#5. Module 4: The 7-Ecosystem Stealth Matrix

Provides an interactive card grid detailing all 7 supported chains:

#Verification & Testing

The Next.js application compiles cleanly in production mode:

npm run build --workspace=@interphase/web-dapp

Output:

SYSTEM TOPOLOGY ARCHITECTURE
Route (app)                                 Size  First Load JS
┌ ○ /                                    34.4 kB         137 kB
└ ○ /_not-found                            985 B         104 kB
+ First Load JS shared by all             103 kB
✓ Built in 1145ms

All browser actions and UI flows were tested and verified locally.

Related Research & Specifications

VOL. 01Architecture & Cryptography

Master Protocol Specification (v3.0.0 Genesis)

Confidential Omnichain Execution Architecture, WASM Cryptography & Compliance Standard

Read Document →
VOL. 02Competitive Intelligence

Competitive Landscape & Market Moat Map

Forensic Analysis of Bridges, Mixers, Stealth Tools, and Centralized Swappers

Read Document →
← PREVIOUS VOLUMEVOL. 03Technical Implementation Roadmap & Execution Plan
NEXT VOLUME →VOL. 05COTI MPC & NEAR Intents Architectural Blueprint
← Return to AI Slop Archive Directory