Sealed Protocol: Technical Overview

Status: public preview. Payments on the site are simulated until the mainnet launch; the vault contract and the agent run on NEAR testnet today. This document describes the system as built. Where it says what users are trusting, it matches the /trust page (docs/TRUST_MODEL.md).

Abstract

Sealed is a chain-abstracted, privacy-preserving payments protocol that turns every X (Twitter) account into a multichain receiving endpoint without any onboarding. Deposit addresses on Bitcoin, every major EVM chain and Solana are derived deterministically from the account's immutable numeric X user ID through NEAR Chain Signatures, a threshold multi-party computation (MPC) signing network. Value is settled through NEAR Intents, an intent-centric, solver-driven cross-chain settlement layer, into a confidential balance on NEAR's private execution layer (Confidential Intents). Ownership is established by an OAuth 2.0 identity attestation verified inside a Trusted Execution Environment (Intel TDX via dstack) by a remotely attested Shade Agent, and every signature is mediated by an on-chain policy engine, the vault smart contract, which enforces rate limits, time-delayed execution and a public governance timelock, and exposes a one-way migration path to full self-custody.

1. Design invariants

The protocol is specified by ten invariants (the product rules R1–R10), each enforced in code and covered by tests (docs/VERIFICATION.md, "Rules R1–R10").

2. Layered architecture

3. Identity layer

• Identity oracle. Handle resolution uses X API v2 with an app-only bearer token, fronted by a cache-first resolver (handle to ID for 24 hours, profile for 6 hours, negative results for 10 minutes) and per-IP fixed-window rate limiting, because every uncached lookup consumes metered API credits against a 300-requests-per-15-minutes application budget.
• Authentication. Sign in with X is OAuth 2.0 Authorization Code with PKCE, executed entirely inside the TEE agent. The PKCE verifier and return path travel inside the state parameter, sealed with AES-256-GCM under a TEE-derived key, so no server-side OAuth state store exists. The agent exchanges the code, calls /2/users/me exactly once, revokes the access token, and mints a first-party session.
• Sessions. v1.<payload>.<mac> tokens, HMAC-SHA256 over a key derived inside the enclave, 15-minute lifetime; value-moving and key-management operations additionally require an authentication event less than 5 minutes old (step-up freshness).
• Adversarial handle hygiene. Homoglyph (lookalike Unicode) detection, rename and recycled-handle warnings from a handle-to-ID history, new-account and protected-account signals.

4. Deterministic multichain address derivation

Addresses are derived with NEAR Chain Signatures' additive key-derivation scheme. The derivation path binds the protocol version, the identity and the key family:

path      = "x/{xUserId}/v1/{family}"            family ∈ { evm, btc, sol, intents }
epsilon   = SHA3-256("near-mpc-recovery v0.1.0 epsilon derivation:" ‖ predecessor ‖ "," ‖ path)
secp256k1 = root_secp + int_be(epsilon) · G              (domain 0: evm, btc)
ed25519   = root_ed   + (int_le(epsilon) mod L) · B      (domain 1: sol, intents)

• The predecessor is the vault contract, so only the vault can request signatures for these keys. The MPC network never reconstructs a private key: signatures are produced jointly by the threshold of independent nodes.
• Address encodings: EIP-55 checksummed Keccak-256 addresses (one EVM key shared across Ethereum, Base, Arbitrum, Robinhood Chain and BNB Chain), native SegWit P2WPKH (bc1q…) for Bitcoin, base58 Ed25519 for Solana, and a 64-hex implicit NEAR account for the handle's NEAR Intents account.
• Frozen at launch. The scheme is covered by shared TypeScript/Rust test vectors, 80 golden keys recorded from both live signer contracts, property-based signature-recovery tests and a live testnet signing test.

5. The policy engine: vault contract

The vault is a NEAR smart contract (Rust, near-sdk) acting as a capability-scoped signing proxy. It never signs an opaque hash: it builds every payload itself or parses externally generated ones against a strict grammar.

Signing surface.

