t1 is the cross-chain application infrastructure to enable better web3 UX
t1 introduces real-time proving (RTP) to introduce cross-chain programmable money
Introduction
Today, we are excited to share more about t1 and our journey. We believe Ethereum should not only be the most decentralized smart contracting ecosystem but also the blockchain with the best user and developer experience.
Ethereum best embodies the ethos and values that inspire us about the future of blockchain technology. These values attract the brightest minds and foster innovation. However, the best technology doesn’t always win.
We believe that for Ethereum to provide the best user and developer experience, the cross-chain application experience must be improved. In other words, the rollup fragmentation problem must be solved. The vision of a unified Ethereum ecosystem truly excites us. We started t1 to help make that vision a reality.
t1 is the first cross-chain application that introduces real-time proving (RTP) and programmability to fix fragmentation and composability challenges in scaling Ethereum. By leveraging AVS-secured Trusted Execution Environments (TEE), t1 introduces real-time proofs that prove the integrity of t1 execution to Ethereum in less time than it takes to create a block on Ethereum (less than 12 seconds). By running partner rollup nodes in its node infrastructure, t1 aggregates and proves their state to Ethereum in real-time. As a result, t1 enables instant settlement between any combination of partner rollups and Ethereum, providing composability. All execution in t1 is cryptographically verified via zk-compressed Remote Attestation coming from Intel TDX Trusted Execution Environment (TEE), ensuring that state transitions are provably correct, tamper-proof, and bound to the current protocol version. In addition to real-time proving, t1 supports general-purpose smart contract programmability and enables writes to partner rollups, in addition to reading their state.
This architecture offers a foundation for building new and enhancing existing cross-chain applications—such as yield aggregators, lending protocols, and decentralized exchanges—that require fast, programmable interoperability without reliance on third-party bridges or message-passing systems. Our mission is to unify Ethereum and its rollup ecosystem by creating a real-time proof powered liquidity layer that enables the best user experience on cross-chain applications.
The Rollup Fragmentation Problem
The current rollup-centric scaling strategy has delivered lower fees and higher throughput, at the cost of fragmentation. Liquidity and user activity are now spread across hundreds of rollups, forcing developers to bring their applications multichain leveraging third-party bridges and messaging protocols. Despite widespread efforts to improve interoperability, the current landscape remains siloed:
Most L2 interoperability efforts focus on specific rollup stacks rather than the entire ecosystem. These efforts reduce the number of siloes yet solidify existing siloes rather than eliminating them.
Interoperability protocols enable message passing and proof generation, but forego benefits of programmability. As a result, each chain remains a siloed execution environment. Users must take separate actions on each chain, adding friction, cost, and fragmentation.
Real-time Zero Knowledge Proving is far from reality, especially for cross-chain interoperability. Real-time ZKP for scaling L1 is yet to be fully realized due to L1 scaling efforts and formal verification requirements. Real-time ZKP for interoperability is even a more difficult endeavor given the rollup blocks are significantly larger than L1 blocks and rollups have shorter block times. We expect real-time ZKP to be 2-4 years out.
As a result, no existing application can offer a seamless, cross-chain user experience today without the complexities of introducing third party bridges or messaging protocols. Without a fundamental shift in how interoperability is achieved, Ethereum risks scaling into a fragmented network where composability remains trapped within silos.
Our Mission: Solving the Fragmentation Problem
t1 introduces a Trusted Execution Environment (TEE) enabled real-time proving (RTP) smart contracting platform to solve fragmentation in the Ethereum ecosystem today.
Real Time Proving
Real-time proving allows t1 to prove its state to Ethereum or partner rollups every block. This means:
Users can enjoy the low cost and high speed of rollups while their assets effectively remain on Ethereum. Funds on t1 can be withdrawn to an L1 wallet in the same block, making interacting with t1 feel similar to interacting with a smart contract on L1.
Applications on Ethereum or rollups can access t1 state (liquidity) because both are proven to Ethereum every block.
Applications on t1 can verify state changes in Ethereum and partner rollups and create cross-chain proofs. This is achieved by running multiple partner rollup full-nodes in the t1 node infrastructure.
Applications on t1 can call functions on Ethereum and on partner rollups to create seamless cross-chain application workflows. This is possible because t1 deposit contracts on Ethereum and partner rollups are authorized to call contracts on those chain whenever the t1 state requires it. This is how we extend money legos cross-chain.
Programmability
Programmability enables t1 to do more than just Real-Time Proving. Today interoperability is about proofs (trusted committees, ZKP, optimistic) and message passing. No solution out there focus on programmability. Smart contracts create a programmable hub for liquidity and cross-chain interactions. Programmability enables currently off-chain components, such as relayer/solver networks for ERC-7683 protocols or aggregator logic, to be brought on-chain. Programmability also enables t1 to become a cross-chain liquidity hub in addition to just being a bridge or a proving system that just passes proofs across blockchains. This means we can build cross-chain collateral accounts, lending/borrowing primitives, and orderbooks (programmable liquidity) on t1, while other proving systems can only pass messages.
Furthermore, t1’s architecture is designed to create cross-chain application experiences without needing buy-in from any rollup or application. In that sense, t1 is the only truly permissionless cross-chain application interface.
What Are TEEs and How Do They Help?
Trusted Execution Environments (TEEs) are specialized hardware-based environments that isolate sensitive computations and data from the rest of the system, ensuring that data is processed correctly and privately. In particular, TEEs provide verifiable computation guarantees through a process called “Remote Attestation,” which proves to external parties that the TEE is running a specific, unmodified piece of software (bytecode) without any tampering. Verifiers can then use this attestation to confirm that a TEE’s output is trustworthy. Additionally, TEEs can preserve privacy by keeping sensitive data and execution logic concealed from the system operator and external observers. In other words, TEEs are secure hardware areas that protect sensitive data and computations from tampering or unauthorized access.
Two key requirements for achieving full unification of Ethereum and the rollup ecosystem, without reorg risks and asynchrony, are shared sequencing across all chains and real-time proving (RTP). At t1, we are working on RTP by employing TEEs. However, TEEs also help with cross-chain composability by enabling follower nodes in t1 to reliably read data from and write data to partner rollups. This setup allows t1 to aggregate the state of Ethereum and partner rollups effectively. Our design, which does not rely on shared sequencing, enables t1 to have as low as a single-block asynchrony window (12 seconds) with Ethereum—a substantial improvement over the current seven-day window in Optimistic Rollups and hours-long window in Zero-Knowledge Rollups.
In addition to RTP and cross-chain communication, TEEs allow t1 to offer an encrypted mempool. An encrypted mempool prevents adversarial reordering, such as sandwich attacks, where an attacker observes a pending user transaction and places trades before (front-running) and after (back-running) it, profiting at the expense of regular users. Sandwich attacks cost Ethereum users over $100mn every year [1]. An encrypted mempool or ephemerally private blockspace also facilitate use cases like sealed-bid auctions and information-incomplete games.
Architecture
Protocol Design
t1 is an EVM-based smart contracting platform that generates real-time proofs to provide a cross-chain application infrastructure. t1 combines the verifiable computation guarantees of Trusted Execution Environments (TEE) with additional defense layers such as economic security (AVS) and bespoke zero-knowledge proofs (ZKP) to enable fast and secure proof generation. t1 has two network stakeholders:
Sequencers are a highly decentralized set of nodes tasked with blindly finalizing the ordering of encrypted transactions in a t1 bundle before it becomes a block. Since Sequencers only order transactions rather than execute them, we can achieve high decentralization and censorship resistance. Sequencers create Sequencing Consensus
Executors are TEE-enabled nodes tasked with executing state changes given the finalized sequences of transactions determined by the Sequencers (i.e. turning bundles into blocks and a new state). Executors provide proof of Execution Consensus.
t1 produces blocks every second. Each block involves two sequential steps:
Tx data broadcast and bundle finalization by Sequencers (Sequencing Consensus proof)
Execution into a block and agreement about the new state, reached by TEE-enabled Executors (Execution Consensus proof).
Both Sequencing Consensus and Execution Consensus are required to update the state of t1 (aka trie root tuple) on Ethereum, only then enabling “convincing” t1 bridge contracts on Ethereum and partner rollups to e.g. release their funds to withdrawing users.
As t1 gradually becomes a fully permissionless network, it’s essential to implement mitigations against potential TEE exploits and develop defense-in-depth strategies. To this end, t1 leverages two sets of EigenLayer Autonomous Verifiable Services (AVS) validators to derive its crypto-economic security from restaked assets, providing a programmatic insurance budget on top of TEE guarantees.
However, an attacker controlling more than the crypto-economic security of the Execution AVS stake and also the necessary TEEs (that they managed to compromise) could produce an integrity proof for a fraudulent new state of t1. For this attack to be economically viable, the value-at-risk would need to be higher than the slashable Execution AVS stake. To ensure that t1’s economic activity is not bound by this security budget, we introduce a bespoke ZKP mechanism as an additional defense layer: t1 uses incentivized periodic ZKP to create checkpoints. When cumulative value-at-risk since the last checkpoint is about to exceed the crypto-economic security budget, the Canonical Bridge will require the provision of an on-demand ZKP before it accepts such a new t1 state—halting finalization until then. However, with adequate t1 gas price policies incentivizing proactive checkpoint creation, we don’t expect this situation to ever happen under normal conditions, achieving a good tradeoff between finalization latency and hard-times resilience.
Note: ZKP generation will likely be outsourced to another network that can meet the latency and cost requirements.
Architecture Diagram
Flow
A user, Alice, deposits funds to a t1 bridge contract on Ethereum or on a Partner Rollup. Once the deposit is confirmed on the source chain, it gets processed by t1 and Alice gets her funds credited towards her aggregate t1 balance.
Alice changes her wallet’s network to t1, creates a t1-native transaction (with some fields encrypted to the shared rotating TEE pubkey), uses her wallet to sign it, and submits it to the network (i.e. the t1 mempool); this may or may not be a specially-treated withdrawal transaction (to Ethereum or a Partner Rollup).
A t1 Sequencer receives and gossips such a partially-blind transaction to other Sequencers in the t1 Sequencing AVSnetwork.
After collecting transactions for one t1 slot (currently set to one second), the slot-leading Sequencer proposes an ordering (a blind non-executed bundle). The rest of Sequencers vote on it using Espresso HotShot, to form Sequencing Consensus. This bundle and a proof of Sequencing Consensus is then passed on to the Execution AVSnetwork.
t1 Executors validate the proof of Sequencing Consensus, decrypt the encrypted parts of the received bundle (if needed and due) using their TEE-derived shared rotating private key, and execute its now fully plaintext ordered transactions against the current state of the t1 blockchain. The slot-leading Executor proposes a new trie root tuple rof state trie root, withdrawals trie root, and proof-of-read trie root—and the rest of the Executors vote on such new trie tuple r to form Execution Consensus.
Note: Executors use follower nodes also running in TEEs to read from and write to Partner Rollups(whenever required by a t1 tx).
The Execution AVS posts t1’s new trie roots r and all the corresponding consensus proofs to the Ethereum t1 Canonical Bridge contract and the full compressed transactions to Ethereum blob DA.
In addition, t1 progressively incentivizes the generation and posting of periodic ZKPs to the Canonical Bridge on Ethereum to create ZKP checkpoints resetting the value-at-risk counters and also speeding up the potential on-demand ZKP creation when required. t1 dynamic gas pricing considers how much AVS security budget is still available, to reach an equilibrium.
In the rare event that new t1 transactions’ (as per all new trie root tuples) cumulative value since the last ZKP checkpoint, despite the mechanisms above, would exceed the crypto-economic security budget provided by Execution AVS, also an on-demand ZKP is required by the Canonical Bridge, pausing finalization until then; this would increase the withdrawal delay to hours under such extreme conditions.
t1’s Canonical Bridge contract on Ethereum checks the new submitted t1 trie root tuple r, Sequencing Consensus,Execution Consensus and transaction data availability for consistency. If successful, such r is accepted. This then generally facilitates withdrawals from t1 to Ethereum with a single-Ethereum-block delay only (i.e. 6 seconds on average).
Suppose, Alice had desired to withdraw funds, in step 2. She may now submit to the Canonical Bridge an Ethereum claim transaction with an inclusion proof of her withdrawal transaction in t1 (as contained within the withdrawal trie committed to in r). The contract then releases the funds to Alice on Ethereum.
If Alice wishes to withdraw funds to her account on a Partner Rollup rather than on Ethereum, the same trie root tuple r update in the Canonical Bridge (i.e. on Ethereum) is required as in 7. However, she submits the claim transaction with an inclusion proof of the withdrawal to the (non-canonical) t1 bridge contract on Partner Rollup instead. The Partner Rollup bridge contract verifies the inclusion proof with respect to r as accepted by the Canonical Bridge on Ethereum (using Partner Rollup’s Ethereum read abilities, usually via Partner Rollup’s own L1 canonical bridge) and then releases the funds to Alice on Partner Rollup.
Bridge Contracts
t1 leverages its contracts on Ethereum and rollups to accept deposits into t1 and allow users to withdraw funds from t1 back to their blockchain of choice.
Ethereum’s contract acts as the Canonical Bridge where t1 trie root updates are posted. Their validity is ensured by verifying Sequencing Consensus, Execution Consensus and the data availability commitment to a blob posted on Ethereum (DA). Therefore, this contract is the source of truth for t1 state.
Withdrawals to Ethereum can be enabled immediately after a transaction updates this contract, by a further “claim” transaction carrying a Merkle proof, on L1 or Partner Rollup itself. Withdrawals on Partner Rollups require the local t1 bridge contract to check the state of Canonical Bridge on Ethereum before the funds can be released to the user on Partner Rollup. The state of the t1 Canonical Bridge is able to be relayed to the Partner Rollup via the arbitrary message passing capability of the Partner Rollup’s own Canonical Bridge. This approach prevents attacks that could otherwise result in double-spend due to reorgs.
Sequencers
In t1, Sequencers sequence and broadcast partially-encrypted transactions, forming a consensus on a blind block order (“bundles”), which is then passed to Executors for execution. Most of the rollups nowadays utilize single-sequencer designs compromising security for speed; also, usually both sequencing and execution are performed by a single entity, leading to little censorship resistance. We want to separate sequencing (broadly accessible) and execution (higher hardware requirements, esp. a TEE) to allow for fast, decentralized consensus, offering strong resistance to censorship and bribery, while minimizing MEV from transaction ordering.
t1’s long-term design employs Espresso Systems' HotShot Consensus, a BFT protocol adapted for PoS, enhancing decentralization. Sequencers, part of t1's AVS, use restaked stake with slashing conditions to maintain security and integrity in transaction sequencing.
Executors
TEE-enabled Executors oversee the current state of t1 by running transactions from Sequencer-ordered blind bundles and establishing consensus on the new state. They utilize t1VM, a TEE-optimized and interop-enriched version of Reth, which ensures full backwards compatibility with Ethereum while adding crosschain-composability-specific capabilities such as reading a chain's contract method or requesting a write call to it. An Ethereum full node is maintained within the Executor for streamlined interaction with the canonical bridge, while follower nodes (clients) for other rollups run by the Executor allow for real-time state monitoring and interactions with them, without delays usually required for fraud or zero-knowledge proofs. t1VM includes unique capabilities powered by Reth’s ExEx, enabling Executors to interact with both Ethereum and other (partner) rollups from within t1's Solidity smart contracts.
Executors operate under a leader-based, instant-finality PoS Byzantine Fault Tolerant consensus system, representing the second category of t1's AVS, and they are liable to slashing to enforce system integrity.
All execution happens inside Intel TDX-based TEEs, which cryptographically isolate the runtime logic and protect it from tampering, even by the host OS. Before processing transactions or joining Execution Consensus, each Executor must successfully complete a hardware-backed Remote Attestation, as detailed in the Remote Attestation Design and Enforcement.
Use-cases
Applications built natively on t1 leverage real-time proving and are designed to provide a better user experience with seamless cross-chain coordination. We’re still early in uncovering all of the possibilities real-time proving enables but have identified a few primitives that are uniquely enabled by t1:
Cross-chain vaults. Non-custodial cross-chain yield optimization that automates yield discovery and rebalancing across rollups. Using t1’s real-time proving (RTP) interoperability infrastructure funds move between lending protocols and yield sources.
Cross-chain loans. Users can deposit collateral into lending contracts on any partner rollup, while market makers borrow against these deposits through t1’s cross-chain collateral accounts to fill intents. Loans can be settled and returned to the origin chain within one minute, with a share of bridging fees passed back to depositors as yield. This design reduces capital requirements for borrowers while delivering competitive, real-demand-driven returns to lenders.
These use-cases build TVL on t1 and empowers the network to become a programmable liquidity layer that any connected chain can tap into. Thanks to RTP, t1 eliminates the fragmentation of liquidity across isolated ecosystems and enables applications to operate as if liquidity were unified.
t1 is also designed to enhance the functionality of existing applications. For Ethereum L1 applications, t1 offers an execution environment with significantly lower costs while maintaining composability with Ethereum enabling applications to scale. Appchains and rollups can leverage t1’s infrastructure to access cross-chain liquidity without the need for custom integrations or shared sequencer agreements. By being as a permissionless interoperability layer, t1 allows partner applications to improve capital efficiency and offer better UX.
Today, applications need to deploy on multiple rollups to meet user demand. In the future, applications built on t1 will be able to serve users across multiple rollups by deploying on t1 alone.
Conclusion
t1 addresses fragmentation and composability challenges in the Ethereum ecosystem by innovating on real-time proving (RTP) with a network secured by TEEs, AVS and bespoke ZKPs. This architecture, designed with defense-in-depth in mind, allows instant settlement back to Ethereum under almost all circumstances while remaining resistant even against adversaries controlling a large stake of the network. We believe this is a practical and solution-oriented approach that addresses the rollup fragmentation issue today.
If you’re excited about fixing Ethereum’s fragmentation problem, join us in this journey! Follow us on Twitter @t1protocol for the latest updates, insights and community discussions.
Are you a developer eager to get early access to our codebase and willing to help shape the future of Ethereum’s composability? Or perhaps you’re a passionate community member who wants to contribute to growing the t1 ecosystem? Fill out this form and we’ll be in touch soon.
Let’s build the future of Ethereum together!
keep going your activities
Nice