Skip to content

Refactor: Integration docs for frontend and testnet prep #23

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
princet1protocol merged 2 commits into from
Jun 25, 2025
Merged

Refactor: Integration docs for frontend and testnet prep #23

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
373c0fc
integration docs for frontend and testnet prep
princet1protocol Jun 25, 2025
bd34be4
replace apos
princet1protocol Jun 25, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 17 additions & 16 deletions docs/api/xChainRead/api-reference.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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
Expand All @@ -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
Expand All @@ -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",
Expand All @@ -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.
Expand All @@ -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);
}
```
Expand All @@ -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
Expand Down
35 changes: 22 additions & 13 deletions docs/concepts/glossary.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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)
2 changes: 1 addition & 1 deletion docs/concepts/protocol/_category_.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
{
"label": "Protocol Concepts",
"position": 2
"position": 1
}
4 changes: 2 additions & 2 deletions docs/concepts/protocol/tee.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Loading