Cowrie Research

ten-protocol-primary-sources-2026-05-13

4 min read

TEN Protocol primary sources — 2026-05-13

Project status in this pass

  • TEN’s clearest accessible primary materials in this pass were the official overview docs, the main go-ten repository README, and the gateway/session-key documentation.
  • The official overview page points to a litepaper at https://ten.xyz/litepaper, and the repository README points to a reference whitepaper at https://whitepaper.ten.xyz/, but neither path produced readable document text during this pass.
  • The main reason TEN matters for the corpus is that it makes the confidentiality control plane unusually explicit: enclave execution, hostile-host mediation, gateway-scoped identity/access policy, private indexing, and gateway-native session-key management all appear as separate layers rather than one generic privacy claim.

Primary-source snapshots

1) TEN overview docs

  • URL: https://docs.ten.xyz/docs/overview/
  • Key excerpts/signals:
    • Describes TEN as an Ethereum-compatible Layer 2 that brings “programmable privacy,” “shared encrypted state,” and confidential smart-contract execution.
    • Frames the core primitive as a “confidential rollup.”
    • Says encrypted transactions are decrypted only under programmable rules.
    • Says developers can choose what data is public, private, or time-delayed through “smart transparency.”
    • Links to an official litepaper, even though that document was not readily extractable in this pass.
  • Why it mattered:
    • This page is the cleanest official statement that TEN is not just a generic rollup plus a privacy feature; the project is explicitly trying to turn selective disclosure and encrypted shared state into application-facing infrastructure.

2) go-ten repository README

  • URL: https://raw.githubusercontent.com/ten-protocol/go-ten/main/README.md
  • Key excerpts/signals:
    • Says TEN is an encrypted EVM Ethereum Layer 2 and identifies three core processes: the Enclave, the Host, and the Gateway.
    • Says the Gateway exposes standard Ethereum RPC and manages viewing keys on behalf of users while running in a TEE.
    • Says the Host is operator-controlled, not attested, and should be treated as adversarial by the enclave.
    • Says the trusted computing base is the enclave plus an encrypted relational database.
    • Explains that ordinary external indexing is impossible because TEN’s data is private, so “the enclave itself has to be an indexing service.”
    • Says the active mempool runs inside the secure enclave and that this prevents sequencer-side ordering games/MEV in the normal transparent-node sense.
    • Distinguishes sequencer and validator nodes: only the sequencer actively produces batches, while validators still validate user transactions and return useful errors.
    • Describes Ethereum integration, synthetic L1→L2 transactions, encrypted batch payloads, rollup/blob data availability, and rollup-header commitments for L2→L1 bridge messages.
  • Why it mattered:
    • This README is the best single source for TEN’s real architectural decomposition. It makes confidentiality legible not only as encrypted execution, but as a broader reshaping of indexing, RPC, sequencing, and bridge design.

3) Programmable gateway access docs

  • URL: https://docs.ten.xyz/docs/write-ten-dapp/programmable-gateway-access
  • Key excerpts/signals:
    • Says users first create a gateway user and receive an encryption token plus a fresh viewing-key pair.
    • Requires wallets to authenticate addresses to that token by signing a gateway-provided message.
    • Says multiple addresses can be associated with a single encryption token.
    • States that JSON-RPC requests are sent through the gateway with the token as a query parameter.
    • Says the gateway enforces that reads and writes are scoped to accounts bound to that token and forwards calls to the TEN node over an encrypted channel.
    • Includes helper endpoints for revoking access, network-health queries, config discovery, and browser cookie storage of the token.
  • Why it mattered:
    • This page makes clear that TEN’s privacy model is partly chain architecture and partly gateway policy. Access to private state is mediated through token-bound identity and gateway authorization, not simply by “running a private rollup.”

4) Session-key docs

  • URL: https://docs.ten.xyz/docs/write-ten-dapp/session-keys/
  • Key excerpts/signals:
    • Contrasts TEN’s approach with classic EIP-4337 by saying native session keys are managed by the gateway and TEEs without requiring proxy contracts or a bundler.
    • Describes session keys as ephemeral Ethereum accounts managed by the gateway and linked to a user’s viewing key / encryption token.
    • Says users can have up to 100 session keys and that the gateway can automatically expire idle keys and sweep funds back to the primary account.
    • Shows that session-key management is exposed through special JSON-RPC/custom-query flows rather than through a separate onchain smart-account framework.
    • Says the gateway verifies session-key ownership under the authenticated token before signing and broadcasting transactions.
  • Why it mattered:
    • This is the clearest evidence that TEN’s wallet-abstraction layer is itself a core control surface. The gateway is not merely an onboarding helper; it actively holds scoped spending authority inside the TEE and shapes the UX/security tradeoff for private apps.

Working conclusion

TEN is best cataloged as confidential-rollup infrastructure where the decisive mechanism is not only encrypted execution but the explicit split between enclave execution, adversarial host mediation, gateway-managed viewing/access policy, private indexing, and native session-key custody. The main corpus value is that TEN makes several normally hidden layers legible at once: who can see private state, who orders transactions, who mediates queries, and where smart-account-like authority actually lives when a privacy-preserving chain still wants mainstream Ethereum UX.

Graph View