MVP Architecture

V3: Asynchronous Privacy Pool with TEE Coordinators

Core Principle

A network of decentralized coordinators running inside a Trusted Execution Environment (TEE) (Intel SGX / AWS Nitro Enclaves), with mandatory Remote Attestation before any sensitive signing operation.

Security Shift

Before (POC)	After (V3)
Behavioral security (client monitoring, best-effort execution)	Cryptographic execution security (attested binary + binding settlement/fee logic)

Cryptographic Guarantees

1. Binary Integrity via Remote Attestation — users verify the enclave measurement before sending FROST shares. A coordinator fork that removes fees or ignores policies is rejected.

2. Protocol Fee Hard-Bound to Settlement — the enclave builds settlement transactions with a mandatory fee output. Removing the fee invalidates the signing process.

3. Software Atomicity — the TEE aggregates all signatures and broadcasts only when all transactions are ready. No vulnerability window.

Why DKG + Delegation (Not a Raw Private Key)?

Approach	Advantage
DKG + delegation (our approach)	Key never existed in full form before delegation. LP can verify the TEE participated in DKG. Pre-signed refund possible before delegating.
Raw private key handoff	Simpler but no process verifiability, no pre-delegation refund, separate key management path.

LP Delegation Flow

LP                                          TEE Enclave
 |                                           |
 |  1. 2/2 FROST DKG ────────────────────►  |
 |     → W_lp (joint pubkey)                |
 |                                           |
 |  2. Verifies attestation                  |  Proven code:
 |     (MRENCLAVE / PCR)                     |  - spending rules
 |                                           |  - no key export
 |  3. Sends share_lp ────────────────────►  |  - refund logic
 |     via encrypted attested channel        |  - fee logic
 |                                           |
 |  4. Funds W_lp ────────────────────────►  |  Holds:
 |     (SystemProgram.transfer)              |  share_lp + share_tee
 |                                           |  = solo signing
 |  5. Disconnects                           |

Spending Policies

At delegation time, the LP registers a signed spending policy:

Parameter	Example	Purpose
`max_amount_per_swap`	5 SOL	Cap per individual swap
`total_committed`	20 SOL	Total amount committed to the pool
`payout_deadline`	3 weeks	After this, TEE must auto-refund
`refund_address`	LP_origin	Where funds go if no swap or deadline reached
`min_fee_bps`	30 bps	Minimum acceptable fee

The attested binary refuses to sign any transaction that violates these constraints.

TEE Orchestration (Asynchronous)

Once Alice has deposited and delegated:

Matching — select LP wallets whose constraints are compatible
Scheduling — generate a random payout schedule using attested CSPRNG. Amounts are fragmented non-uniformly
Deferred execution — at each scheduled slot, the TEE signs and broadcasts:
- W_lp_N → Alice_fresh_N (payout)
- W_alice → LP_refund_address (reimbursement)
- Fee output to protocol xPub address
All transactions are SystemProgram.transfer only

Example Payout Schedule

Timeline (3 weeks)
──────────────────────────────────────────────────

  Day 2       Day 5       Day 11      Day 16      Day 20
  0.4 SOL     1.1 SOL     0.3 SOL     0.8 SOL     0.4 SOL
    |            |           |            |           |
    v            v           v            v           v
  W_lp_1 →   W_lp_2 →   W_lp_1 →   W_lp_4 →   W_lp_2 →
  Alice_1     Alice_2     Alice_3     Alice_4     Alice_5

Each payout goes to a fresh address. No link between Alice_1 through Alice_5 on-chain.

MVP Architecture

On this page