From 373c0fcbd2c4b948b7a335693f52950d23f37167 Mon Sep 17 00:00:00 2001 From: prince Date: Wed, 25 Jun 2025 23:40:26 +0800 Subject: [PATCH 1/5] integration docs for frontend and testnet prep --- docs/api/xChainRead/api-reference.md | 33 +- docs/concepts/glossary.md | 35 +- docs/concepts/protocol/_category_.json | 2 +- docs/concepts/protocol/tee.md | 4 +- docs/concepts/research.md | 31 +- docs/concepts/resources.md | 4 +- docs/concepts/what-is-t1.md | 12 - .../03-advanced-topics/06-research.md | 5 +- docs/integration/7683/frontend.md | 185 +++++++++ .../7683/xChainRead.md} | 25 +- docusaurus.config.js | 26 +- sidebars.js | 1 + src/pages/index.tsx | 365 ++++++++++++------ static/img/x.svg | 1 + 14 files changed, 535 insertions(+), 194 deletions(-) delete mode 100644 docs/concepts/what-is-t1.md create mode 100644 docs/integration/7683/frontend.md rename docs/{api/xChainRead/overview.md => integration/7683/xChainRead.md} (82%) create mode 100644 static/img/x.svg diff --git a/docs/api/xChainRead/api-reference.md b/docs/api/xChainRead/api-reference.md index 15db609e1..dba3bc84b 100644 --- a/docs/api/xChainRead/api-reference.md +++ b/docs/api/xChainRead/api-reference.md @@ -1,19 +1,20 @@ --- - id: api-reference title: API Reference sidebar_label: API Reference -sidebar_position: 2 +sidebar_position: 1 --- # API Reference ### Get Read Proofs + Retrieve proof data for cross-chain read requests. **URL**: https://api.v05.t1protocol.com/api/read-proofs **Parameters**: + - `address` (string, required): Address of the EOA that triggered the Proof of Read request - `direction` (string, optional): L1_TO_L2 or L2_TO_L1 - `page` (number, optional): Page number @@ -22,7 +23,6 @@ Retrieve proof data for cross-chain read requests. **Example**: https://api.v05.t1protocol.com/api/read-proofs?address=0x81B5e00e15fb3ee055aB5e616Ccb52fA935D3534&direction=L1_TO_L2&page=1&page_size=100 - **Response Format**: ```json @@ -35,7 +35,7 @@ https://api.v05.t1protocol.com/api/read-proofs?address=0x81B5e00e15fb3ee055aB5e6 "direction": "L1_TO_L2", // Arbitrum Sepolia to Base Sepolia "claim_info": { "from": "0x81B5e00e15fb3ee055aB5e616Ccb52fA935D3534", - "to": "0xf96B8CcB029E0932fe36da0CeDd2b035E2c1695d", + "to": "0xf96B8CcB029E0932fe36da0CeDd2b035E2c1695d", "value": "0", "nonce": "4", "message": "0xe11680cd0000000000000000000000000000000000000000000000000000000000014a34000000000000000000000000f96b8ccb029e0932fe36da0cedd2b035e2c1695d374f3efe8b19f4937fadee47d33f93d66a6dd62f5141d8efa41bf5de64f6e53a00000000000000000000000000000000000000000000000000000000000000a000000000000000000000000081b5e00e15fb3ee055ab5e616ccb52fa935d35340000000000000000000000000000000000000000000000000000000000000024ebd45ba21b50198add4a3fd45e9b53bf0a37bd0859d912cfdde54efefe31a0a0fc203b1f00000000000000000000000000000000000000000000000000000000", @@ -52,16 +52,16 @@ https://api.v05.t1protocol.com/api/read-proofs?address=0x81B5e00e15fb3ee055aB5e6 ### Key Fields -| Field | Description | -|-------|-------------| -| `source_tx_hash` | Transaction hash that initiated the read request | -| `message_type` | Message type (4 = xChainRead) | -| `block_number` | Block number when request was submitted | -| `request_id` | Unique identifier for the read request | -| `x_chain_read_result` | Raw ABI-encoded result from target function | -| `handle_read_result_with_proof_calldata` | **Ready-to-use calldata for your contract** | -| `proof.batch_index` | Batch containing this read result | -| `proof.merkle_proof` | Cryptographic proof for verification | +| Field | Description | +| ---------------------------------------- | ------------------------------------------------ | +| `source_tx_hash` | Transaction hash that initiated the read request | +| `message_type` | Message type (4 = xChainRead) | +| `block_number` | Block number when request was submitted | +| `request_id` | Unique identifier for the read request | +| `x_chain_read_result` | Raw ABI-encoded result from target function | +| `handle_read_result_with_proof_calldata` | **Ready-to-use calldata for your contract** | +| `proof.batch_index` | Batch containing this read result | +| `proof.merkle_proof` | Cryptographic proof for verification | :::tip The `handle_read_result_with_proof_calldata` field contains pre-encoded calldata that you can directly submit to your contract's `handleReadResultWithProof` function. @@ -85,9 +85,9 @@ interface T1XChainReader { function requestRead( ReadRequest calldata request ) external payable returns (bytes32 requestId); - + function verifyProofOfRead( - bytes calldata encodedProofOfRead + bytes calldata encodedProofOfRead ) external view returns (bytes32 requestId, bytes memory result); } ``` @@ -112,6 +112,7 @@ event ProofOfReadRootCommitted(uint256 batchIndex); ### Proof Encoding Format Proofs use the following ABI encoding: + ```solidity abi.encode( uint256 batchIndex, // index of the batch posted by the prover diff --git a/docs/concepts/glossary.md b/docs/concepts/glossary.md index 816d10ac1..74717fbc3 100644 --- a/docs/concepts/glossary.md +++ b/docs/concepts/glossary.md @@ -1,28 +1,37 @@ --- id: glossary title: Glossary -sidebar_position: 5 +sidebar_position: 4 --- ## TEE -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 proof to confirm that the TEE and its 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. + +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. ## ZKP -A zero-knowledge (ZK) proof is a cryptographic protocol that enables one person (the prover) to convince another (the verifier) that a particular claim is true without disclosing any details about the claim itself. + +A zero-knowledge (ZK) proof is a cryptographic protocol that enables one entity (the prover) to convince another one (the verifier) that a particular claim is true without disclosing any details about the claim itself. ZKPs used in blockchains are additionally succinct, meaning that the work required by the verifier to check the proof is substantially smaller than the work of re-running the computation required to reach the claim independently. ## AVS -[AVS](https://app.eigenlayer.xyz/avs) (Actively Validated Service) is a term coined by EigenLayer that refers to services or applications built on top of the Ethereum blockchain and used for security and validation mechanisms. These services could include rollups, DA layers, interoperability protocols, etc. It allows Ethereum validators to use their staked assets to provide security to other applications built on EigenLayer. + +[AVS](https://app.eigenlayer.xyz/avs) is a term coined by EigenLayer that refers to services or applications built on top of the Ethereum blockchain and used for security and validation mechanisms. These services could include rollups, DA layers, interoperability protocols, etc. It allows Ethereum validators to use their staked assets to provide security to other applications built on EigenLayer. + +## Reth + +[Reth](https://github.com/paradigmxyz/reth) (Rust Ethereum) is an Ethereum execution node implementation focused on being user-friendly, modular, and efficient. Reth is an execution client compatible with all Ethereum consensus client implementations that support the Engine API. As a full Ethereum node, Reth will allow users to sync the complete Ethereum blockchain from genesis and interact with it (and its historical state, if in archive mode) once synced. + +## Reth ExEx + +[Execution Extensions](https://www.paradigm.xyz/2024/05/reth-exex) aka ExEx is a feature of Reth that allows developers to receive comprehensive data about a newly “mined” block in an observer-listener pattern. Thanks to this, developers can perform actions based on certain changes on the blockchain in an efficient and seamless way. + +## Real-Time Proving (RTP) + +RTP is the ability to prove state transitions in a rollup within one base layer block, which is 12 seconds for Ethereum L1. Real-time proving, for example, allows rollup deposits to be withdrawn immediately (real-time settlement). ## Sequencer -Sequencers are a highly decentralized set of nodes tasked with blindly finalizing the ordering of encrypted transactions in a 𝚝𝟷 block. Since Sequencers only order transactions rather than executing them, we can achieve high decentralization and censorship resistance. Sequencers create Sequencing Consensus. -## Executor -Executors are a network of TEE-enabled nodes tasked with executing state changes given the finalized sequences of transactions (i.e. blocks) determined by the Sequencers. Executors provide proofs of Execution Consensus. +Sequencers are a highly decentralized set of nodes tasked with blindly finalizing the ordering of encrypted transactions in a 𝚝𝟷 block. Since Sequencers only order transactions rather than executing them, we can achieve high decentralization and censorship resistance. Sequencers create Sequencing Consensus. [More](https://www.notion.so/t1protocol/Litepaper-9a2cc4d321ce4a08a4905aa809fb436e?source=copy_link#107231194dc380e7a4b2e58c1682a6cd) -## Reth -[Reth](https://github.com/paradigmxyz/reth) (Rust Ethereum) is an Ethereum full-node implementation focused on being user-friendly, modular, fast, and efficient. Reth is an execution client compatible with all Ethereum consensus client implementations that support the Engine API. As a full Ethereum node, Reth will allow users to sync the complete Ethereum blockchain from genesis and interact with it (and its historical state, if in archive mode) once synced. +## Executor -## ExEx -[Execution Extensions](https://www.paradigm.xyz/2024/05/reth-exex) (or ExExes, for short) allow developers to build their own infrastructure that relies on Reth as a base for driving the 𝚝𝟷 chain forward. -## Single Block DTW (SBDTW or DTW for short) -Deposit from L1 to t1, trade on t1 and Withdraw from t1 to L1, which happens in one L1 block. This is a feature unique to t1. +Executors are a network of TEE-enabled nodes tasked with executing state changes given the ordered sequences of transactions (i.e. bundles) determined by the Sequencers. Executors provide proofs of Execution Consensus. [More](https://www.notion.so/t1protocol/Litepaper-9a2cc4d321ce4a08a4905aa809fb436e?source=copy_link#107231194dc3807b9e31e2a937f8da67) diff --git a/docs/concepts/protocol/_category_.json b/docs/concepts/protocol/_category_.json index 2cafa59c8..b7199f6ef 100644 --- a/docs/concepts/protocol/_category_.json +++ b/docs/concepts/protocol/_category_.json @@ -1,4 +1,4 @@ { "label": "Protocol Concepts", - "position": 2 + "position": 1 } diff --git a/docs/concepts/protocol/tee.md b/docs/concepts/protocol/tee.md index 4136d52e9..3e0734734 100644 --- a/docs/concepts/protocol/tee.md +++ b/docs/concepts/protocol/tee.md @@ -6,6 +6,6 @@ sidebar_position: 2 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 proof to confirm that the TEE and its 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 at all, are shared sequencing across all chains and real-time proving (RTP). At 𝚝𝟷, we are working on RTP by employing TEEs. However, TEEs also help with cross-chain composability by enabling lightclients in 𝚝𝟷 to reliably read data from and write data to partner rollups. This setup allows 𝚝𝟷 to effectively aggregate the state of Ethereum and partner rollups. Our current design, which does not rely on shared sequencing, enables 𝚝𝟷 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. +Two key requirements for achieving full unification of Ethereum and the rollup ecosystem, without reorg risks and asynchrony at all, 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 lightclients in t1 to reliably read data from and write data to partner rollups. This setup allows t1 to effectively aggregate the state of Ethereum and partner rollups. Our current 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 𝚝𝟷 to offer an encrypted mempool. An encrypted mempool prevents adversarial reordering, such as sandwich attacks, where an attacker observes a pending 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](https://eigenphi.io/mev/ethereum/sandwich). An encrypted mempool also facilitates use cases like sealed-bid auctions and information-incomplete games. +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 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](https://eigenphi.io/mev/ethereum/sandwich). An encrypted mempool also facilitates use cases like sealed-bid auctions and information-incomplete games. diff --git a/docs/concepts/research.md b/docs/concepts/research.md index 69d1e1e14..bb2b6be94 100644 --- a/docs/concepts/research.md +++ b/docs/concepts/research.md @@ -1,35 +1,44 @@ --- id: research title: Research -sidebar_position: 3 +sidebar_position: 2 --- # Research -The rollup landscape is changing rapidly, and we at 𝚝𝟷 strive to stay at the bleeding edge. Our research focuses on improving scalable composability among and between blockchains and rollups. + +The rollup landscape is changing rapidly, and we at t1 strive to stay at the bleeding edge. Our research focuses on improving scalable composability among and between blockchains and rollups. + +## **t1** is the cross-chain application infra to enable better web3 UX + +Authors: Can Kisagun, CEO & Co-founder of t1 + +> 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. + +- [**t1** is the cross-chain application infra to enable better web3 UX](https://t1protocol.substack.com/p/t1-is-the-cross-chain-application) ## The Rollup Fragmentation Problem -Authors: Can Kisagun, CEO & Co-founder of 𝚝𝟷 +Authors: Can Kisagun, CEO & Co-founder of t1 > Rollups, which execute transactions outside of Ethereum (off-chain) and post integrity (execution) proofs and transaction data to Layer 1 for verification, have scaled Ethereum in a secure and performant way, enabling significant reduction in transaction fees and improvements in user experience. However, while improving scalability, rollups also introduced siloed execution that led to liquidity fragmentation and broke composability in Ethereum. In this article, we talk about the rollup fragmentation problem, its implications for users and developers, and we explore how emerging technologies can restore composability. Ethereum ultimately needs to provide a unified and composable ecosystem where users can interact with different applications seamlessly, across rollups. To get there, the focus must be on shared sequencing and real-time proof generation. - [The Rollup Fragmentation Problem](https://t1protocol.substack.com/p/the-rollup-fragmentation-problem) -## Introducing **𝚝𝟷:** Unifying Ethereum’s Ecosystem for the Future of Web3 +## Introducing **t1:** Unifying Ethereum’s Ecosystem for the Future of Web3 -Authors: Can Kisagun, CEO & Co-founder of 𝚝𝟷 +Authors: Can Kisagun, CEO & Co-founder of t1 -> Today, we are excited to share more about 𝚝𝟷 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. It has the most decentralized community—a place where the brightest minds gather and innovation thrives. However, the best technology doesn’t always win. -We believe that for Ethereum to provide the best user and developer experience, the rollup fragmentation problem must be solved. The vision of a unified Ethereum ecosystem truly excites us. We started 𝚝𝟷 earlier this year to make this vision a reality. +> 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. It has the most decentralized community—a place where the brightest minds gather and innovation thrives. However, the best technology doesn’t always win. +> We believe that for Ethereum to provide the best user and developer experience, the rollup fragmentation problem must be solved. The vision of a unified Ethereum ecosystem truly excites us. We started t1 earlier this year to make this vision a reality. -- [Introducing **𝚝𝟷**](https://t1protocol.substack.com/p/introducing-t1-unifying-ethereums-ecosystem) +- [Introducing **t1**](https://t1protocol.substack.com/p/introducing-t1-unifying-ethereums-ecosystem) ## How to run Reth in Intel TDX -Authors: KSS, Founding Engineer at 𝚝𝟷 +Authors: KSS, Founding Engineer at t1 > Trusted Execution Environments (TEE) are hardly a novelty. They are currently one of the most established methods of performing verifiable computation server-side. As crazy as it sounds, SGX was introduced by Intel nearly a decade ago. The wider blockchain community took its time to realize how great of a pairing TEEs and blockchains are, and harness that potential by taking the best of on-chain security and off-chain performance. -There were some good reasons to be cautious about Intel SGX with its poor developer experience, lack of crucial features and numerous exploits (https://sgx.fail/, anyone?). In the end, with the release of Intel TDX in 2023 and great RnD teams such as Flashbots and Automata paving the path, many L2 solutions decided to adopt TEEs as a crucial extension of their tech. +> There were some good reasons to be cautious about Intel SGX with its poor developer experience, lack of crucial features and numerous exploits (https://sgx.fail/, anyone?). In the end, with the release of Intel TDX in 2023 and great RnD teams such as Flashbots and Automata paving the path, many L2 solutions decided to adopt TEEs as a crucial extension of their tech. - [How to run Reth in Intel TDX](https://t1protocol.substack.com/p/how-to-run-reth-in-intel-tdx) diff --git a/docs/concepts/resources.md b/docs/concepts/resources.md index 0d7592f8f..ebf55317f 100644 --- a/docs/concepts/resources.md +++ b/docs/concepts/resources.md @@ -1,9 +1,9 @@ --- id: resources title: Resources -sidebar_position: 4 +sidebar_position: 3 --- This page will be periodically updated with helpful resources as they are made available. -- [**𝚝𝟷 Rollup Visualization**](https://www.t1protocol.com/#how-it-works) \ No newline at end of file +- [**t1 Rollup Visualization**](https://www.t1protocol.com/#how-it-works) diff --git a/docs/concepts/what-is-t1.md b/docs/concepts/what-is-t1.md deleted file mode 100644 index 81c087e47..000000000 --- a/docs/concepts/what-is-t1.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -id: overview -title: 𝚝𝟷 Overview -sidebar_position: 1 ---- - -t1 is an EVM-based cross-chain application infrastructure that introduces Real-Time Proving (RTP) and programmability to address fragmentation and composability challenges in scaling Ethereum: - -- Real-time proving: Using Trusted Execution Environments (TEEs), 𝚝𝟷 proves its execution integrity to Ethereum and partner rollups in under 12 seconds. By running partner rollup nodes within its infrastructure, 𝚝𝟷 aggregates and proves their state to Ethereum in 1-2 L1 blocks—enabling instant settlement between Ethereum and any partner rollup. -- Programmability: t1 smart contracts are able to read from and write to Ethereum and partner rollups - -The result: t1 provides the missing infrastructure for seamless cross-chain applications and liquidity movement—today. diff --git a/docs/contracts/v2/concepts/03-advanced-topics/06-research.md b/docs/contracts/v2/concepts/03-advanced-topics/06-research.md index 216812e8b..b9a434d0f 100644 --- a/docs/contracts/v2/concepts/03-advanced-topics/06-research.md +++ b/docs/contracts/v2/concepts/03-advanced-topics/06-research.md @@ -3,11 +3,10 @@ id: research title: Research --- - # The Rollup Fragmentation Problem -Authors: Can Kisagun, CEO & Co-founder of 𝚝𝟷 +Authors: Can Kisagun, CEO & Co-founder of t1 > Rollups, which execute transactions outside of Ethereum (off-chain) and post integrity (execution) proofs and transaction data to Layer 1 for verification, have scaled Ethereum in a secure and performant way, enabling significant reduction in transaction fees and improvements in user experience. However, while improving scalability, rollups also introduced siloed execution that led to liquidity fragmentation and broke composability in Ethereum. In this article, we talk about the rollup fragmentation problem, its implications for users and developers, and we explore how emerging technologies can restore composability. Ethereum ultimately needs to provide a unified and composable ecosystem where users can interact with different applications seamlessly, across rollups. To get there, the focus must be on shared sequencing and real-time proof generation. -- [The Rollup Fragmentation Problem](https://t1protocol.substack.com/p/the-rollup-fragmentation-problem) \ No newline at end of file +- [The Rollup Fragmentation Problem](https://t1protocol.substack.com/p/the-rollup-fragmentation-problem) diff --git a/docs/integration/7683/frontend.md b/docs/integration/7683/frontend.md new file mode 100644 index 000000000..4324d1041 --- /dev/null +++ b/docs/integration/7683/frontend.md @@ -0,0 +1,185 @@ +--- +id: frontend +title: Frontend Integration +sidebar_label: Frontend Integration +sidebar_position: 2 +--- + +# Frontend Integration for 7683 Intent Bridging + +This guide explains how to integrate the 7683 intent bridging mechanism into your frontend application. It covers encoding the order data, estimating gas, and executing the bridge transaction. + +## Overview + +The 7683 Intent Bridge enables cross-chain token transfers through an intent-based system. Users express their intent to bridge tokens, and fillers compete to fulfill these intents, providing better execution and potentially better rates. + +## How it works + +The 7683 Intent Bridge operates through a standardized intent protocol: + +1. **Intent Creation**: Users create an intent specifying source and destination tokens, amounts, and execution parameters +2. **Order Encoding**: The intent is encoded according to ERC-7683 standards with proper ABI encoding +3. **On-Chain Submission**: The encoded intent is submitted to the origin chain contract +4. **Filler Execution**: Off-chain fillers monitor intents and compete to fulfill them on the destination chain +5. **Settlement**: Once filled, the intent is marked as complete and funds are released + +## Integration Overview + +The main components of frontend integration are: + +- Encoding intent order data in a Solidity-compatible format. +- Executing the bridge intent with custom parameters. + +## Encoding Order Data + +To prepare the order data for execution, use the `encodeIntentOrderData` function. This ensures the `bytes` format is correctly aligned for the 7683 contract. + +### IntentOrderData Type Definition + +```ts +export type IntentOrderData = { + sender: string // padded address + recipient: string // padded address + inputToken: string // padded address + outputToken: string // padded address + amountIn: string + amountOut: string + senderNonce: number + originDomain: number + destinationDomain: number + destinationSettler: string // padded address + fillDeadline: number + data: string // hex string like "0x" +} +``` + +```ts +export function encodeIntentOrderData(orderData: IntentOrderData): string { + const abiCoder = ethers.utils.defaultAbiCoder + const toBytes32 = (addr: string) => ethers.utils.hexZeroPad(addr, 32) + + const orderDataEncoded = abiCoder.encode( + [ + 'bytes32', + 'bytes32', + 'bytes32', + 'bytes32', + 'uint256', + 'uint256', + 'uint256', + 'uint32', + 'uint32', + 'bytes32', + 'uint32', + 'bytes', + ], + [ + toBytes32(orderData.sender), + toBytes32(orderData.recipient), + toBytes32(orderData.inputToken), + toBytes32(orderData.outputToken), + orderData.amountIn, + orderData.amountOut, + orderData.senderNonce, + orderData.originDomain, + orderData.destinationDomain, + toBytes32(orderData.destinationSettler), + orderData.fillDeadline, + orderData.data, + ] + ) + + const dynamicOffsetPrefix = '0x0000000000000000000000000000000000000000000000000000000000000020' + return dynamicOffsetPrefix + orderDataEncoded.slice(2) +} +``` + +### 2. Order Data Type Hash + +Define the EIP-712 type string and hash for the order data: + +```typescript +export const ORDER_DATA_TYPE_STRING = + 'OrderData(' + + 'bytes32 sender,' + + 'bytes32 recipient,' + + 'bytes32 inputToken,' + + 'bytes32 outputToken,' + + 'uint256 amountIn,' + + 'uint256 amountOut,' + + 'uint256 senderNonce,' + + 'uint32 originDomain,' + + 'uint32 destinationDomain,' + + 'bytes32 destinationSettler,' + + 'uint32 fillDeadline,' + + 'bytes data)' + +export const ORDER_DATA_TYPE_HASH = ethers.utils.keccak256(ethers.utils.toUtf8Bytes(ORDER_DATA_TYPE_STRING)) +``` + +### 3. Executing Intent Bridge + +Here's the complete implementation for executing an intent bridge: + +```typescript +export const executeIntentBridge = async ( + walletProvider: providers.ExternalProvider, + walletAddress: string, + fromChainId: number, + toChainId: number, + amount: string +) => { + const provider = new ethers.providers.Web3Provider(walletProvider, 'any') + const signer = provider.getSigner() + + const originChainContract = new ethers.Contract( + process.env.ORIGIN_CHAIN_7683_CONTRACT_ADDRESS, + ORIGIN_CHAIN_7683_ABI, + signer + ) + + try { + const amountAfterConversion = ethers.utils.parseUnits(amount, 18) + + // Construct order data + const orderData: IntentOrderData = { + sender: walletAddress, + recipient: walletAddress, + inputToken: '0x0000000000000000000000000000000000000000', // Native ETH + outputToken: '0x0000000000000000000000000000000000000000', // Native ETH + amountIn: Number(amountAfterConversion).toString(), + amountOut: Number(amountAfterConversion).toString(), // Adjust amountOut based on the filler's fee + senderNonce: Math.floor(Math.random() * 1e15), + originDomain: fromChainId, + destinationDomain: toChainId, + destinationSettler: process.env.DESTINATION_CHAIN_7683_CONTRACT_ADDRESS, + fillDeadline: Math.floor(Date.now() / 1000) + 24 * 60 * 60, // 24 hour deadline + data: '0x', + } + + // Encode order data + const encodedOrderData = encodeIntentOrderData(orderData) + + // Submit the intent to the contract + const executeIntentBridgeResult = await originChainContract.open( + { + fillDeadline: orderData.fillDeadline, + orderDataType: ORDER_DATA_TYPE_HASH, + orderData: encodedOrderData, + }, + { + value: amountAfterConversion.toBigInt(), + } + ) + await executeIntentBridgeResult.wait() + } catch (e) { + console.error(e) + } +} +``` + +### Security Considerations + +- **Nonce Management**: Each intent uses a unique random nonce to prevent replay attacks +- **Deadline Protection**: 24-hour deadline prevents indefinite pending states +- **Amount Validation**: Ensure proper decimal conversion and fee calculations diff --git a/docs/api/xChainRead/overview.md b/docs/integration/7683/xChainRead.md similarity index 82% rename from docs/api/xChainRead/overview.md rename to docs/integration/7683/xChainRead.md index 5df2e9b36..2c5e11d5d 100644 --- a/docs/api/xChainRead/overview.md +++ b/docs/integration/7683/xChainRead.md @@ -1,7 +1,7 @@ --- -id: overview +id: xChainRead title: xChainRead Overview -sidebar_label: Overview +sidebar_label: xChainRead sidebar_position: 1 --- @@ -27,6 +27,7 @@ t1 runs full nodes of partner rollups inside TEEs, ensuring verifiable execution ### 1. Deploy Your Contract t1 currently supports the following chains: + - Arbitrum Sepolia - Base Sepolia @@ -38,17 +39,17 @@ import "./T1XChainReader.sol"; contract IntentSettler { T1XChainReader public xChainRead; mapping(bytes32 => bytes32) public readRequestToOrderId; - + constructor(address _xChainReader) { xChainRead = T1XChainReader(_xChainReader); } function requestVerification(bytes32 orderId) external payable { bytes memory callData = abi.encodeWithSignature( - "getFilledOrderStatus(bytes32)", + "getFilledOrderStatus(bytes32)", orderId ); - + bytes32 requestId = xChainRead.requestRead({ destinationDomain: 84532, // Base Sepolia targetContract: 0xf96B8CcB029E0932fe36da0CeDd2b035E2c1695d, @@ -57,19 +58,19 @@ contract IntentSettler { callData: callData, requester: msg.sender }); - + readRequestToOrderId[requestId] = orderId; } function handleReadResultWithProof(bytes calldata encodedProofOfRead) external { - (bytes32 requestId, bytes memory result) = + (bytes32 requestId, bytes memory result) = xChainRead.verifyProofOfRead(encodedProofOfRead); - + bytes32 orderId = readRequestToOrderId[requestId]; require(orderId != bytes32(0), "Invalid request"); - + delete readRequestToOrderId[requestId]; - + // Process verified result bool isSettled = (result.length != 0); if (isSettled) { @@ -91,8 +92,8 @@ The `requestRead` function is used to request a cross-chain read. It takes a `Re ### 3. Handle Proof Response -Once the read request is processed, the result will be posted to the [API](./api-reference). You can fetch the proof from the API and verify it with your contract. The `verifyProofOfRead` function is used to verify the proof. It takes a `bytes` calldata as input, which can be fetched via the `handle_read_result_with_proof_calldata` field from the API. If the proof is valid, the function will return the request ID and the result of the target function. If the proof is invalid, the function will revert. +Once the read request is processed, the result will be posted to the [API](../../api/xChainRead/api-reference). You can fetch the proof from the API and verify it with your contract. The `verifyProofOfRead` function is used to verify the proof. It takes a `bytes` calldata as input, which can be fetched via the `handle_read_result_with_proof_calldata` field from the API. If the proof is valid, the function will return the request ID and the result of the target function. If the proof is invalid, the function will revert. ## Next Steps -- [API Reference](./api-reference) - Detailed API documentation \ No newline at end of file +- [API Reference](../../api/xChainRead/api-reference) - Detailed API documentation diff --git a/docusaurus.config.js b/docusaurus.config.js index 3e178d043..95ef997d5 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -11,16 +11,15 @@ module.exports = { // From node nodeEnv: process.env.NODE_ENV, }, - title: '𝚝𝟷', + title: 't1', tagline: 'Documentation and Guides', - // TODO - update when we publish a URL - url: 'https://docs.uniswap.org', + url: 'https://docs.t1protocol.com', baseUrl: '/', onBrokenLinks: 'warn', onBrokenMarkdownLinks: 'ignore', favicon: 'img/favicon.ico', - organizationName: '𝚝𝟷', // Usually your GitHub org/user name. - projectName: '𝚝𝟷-docs', // Usually your repo name. + organizationName: 't1', // Usually your GitHub org/user name. + projectName: 't1-docs', // Usually your repo name. themeConfig: { image: 'img/t1-rollup.png', prism: { @@ -28,20 +27,27 @@ module.exports = { }, algolia: null, navbar: { - title: '𝚝𝟷 Docs', + title: 't1 Docs', items: [ { - to: '/concepts/overview', + to: '/concepts/protocol/rtp', label: 'Concepts', position: 'left', className: 'V3_active', }, { - to: '/api/xChainRead/overview', + to: '/integration/7683/xChainRead', + label: 'Integration', + position: 'left', + className: 'V3_active', + }, + { + to: '/api/xChainRead/api-reference', label: 'API', position: 'left', className: 'V3_active', }, + { // TODO(docs): Publish docs repo and make public at this URL href: 'https://github.com/t1protocol/', @@ -71,7 +77,7 @@ module.exports = { href: 'https://discord.com/invite/nbvyXZHgke', }, { - label: 'Twitter', + label: 'X', href: 'https://x.com/t1protocol', }, { @@ -93,7 +99,7 @@ module.exports = { // Should we use the prefers-color-scheme media-query, // using user system preferences, instead of the hardcoded defaultMode - respectPrefersColorScheme: true, + respectPrefersColorScheme: false, }, }, presets: [ diff --git a/sidebars.js b/sidebars.js index 80846b7c3..60fd8262d 100644 --- a/sidebars.js +++ b/sidebars.js @@ -2,6 +2,7 @@ const sidebars = { // By default, Docusaurus generates a sidebar from the docs folder structure apiSidebar: [{ type: 'autogenerated', dirName: 'api' }], + integrationSidebar: [{ type: 'autogenerated', dirName: 'integration' }], conceptsSidebar: [{ type: 'autogenerated', dirName: 'concepts' }], contractsSidebar: [{ type: 'autogenerated', dirName: 'contracts' }], sdkSidebar: [{ type: 'autogenerated', dirName: 'sdk' }], diff --git a/src/pages/index.tsx b/src/pages/index.tsx index 25aa6af7b..120bfa708 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -5,6 +5,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl' import styled from '@emotion/styled' import Discord from '@site/static/img/discord.svg' import GitHub from '@site/static/img/github.svg' +import X from '@site/static/img/x.svg' import Layout from '@theme/Layout' import ThemedImage from '@theme/ThemedImage' import { TraceEvent } from '@uniswap/analytics' @@ -19,28 +20,28 @@ import { ArrowUpRight as LinkIcon, BookOpen, Info, Link as Chain } from 'react-f export const actions = [ { - title: 'What is 𝚝𝟷', + title: 'Learn More', icon: Info, - to: '/concepts/overview', - text: `Get familiar with the core concepts of the 𝚝𝟷 Protocol.`, + to: '/concepts/protocol/rtp', + text: `Get familiar with the core concepts of the t1 Protocol.`, }, { - title: '𝚝𝟷 testnet portal', + title: 't1 Testnet Portal', icon: Chain, to: 'https://testnet.t1protocol.com/', - text: `Experience real time cross-chain interactions with 𝚝𝟷.`, + text: `Experience real time cross-chain interactions with t1.`, }, { - title: 'The 𝚝𝟷 smart contracts', + title: 't1 Smart Contracts', icon: BookOpen, to: 'https://github.com/t1protocol/t1/tree/canary/contracts', - text: `Learn about the architecture of 𝚝𝟷 smart contracts.`, + text: `Learn about the architecture of t1 smart contracts.`, }, ] export const developerLinks = [ { - title: 't1 monorepo', + title: 't1 Monorepo', href: 'https://github.com/t1protocol/t1', icon: GitHub, }, @@ -48,61 +49,77 @@ export const developerLinks = [ export const dAppGuides = [ { - title: '𝚝𝟷 RTP intent bridge', - text: 'Deposit funds to start interacting with apps on 𝚝𝟷 testnet.', + title: 't1 RTP Intent Bridge', + text: 'Deposit funds to start interacting with apps on t1 testnet.', to: 'https://testnet.t1protocol.com/bridge/?bridgeType=INTENT', }, + { + title: 'More products coming soon', + text: 'Stay tuned for additional dApps built on t1.', + to: '#', + disabled: true, + }, ] export const smartContractGuides = [ { - title: 'xChainRead', + title: 'ERC 7683 Cross Chain Intents', text: 'Read data from other chains and prove the results back to your contract.', - to: '/api/xChainRead/overview', + to: '/integration/7683/xChainRead', }, ] const Container = styled.div` display: flex; flex-direction: column; - margin: 0 auto; + margin: 0 2rem; + + @media (max-width: 960px) { + flex-direction: column; + gap: 16px; + margin: 0 1rem; + } + + @media (max-width: 640px) { + margin: 0; + } ` const Row = styled.div` - display: grid; - grid-template-columns: 1fr 1fr 1fr; - grid-gap: 16px; - justify-content: center; - margin: 0 auto; - padding: 1rem 0; - max-width: 960px; + display: flex; + justify-content: space-between; + gap: 24px; + width: 100%; - @media (max-width: 960px) { - grid-template-columns: 1fr; - padding: 1rem; - max-width: 100%; - margin: 0 1rem; + /* Tablet (2 columns) */ + @media (max-width: 1000px) { + flex-direction: column; + gap: 16px; } @media (max-width: 640px) { - grid-template-columns: 1fr; + padding: 1rem; } ` -const TwoRow = styled(Row)` - grid-template-columns: 1fr 1fr; - grid-gap: 48px; +const RowCentered = styled.div` + display: flex; + justify-content: center; + gap: 24px; + width: 100%; - @media (max-width: 960px) { - grid-template-columns: 1fr; + /* Tablet (2 columns) */ + @media (max-width: 1000px) { + flex-direction: column; + gap: 16px; } @media (max-width: 640px) { - grid-template-columns: 1fr; + padding: 1rem; } ` const Card = styled.div` display: flex; max-height: 250px; - min-width: 350px; + min-width: 330px; padding: 1rem; flex-direction: column; justify-content: center; @@ -141,12 +158,10 @@ const CenterCard = styled(Card)` } ` +/* Card adjustments for Flexbox */ const ShadowCard = styled(Card)` - box-shadow: 0px 6px 10px rgba(0, 0, 0, 0.05); - background-color: #ffffff10; - backdrop-filter: blur(10px); - min-height: 200px; - /* background-color: var(--ifm-color-emphasis-0); */ + flex: 1 1 200px; /* Grow, shrink, min-width */ + box-sizing: border-box; ` const IconWrapper = styled.div` @@ -211,33 +226,114 @@ const StyledTitleImage = styled(StyledImage)` ` const StyledIcon = styled.div` + display: flex; + align-items: center; + justify-content: center; svg { fill: var(--ifm-font-color-base); } ` +const DescriptionSection = styled.div` + max-width: 1100px; + margin: 0 auto 2rem auto; + padding: 0 1rem; + text-align: center; + line-height: 1.6; +` + +const DescriptionText = styled.p` + margin-bottom: 1.5rem; + text-align: left; +` + +const DescriptionList = styled.ul` + text-align: left; + margin-bottom: 1.5rem; + padding-left: 1.5rem; +` + +const DescriptionListItem = styled.li` + margin-bottom: 0.5rem; +` + +const DappsContainer = styled.div` + margin-top: 3rem; + margin-bottom: 2rem; + display: flex; + flex-direction: column; + + @media (max-width: 640px) { + margin-top: 2rem; + padding: 0 1rem; + } +` + +const ExploreContainer = styled.div` + margin-top: 3rem; + display: flex; + flex-direction: column; + + @media (max-width: 640px) { + margin-top: 1rem; + padding: 0 1rem; + } +` + +const LinksContainer = styled.div` + margin: 2rem 0 3rem 0; + + @media (max-width: 640px) { + margin: 0 0 3rem 0; + } +` + export default function Home() { return ( - + +
-

