Summary: t1 is best understood as an attempt to repair Ethereum rollup fragmentation by making cross-chain execution legible to Ethereum in near real time, not as a generic bridge or another standalone rollup. Its core mechanism combines TEE-based execution, partner-rollup reads and writes, Ethereum-verified canonical bridge updates, and an eventual defense-in-depth path toward sequencer/executor consensus plus periodic ZK checkpoints. The reusable insight is that t1 shifts the control surface away from classic optimistic message bridges and toward remote-attested operators, bridge-enforced value-at-risk budgeting, partner-rollup node access, and whatever entity defines the proving and finality stack around those TEEs.
What it does:
Lets users deposit from Ethereum or partner rollups into a shared t1 balance and then transact from a unified cross-chain hub
Uses TEE-enabled nodes to read from partner rollups and trigger writes back to them as part of t1-native execution
Posts new trie roots, TEE proofs, and transaction data commitments to an Ethereum canonical bridge so withdrawals can finalize with roughly single-block delay in the normal path
Frames itself as programmable cross-chain application infrastructure, so apps can evolve into composable appchains instead of relying only on message passing
Plans a v2 architecture that separates sequencing and execution, with HotShot-based sequencing consensus, TEE-backed execution consensus, encrypted transaction fields, and periodic ZK checkpoints that reset value-at-risk counters
Key claims:
The official site positions t1 as cross-chain infrastructure that solves fragmentation by bringing “real-time proving and composability” to Ethereum and L2s
The architecture docs say v1 uses a TEE-enabled sequencer that executes blocks, reads and writes partner-rollup state inside the TEE, and submits new trie roots plus TEE proofs to Ethereum
The TEE docs say remote attestation is the basis for proving that specific unmodified software executed inside the enclave, and that this is what enables t1’s real-time proving model
The research page claims t1 can aggregate and prove partner-rollup state to Ethereum in less time than an Ethereum block, using AVS-secured TEEs and zk-compressed remote attestation
The v2 architecture introduces a more explicit split between blind transaction ordering, execution consensus, encrypted inputs, and on-demand ZK proofs when cumulative post-checkpoint value would exceed the protocol’s crypto-economic security budget
The docs explicitly describe dynamic gas pricing and checkpoint logic as mechanisms for managing bridge-side value-at-risk, which makes the system analytically closer to a security-budgeted confirmation layer than to a simple bridge router
The GitHub org and monorepo suggest a real implementation effort around the protocol, docs, and supporting contracts rather than only a narrative whitepaper
Whitepaper: A canonical public litepaper PDF exists at https://docs.t1protocol.com/t1-vision-litepaper.pdf, but the most usable primary materials in this pass were the official site, docs pages for architecture / TEE / research / resources, and the public GitHub org; see ../whitepapers/t1-primary-sources-2026-05-08.md.