Guardrails. A per-handle, per-token rolling 24-hour spend window (window_add, checked arithmetic, property-tested with proptest), a delay threshold above which transfers enter a public 24-hour queue, and owner-key additions that always queue. If the MPC call fails, the callback restores the consumed allowance (compensating transaction). Tokens without a configured limit fail closed.

Governance. A multisig can only propose changes (limits, approved agent measurements and CPU identifiers, sweep routes, code upgrades), which execute after a public 14-day timelock. The only immediate governance powers reduce capability: a 72-hour self-expiring circuit breaker, per-instance agent revocation, proposal cancellation and lock_forever, which removes the upgrade path permanently. After deployment the vault account holds no access keys: its code can change only through its own timelocked execute_upgrade.

Agent registry. In TEE mode, agents register with a dstack remote-attestation quote verified on-chain by the vendored shade-attestation crate (Intel TDX DCAP verification): approved measurements (the published code hash), an approved platform identifier (PPID), and report data binding the quote to the agent's NEAR account. Registrations expire after 7 days; an agent whose measurements are revoked is evicted on its next call.

6. Confidential settlement: NEAR Intents and 1Click

• Intent-based settlement. Every spend from a handle's balance is a 1Click quote: solvers compete to fill it, and settlement happens atomically in the intents.near verifier contract.
• Confidential sends. In-app sends request quotes with recipientType: CONFIDENTIAL_INTENTS and a confidentiality level, delivering into the recipient's account on NEAR's private layer (the NEAR Private Shard). Confidential balances are held as IMT-wrapped tokens (imt:{minter}:{token}).
• Account authentication. Reading a confidential balance needs a User-Session: the vault signs an empty-intents NEP-413 login message with a versioned nonce (the verifier's current salt plus a timestamped random component); /v0/auth/authenticate returns a short-lived token held only in enclave memory.
• Externally generated intents. Spending confidential balances uses generate-intent → vault-side validation and MPC signature → submit-intent. The vault parses the message and enforces signer, token, amount and deadline before signing.
• Public balances (credited by sweeps) are read with mt_batch_balance_of; balances are the union of public and confidential holdings, spent one token at a time.

7. Ingress: public deposits and the sweep pipeline

• Detection is balance-based rather than event-based: Multicall3 batch reads (up to 200 balances per call) at the confirmation depth on EVM chains, Esplora UTXO queries on Bitcoin, and batched getMultipleAccounts / token-account reads on Solana. Observations are untrusted hints: the agent re-reads chain state before planning.
• Routes are governance-approved per {chain}:{asset}. Registered routes deliver to the handle's PoA bridge deposit address after a public 24-hour activation delay and within a per-handle daily cap; omni_evm routes embed the destination in Omni Bridge initTransfer calldata, making the destination provable on-chain.
• Chain-specific builders: EIP-1559 transactions with OP Stack L1 data-fee bounds on Base; BIP-143 SegWit sighashes for Bitcoin; Solana transactions with on-chain derivation of associated token accounts (program-derived addresses with an Ed25519 off-curve check), CreateIdempotent and TransferChecked. All builders are byte-for-byte identical to reference implementations in the test suite.
• Gas abstraction. A relayer hot wallet (EVM and Solana keys derived from the enclave master key) funds token sweeps. It accepts an X ID, never an address, derives the destination itself, and has per-funding and daily budgets; it is not reachable over the RPC surface.
• Continuous verification. The sweeper audits every registered sweep address against the bridge hourly and raises an error-level alert on divergence, well inside the 24-hour activation window.

8. Egress: withdrawals, swaps and shielded exits

• Withdrawals to any supported chain and swaps inside the confidential balance are 1Click quotes executed through the vault's external-intent path, with step-up authentication.
• Delay-queue semantics: above the per-token threshold, a withdrawal enters the public queue; when due, the agent re-quotes and spends the queued allowance with a fresh message.
• Shielded exit: ZEC withdrawals target unified Zcash addresses for continued privacy after leaving the protocol (delivery to the shielded receiver is confirmed in the mainnet smoke test).
• Fee mechanics: 0.75% on withdrawals, collected as a separate vault-signed transfer to the treasury within the same guardrail window, rounded up to the base unit; the holder discount and buyback module are implemented and switched off until a token exists.

9. Sovereign exit: from system key to self-custody

• Proof of possession: new owner keys sign a one-time challenge: Ed25519 (Solana wallets, NEAR keys), EIP-191 personal_sign with public-key recovery (EVM wallets), or a WebAuthn P-256 assertion bound to the site origin (passkeys).
• Queued registration: additions always wait in the public delay queue, then are submitted to intents.near as add_public_key intents by the agent's executor account (an implicit NEAR account derived from the enclave master key, used only for gas).
• System-key revocation requires an active wallet key (passkeys are origin-bound) and emits a remove_public_key intent; from then on the vault refuses to act for the handle.

10. Trusted execution and key management

• Remote attestation. The agent runs as a Shade Agent in a confidential VM (Intel TDX, dstack on Phala Cloud). Its image is a single esbuild bundle in a digest-pinned, reproducible OCI image: a clean rebuild of the same commit yields the same digest. The approved code hash is the SHA-256 of the canonical measurement set (MRTD, RTMR0–2, the key-provider event digest and the app-compose hash) that governance approves through the timelock.
• Key hierarchy. Inside the enclave, a 32-byte master key comes from dstack's key management service, bound to the attested application identity. Every operational key is derived from it with HKDF-SHA256 under a distinct context label:

• Horizontal scalability. Because every key is derived from the attested identity, any approved instance can serve any session: agents are stateless replicas behind the vault's registry.

11. Transport, application security and data minimization

• Service mesh authentication: web-to-agent and sweeper-to-agent calls use an allow-listed RPC table with HMAC-SHA256 request signing over method, path, timestamp, nonce and body digest, a 60-second validity window and a replay cache.
• Web hardening: strict nonce-based Content Security Policy, CSRF defences with login-CSRF binding of the OAuth state, per-IP rate limiting, schema-validated API contracts (zod) on both sides of every call, and a zod-free client entry that keeps first-visit bundles small.
• Data minimization: Postgres holds only caches and public metadata; no private balances, OAuth tokens or sender-recipient relationships are persisted. Structured logs are redacted by key and by value pattern, with dedicated tests.
• Supply-chain controls: pinned toolchains, reproducible contract and agent builds, secret scanning on every commit, and a dependency audit gate in CI.

12. Privacy model and trust assumptions

Confidential: who a private payment was for, every balance, incoming private payments, and activity history.

Public by construction: deposits into the private layer and withdrawals out of it (on the chain where they happen); payments to a handle's public addresses and their sweep; while a handle still uses the system key, the token and amount of each outgoing move, because guardrails are enforced on-chain. Timing and amount correlation can link transactions. Confidential is not anonymous.

Trust assumptions:

1. The X account. Whoever controls it can sign in and, until an owner key is added, spend within the guardrails.
2. The MPC network. A colluding threshold of Chain Signatures nodes could sign arbitrary payloads.
3. The TEE. A hardware or hosting compromise could impersonate the agent; guardrails, the delay queue and the circuit breaker bound the damage for system-key handles.
4. The private layer. Confidential state depends on NEAR's approved validator set.
5. Code correctness. The contract and agent have not been audited yet.

13. Engineering and verification

• Monorepo: pnpm workspaces and Turborepo; strict TypeScript; Rust for the contract, built in a pinned cargo-near container.
• Testing pyramid: 579 unit tests; property-based testing with fast-check (derivation, fee math) and proptest (the guardrail window); contract unit tests (92% line coverage) and near-sandbox integration tests against a signing MPC stand-in; byte-identical transaction vectors against reference libraries; 62 Playwright end-to-end tests (all eight user journeys, WCAG 2.1 AA accessibility scans, JavaScript page-weight budgets).
• Live verification: the journeys run through the deployed testnet vault and the real testnet MPC network; vault-signed sweeps are accepted by Base Sepolia and Solana devnet nodes.
• Quality gates: lint, type-check, secret scan and formatting on every commit; 80% line coverage enforced per package.

Glossary

Further reading: docs/ARCHITECTURE.md (every flow with diagrams), docs/THREAT_MODEL.md, docs/TRUST_MODEL.md, docs/DEPLOYMENT.md, DECISIONS.md.