Welcome to 𝚝𝟷 Docs

+
Welcome to t1 Docs
- + + + t1 is an EVM-based cross-chain application infrastructure that introduces Real-time proving (RTP) and + programmability to address fragmentation and composability challenges in scaling Ethereum: + + + + + Real-time proving: Using Trusted Execution Environments (TEEs), t1 proves its execution + integrity to Ethereum and partner rollups in under 12 seconds. By running partner rollup nodes within + its infrastructure, t1 aggregates and proves their state to Ethereum in 1-2 L1 blocks—enabling instant + settlement between Ethereum and any partner rollup. + + + Programmability: t1 smart contracts are able to read from and write to Ethereum and + partner rollups. (coming soon) + + + + + t1 provides the missing infrastructure for seamless cross-chain applications and liquidity movement—today. + + + {actions.map((action) => ( - -
-

Explore dApps

-

See what's possible with 𝚝𝟷.

-
- {dAppGuides.map((action) => ( + <> + {/* Smart Contracts Section */} + +
+ Integrate Your Smart Contracts +
+

Build with t1's cross-chain capabilities

+ +
+ {smartContractGuides.map((action) => ( - - + +

{action.title}

@@ -299,28 +401,47 @@ export default function Home() { ))}
-
-
-

Integrate your smart contracts

-

Get started integrating with 𝚝𝟷's Proof of Read in your smart contracts.

-
- {smartContractGuides.map((action) => ( + + + {/* Explore dApps Section */} + +
Explore dApps
+

See what's possible with t1

+ +
+ {dAppGuides.map((action) => ( - - + +

{action.title}

- - - + {!action.disabled && ( + + + + )}

{action.text}

 @@ -328,45 +449,65 @@ export default function Home() { ))}
-
- + +
- - - - - -
-

Discord

-

Join our Developer Community.

-
- - - - - - - - - -
-

GitHub

-

View all 𝚝𝟷 repositories.

-
- - - - + + + + + + + + +
+

X

+

Stay up to date on X.

+
+ + + + + + + +
+

Discord

+

Join our Developer Community.

+
+ + + + + + + + + +
+

GitHub

+

View all t1 repositories.

+
+ + + + + ) diff --git a/static/img/x.svg b/static/img/x.svg new file mode 100644 index 000000000..86a1f3ee8 --- /dev/null +++ b/static/img/x.svg @@ -0,0 +1 @@ + \ No newline at end of file From bd34be4027bf22292976379458024accbf6150a5 Mon Sep 17 00:00:00 2001 From: prince Date: Wed, 25 Jun 2025 23:44:04 +0800 Subject: [PATCH 2/5] replace apos --- src/pages/index.tsx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/pages/index.tsx b/src/pages/index.tsx index 120bfa708..de3703f42 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -367,7 +367,7 @@ export default function Home() {
Integrate Your Smart Contracts
-

Build with t1's cross-chain capabilities

+

Build with t1's cross-chain capabilities

Explore dApps
-

See what's possible with t1

+

See what's possible with t1

Date: Thu, 26 Jun 2025 00:00:49 +0800 Subject: [PATCH 3/5] increased padding --- src/pages/index.tsx | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/pages/index.tsx b/src/pages/index.tsx index de3703f42..e7ad0f093 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -71,16 +71,16 @@ export const smartContractGuides = [ const Container = styled.div` display: flex; flex-direction: column; - margin: 0 2rem; + margin: 0 4.5rem; @media (max-width: 960px) { flex-direction: column; gap: 16px; - margin: 0 1rem; + margin: 0 2rem; } @media (max-width: 640px) { - margin: 0; + margin: 0 1rem; } ` @@ -162,6 +162,7 @@ const CenterCard = styled(Card)` const ShadowCard = styled(Card)` flex: 1 1 200px; /* Grow, shrink, min-width */ box-sizing: border-box; + background: #ffffff10; ` const IconWrapper = styled.div` From 6521bc7163f6f231a8fdf7f33ad0deb8d4eb126b Mon Sep 17 00:00:00 2001 From: prince Date: Thu, 26 Jun 2025 00:06:52 +0800 Subject: [PATCH 4/5] fix lint --- src/pages/index.tsx | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/pages/index.tsx b/src/pages/index.tsx index 8bcb003c3..e7ad0f093 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -71,10 +71,8 @@ export const smartContractGuides = [ const Container = styled.div` display: flex; flex-direction: column; - margin: 0 4.5rem; - @media (max-width: 960px) { flex-direction: column; gap: 16px; @@ -165,7 +163,6 @@ const ShadowCard = styled(Card)` flex: 1 1 200px; /* Grow, shrink, min-width */ box-sizing: border-box; background: #ffffff10; - ` const IconWrapper = styled.div` From ba214987b60d24e518171f5f92d7c8695ab81be5 Mon Sep 17 00:00:00 2001 From: prince Date: Thu, 26 Jun 2025 00:36:37 +0800 Subject: [PATCH 5/5] fix spacing --- src/pages/index.tsx | 401 ++++++++++++++++++++++---------------------- 1 file changed, 203 insertions(+), 198 deletions(-) diff --git a/src/pages/index.tsx b/src/pages/index.tsx index e7ad0f093..234e1b230 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -71,7 +71,7 @@ export const smartContractGuides = [ const Container = styled.div` display: flex; flex-direction: column; - margin: 0 4.5rem; + margin: 0 2rem; @media (max-width: 960px) { flex-direction: column; @@ -84,6 +84,13 @@ const Container = styled.div` } ` +const InnerContainer = styled.div` + display: flex; + flex-direction: column; + margin: 0 auto; + max-width: 1100px; +` + const Row = styled.div` display: flex; justify-content: space-between; @@ -119,10 +126,8 @@ const RowCentered = styled.div` const Card = styled.div` display: flex; max-height: 250px; - min-width: 330px; padding: 1rem; flex-direction: column; - justify-content: center; cursor: pointer; border: 1px solid transparent; border-radius: 20px; @@ -265,8 +270,7 @@ const DappsContainer = styled.div` flex-direction: column; @media (max-width: 640px) { - margin-top: 2rem; - padding: 0 1rem; + margin: 2rem 1rem 0 1rem; } ` @@ -276,8 +280,7 @@ const ExploreContainer = styled.div` flex-direction: column; @media (max-width: 640px) { - margin-top: 1rem; - padding: 0 1rem; + margin: 2rem 1rem 0 1rem; } ` @@ -299,216 +302,218 @@ export default function Home() { }} /> - -
-
Welcome to t1 Docs
-
- - - t1 is an EVM-based cross-chain application infrastructure that introduces Real-time proving (RTP) and - programmability to address fragmentation and composability challenges in scaling Ethereum: - - - - - Real-time proving: Using Trusted Execution Environments (TEEs), t1 proves its execution - integrity to Ethereum and partner rollups in under 12 seconds. By running partner rollup nodes within - its infrastructure, t1 aggregates and proves their state to Ethereum in 1-2 L1 blocks—enabling instant - settlement between Ethereum and any partner rollup. - - - Programmability: t1 smart contracts are able to read from and write to Ethereum and - partner rollups. (coming soon) - - - - - t1 provides the missing infrastructure for seamless cross-chain applications and liquidity movement—today. - - - - - {actions.map((action) => ( - - - - - - - - - - - -

{action.title}

-

{action.text}

- - - - ))} - - - <> - {/* Smart Contracts Section */} - -
- Integrate Your Smart Contracts -
-

Build with t1's cross-chain capabilities

- + +
- {smartContractGuides.map((action) => ( +
Welcome to t1 Docs
+
+ + + t1 is an EVM-based cross-chain application infrastructure that introduces Real-time proving (RTP) and + programmability to address fragmentation and composability challenges in scaling Ethereum: + + + + + Real-time proving: Using Trusted Execution Environments (TEEs), t1 proves its + execution integrity to Ethereum and partner rollups in under 12 seconds. By running partner rollup + nodes within its infrastructure, t1 aggregates and proves their state to Ethereum in 1-2 L1 + blocks—enabling instant settlement between Ethereum and any partner rollup. + + + Programmability: t1 smart contracts are able to read from and write to Ethereum and + partner rollups. (coming soon) + + + + + t1 provides the missing infrastructure for seamless cross-chain applications and liquidity + movement—today. + + + + + {actions.map((action) => ( - - - -
-

{action.title}

-
+ + + + + + - -

{action.text}

- + +

{action.title}

+

{action.text}

+ ))} -
- - - {/* Explore dApps Section */} - -
Explore dApps
-

See what's possible with t1

- -
- {dAppGuides.map((action) => ( - - - - -
-

{action.title}

-
- {!action.disabled && ( + + + <> + {/* Smart Contracts Section */} + +
+ Integrate Your Smart Contracts +
+

Build with t1's cross-chain capabilities

+ +
+ {smartContractGuides.map((action) => ( + + + + +
+

{action.title}

+
- )} - -

{action.text}

- - - - ))} -
- - -
- - - - - - - - -
-

X

-

Stay up to date on X.

-
- - - - - - - -
-

Discord

-

Join our Developer Community.

-
- - - - - - - - - -
-

GitHub

-

View all t1 repositories.

-
- - - - - + +

{action.text}

+ + + + ))} +
+ + + {/* Explore dApps Section */} + +
Explore dApps
+

See what's possible with t1

+ +
+ {dAppGuides.map((action) => ( + + + + +
+

{action.title}

+
+ {!action.disabled && ( + + + + )} + +

{action.text}

+ + + + ))} +
+ + +
+ + + + + + + + +
+

X

+

Stay up to date on X.

+
+ + + + + + + +
+

Discord

+

Join our Developer Community.

+
+ + + + + + + + + +
+

GitHub

+

View all t1 repositories.

+
+ + + + + + )