- A Type 1 ZK-EVM
+ A Type 1 ZK-EVM
Fully decentralized, Ethereum-equivalent ZK-Rollup.
@@ -52,9 +52,9 @@ export default function Hero() {
diff --git a/packages/website/pages/_meta.json b/packages/website/pages/_meta.json
index 8e2e86e9c1b..010124db22a 100644
--- a/packages/website/pages/_meta.json
+++ b/packages/website/pages/_meta.json
@@ -24,5 +24,45 @@
"type": "page",
"href": "https://mirror.xyz/labs.taiko.eth",
"newWindow": true
+ },
+ "feedback": {
+ "title": "Feedback ↗",
+ "type": "page",
+ "href": "https://forms.gle/RZsweAPy5RhQSP6j7",
+ "newWindow": true
+ },
+ "bridge": {
+ "title": "Bridge ↗",
+ "type": "page",
+ "href": "https://bridge.a2.taiko.xyz",
+ "newWindow": true
+ },
+ "swap": {
+ "title": "Swap ↗",
+ "type": "page",
+ "href": "https://swap.a2.taiko.xyz",
+ "newWindow": true
+ },
+ "status": {
+ "title": "Status ↗",
+ "type": "page",
+ "href": "https://status.a2.taiko.xyz",
+ "newWindow": true
+ },
+ "explorers": {
+ "title": "Explorers",
+ "type": "menu",
+ "items": {
+ "l1-block-explorer": {
+ "title": "Sepolia Block Explorer ↗",
+ "href": "https://sepolia.etherscan.io",
+ "newWindow": true
+ },
+ "l2-block-explorer": {
+ "title": "Taiko Block Explorer ↗",
+ "href": "https://explorer.a2.taiko.xyz",
+ "newWindow": true
+ }
+ }
}
}
diff --git a/packages/website/pages/docs/_meta.json b/packages/website/pages/docs/_meta.json
index f4456f65c2a..b2a0b688c90 100644
--- a/packages/website/pages/docs/_meta.json
+++ b/packages/website/pages/docs/_meta.json
@@ -1,6 +1,6 @@
{
"index": {
- "title": "Introduction 👋"
+ "title": "Hello 👋"
},
"concepts": {
"title": "Concepts"
diff --git a/packages/website/pages/docs/concepts.mdx b/packages/website/pages/docs/concepts.mdx
new file mode 100644
index 00000000000..a65dcb6a9ea
--- /dev/null
+++ b/packages/website/pages/docs/concepts.mdx
@@ -0,0 +1 @@
+Learn all about Taiko's core concepts here.
\ No newline at end of file
diff --git a/packages/website/pages/docs/concepts/_meta.json b/packages/website/pages/docs/concepts/_meta.json
index fa3e4f9a03b..25998bbb2d5 100644
--- a/packages/website/pages/docs/concepts/_meta.json
+++ b/packages/website/pages/docs/concepts/_meta.json
@@ -2,8 +2,11 @@
"overview": {
"title": "Overview"
},
- "creating-l2-blocks": {
- "title": "Creating L2 blocks"
+ "creating-taiko-blocks": {
+ "title": "Creating Taiko blocks"
+ },
+ "proving-taiko-blocks": {
+ "title": "Proving Taiko blocks"
},
"bridging": {
"title": "Bridging"
diff --git a/packages/website/pages/docs/concepts/bridging.mdx b/packages/website/pages/docs/concepts/bridging.mdx
deleted file mode 100644
index c78ee5583c1..00000000000
--- a/packages/website/pages/docs/concepts/bridging.mdx
+++ /dev/null
@@ -1,108 +0,0 @@
-# Bridging
-
-Let's explain bridging on Taiko. We will go over the following topics:
-
-- What is bridging and why is it important?
-- How does the Taiko protocol enable secure cross-chain messaging?
-- What is Taiko's Signal Service?
-- A flowchart of bridging for the visual learners
-- How does Ether bridging work?
-- How does ERC-20 bridging work?
-
-## What is bridging and why is it important?
-
-Bridges are foundational for cross-chain users and applications. Users might come to another chain, such as Taiko (a ZK-rollup). To do this, they need to bridge over funds. Notoriously, bridging has been a dangerous operation. How do you make sure that this bridge is secure?
-
-## How does the Taiko protocol enable secure cross-chain messaging?
-
-### Taiko stores block hashes of each chain
-
-Taiko deploys two smart contracts which store the hashes of the other chain:
-
-- TaikoL1 stores a blockNumber->blockHash mapping `l2Hashes` (deployed on Ethereum)
-- TaikoL2 stores a blockNumber->blockHash mapping `l1Hashes` (deployed on Taiko)
-
-Every time an L2 block is created on Taiko, the hash of the enclosing block on L1 is stored in the TaikoL2 contract. And every time an L1 block is verified, the L2 hash is stored in the TaikoL1 contract (only the latest one, if multiple ones are verified at once).
-
-### Merkle trees enable verifying values exist on the other chain
-
-Merkle trees are a data storage structure that allows a lot of data to be fingerprinted with a single hash, called the root hash. The way that they are structured enables one to verify that some value exists within this large data structure, without actually needing to have access to the entire merkle tree. To do this, the verifier would need:
-
-- The root hash, this represents the root of the merkle tree
-- The value, this is the value we are checking is inside the root hash
-- A list of intermediate sibling hashes, these are the hashes that enable the verifier to re-calculate the root hash
-
-A verifier will take the value, which is a leaf in the merkle tree, and using the sibling hashes will recalculate the merkle root. A simple way to think of this is that it checks if the calculated root hash matches the one we were provided. If it does, it means we have proved that this exists in the root hash.
-
-If we assume that each chain correctly maintains the latest hashes of the other chain, we can verify on one chain that a message was sent on the other chain.
-
-## What is Taiko's Signal Service?
-
-Taiko's signal service is a smart contract available on both L1 and L2, available for any dapp developer to use. It exposes a [really simple interface](/docs/reference/contract-documentation/signal/ISignalService). And it's what uses the previously mentioned merkle proofs to provide a service for secure cross-chain messaging.
-
-You can store signals and check if a signal was sent from an address. It also exposes one more important function: `isSignalReceived`.
-
-What does this function do? The first thing to understand is that the Taiko protocol maintains two important contracts:
-
-- [TaikoL1](/docs/reference/contract-documentation/L1/TaikoL1)
-- [TaikoL2](/docs/reference/contract-documentation/L2/TaikoL2)
-
-These contracts both keep track of the block hashes on the **other chain**. So TaikoL1, which is deployed on Ethereum, has access to the latest block hashes on Taiko. And TaikoL2, which is deployed on Taiko, has access to the latest block hashes on Ethereum.
-
-So, `isSignalReceived` can prove on either chain that you sent a signal to the Signal Service on the other chain. A user or dapp can call `eth_getProof`(https://eips.ethereum.org/EIPS/eip-1186) which generates a merkle proof.
-
-You need to provide `eth_getProof` with:
-
-1. The signal (the data you want to prove exists within the storage root of some block on the chain)
-2. The address of the signal service (the contract address which stores the provided signal)
-3. The block number you are asserting the signal was sent on (optional—if you don't provide this, it will default to the latest block number)
-
-And, `eth_getProof` will generate a merkle proof (it will give the necessary sibling hashes and the height of the block, that along with the signal, can rebuild the merkle storage root of the block you are asserting the signal exists in).
-
-This means, assuming that the hashes which TaikoL1 and TaikoL2 maintain are correct, we can reliably send **cross-chain messages**.
-
-Let's walk through an example:
-
-1. First, we can send a message on some source chain, and store it on the signal service.
-2. Next, we call `eth_getProof`, which will give us a proof that we did indeed send a message on the source chain.
-3. Finally, we call `isSignalReceived` on the destination chain's SignalService which essentially just verifies the merkle proof. `isSignalReceived` will look up the block hash you are asserting you had stored a message on the source chain (where you originally sent the message), and with the sibling hashes inside the merkle proof it will rebuild the merkle root, which verifies the signal was included in that merkle root—meaning it was sent.
-
-And boom! We have sent a cross-chain message. Confusing? Well leave some feedback please if it is, so we can clear it up.
-
-## A flowchart of bridging for the visual learners
-
- \
-
-
-## How does Ether bridging work?
-
-Taiko's bridge utilizes the Signal Service we described. Here is the general user flow for Taiko's bridge:
-
-1. The user sends their funds to the Bridge contract
-2. The Bridge locks the Ether, and stores a message by calling `sendSignal(message)` on the SignalService contract
-3. The user receives Ether on the destination chain, if they (or another) provide a valid merkle proof that the message was received on the source chain
-
-## How does ERC-20 bridging work?
-
-ERC-20 tokens originate from a canonical chain. To send a token and bridge it to the other chain, a new BridgedERC20 contract needs to be deployed on the destination chain. For example, the HORSE token's canonical chain is [deployed on Ethereum A1](https://l1explorer.a1.taiko.xyz/address/0x3E3a3416DbCc5cb4448B6b171fF15f9Da35Ab72d). To enable bridging to Taiko A1, there is also a BridgedERC20 contract for it [deployed on Taiko A1](https://l2explorer.a1.taiko.xyz/address/0xb8eA36284d1Fa062cc0c969E28a49f3531cFB1bf).
-
-### Bridge from canonical chain to destination chain
-
-Here are the overall steps for transferring canonical ERC-20 from a source chain to the destination chain:
-
-1. A contract for the ERC-20 must first be deployed on the destination chain (will be done automatically by the TokenVault if not already deployed)
-
-2. Call sendERC20 on the source chain TokenVault, this will **transfer** the amount by using the `safeTransferFrom` function on the canonical ERC-20 contract, on the source chain, to the TokenVault.
-
-3. Send a message to the Signal Service (on the source chain), this message will contain some metadata related to the bridge request, but most importantly it includes the calldata for the `receiveERC20` method.
-
-4. Process the message on the destination chain by submitting a merkle proof (generated from the source chain), proving that a message is included in the state of the source chain Signal Service. After verifying this occurred and doing some checks, it will attempt to invoke the `receiveERC20` method encoded in the message. This will **mint** ERC-20 on the BridgedERC20 contract to the `to` address on the destination chain!
-
-### Bridge from destination chain back to the canonical chain
-
-Okay now let's do the reverse, how do we transfer a bridged token from a source chain to the destination chain?
-
-1. A contract for the ERC-20 already exists on the canonical chain, so no need to deploy a new one.
-2. Call sendERC20 on the source chain TokenVault, this will **burn** the ERC-20 on the BridgedERC20 contract.
-3. Send a message to the Signal Service (on the source chain), this message will contain some metadata related to the bridge request, but most importantly it includes the calldata for the `receiveERC20` method.
-4. Process the message on the destination chain by submitting a merkle proof (generated from the source chain), proving that a message is included in the state of the source chain Signal Service. After verifying this occurred and doing some checks, it will attempt to invoke the `receiveERC20` method encoded in this message. This will **transfer** the amount from the destination chain TokenVault to the `to` address on the destination chain.
diff --git a/packages/website/pages/docs/concepts/bridging/_meta.json b/packages/website/pages/docs/concepts/bridging/_meta.json
new file mode 100644
index 00000000000..d8ced8fb987
--- /dev/null
+++ b/packages/website/pages/docs/concepts/bridging/_meta.json
@@ -0,0 +1,14 @@
+{
+ "cross-chain-messaging": {
+ "title": "Cross-chain messaging"
+ },
+ "the-signal-service": {
+ "title": "The signal service"
+ },
+ "the-taiko-bridge-dapp": {
+ "title": "The bridge dapp"
+ },
+ "how-the-bridge-works": {
+ "title": "How the bridge dapp works"
+ }
+}
diff --git a/packages/website/pages/docs/concepts/bridging/cross-chain-messaging.mdx b/packages/website/pages/docs/concepts/bridging/cross-chain-messaging.mdx
new file mode 100644
index 00000000000..f1a422c5d87
--- /dev/null
+++ b/packages/website/pages/docs/concepts/bridging/cross-chain-messaging.mdx
@@ -0,0 +1,31 @@
+Bridges are foundational for cross-chain users and applications. Users might come to another chain, such as Taiko (a ZK-rollup). To do this, they need to bridge over funds. Notoriously, bridging has been a dangerous operation. How do you make sure that this bridge is secure?
+
+Let's explain bridging on Taiko. We will answer the following questions:
+
+- How does the Taiko protocol enable secure cross-chain messaging?
+- What is the Taiko signal service?
+- What is the Taiko bridge dapp?
+- How does the bridge dapp work?
+
+The Taiko protocol's design, specifically its Ethereum-equivalency enables secure cross-chain messaging. Let's see how it works by simply using merkle proofs.
+
+### Taiko stores block hashes of each chain
+
+Taiko deploys two smart contracts which store the hashes of the other chain:
+
+- TaikoL1 stores a blockNumber->blockHash mapping `l2Hashes` (deployed on Ethereum)
+- TaikoL2 stores a blockNumber->blockHash mapping `l1Hashes` (deployed on Taiko)
+
+Every time an L2 block is created on Taiko, the hash of the enclosing block on L1 is stored in the TaikoL2 contract. And every time an L1 block is verified, the L2 hash is stored in the TaikoL1 contract (only the latest one, if multiple ones are verified at once).
+
+### Merkle trees enable verifying values exist on the other chain
+
+Merkle trees are a data storage structure that allows a lot of data to be fingerprinted with a single hash, called the root hash. The way that they are structured enables one to verify that some value exists within this large data structure, without actually needing to have access to the entire merkle tree. To do this, the verifier would need:
+
+- The root hash, this represents the root of the merkle tree
+- The value, this is the value we are checking is inside the root hash
+- A list of intermediate sibling hashes, these are the hashes that enable the verifier to re-calculate the root hash
+
+A verifier will take the value, which is a leaf in the merkle tree, and using the sibling hashes will recalculate the merkle root. A simple way to think of this is that it checks if the calculated root hash matches the one we were provided. If it does, it means we have proved that this exists in the root hash.
+
+If we assume that each chain correctly maintains the latest hashes of the other chain, we can verify on one chain that a message was sent on the other chain.
diff --git a/packages/website/pages/docs/concepts/bridging/how-the-bridge-works.mdx b/packages/website/pages/docs/concepts/bridging/how-the-bridge-works.mdx
new file mode 100644
index 00000000000..aeefc76786e
--- /dev/null
+++ b/packages/website/pages/docs/concepts/bridging/how-the-bridge-works.mdx
@@ -0,0 +1,37 @@
+First, here is a flowchart of how our bridge dapp implementation works, which uses the signal service:
+
+ \
+
+
+## How does Ether bridging work?
+
+Taiko's bridge utilizes the Signal Service we described. Here is the general user flow for Taiko's bridge:
+
+1. The user sends their funds to the Bridge contract
+2. The Bridge locks the Ether, and stores a message by calling `sendSignal(message)` on the SignalService contract
+3. The user receives Ether on the destination chain, if they (or another) provide a valid merkle proof that the message was received on the source chain
+
+## How does ERC-20 bridging work?
+
+ERC-20 tokens originate from a canonical chain. To send a token and bridge it to the other chain, a new BridgedERC20 contract needs to be deployed on the destination chain. For example, the HORSE token's canonical chain is [deployed on Ethereum (Sepolia)](https://explorer.a2.taiko.xyz/address/0x3E3a3416DbCc5cb4448B6b171fF15f9Da35Ab72d). To enable bridging to Taiko, there is also a BridgedERC20 contract for it [deployed on Taiko (Askja)](https://explorer.a2.taiko.xyz/address/0xb8eA36284d1Fa062cc0c969E28a49f3531cFB1bf).
+
+### Bridge from canonical chain to destination chain
+
+Here are the overall steps for transferring canonical ERC-20 from a source chain to the destination chain:
+
+1. A contract for the ERC-20 must first be deployed on the destination chain (will be done automatically by the TokenVault if not already deployed)
+
+2. Call sendERC20 on the source chain TokenVault, this will **transfer** the amount by using the `safeTransferFrom` function on the canonical ERC-20 contract, on the source chain, to the TokenVault.
+
+3. Send a message to the Signal Service (on the source chain), this message will contain some metadata related to the bridge request, but most importantly it includes the calldata for the `receiveERC20` method.
+
+4. Process the message on the destination chain by submitting a merkle proof (generated from the source chain), proving that a message is included in the state of the source chain Signal Service. After verifying this occurred and doing some checks, it will attempt to invoke the `receiveERC20` method encoded in the message. This will **mint** ERC-20 on the BridgedERC20 contract to the `to` address on the destination chain!
+
+### Bridge from destination chain back to the canonical chain
+
+Okay now let's do the reverse, how do we transfer a bridged token from a source chain to the destination chain?
+
+1. A contract for the ERC-20 already exists on the canonical chain, so no need to deploy a new one.
+2. Call sendERC20 on the source chain TokenVault, this will **burn** the ERC-20 on the BridgedERC20 contract.
+3. Send a message to the Signal Service (on the source chain), this message will contain some metadata related to the bridge request, but most importantly it includes the calldata for the `receiveERC20` method.
+4. Process the message on the destination chain by submitting a merkle proof (generated from the source chain), proving that a message is included in the state of the source chain Signal Service. After verifying this occurred and doing some checks, it will attempt to invoke the `receiveERC20` method encoded in this message. This will **transfer** the amount from the destination chain TokenVault to the `to` address on the destination chain.
diff --git a/packages/website/pages/docs/concepts/bridging/the-signal-service.mdx b/packages/website/pages/docs/concepts/bridging/the-signal-service.mdx
new file mode 100644
index 00000000000..e89b65121b3
--- /dev/null
+++ b/packages/website/pages/docs/concepts/bridging/the-signal-service.mdx
@@ -0,0 +1,30 @@
+Taiko's signal service is a smart contract available on both L1 and L2, available for any dapp developer to use. It exposes a [really simple interface](/docs/reference/contract-documentation/signal/ISignalService). And it's what uses the previously mentioned merkle proofs to provide a service for secure cross-chain messaging.
+
+You can store signals and check if a signal was sent from an address. It also exposes one more important function: `isSignalReceived`.
+
+What does this function do? The first thing to understand is that the Taiko protocol maintains two important contracts:
+
+- [TaikoL1](/docs/reference/contract-documentation/L1/TaikoL1)
+- [TaikoL2](/docs/reference/contract-documentation/L2/TaikoL2)
+
+These contracts both keep track of the block hashes on the **other chain**. So TaikoL1, which is deployed on Ethereum, has access to the latest block hashes on Taiko. And TaikoL2, which is deployed on Taiko, has access to the latest block hashes on Ethereum.
+
+So, `isSignalReceived` can prove on either chain that you sent a signal to the Signal Service on the other chain. A user or dapp can call `eth_getProof`(https://eips.ethereum.org/EIPS/eip-1186) which generates a merkle proof.
+
+You need to provide `eth_getProof` with:
+
+1. The signal (the data you want to prove exists within the storage root of some block on the chain)
+2. The address of the signal service (the contract address which stores the provided signal)
+3. The block number you are asserting the signal was sent on (optional—if you don't provide this, it will default to the latest block number)
+
+And, `eth_getProof` will generate a merkle proof (it will give the necessary sibling hashes and the height of the block, that along with the signal, can rebuild the merkle storage root of the block you are asserting the signal exists in).
+
+This means, assuming that the hashes which TaikoL1 and TaikoL2 maintain are correct, we can reliably send **cross-chain messages**.
+
+Let's walk through an example:
+
+1. First, we can send a message on some source chain, and store it on the signal service.
+2. Next, we call `eth_getProof`, which will give us a proof that we did indeed send a message on the source chain.
+3. Finally, we call `isSignalReceived` on the destination chain's SignalService which essentially just verifies the merkle proof. `isSignalReceived` will look up the block hash you are asserting you had stored a message on the source chain (where you originally sent the message), and with the sibling hashes inside the merkle proof it will rebuild the merkle root, which verifies the signal was included in that merkle root—meaning it was sent.
+
+And boom! We have sent a cross-chain message. Confusing? Well leave some feedback please if it is, so we can clear it up.
diff --git a/packages/website/pages/docs/concepts/bridging/the-taiko-bridge-dapp.mdx b/packages/website/pages/docs/concepts/bridging/the-taiko-bridge-dapp.mdx
new file mode 100644
index 00000000000..8512a1000af
--- /dev/null
+++ b/packages/website/pages/docs/concepts/bridging/the-taiko-bridge-dapp.mdx
@@ -0,0 +1 @@
+The bridge is a set of smart contracts and a frontend web app that allow you to send testnet ETH and ERC-20 tokens between Sepolia and Taiko. This bridge is just one possible implementation built on top of Taiko's core protocol, specifically the signal service which anybody can use to build bridges. You can try the bridge [here](https://bridge.a2.taiko.xyz).
diff --git a/packages/website/pages/docs/concepts/creating-l2-blocks/_meta.json b/packages/website/pages/docs/concepts/creating-l2-blocks/_meta.json
deleted file mode 100644
index ee0deae7cf5..00000000000
--- a/packages/website/pages/docs/concepts/creating-l2-blocks/_meta.json
+++ /dev/null
@@ -1,11 +0,0 @@
-{
- "creating-l2-blocks": {
- "title": "Creating L2 blocks"
- },
- "intrinsic-validity-functions": {
- "title": "Intrinsic validity functions"
- },
- "anchor-transaction": {
- "title": "Anchor transaction"
- }
-}
\ No newline at end of file
diff --git a/packages/website/pages/docs/concepts/creating-taiko-blocks/_meta.json b/packages/website/pages/docs/concepts/creating-taiko-blocks/_meta.json
new file mode 100644
index 00000000000..3181d51eabc
--- /dev/null
+++ b/packages/website/pages/docs/concepts/creating-taiko-blocks/_meta.json
@@ -0,0 +1,11 @@
+{
+ "proposing-blocks": {
+ "title": "Proposing blocks"
+ },
+ "intrinsic-validity-functions": {
+ "title": "Intrinsic validity functions"
+ },
+ "anchor-transaction": {
+ "title": "Anchor transaction"
+ }
+}
diff --git a/packages/website/pages/docs/concepts/creating-l2-blocks/anchor-transaction.mdx b/packages/website/pages/docs/concepts/creating-taiko-blocks/anchor-transaction.mdx
similarity index 100%
rename from packages/website/pages/docs/concepts/creating-l2-blocks/anchor-transaction.mdx
rename to packages/website/pages/docs/concepts/creating-taiko-blocks/anchor-transaction.mdx
diff --git a/packages/website/pages/docs/concepts/creating-l2-blocks/intrinsic-validity-functions.mdx b/packages/website/pages/docs/concepts/creating-taiko-blocks/intrinsic-validity-functions.mdx
similarity index 100%
rename from packages/website/pages/docs/concepts/creating-l2-blocks/intrinsic-validity-functions.mdx
rename to packages/website/pages/docs/concepts/creating-taiko-blocks/intrinsic-validity-functions.mdx
diff --git a/packages/website/pages/docs/concepts/creating-l2-blocks/creating-l2-blocks.mdx b/packages/website/pages/docs/concepts/creating-taiko-blocks/proposing-blocks.mdx
similarity index 100%
rename from packages/website/pages/docs/concepts/creating-l2-blocks/creating-l2-blocks.mdx
rename to packages/website/pages/docs/concepts/creating-taiko-blocks/proposing-blocks.mdx
diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json b/packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json
new file mode 100644
index 00000000000..c74e1bd3c27
--- /dev/null
+++ b/packages/website/pages/docs/concepts/proving-taiko-blocks/_meta.json
@@ -0,0 +1,11 @@
+{
+ "provers": {
+ "title": "Provers"
+ },
+ "the-oracle-prover": {
+ "title": "The oracle prover"
+ },
+ "verified-blocks-and-parallel-proving": {
+ "title": "Verified blocks & parallel proving"
+ }
+}
diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx b/packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx
new file mode 100644
index 00000000000..7075acb2cea
--- /dev/null
+++ b/packages/website/pages/docs/concepts/proving-taiko-blocks/provers.mdx
@@ -0,0 +1 @@
+The purpose of proving blocks is to allow bridges to withdraw state out of the rollup. To rely on some state that happened inside of the rollup, a bridge will want a proof that everything was done correctly. On Taiko you can [run a node as a prover](/docs/guides/run-a-taiko-node) and prove blocks, permissionlessly. This means that you can examine the proposed blocks on the TaikoL1 contract, and generate proofs for them. Currently, any prover can create proofs for proposed blocks. This means that the number of "fork choices" has no upper bound, because we don't know what is the correct state transition yet. Only first prover with a valid proof of the correct fork choice (state transition) will receive the reward of TTKO.
diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx b/packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx
new file mode 100644
index 00000000000..7c75790b407
--- /dev/null
+++ b/packages/website/pages/docs/concepts/proving-taiko-blocks/the-oracle-prover.mdx
@@ -0,0 +1 @@
+There is a concept of an oracle prover on Taiko, which will be removed when the circuits are complete and some rollup training wheels have been removed (such as DAO governance and multi-proofs). The oracle prover is a prover that is trusted to provide the correct state transition. If oracle proving is enabled, then the oracle prover will be forced as the first prover for a block and the second will be from a prover. The actual prover (one of you) however will receive the reward of course, this is just a safety mechanism we have in place while the ZK-EVM is still in development.
diff --git a/packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx b/packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx
new file mode 100644
index 00000000000..bcf9416167c
--- /dev/null
+++ b/packages/website/pages/docs/concepts/proving-taiko-blocks/verified-blocks-and-parallel-proving.mdx
@@ -0,0 +1,20 @@
+There are three states that a block can be in on Taiko:
+- Proposed
+- Proved
+- Verified
+
+We already know what a proposed block is (must pass at least the block-level intrinsic validity tests to be accepted by the TaikoL1 contract). Next, a proposed block can be valid or invalid, depending on whether it passes the transaction list intrinsic validity test. A block is invalid if it fails the transaction list intrinsic validity test, and this block is not created on Taiko.
+
+Now, a block can be proved, but also further "verified". What's the difference? A block is proved if it has a valid proof which proves a state transition from one state (parent block) to another (current block). However, blocks are proven in parallel by the decentralized provers. So while a block can prove a parent block transitions to the current block, we don't know if the parent block itself has been proven. As you can see, for a block to be "verified", it needs to prove the valid state transition to the current block, but the parent also need to be verified. We assume that the genesis block (which has no parent), is verified. So all the children blocks from genesis to the current block need to have proofs of their state transition for the current block to be "verified".
+
+For the visual learners here is a visualization of the three stages (proposed -> proved -> verified)
+
+**Proposed:**
+
+
+**Proved:**
+
+
+**Verified:**
+
+
diff --git a/packages/website/pages/docs/concepts/taiko-nodes.mdx b/packages/website/pages/docs/concepts/taiko-nodes.mdx
index 7f5c9a3e225..9fcc8451c23 100644
--- a/packages/website/pages/docs/concepts/taiko-nodes.mdx
+++ b/packages/website/pages/docs/concepts/taiko-nodes.mdx
@@ -1,9 +1,8 @@
-# Overview
There are two parts to a Taiko node, which are connected over the engine API:
- `taiko-geth`
- `taiko-client`
-
+
## Taiko geth
diff --git a/packages/website/pages/docs/guides.mdx b/packages/website/pages/docs/guides.mdx
new file mode 100644
index 00000000000..6f6fe027950
--- /dev/null
+++ b/packages/website/pages/docs/guides.mdx
@@ -0,0 +1,10 @@
+Here are the testnet guides:
+- 👛 [Configure your wallet](/docs/guides/configure-your-wallet)
+- 💦 [Receive tokens](/docs/guides/receive-tokens)
+- 🌉 [Use the bridge](/docs/guides/use-the-bridge)
+- 🔀 [Swap tokens](/docs/guides/swap-tokens)
+- 🌐 [Run a node](/docs/guides/run-a-node)
+- 🧙 [Deploy a contract](/docs/guides/deploy-a-contract)
+- 🛠️ [Build a dapp](/docs/guides/build-a-dapp)
+
+You can leave feedback [here](https://forms.gle/RZsweAPy5RhQSP6j7) and ask any questions on the [Taiko Discord](https://discord.gg/taikoxyz)!
\ No newline at end of file
diff --git a/packages/website/pages/docs/guides/_meta.json b/packages/website/pages/docs/guides/_meta.json
index cb98e8f55a4..347669f643f 100644
--- a/packages/website/pages/docs/guides/_meta.json
+++ b/packages/website/pages/docs/guides/_meta.json
@@ -1,18 +1,21 @@
{
- "configure-wallet": {
- "title": "Configure your wallet"
+ "configure-your-wallet": {
+ "title": "👛 Configure your wallet"
},
- "request-from-faucet": {
- "title": "Request from faucet"
+ "receive-tokens": {
+ "title": "💦 Receive tokens"
},
"use-the-bridge": {
- "title": "Use the bridge"
+ "title": "🌉 Use the bridge"
+ },
+ "swap-tokens": {
+ "title": "🔀 Swap tokens"
},
"run-a-node": {
- "title": "Run a Taiko node"
+ "title": "🌐 Run a node"
},
"deploy-a-contract": {
- "title": "Deploy a basic contract"
+ "title": "🧙 Deploy a contract"
},
- "signal-service-tutorial": "Build a dapp with Taiko's signal service"
+ "build-a-dapp": "🛠️ Build a dapp"
}
diff --git a/packages/website/pages/docs/guides/build-a-dapp.mdx b/packages/website/pages/docs/guides/build-a-dapp.mdx
new file mode 100644
index 00000000000..d84eda2df1a
--- /dev/null
+++ b/packages/website/pages/docs/guides/build-a-dapp.mdx
@@ -0,0 +1,8 @@
+This guide will help you build a dapp on Taiko (Askja testnet)! The starter dapp highlights an important feature of Taiko: sending secure cross-chain messages between Taiko and Ethereum. Read more about cross-chain messaging [here](/docs/concepts/bridging).
+
+## Prerequisites
+
+- A curiousity to learn and build 🙃.
+
+## Steps
+1. Visit the [dapp-slaps starter template](https://github.com/d1onys1us/dapp-slaps) to create an Ethereum dapp with one-click.
diff --git a/packages/website/pages/docs/guides/configure-wallet.mdx b/packages/website/pages/docs/guides/configure-wallet.mdx
deleted file mode 100644
index 8425413fe05..00000000000
--- a/packages/website/pages/docs/guides/configure-wallet.mdx
+++ /dev/null
@@ -1,16 +0,0 @@
-import AddEthereumChainButton from "../../../components/AddEthereumChainButton";
-
-These steps will help you connect your wallet to the Taiko A1 testnet. There are two networks to configure your wallet with: **Ethereum A1** and **Taiko A1**.
-
-## Prerequisites
-
-- Have a wallet installed and ready to use. Some examples are MetaMask and Frame. Please use a hot wallet (not a hardware wallet) for this guide, preferably a throwaway wallet.
-
-## Steps
-
-1. Try clicking the buttons below to automatically add the networks to your wallet (using `wallet_addEthereumChain`).
-2. Add the Sepolia testnet by clicking "Add chain" on [https://chainlist.wtf/](https://chainlist.wtf).
-3. Add the Taiko network by clicking the "Add chain" button:
-4. If that doesn't work, manually add the networks to your wallet using the [RPC configuration](/docs/reference/rpc-configuration).
-
-## Troubleshooting
\ No newline at end of file
diff --git a/packages/website/pages/docs/guides/configure-your-wallet.mdx b/packages/website/pages/docs/guides/configure-your-wallet.mdx
new file mode 100644
index 00000000000..7228fa52aa1
--- /dev/null
+++ b/packages/website/pages/docs/guides/configure-your-wallet.mdx
@@ -0,0 +1,22 @@
+import AddEthereumChainButton from "../../../components/AddEthereumChainButton";
+import { Steps } from "nextra-theme-docs";
+
+This guide help you connect your wallet to Taiko (Askja testnet). There are two networks to configure your wallet with: **Ethereum (Sepolia testnet)** and **Taiko (Askja testnet)**.
+
+## Prerequisites
+
+- You have a wallet installed and ready to use. Some examples are MetaMask and Frame. Please use a hot wallet (not a hardware wallet) for this guide, preferably a throwaway wallet.
+
+## Steps
+
+
+ ### Add the Sepolia testnet
+ Visit [https://chainid.network/](https://chainid.network/), search for "Sepolia", and click the "Add Chain" button.
+
+ ### Add the Taiko testnet
+ Visit [https://chainid.network/](https://chainid.network/), search for "Taiko", and click the "Add Chain" button.
+
+
+## Troubleshooting
+### The add chain buttons did not work
+Try to manually add the network to your wallet using the [RPC configuration](/docs/reference/rpc-configuration).
diff --git a/packages/website/pages/docs/guides/deploy-a-contract.md b/packages/website/pages/docs/guides/deploy-a-contract.md
deleted file mode 100644
index 32521862618..00000000000
--- a/packages/website/pages/docs/guides/deploy-a-contract.md
+++ /dev/null
@@ -1,25 +0,0 @@
-These steps will show you how to deploy a smart contract to Taiko A1 using Foundry. Read the [Foundry Book](https://book.getfoundry.sh/getting-started/first-steps) for the latest docs on Foundry.
-
-## Prerequisites
-
-- Have the private key to an account that has some ETH on Taiko A1. This is to pay the small transaction fee for deploying the contract. You can check the following articles if you are unsure how to do this:
-
- - [With MetaMask](https://www.herongyang.com/Ethereum/Ethereum-Account-Public-Private-Key-Example.html)
- - [With OpenSSL](https://gist.github.com/miguelmota/3793b160992b4ea0b616497b8e5aee2f)
- - [With ethereumjs-wallet](https://piyopiyo.medium.com/how-to-generate-ethereum-private-key-and-address-in-local-offline-environment-90294308593c)
-
-## Steps
-
-1. [Install Foundry](https://book.getfoundry.sh/getting-started/installation) (if you haven't already).
-2. Create a project with Foundry, and `cd` into it:
- ```sh
- forge init hello_foundry && cd hello_foundry
- ```
-3. Deploy the contract from your project, located at `src/Counter.sol`. Replace `YOUR_PRIVATE_KEY` with your private key, mentioned in the previous prerequisites section.
- ```sh
- forge create --legacy --rpc-url https://l2rpc.hackathon.taiko.xyz --private-key YOUR_PRIVATE_KEY src/Counter.sol:Counter
- ```
- > Note: The `--legacy` flag is needed because EIP-1559 is currently disabled on Taiko—there are plans to re-enable it in the future.
-4. Paste the address from the output into the [L2 block explorer](https://l2explorer.hackathon.taiko.xyz/) to verify that the contract was deployed.
-
-## Troubleshooting
diff --git a/packages/website/pages/docs/guides/deploy-a-contract.mdx b/packages/website/pages/docs/guides/deploy-a-contract.mdx
new file mode 100644
index 00000000000..370fced4cd1
--- /dev/null
+++ b/packages/website/pages/docs/guides/deploy-a-contract.mdx
@@ -0,0 +1,37 @@
+import { Callout, Steps } from "nextra-theme-docs";
+
+
+ Make sure you are using a test / throwaway wallet, to be safe. Don't ever reveal the private key of your main wallet!
+
+
+This guide will help you deploy a smart contract to Taiko (Askja testnet) using Foundry.
+
+## Prerequisites
+
+- [Foundry](https://book.getfoundry.sh/getting-started/installation) is installed.
+- You have the private key handy to an account that has testnet ETH on Taiko (to pay the transaction fee for deploying the contract).
+ - [Retrieve private key with MetaMask](https://support.metamask.io/hc/en-us/articles/360015289632-How-to-export-an-account-s-private-key#:~:text=On%20the%20account%20page%2C%20click,click%20%E2%80%9CConfirm%E2%80%9D%20to%20proceed.).
+ - [Generate wallet keys with OpenSSL](https://gist.github.com/miguelmota/3793b160992b4ea0b616497b8e5aee2f).
+ - [Generate wallet keys with ethereumjs-wallet](https://piyopiyo.medium.com/how-to-generate-ethereum-private-key-and-address-in-local-offline-environment-90294308593c).
+- Have some testnet ETH on Taiko:
+ - First, [request Sepolia ETH](/guides/receive-tokens) from the faucet.
+ - Then, [use the bridge](/docs/guides/use-the-bridge) to send the testnet ETH to Taiko.
+
+## Steps
+
+
+ ### Create a project with Foundry
+ ```sh
+ forge init hello_foundry && cd hello_foundry
+ ```
+
+ ### Deploy the contract
+ Deploy the contract located at `src/Counter.sol`. Replace `YOUR_PRIVATE_KEY` below with your private key which has some testnet ETH on Taiko.
+ > Note: The `--legacy` flag is needed because EIP-1559 is currently disabled on Taiko—it will be re-enabled in the future.
+ ```sh
+ forge create --legacy --rpc-url https://rpc.a2.taiko.xyz --private-key YOUR_PRIVATE_KEY src/Counter.sol:Counter
+ ```
+
+ ### View your contract
+ Paste the address from the output into the [Taiko block explorer](https://explorer.a2.taiko.xyz) and verify that the contract was deployed.
+
diff --git a/packages/website/pages/docs/guides/receive-tokens.mdx b/packages/website/pages/docs/guides/receive-tokens.mdx
new file mode 100644
index 00000000000..c4807f4053c
--- /dev/null
+++ b/packages/website/pages/docs/guides/receive-tokens.mdx
@@ -0,0 +1,24 @@
+import { Steps } from "nextra-theme-docs";
+
+This guide will help you receive testnet tokens from the faucet(s).
+
+## Prerequisites
+
+- You have an Ethereum wallet address to accept the testnet tokens.
+
+## Steps
+
+
+ ### Receive Sepolia ETH
+ Visit one the faucets to receive ETH on Sepolia:
+ - [https://sepolia-faucet.pk910.de](https://sepolia-faucet.pk910.de/) (recommended)
+ - [https://faucet-sepolia.rockx.com](https://faucet-sepolia.rockx.com/)
+
+ ### Receive HORSE
+ Navigate to [the bridge](https://bridge.a2.taiko.xyz), select HORSE from the dropdown, and click "Faucet".
+
+ 
+
+ ### Receive BLL
+ Repeat the previous step for receiving HORSE, except select "BLL" from the dropdown.
+
diff --git a/packages/website/pages/docs/guides/request-from-faucet.md b/packages/website/pages/docs/guides/request-from-faucet.md
deleted file mode 100644
index 511b17fd26d..00000000000
--- a/packages/website/pages/docs/guides/request-from-faucet.md
+++ /dev/null
@@ -1,17 +0,0 @@
-These steps will help you receive testnet tokens from the faucet.
-
-## Prerequisites
-
-- An Ethereum wallet address to accept the testnet tokens
-
-## Steps
-
-**Request ETH on Sepolia**
-
-1. Visit the recommended [Sepolia faucet](https://sepolia-faucet.pk910.de/) to receive ETH on Sepolia.
-
-**Request ETH on Taiko**
-
-1. Visit the [Taiko faucet](https://l2faucet.hackathon.taiko.xyz/) to receive ETH on Taiko.
-
-## Troubleshooting
diff --git a/packages/website/pages/docs/guides/run-a-node.mdx b/packages/website/pages/docs/guides/run-a-node.mdx
index 0bec6f53819..ca4590148b7 100644
--- a/packages/website/pages/docs/guides/run-a-node.mdx
+++ b/packages/website/pages/docs/guides/run-a-node.mdx
@@ -1,6 +1,6 @@
import { Callout, Steps, Tab, Tabs } from "nextra-theme-docs";
-Taiko's network is fully decentralized and relies on the community to run nodes. This guide will walk you through the process of operating a Taiko node via [simple-taiko-node](https://github.com/taikoxyz/simple-taiko-node), the easiest way to get started operating a Taiko node. With simple-taiko-node you can:
+This guide will walk you through the process of operating a Taiko node via [simple-taiko-node](https://github.com/taikoxyz/simple-taiko-node). You will be able to:
- Run a Taiko node easily from the command line on Windows, Mac, and Linux.
- Run a Taiko node regularly or as a prover.
@@ -10,20 +10,21 @@ Taiko's network is fully decentralized and relies on the community to run nodes.
- [Docker](https://docs.docker.com/engine/install/) is installed and **running**.
- [Git](https://github.com/git-guides/install-git/) is installed.
-- Should have some ETH on the Sepolia network (see [request from faucet](/docs/guides/request-from-faucet)) if running a prover.
-- Because we use a fork of geth, you can consult the [geth minimum requirements](https://github.com/ethereum/go-ethereum#hardware-requirements), with the exception of 1TB of free space, as the Taiko rollup state is much smaller.
- - If you are running a prover, 32GB of RAM and 8 cores is recommended.
+- Consult the [Geth minimum hardware requirements](https://github.com/ethereum/go-ethereum#hardware-requirements), with the exception of 1TB of free space (you won't need much, even ~50GB should suffice).
+- If running a prover:
+ - Must have some ETH on Sepolia (see [receive tokens](/docs/guides/receive-tokens)).
+ - Should have 8/16 core CPU and 32GB of RAM.
## Steps
- ### Clone simple-taiko-node
- ```sh
- git clone https://github.com/taikoxyz/simple-taiko-node.git
- cd simple-taiko-node
- ```
+### Clone simple-taiko-node
+```sh
+git clone https://github.com/taikoxyz/simple-taiko-node.git
+cd simple-taiko-node
+```
-### Configure your node as a prover (optional)
+### Configure your node (required)
First, copy the `.env.sample` to a new file `.env`:
@@ -31,23 +32,39 @@ First, copy the `.env.sample` to a new file `.env`:
cp .env.sample .env
```
-Then, open the `.env` file in your preferred text editor:
+And open the `.env` file in your preferred text editor:
{" "}
+
```sh nano .env ```
```sh vim .env ```
```sh notepad .env ```
-Finally, set the following environment variables to configure your node:
- - Set `ENABLE_PROVER` to `true` (replacing the default `false` with `true`).
- - Set `L1_PROVER_PRIVATE_KEY` to that of your wallet's private key; it will need some balance on Sepolia to prove blocks (if using MetaMask, follow these directions to [retrieve the private key](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-export-an-account-s-private-key)).
+Finally, set the following environment variables:
+
+- L1_ENDPOINT_HTTP
+- L1_ENDPOINT_WS
+
+> **Note:** You can get a Sepolia L1 endpoint from a few places, [Alchemy](https://www.alchemy.com/) is one popular example.
+
+### Enable your node as a prover (optional)
+
+> **NOTE:**: Only the first prover can get the reward, and others will be rejected by the protocol smart contract (with a custom error: L1_ID() or L1_ALREADY_PROVEN()). `💰 Your block proof was accepted` means you are the first prover and receive the reward. `✅ Valid block proven` means a proposed block was successfully proved on TaikoL1.
+
+Set the following environment variables to enable your node as a prover: - Set `ENABLE_PROVER` to `true` (replacing the default `false` with `true`). - Set `L1_PROVER_PRIVATE_KEY` to that of your wallet's private key; it will need some balance on Sepolia to prove blocks (if using MetaMask, follow these directions to [retrieve the private key](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-export-an-account-s-private-key)).
### Start a node
-If this is the first time starting the node, it may take some time to synchronize from the genesis block. You can monitor this progress through logs, or in the local grafana dashboard and see the latest L2 chain status in the [Taiko Alpha-2 L2 block explorer](https://l2explorer.a2.taiko.xyz/).
+ If this is the first time starting the node, it may take some time to
+ synchronize from the genesis block. You can monitor this progress through
+ logs, or in the local grafana dashboard and see the latest L2 chain status in
+ the [Taiko alpha-2 block explorer](https://explorer.a2.taiko.xyz/).
+
+
+ If you ran an alpha-1 testnet node make sure to first run a `docker compose down -v` to remove the old volumes.
Make sure Docker is running and then run the following command to start the node. If you want to run it in the background, please add the `-d` flag (`docker compose up -d`).
@@ -80,7 +97,7 @@ To view the Docker logs, the following commands can be ran:
docker compose logs -f
```
-**View the prover image's logs
+\*\*View the prover image's logs
```sh
docker compose logs -f taiko_client_prover
@@ -98,12 +115,12 @@ docker compose logs -f l2_execution_engine
docker stats
```
-
### View the node's status dashboard
A [Grafana](https://grafana.com/) dashboard with a [Prometheus](https://prometheus.io/) datasource is also included to display the L2 execution engine's real time status. You can visit it at [http://localhost:3000/d/L2ExecutionEngine/l2-execution-engine-overview?orgId=1&refresh=10s](http://localhost:3000/d/L2ExecutionEngine/l2-execution-engine-overview?orgId=1&refresh=10s).
{" "}
+
![image]()
`error="failed to fetch L2 parent block: not found` | You can ignore this error. |
-| `Error starting ...: listen tcp4 0.0.0.0:{port} bind: address already in use` | The port is already in use by another service. You can either shut down the other program or change the port in the .env file. |
+| Error message | Explanation |
+| ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Fatal: Failed to register the Ethereum service: database contains incompatible genesis` | Try to remove the node with `docker compose down -v` and then try again. |
+| `Unhandled trie error: missing trie node` | You can ignore this error, it doesn't affect you and goes away after a while. |
+| `Block batch iterator callback error`
`error="failed to fetch L2 parent block: not found` | You can ignore this error. |
+| `Error starting ...: listen tcp4 0.0.0.0:{port} bind: address already in use` | The port is already in use by another service. You can either shut down the other program or change the port in the .env file. |
| `error parsing HTTP 403 response body: invalid character '<' looking for beginning of value` | Your IP address is being geo-blocked due to sanctions lists. If you're affected, try changing hosting locations or utilize a VPN to change your IP address. |
-| `ERROR: The Compose file './docker-compose.yml' is invalid because: Unsupported config option for some_serivce 'pull_policy'` | Your docker installation is out of date. You need to update your docker compose installation https://docs.docker.com/compose/install/ |
-| `daemon docker is not running`
`Cannot connect to the Docker daemon` | Need to start the Docker Desktop. Search for the Docker Desktop in the Start menu (or Spotlight/Finder for Mac) and run. Then rerun the command in the terminal `docker compose up -d` |
+| `ERROR: The Compose file './docker-compose.yml' is invalid because: Unsupported config option for some_serivce 'pull_policy'` | Your docker installation is out of date. You need to update your docker compose installation: https://docs.docker.com/compose/install/. |
+| `daemon docker is not running`
`Cannot connect to the Docker daemon` | Need to start the Docker before running the commands. |
**Unclean Shutdown**
diff --git a/packages/website/pages/docs/guides/signal-service-tutorial.mdx b/packages/website/pages/docs/guides/signal-service-tutorial.mdx
deleted file mode 100644
index 35611f05c76..00000000000
--- a/packages/website/pages/docs/guides/signal-service-tutorial.mdx
+++ /dev/null
@@ -1,8 +0,0 @@
-One of the most important features of Taiko is the ability to send secure cross-chain messages between Taiko and Ethereum, which this starter dapp will demonstrate. Read more about bridging [here](/docs/concepts/bridging).
-
-## Prerequisites
-
-- A curiousity to learn and build :)
-
-## Steps
-1. Visit the [dapp-slaps starter template](https://github.com/d1onys1us/dapp-slaps) to create an Ethereum dapp with one-click.
diff --git a/packages/website/pages/docs/guides/swap-tokens.mdx b/packages/website/pages/docs/guides/swap-tokens.mdx
new file mode 100644
index 00000000000..a538b162cde
--- /dev/null
+++ b/packages/website/pages/docs/guides/swap-tokens.mdx
@@ -0,0 +1,24 @@
+import { Steps } from "nextra-theme-docs";
+
+This guide will you help you interact with Swap, which is a fork of Uniswap v2 which Taiko has deployed only for testing purposes.
+
+## Prerequisites
+
+- You must have some tokens (at least ETH) on Taiko (Askja testnet). You can [receive some ETH, HORSE, and BLL from the faucets](/docs/guides/receive-tokens) and then [bridge them to Taiko](/docs/guides/use-the-bridge).
+
+## Steps
+
+
+ ### Navigate to Swap
+ Navigate to [https://swap.a2.taiko.xyz](https://swap.a2.taiko.xyz).
+
+ ### Swap some tokens
+ Swap some tokens. You can receive some testnet tokens [here](/docs/guides/receive-tokens).
+
+ 
+
+ ### Provide liquidity
+ Provide liquidity to a pool. You can receive some testnet tokens [here](/docs/guides/receive-tokens).
+
+ 
+
diff --git a/packages/website/pages/docs/guides/use-the-bridge.mdx b/packages/website/pages/docs/guides/use-the-bridge.mdx
index 9cf82c07215..f1aea007d24 100644
--- a/packages/website/pages/docs/guides/use-the-bridge.mdx
+++ b/packages/website/pages/docs/guides/use-the-bridge.mdx
@@ -1,21 +1,27 @@
-import { Callout } from 'nextra-theme-docs'
+import { Callout, Steps } from "nextra-theme-docs";
-
- The bridge is currently not deployed on the Taiko hackathon testnet, but you can build bridges with the Signal Service cross-chain messaging.
+
+ The BLL token should succeed when **minting** from the faucet, and when **sending the bridge message** to Sepolia or Taiko. However, it will fail about 50% of the time when **claiming** on Sepolia—this is intentionally done so we can test the error handling.
-These steps will help you to use the bridge to transfer assets between Ethereum A1 and Taiko A1. All the bridge contracts can be found [here](/docs/reference/contract-addresses).
+
+This guide will help you use the bridge to send tokens between Sepolia and Taiko (Askja testnet). You can read more about how bridging works [here](/docs/concepts/bridging#what-is-the-taiko-bridge).
## Prerequisites
-- Have some ETH or HORSE on either Ethereum A1 or Taiko A1. If you don't have any, you can [request from faucet](/docs/guides/request-from-faucet).
+- A wallet with some testnet ETH on Sepolia and/or Taiko (you can [receive tokens here](/docs/guides/receive-tokens)).
## Steps
-1. Visit the [bridge](https://bridge.a1.taiko.xyz/) and follow through the UI to bridge your tokens.
+
+ ### Visit the bridge
+ Visit the [bridge](https://bridge.a2.taiko.xyz/) and the UI should be intuitive.
-## Troubleshooting
+ ### Bridge tokens from Sepolia to Taiko
+ Try bridging ETH, HORSE, and/or BLL from Sepolia to Taiko. You can also try manually claiming the transfer yourself by clicking the "Claim" button under the "Transactions" tab.
-### Why is my L2 -> L1 transfer taking so long?
+ 
-The transfer from L2 to L1 can take a while because Taiko has a several hours delay in syncing block headers to allow uncle proof generation time, and we need the synced header to match so the Merkle proof of the message being sent on L2 is valid on L1.
+ ### Bridge tokens from Taiko to Sepolia
+ Try bridging ETH, HORSE, and/or BLL from Taiko to Sepolia. You can also try manually claiming the transfer yourself by clicking the "Claim" button under the "Transactions" tab.
+
diff --git a/packages/website/pages/docs/index.md b/packages/website/pages/docs/index.md
deleted file mode 100644
index 1f040b969bf..00000000000
--- a/packages/website/pages/docs/index.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## What is Taiko?
-
-Taiko is a fully decentralized, Ethereum-equivalent ZK-Rollup (a [Type 1 ZK-EVM](https://mirror.xyz/labs.taiko.eth/w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo)). Taiko's full decentralization and Ethereum-equivalence are two big differentiators when compared to other ZK-EVMs.
-
-Taiko is working on the full Ethereum [ZK-EVM circuits](https://github.com/privacy-scaling-explorations/zkevm-circuits) as part of a community effort led by the EF's PSE team.
-
-## Navigating the site
-
-This documentation site is your one-stop shop for all things Taiko:
-
-- **Concepts**: Concepts about how Taiko works
-- **Guides**: Easy to follow guides to use Taiko
-- **Reference**: Quick reference documentation about the network (e.g., contract addresses, protocol configurations)
-- **Resources**: Additional resources for your knowledge
-
-## Resources to get started
-
-Check out these resources to get started learning more about Taiko:
-
-- [Introduction to Taiko](https://mirror.xyz/labs.taiko.eth/oRy3ZZ_4-6IEQcuLCMMlxvdH6E-T3_H7UwYVzGDsgf4)
-- [The Type 1 ZK-EVM](https://mirror.xyz/labs.taiko.eth/w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo)
-- [Whitepaper](https://taikoxyz.github.io/taiko-mono/taiko-whitepaper.pdf)
-- [Contract documentation](/docs/reference/contract-documentation/)
-
-## Contribute
-
-Contributions are very welcome, check out the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md) to get started!
-
-## What does "Taiko" mean?
-
-The word "Taiko" comes from an old Chinese saying 一鼓作气 (Yīgǔzuòqì). The literal meaning of the saying is that the first drum beat arouses courage. The implied meaning of the idiom is to accomplish a task or goal in one intense effort.
-
-Taiko (太鼓) also refers to a "drum" in Japanese. Taiko is the drum that arouses courage and leads to accomplishing goals.
diff --git a/packages/website/pages/docs/index.mdx b/packages/website/pages/docs/index.mdx
new file mode 100644
index 00000000000..73e1b287f54
--- /dev/null
+++ b/packages/website/pages/docs/index.mdx
@@ -0,0 +1,21 @@
+## Welcome to Taiko!
+
+Taiko is a fully decentralized, Ethereum-equivalent ZK-Rollup ([Type 1 ZK-EVM](https://mirror.xyz/labs.taiko.eth/w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo)). Taiko is working on the full Ethereum [ZK-EVM circuits](https://github.com/privacy-scaling-explorations/zkevm-circuits) as part of a community effort led by the EF's PSE team.
+
+## Use the Askja testnet
+
+All the fun tasks can be found under [guides](/docs/guides).
+
+## Contribute to Taiko
+
+Taiko is a fully open source and community driven project, check out the [contributing guide](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md) to get started as a contributor!
+
+## Join the Discord
+
+We're vibing out on Discord, come [join the community](https://discord.gg/taikoxyz)!
+
+## But what does "Taiko" mean?
+
+The word "Taiko" comes from an old Chinese saying 一鼓作气 (Yīgǔzuòqì). The literal meaning of the saying is that the first drum beat arouses courage. The implied meaning of the idiom is to accomplish a task or goal in one intense effort.
+
+Taiko (太鼓) also refers to a "drum" in Japanese. Taiko is the drum that arouses courage and leads to accomplishing goals.
diff --git a/packages/website/pages/docs/reference.mdx b/packages/website/pages/docs/reference.mdx
new file mode 100644
index 00000000000..185d8819892
--- /dev/null
+++ b/packages/website/pages/docs/reference.mdx
@@ -0,0 +1 @@
+Handy reference documentation for Taiko.
diff --git a/packages/website/pages/docs/reference/contract-addresses.md b/packages/website/pages/docs/reference/contract-addresses.md
index 756130b31d8..e672afe77ed 100644
--- a/packages/website/pages/docs/reference/contract-addresses.md
+++ b/packages/website/pages/docs/reference/contract-addresses.md
@@ -1,15 +1,36 @@
-# Hackathon testnet contract addresses
+## Protocol contracts
-**Sepolia (L1)**
+**Sepolia**
-| Contract name | Contract address |
-| ------------- | -------------------------------------------- |
-| TaikoL1 | `0xEdE510d93A3a6C5e8B8Be88F7719716063140197` |
-| SignalService | `0xe40D5bedD2f3d9F288CC12c69463bC43c77488d6` |
+| Contract name | Contract address |
+|----------------|-------------------------------------------------------------------------------------------------------------------------------|
+| AddressManager | [0x6669f7B6DD295233C9F9482b5c7271E0cE5Aac4f](https://sepolia.etherscan.io/address/0x6669f7B6DD295233C9F9482b5c7271E0cE5Aac4f) |
+| Bridge | [0x2aB7C0ab9AB47fcF370d13058BfEE28f2Ec0940c](https://sepolia.etherscan.io/address/0x2aB7C0ab9AB47fcF370d13058BfEE28f2Ec0940c) |
+| SignalService | [0x07130410064Ab5C32486CC36904fb219ae97156F](https://sepolia.etherscan.io/address/0x07130410064Ab5C32486CC36904fb219ae97156F) |
+| TaikoL1 | [0xAC9251ee97Ed8beF31706354310C6b020C35d87b](https://sepolia.etherscan.io/address/0xAC9251ee97Ed8beF31706354310C6b020C35d87b) |
+| TokenVault | [0x4284890d4AcD0bcb017eCE481B96fD4Cb457CAc8](https://sepolia.etherscan.io/address/0x4284890d4AcD0bcb017eCE481B96fD4Cb457CAc8) |
-**Taiko (L2)**
+**Taiko**
-| Contract name | Contract address |
-| ------------- | -------------------------------------------- |
-| TaikoL1 | `0x0000777700000000000000000000000000000001` |
-| SignalService | `0x191E3D5a00d54799D7da6c04d56b19938304c312` |
+| Contract name | Contract address |
+|---------------|--------------------------------------------------------------------------------------------------------------------------------|
+| Bridge | [0x0000777700000000000000000000000000000004](https://explorer.a2.taiko.xyz/address/0x0000777700000000000000000000000000000004) |
+| EtherVault | [0x0000777700000000000000000000000000000003](https://explorer.a2.taiko.xyz/address/0x0000777700000000000000000000000000000003) |
+| SignalService | [0xbB203a6f73F805E44E97dcC0c894eFe0fAf72498](https://explorer.a2.taiko.xyz/address/0xbB203a6f73F805E44E97dcC0c894eFe0fAf72498) |
+| TaikoL2 | [0x0000777700000000000000000000000000000001](https://explorer.a2.taiko.xyz/address/0x0000777700000000000000000000000000000001) |
+| TokenVault | [0x0000777700000000000000000000000000000002](https://explorer.a2.taiko.xyz/address/0x0000777700000000000000000000000000000002) |
+
+## ERC-20 token contracts
+
+**Sepolia**
+| Name | Symbol | Contract address |
+|------------------|--------|-------------------------------------------------------------------------------------------------------------------------------|
+| Bull Token | BLL | [0x5B9fEDd37f0B92E7E282B19cEbCF06F57B77C604](https://sepolia.etherscan.io/address/0x5B9fEDd37f0B92E7E282B19cEbCF06F57B77C604) |
+| Horse Token | HORSE | [0x1E8C104D068F22D351859cdBfE41A697A98E6EA2](https://sepolia.etherscan.io/address/0x1E8C104D068F22D351859cdBfE41A697A98E6EA2) |
+| Test Taiko Token | TTKO | [0xcFB226eE6071aadd9B39460434957FBD4B32Af79](https://sepolia.etherscan.io/address/0xcFB226eE6071aadd9B39460434957FBD4B32Af79) |
+
+**Taiko**
+| Name | Symbol | Contract address |
+|-------------|--------|--------------------------------------------------------------------------------------------------------------------------------|
+| Bull Token | BLL | [0x6048e5ca54c021D39Cd33b63A44980132bcFA66d](https://explorer.a2.taiko.xyz/address/0x6048e5ca54c021D39Cd33b63A44980132bcFA66d) |
+| Horse Token | HORSE | [0xCea5BFE9542eDf828Ebc2ed054CA688f0224796f](https://explorer.a2.taiko.xyz/address/0xCea5BFE9542eDf828Ebc2ed054CA688f0224796f) |
diff --git a/packages/website/pages/docs/reference/contract-documentation.md b/packages/website/pages/docs/reference/contract-documentation.md
index bc9d796ba2f..79ee9357b90 100644
--- a/packages/website/pages/docs/reference/contract-documentation.md
+++ b/packages/website/pages/docs/reference/contract-documentation.md
@@ -1,3 +1 @@
-# Contract documentation
-
-Here you can find the documentation for the Taiko smart contracts.
+Here you will find the documentation for the Taiko smart contracts.
diff --git a/packages/website/pages/docs/reference/contract-documentation/bridge/BridgeCustomErrors.md b/packages/website/pages/docs/reference/contract-documentation/bridge/BridgeCustomErrors.md
new file mode 100644
index 00000000000..52e6a13fb48
--- /dev/null
+++ b/packages/website/pages/docs/reference/contract-documentation/bridge/BridgeCustomErrors.md
@@ -0,0 +1,137 @@
+---
+title: BridgeCustomErrors
+---
+
+## BridgeCustomErrors
+
+### B_CANNOT_RECEIVE
+
+```solidity
+error B_CANNOT_RECEIVE()
+```
+
+### B_DENIED
+
+```solidity
+error B_DENIED()
+```
+
+### B_ERC20_CANNOT_RECEIVE
+
+```solidity
+error B_ERC20_CANNOT_RECEIVE()
+```
+
+### B_ETHER_RELEASED_ALREADY
+
+```solidity
+error B_ETHER_RELEASED_ALREADY()
+```
+
+### B_EV_DO_NOT_BURN
+
+```solidity
+error B_EV_DO_NOT_BURN()
+```
+
+### B_EV_NOT_AUTHORIZED
+
+```solidity
+error B_EV_NOT_AUTHORIZED()
+```
+
+### B_EV_PARAM
+
+```solidity
+error B_EV_PARAM()
+```
+
+### B_FAILED_TRANSFER
+
+```solidity
+error B_FAILED_TRANSFER()
+```
+
+### B_FORBIDDEN
+
+```solidity
+error B_FORBIDDEN()
+```
+
+### B_GAS_LIMIT
+
+```solidity
+error B_GAS_LIMIT()
+```
+
+### B_INCORRECT_VALUE
+
+```solidity
+error B_INCORRECT_VALUE()
+```
+
+### B_INIT_PARAM_ERROR
+
+```solidity
+error B_INIT_PARAM_ERROR()
+```
+
+### B_MSG_HASH_NULL
+
+```solidity
+error B_MSG_HASH_NULL()
+```
+
+### B_MSG_NON_RETRIABLE
+
+```solidity
+error B_MSG_NON_RETRIABLE()
+```
+
+### B_MSG_NOT_FAILED
+
+```solidity
+error B_MSG_NOT_FAILED()
+```
+
+### B_NULL_APP_ADDR
+
+```solidity
+error B_NULL_APP_ADDR()
+```
+
+### B_OWNER_IS_NULL
+
+```solidity
+error B_OWNER_IS_NULL()
+```
+
+### B_SIGNAL_NOT_RECEIVED
+
+```solidity
+error B_SIGNAL_NOT_RECEIVED()
+```
+
+### B_STATUS_MISMTACH
+
+```solidity
+error B_STATUS_MISMTACH()
+```
+
+### B_WRONG_CHAIN_ID
+
+```solidity
+error B_WRONG_CHAIN_ID()
+```
+
+### B_WRONG_TO_ADDRESS
+
+```solidity
+error B_WRONG_TO_ADDRESS()
+```
+
+### B_ZERO_SIGNAL
+
+```solidity
+error B_ZERO_SIGNAL()
+```
diff --git a/packages/website/pages/docs/reference/rpc-configuration.md b/packages/website/pages/docs/reference/rpc-configuration.md
index 24c0ce013d6..5899aa94185 100644
--- a/packages/website/pages/docs/reference/rpc-configuration.md
+++ b/packages/website/pages/docs/reference/rpc-configuration.md
@@ -1,6 +1,4 @@
-# Hackathon testnet RPC configuration
-
-| Network | Chain ID | RPC URL | Symbol | Block Explorer URL |
-| ------- | -------- | --------------------------------- | ------ | -------------------------------------- |
-| Sepolia | 11155111 | https://rpc.sepolia.org | ETH | https://sepolia.etherscan.io/ |
-| Taiko | 167002 | https://l2rpc.hackathon.taiko.xyz | ETH | https://l2explorer.hackathon.taiko.xyz |
+| Network | Chain ID | RPC URL | Symbol | Block Explorer URL |
+|---------|----------|--------------------------|--------|-------------------------------|
+| Sepolia | 11155111 | https://rpc.sepolia.org | ETH | https://sepolia.etherscan.io/ |
+| Taiko | 167004 | https://rpc.a2.taiko.xyz | ETH | https://explorer.a2.taiko.xyz |
diff --git a/packages/website/pages/docs/resources.mdx b/packages/website/pages/docs/resources.mdx
new file mode 100644
index 00000000000..3dfa00d897c
--- /dev/null
+++ b/packages/website/pages/docs/resources.mdx
@@ -0,0 +1 @@
+Useful resources for learning about Taiko.
\ No newline at end of file
diff --git a/packages/website/pages/showcase.mdx b/packages/website/pages/showcase.mdx
index 3eecdd21914..7b76a5c42ef 100644
--- a/packages/website/pages/showcase.mdx
+++ b/packages/website/pages/showcase.mdx
@@ -2,10 +2,11 @@ import { Card, Cards } from 'nextra-theme-docs';
import Image from 'next/image';
import taikoBridge from '../public/images/showcase/bridge-showcase.png';
import orbiter from '../public/images/showcase/orbiter-showcase.png';
+import taikoSwap from '../public/images/showcase/swap-showcase.png';
{Showcase
}
-{Dapps integrated with Taiko ✨
}
+{Dapps deployed on Taiko 🥁
}
{[
@@ -14,6 +15,11 @@ import orbiter from '../public/images/showcase/orbiter-showcase.png';
url: 'https://bridge.a2.taiko.xyz',
image: taikoBridge
},
+ {
+ name: 'Swap',
+ url: 'https://swap.a2.taiko.xyz',
+ image: taikoSwap
+ },
{
name: 'Orbiter',
url: 'https://orbiter.finance',
diff --git a/packages/website/public/images/diagrams/bridging-process-message.png b/packages/website/public/images/diagrams/concepts/bridging/bridging-process-message.png
similarity index 100%
rename from packages/website/public/images/diagrams/bridging-process-message.png
rename to packages/website/public/images/diagrams/concepts/bridging/bridging-process-message.png
diff --git a/packages/website/public/images/diagrams/bridging-send-message.png b/packages/website/public/images/diagrams/concepts/bridging/bridging-send-message.png
similarity index 100%
rename from packages/website/public/images/diagrams/bridging-send-message.png
rename to packages/website/public/images/diagrams/concepts/bridging/bridging-send-message.png
diff --git a/packages/website/public/images/diagrams/concepts/proving-taiko-blocks/proposed.png b/packages/website/public/images/diagrams/concepts/proving-taiko-blocks/proposed.png
new file mode 100644
index 00000000000..65092c36e18
Binary files /dev/null and b/packages/website/public/images/diagrams/concepts/proving-taiko-blocks/proposed.png differ
diff --git a/packages/website/public/images/diagrams/concepts/proving-taiko-blocks/proved.png b/packages/website/public/images/diagrams/concepts/proving-taiko-blocks/proved.png
new file mode 100644
index 00000000000..8bfb400bd59
Binary files /dev/null and b/packages/website/public/images/diagrams/concepts/proving-taiko-blocks/proved.png differ
diff --git a/packages/website/public/images/diagrams/concepts/proving-taiko-blocks/verified.png b/packages/website/public/images/diagrams/concepts/proving-taiko-blocks/verified.png
new file mode 100644
index 00000000000..339fa680802
Binary files /dev/null and b/packages/website/public/images/diagrams/concepts/proving-taiko-blocks/verified.png differ
diff --git a/packages/website/public/images/diagrams/taiko-nodes.png b/packages/website/public/images/diagrams/concepts/taiko-nodes/taiko-nodes.png
similarity index 100%
rename from packages/website/public/images/diagrams/taiko-nodes.png
rename to packages/website/public/images/diagrams/concepts/taiko-nodes/taiko-nodes.png
diff --git a/packages/website/public/images/guides/bridge-claim.png b/packages/website/public/images/guides/bridge-claim.png
new file mode 100644
index 00000000000..7ecbc6bd1b8
Binary files /dev/null and b/packages/website/public/images/guides/bridge-claim.png differ
diff --git a/packages/website/public/images/guides/receive-horse.png b/packages/website/public/images/guides/receive-horse.png
new file mode 100644
index 00000000000..8e84214d839
Binary files /dev/null and b/packages/website/public/images/guides/receive-horse.png differ
diff --git a/packages/website/public/images/guides/swap-liquidity.png b/packages/website/public/images/guides/swap-liquidity.png
new file mode 100644
index 00000000000..c99060417ca
Binary files /dev/null and b/packages/website/public/images/guides/swap-liquidity.png differ
diff --git a/packages/website/public/images/guides/swap-swap.png b/packages/website/public/images/guides/swap-swap.png
new file mode 100644
index 00000000000..b492aa7d695
Binary files /dev/null and b/packages/website/public/images/guides/swap-swap.png differ
diff --git a/packages/website/public/images/showcase/bridge-showcase.png b/packages/website/public/images/showcase/bridge-showcase.png
index cc1a506d08e..ab21f0ed093 100644
Binary files a/packages/website/public/images/showcase/bridge-showcase.png and b/packages/website/public/images/showcase/bridge-showcase.png differ
diff --git a/packages/website/public/images/showcase/orbiter-showcase.png b/packages/website/public/images/showcase/orbiter-showcase.png
index 13f2c653ba4..fc1a6020600 100644
Binary files a/packages/website/public/images/showcase/orbiter-showcase.png and b/packages/website/public/images/showcase/orbiter-showcase.png differ
diff --git a/packages/website/public/images/showcase/swap-showcase.png b/packages/website/public/images/showcase/swap-showcase.png
new file mode 100644
index 00000000000..46f3222e36a
Binary files /dev/null and b/packages/website/public/images/showcase/swap-showcase.png differ
diff --git a/packages/website/theme.config.tsx b/packages/website/theme.config.tsx
index cf31a286d33..be0741009c2 100644
--- a/packages/website/theme.config.tsx
+++ b/packages/website/theme.config.tsx
@@ -7,9 +7,8 @@ export default {
banner: {
key: "banner",
text: (
-
- 📌 The alpha-1 testnet (Snæfellsjökull) has been shut down, with the
- alpha-2 testnet coming soon. Follow us to stay updated →
+
+ 🌋 Askja testnet is here! Learn more →
),
},
@@ -20,7 +19,7 @@ export default {
docsRepositoryBase:
"https://github.com/taikoxyz/taiko-mono/blob/main/packages/website",
editLink: {
- text: "Edit this page on GitHub ↗",
+ text: "Improve this page on GitHub ↗",
},
feedback: {
content: null,
@@ -28,7 +27,6 @@ export default {
footer: {
component: Footer,
},
- gitTimestamp: false,
head: () => {
const { asPath } = useRouter();
const { frontMatter } = useConfig();