Trust Model & Security

Trust Model

Explicit tradeoff: in the POC, no one ever holds the full key (pure 2/2 FROST). In the pool, the TEE holds both shares after delegation. That is an additional trust assumption, compensated for by verifiable attestation. This is trust-minimized, not trustless.

---

Failure Scenarios

TEE Down (Crash / Maintenance)

LP: broadcasts refund_lp via durable nonce. Always valid, no TEE needed.

Alice (depends on timing):

• Nonce not yet advanced → broadcasts pre-signed refund → recovers SOL
• Nonce already advanced → old refund invalid → waits for TEE restart or failover to another TEE in the coordinator network

TEE Compromised (Hardware Exploit)

An attacker who compromises the enclave obtains all delegated shares and can drain active wallets.

Hardware risk: high impact, very low probability. Requires physical CPU exploit.

Known attacks on Intel SGX: Foreshadow (2018), Plundervolt (2019), SGAxe (2020), AEPIC Leak (2022).

Mitigations: liquidity caps, enclave rotation, TEE quorum (M-of-N), on-chain monitoring, prefer AWS Nitro.

Alice Double-Spend

Impossible by design. When Alice delegates her share, the TEE immediately advances the durable nonce. The pre-signed refund was signed with the old nonce value — Solana rejects it.

LP Deadline Reached

TEE auto-refunds W_lp → LP_origin. Hardcoded in attested binary.

---

Adversarial Analysis

Timing Correlation

If the pool is small, an analyst can correlate inflows/outflows.

Mitigations: minimum anonymity set (K active LP wallets), batching multiple swaps, temporal jitter.

LP Collusion

A malicious LP creates N wallets to maximize matching probability.

Mitigations: TEE never reveals match info to LPs. LP reimbursements come from W_alice (unlinkable). Fundamentally a pool-size problem.

Progressive Rollout