Deep research on MPC, TEE, and threshold cryptography primitives for AI agent signing — fully autonomous and user-cosigned architectures compared.
Giving an AI agent autonomous financial authority creates a three-way tension between autonomy (agent signs without friction), control (human can override or cap spending), and compliance (platform is not a custodian). Traditional architectures force you to pick two. The cutting edge in 2026 delivers all three — but only with the right combination of cryptographic primitives.
Agent holds or participates in a signing quorum. Executes trades/transfers within policy bounds with zero human friction per transaction. Suitable for HFT-style bots, DCA strategies, routine rebalancing.
Agent proposes; user must contribute a shard/approval from personal device (Telegram bot, mobile app) before broadcast. Required for withdrawals above threshold, strategy changes, or by user preference.
The dominant 2026 stack is a layered model: (1) MPC or TEE secures the key material so no single entity can extract the full private key; (2) a policy engine enforces velocity limits, allowlists, and circuit breakers autonomously; (3) threshold co-signing gates exceptional operations behind human approval. The market has consolidated significantly — Privy → Stripe, Dynamic → Fireblocks, Web3Auth → MetaMask/Consensys, Sequence → Polygon Labs — leaving fewer truly independent vendors.
For trading bots: Turnkey (TEE) + Safe (on-chain guard module) as the primary stack. Turnkey gives sub-100ms autonomous signing; Safe's guard module enforces on-chain policy and enables co-sign upgrades for large withdrawals. For decentralized, non-custodial user wallets where Openclaw must not be a custodian: Lit Protocol (decentralized MPC + TEE hybrid). Keep user co-sign via a lightweight Telegram → webhook → Lit Action approval flow.
The agent is the only authorized party for routine operations. The key lives in a secure enclave (TEE) or is distributed via MPC with the platform's signing node acting as co-participant in a 2-of-2 scheme where both parties are automated systems. From the chain's perspective, a normal ECDSA/Schnorr signature appears — indistinguishable from a single signer.
The critical insight here is that the policy engine must live outside the agent's own code. If the agent is compromised (prompt injection, model hallucination), hardcoded rules in the agent logic can be bypassed. External policy enforcement — at the signer level — is the only reliable guardrail.
Key latency considerations for Openclaw's trading context:
The key is split into at least 3 shares. The agent holds share 1, the platform/enclave holds share 2, and the user holds share 3 on their personal device. For routine operations, the agent + platform (2-of-3) suffice. For exceptional operations (withdrawal above X, shutting a strategy, new venue authorization), the user's shard is required.
Telegram Integration Pattern: The user's shard lives in a Telegram mini-app wallet (e.g., TonKeeper-style but for EVM/Solana). The agent pushes a transaction request to a webhook; the user sees a formatted approval card in Telegram (asset, amount, destination, risk score), approves with a tap. The device signs with share #3, sends partial signature back to the coordination layer, which assembles the full signature and broadcasts.
From a regulatory standpoint: if Openclaw's server holds any key share and can move funds without user involvement (even in a 2-of-3 where platform + agent suffice), regulators may classify Openclaw as a custodian requiring a money transmitter license. The cleanest non-custodial posture requires user involvement in every signing event — or a TEE architecture where the platform demonstrably cannot access key material. This matters in UAE VARA/ADGM jurisdiction.
A private key is never assembled at any point. Multiple parties each hold a cryptographic "share" and collaboratively execute a signing protocol (typically threshold ECDSA or FROST for Schnorr). The on-chain result is a standard signature — no bloat, chain-agnostic.
Key variants: GG18/GG20 (older, widely deployed), CGGMP21 (Fireblocks MPC-CMP), FROST (Schnorr, fewer rounds), Dkls23 (used in newer Web3Auth/ZenGo).
A hardware-isolated CPU region (Intel SGX/TDX, AMD SEV-SNP, ARM TrustZone, AWS Nitro Enclaves) where code and key material are protected from the OS, hypervisor, and even the cloud operator. Remote attestation lets external parties cryptographically verify what code is running inside.
Key property: The full private key exists but is locked inside the enclave. The platform can't extract it. Fast (sub-100ms) but single-vendor dependency if using AWS Nitro.
Key shares are distributed across a decentralized network of nodes, each running inside a TEE. Used by Lit Protocol (AMD SEV-SNP, threshold BLS + ECDSA) and Safeheron (Intel SGX). No single company can reconstruct the key even under legal compulsion. "Lit Actions" allow programmable on-chain and off-chain signing conditions.
This is the strongest self-custody posture — non-custodial at the cryptographic and governance levels simultaneously.
The "wallet" is an on-chain smart contract with programmable validation logic. ERC-4337 deploys a new smart account address; EIP-7702 (live since Ethereum Pectra, May 2025) upgrades an existing EOA to a smart account without address migration. Session keys give agents scoped, time-limited signing authority without touching the master key.
Safe ($100B+ secured) adds guard modules for per-transaction policy enforcement. Perfect as the governance layer on top of MPC/TEE signing.
The private key is split into N shares (k-of-N recoverable). Unlike MPC/TSS, the key is reconstructed in memory at signing time. Simpler to implement and understand, but introduces a momentary single point of failure at each signing event. Used by older Privy implementations before their TEE migration.
Emerging layer for proving the agent followed its strategy without revealing the strategy itself. zkML proofs (zkML) prove a model ran correctly; TEE attestation proves specific code was executed. Used in ERC-8004 (Ethereum "Trustless Agents" standard, Q4 2025) where agents carry on-chain identity with cryptographic proof of execution. Phala's dstack + Intel TDX implements this today.
Relevant for Openclaw's leaderboard integrity — proving a bot traded honestly without revealing its strategy.
Privy → Stripe (June 2025) · Dynamic → Fireblocks (2025) · Web3Auth → MetaMask/Consensys · Sequence → Polygon Labs. If vendor independence matters to Openclaw, prioritize Turnkey, Lit Protocol, Openfort, or Dfns — none of which have been absorbed into larger stacks.
Dominant institutional custody. MPC-BAM protocol with 2-party ECDSA; key shares refresh every few minutes. Acquired Dynamic (embedded wallets). ~$8B valuation, $1.04B raised. 130M+ wallets secured. Policy engine is enterprise-grade. Best for Openclaw if targeting institutional bot operators.
Fastest signing latency in the market: 50–100ms via AWS Nitro Enclaves. Pure infrastructure layer — you build the wallet UX. Full private key lives in enclave (vs MPC). Chain-agnostic via secp256k1/ed25519 curve support. Best-in-class for autonomous agent signing with policy engine. Used by Alchemy, Moonshot, Spectral (AI agents). Top pick for Openclaw's autonomous bot wallets.
Distributed key network where 30+ nodes run AMD SEV-SNP TEEs. DKG (Distributed Key Generation) — no node ever sees the full key. "Lit Actions" = programmable JavaScript signing conditions (e.g., "sign only if onchain balance > X"). Threshold BLS + ECDSA. Best for non-custodial user wallets where Openclaw must not hold any share. Adds 300–600ms but delivers genuine decentralization.
Industry standard for on-chain governance. $100B+ secured. Modular: Guards enforce per-TX policy; Modules add roles; Delegates allow agents to propose without master-key access. ERC-4337 compatible. Pairs with MPC/TEE as a governance layer over the signing key — agent can execute within Safe's rules, human must approve exceptional ops. Best governance layer for DeFi-facing Openclaw bots.
Purpose-built for AI agents. TEE-secured CDP wallets (non-custodial). Pre-built skills: trade, earn, send, fund. x402 machine-to-machine payments (50M+ TXs). Base-native with gasless transactions. Strong for Base-ecosystem DeFi agents. LangChain + Vercel AI SDK + MCP integrations. Good if Openclaw is Base-first or wants prebuilt agent skill library.
Confidential AI compute cloud. Agents run in Intel TDX enclaves via "dstack". Generates wallet keys entirely inside TEE — developers lose access post-deployment (full agent autonomy). ERC-8004 standard for on-chain agent identity + reputation. Newton (Magic Labs) uses Phala for non-custodial DeFi automation. Best for Openclaw's verifiable agent execution layer (leaderboard integrity).
Acquired by Stripe June 2025. TEE-based embedded wallets (175ms signing). Deep Stripe + Bridge stablecoin integration. 75M wallets, trusted by OpenSea, Hyperliquid, Farcaster. Now on Stripe ecosystem rails — excellent for fiat/crypto hybrid flows. Vendor lock-in concern post-acquisition. Good if Openclaw wants Stripe payments integration for competition entry fees.
Open-source wallet infra with self-hostable key management (OpenSigner). TEE backend wallets for server-side key storage. Native smart accounts with gas sponsorship, session keys, and policy engine built-in. 125ms signing. Best choice if Openclaw wants to self-host wallet infrastructure and avoid vendor dependency entirely. True ownership of the stack.
Institutional MPC wallet with hardware isolation. MPC protocols + isolated hardware + biometrics. Developer-friendly API for DeFi trading. Transaction simulation before signing. Role-based vaults. Good for Openclaw's institutional/DAO participants who need DeFi-native MPC with compliance tooling.
| Provider | Core Tech | Signing Latency | Scenario A (Autonomous) | Scenario B (Co-Sign) | Non-Custodial? | Self-Hostable | Chain Coverage | Vendor Risk | Openclaw Fit |
|---|---|---|---|---|---|---|---|---|---|
| Turnkey | TEE AWS Nitro | 50–100ms ⚡ | ✓ Policy Engine | Manual webhook | Platform-dependent | No | Any (curve-agnostic) | AWS dependency | ★★★★★ Bot wallets |
| Fireblocks | MPC-CMP TSS | 200ms+ | ✓ Enterprise policy | ✓ Native mobile SDK | ✓ True MPC | No | 50+ chains | Vendor lock-in | ★★★★☆ Institutional |
| Lit Protocol | Hybrid dMPC + TEE | 300–600ms | ✓ Lit Actions | ✓ Programmable | ✓ Fully decentralized | No (network) | EVM, Solana, BTC | Low (decentralized) | ★★★★★ User wallets |
| Safe + Session Keys | Smart Contract AA | Block time (5s+) | ✓ Session keys only | ✓ On-chain guard | ✓ Trustless | Yes | EVM only | Open-source | ★★★☆☆ DeFi governance |
| Coinbase AgentKit | TEE CDP | ~100ms | ✓ Agent Skills | Via CDP portal | TEE-dependent | No | Base-native | Coinbase ecosystem | ★★★☆☆ Base-only |
| Phala + dstack | TEE Intel TDX | Variable | ✓ Full autonomy | Complex setup | ✓ Developer excluded | Via Phala Cloud | Any via lib | Network maturity | ★★★★☆ Bot attestation |
| Privy (Stripe) | TEE + SSS | 175ms | ✓ Server wallets | ✓ Social login | TEE-dependent | No | EVM + Solana | Stripe lock-in | ★★★☆☆ User onboarding |
| Openfort | TEE Open-Source | 125ms | ✓ Session keys | ✓ Custom flows | ✓ Self-hosted | Yes ✓ | EVM + Solana | None (open-source) | ★★★★☆ Self-sovereign |
| Fordefi | MPC + TEE HW isolated | 200–300ms | ✓ DeFi API | ✓ Mobile approval | ✓ MPC | No | Multi-chain + DeFi | Vendor | ★★★★☆ Pro traders |
| Web3Auth | dMPC Torus Network | 500ms+ | ✓ Server wallets | ✓ Social recovery | Network-dependent | No | Any curve | MetaMask/Consensys | ★★☆☆☆ Latency issues |
The agent's wallet key lives entirely in a TEE (Turnkey/AWS Nitro). The policy engine is a separate service that checks every signing request before it reaches the enclave. This is the fastest path and the right choice for Openclaw's trading bots where sub-100ms matters.
Three-party MPC where threshold logic handles routine ops autonomously and gates exceptional ops behind user co-sign. The user's shard lives on their mobile device, never on a server. This is the strongest self-custody story for end users who are serious about their keys.
A two-layer architecture. The outer layer is a Safe smart account with guard modules for on-chain policy (EVM DeFi). The inner layer uses Turnkey as the master key for the Safe owner. Session keys (EIP-7702 or ERC-4337) give the agent scoped, time-limited authority without touching the master.
The entire trading bot runs inside Intel TDX on Phala Cloud. Keys are generated inside the enclave and never leave. The agent gets an ERC-8004 on-chain identity with a TEE attestation hash that proves which code version is running. This enables Openclaw's leaderboard integrity — cryptographic proof that a top-ranked bot ran its declared strategy, not a different one.
sign() without user involvement makes Openclaw a custodian regardless of TEE. UAE VARA/ADGM requires a VASP license for custodians. Mitigation: ensure user shard or TEE attestation breaks custodian classification.Openclaw has three distinct wallet contexts with different requirements. They should not use the same primitive for all three.
ethers.signMessage submitted to Lit Action condition.Phase 1 (MVP): Turnkey for bot hot wallets + Telegram webhook for co-sign. Fast to ship, battle-tested API.
Phase 2 (User Wallets): Add Lit Protocol for participant self-custody wallets. Lit Actions as programmable spending rules.
Phase 3 (Differentiation): Phala dstack + ERC-8004 for certified bot registration with TEE attestation. Ship as "Verified Bot" badge on leaderboard.
Coinbase's x402 protocol (50M+ transactions) is the emerging standard for agent-to-agent payments — bots paying for data feeds, compute, API access autonomously. Worth integrating in the Openclaw arena as bots acquire data subscriptions or pay entry fees. The protocol is Base-native today but V2 is expanding. Relevant when Openclaw adds a marketplace layer.