diff --git a/README.md b/README.md
index 00ec55a202..fd21430448 100644
--- a/README.md
+++ b/README.md
@@ -63,9 +63,3 @@ yarn serve
```shell
git submodule update --remote arbitrum-sdk
```
-
-### Format content
-Sometimes, your pull request may need to be re-formatted to pass the checks. To be safe, make sure you run the following command (from the `website` directory) before you push your commit:
-```shell
-yarn && yarn format
-```
diff --git a/arbitrum-docs/for-devs/third-party-docs/Particle/particle.mdx b/arbitrum-docs/for-devs/third-party-docs/Particle/particle.mdx
index fec9f30c88..f5a8afd58b 100644
--- a/arbitrum-docs/for-devs/third-party-docs/Particle/particle.mdx
+++ b/arbitrum-docs/for-devs/third-party-docs/Particle/particle.mdx
@@ -6,7 +6,7 @@ sme: TABASCOatw
sidebar_label: 'Particle Network'
---
-import ImageZoomComponent from '@site/src/components/ImageZoom';
+import ImageZoom from '@site/src/components/ImageZoom';
:::info Community member contribution
diff --git a/arbitrum-docs/how-arbitrum-works/timeboost/gentle-introduction.mdx b/arbitrum-docs/how-arbitrum-works/timeboost/gentle-introduction.mdx
index 549334354c..516f968b00 100644
--- a/arbitrum-docs/how-arbitrum-works/timeboost/gentle-introduction.mdx
+++ b/arbitrum-docs/how-arbitrum-works/timeboost/gentle-introduction.mdx
@@ -8,6 +8,8 @@ user_story: As a current or prospective Arbitrum user, I want to understand how
content_type: gentle-introduction
---
+import { FlowChart } from '@site/src/components/InteractiveDiagrams/Timeboost/CentralizedAuction';
+import ImageWithCaption from '@site/src/components/ImageCaptions/';
import ImageZoom from '@site/src/components/ImageZoom';
This introduction will walk you through Arbitrum Timeboost: a novel transaction ordering policy for Arbitrum chains that allows chain owners to capture the Maximal Extractable Value (MEV) on their chain and reduce spam, all while preserving fast block times and protecting users from harmful types of MEV, such as sandwich attacks and front-running.
@@ -17,7 +19,7 @@ Timeboost is the culmination of over a year of research and development by the t
### In a nutshell
- The current "First-Come, First-Serve (FCFS)" ordering policy has many benefits, including a great UX and protection from harmful types of MEV. However, nearly all MEV on the chain is extracted by searchers who invest wastefully in hardware and spamming to win latency races (which negatively strains the network and leads to congestion). Timeboost is a new transaction ordering policy that preserves many of the great benefits of FCFS while unlocking a path for chain owners to capture some of the available MEV on their network and introducing an auction to reduce latency, racing, and, ultimately, spam.
-- Timeboost introduces a few new components to an Arbitrum chain's infrastructure: a sealed-bid second-price auction and a new "express lane" at an Arbitrum chain's sequencer. Valid transactions submitted to the express lane will be sequenced immediately with no delay, while all other transactions submitted to the chain's sequencer will experience a nominal delay (default: 200ms). The auction winner is granted the sole right to control the express lane for pre-defined, temporary intervals. The default block time for Arbitrum chains will continue to be industry-leading at 250ms, even with Timeboost enabled. What will change with Timeboost is that some transactions not in the express lane will be delayed to the next block.
+- Timeboost introduces a few new components to an Arbitrum chain’s infrastructure: a sealed-bid second-price auction and a new "express lane" at an Arbitrum chain’s sequencer. Valid transactions submitted to the express lane will be sequenced immediately with no delay, while all other transactions submitted to the chain’s sequencer will experience a nominal delay (default: 200ms). The auction winner is granted the sole right to control the express lane for pre-defined, temporary intervals. The default block time for Arbitrum chains will continue to be industry-leading at 250ms, even with Timeboost enabled. What will change with Timeboost is that some transactions not in the express lane will be delayed to the next block.
- Timeboost is an optional feature for Arbitrum chains aimed at two types of groups of entities: (1) chain owners and their ecosystems and (2) sophisticated on-chain actors and searchers. Chain owners can use Timeboost to capture additional revenue from the MEV their chain generates already, and sophisticated on-chain actors and searchers will spend their resources on buying rights for the express lane (instead of spending those resources on winning latency races, which otherwise leads to spam and congestion on the network).
- Timeboost will work with both centralized and [decentralized sequencer setups](https://medium.com/@espressosys/espresso-systems-and-offchain-labs-publish-decentralized-timeboost-specification-b29ff20c5db8). The specification for a centralized sequencer is public ([here](https://github.com/OffchainLabs/timeboost-design)) and the [proposal before the Arbitrum DAO](https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/1) allows us to deliver Timeboost to market sooner, rather than waiting until the design with a decentralized sequencer set up and its implementation are complete.
@@ -43,53 +45,51 @@ Timeboost retains most FCFS benefits while addressing FCFS limitations.
#### Timeboost may help reduce spam and congestion on a network
-- By introducing the ability to "purchase a time advantage" through the Timeboost auction, it is expected that rational, profit-seeking actors will spend on auctions _instead of_ investing in hardware or infrastructure to win latency races. This diversion of resources by these actors is expected to reduce FCFS MEV-driven spam on the network.
+- By introducing the ability to “purchase a time advantage” through the Timeboost auction, it is expected that rational, profit-seeking actors will spend on auctions _instead of_ investing in hardware or infrastructure to win latency races. This diversion of resources by these actors is expected to reduce FCFS MEV-driven spam on the network.
## What is Timeboost, and how does it work?
Timeboost is a _transaction ordering policy_. It's a set of rules that the sequencer of an Arbitrum chain is trusted to follow when ordering transactions submitted by users. In the near future, multiple sequencers will be able to enforce those rules with decentralized Timeboost.
-For Arbitrum chains, the sequencer's sole job is to take arriving, valid transactions from users, place them into an order dictated by the transaction ordering policy, and then publish the final sequence to a real-time feed and in compressed batches to the chain's data availability layer. The current transaction ordering policy is FCFS, and Timeboost is a modified FCFS ordering policy.
+For Arbitrum chains, the sequencer’s sole job is to take arriving, valid transactions from users, place them into an order dictated by the transaction ordering policy, and then publish the final sequence to a real-time feed and in compressed batches to the chain’s data availability layer. The current transaction ordering policy is FCFS, and Timeboost is a modified FCFS ordering policy.
Timeboost is implemented using three separate components that work together:
-- **A special "express lane"** which allows valid transactions to be sequenced as soon as the sequencer receives them for a given round.
+- **A special “express lane”** which allows valid transactions to be sequenced as soon as the sequencer receives them for a given round.
- **An off-chain auction** to determine the controller of the express lane for a given round. This auction is managed by an autonomous auctioneer.
- **An auction contract** deployed on the target chain to serve as the canonical source of truth for the auction results and handling of auction proceeds.
-To start, the default duration of a round is 60 seconds. Transactions not in the express lane will be subject to a default 200-millisecond artificial delay to their arrival timestamp before their transaction is sequenced, which means that some non-express lane transactions may get delayed to the next block. It's important to note that the default Arbitrum block time will remain at 250 milliseconds (which can be adjusted to 100 milliseconds if desired). Let's dive into how each of these components works.
+To start, the default duration of a round is 60 seconds. Transactions not in the express lane will be subject to a default 200-millisecond artificial delay to their arrival timestamp before their transaction is sequenced, which means that some non-express lane transactions may get delayed to the next block. It’s important to note that the default Arbitrum block time will remain at 250 milliseconds (which can be adjusted to 100 milliseconds if desired). Let’s dive into how each of these components works.
### The express lane
-The express lane is implemented using a special endpoint on the sequencer, formally titled `timeboost_sendExpressLaneTransaction`. This endpoint is special because transactions submitted to it will be sequenced immediately by the sequencer, hence the name, express lane. The sequencer will only accept valid transaction payloads to this endpoint if they are correctly signed by the current round's express lane controller. Other transactions can still be submitted to the sequencer as normal, but these will be considered non-express lane transactions and will, therefore, have their arrival timestamp delayed by 200 milliseconds. It is important to note that transactions from both the express and non-express lanes are eventually sequenced into a single, ordered stream of transactions for node operators to produce an assertion and later post the data to a data availability layer. The express lane controller does _not_:
+The express lane is implemented using a special endpoint on the sequencer, formally titled `timeboost_sendExpressLaneTransaction`. This endpoint is special because transactions submitted to it will be sequenced immediately by the sequencer, hence the name, express lane. The sequencer will only accept valid transaction payloads to this endpoint if they are correctly signed by the current round’s express lane controller. Other transactions can still be submitted to the sequencer as normal, but these will be considered non-express lane transactions and will, therefore, have their arrival timestamp delayed by 200 milliseconds. It is important to note that transactions from both the express and non-express lanes are eventually sequenced into a single, ordered stream of transactions for node operators to produce an assertion and later post the data to a data availability layer. The express lane controller does _not_:
- Have the right to re-order transactions.
-- Have a guarantee that their transactions will always be first at the "top-of-the-block."
+- Have a guarantee that their transactions will always be first at the “top-of-the-block.”
- Guarantee a profit at all.
The value of the express lane will be the sum of how much MEV the express lane controller predicts they can extract during the upcoming round (i.e., MEV opportunity estimates made before the auction closes) _plus_ the amount of MEV extracted by the express lane controller while they are in control (that they otherwise did not predict). Understanding how the value of the express lane is determined can be useful for chain owners when adjusting to the artificial delay and the time before the auction closes.
### The Timeboost auction
-
-
Control of the express lane in each round (default: 60 seconds) is determined by a per-round auction, which is a sealed-bid, second-price auction. This auction is held to determine the express lane controller for the next round. In other words, the express lane controller was determined at any point in time in the previous auction round. Bids for the auction can be made with any ERC20 token, in any amount, and be collected by any address - at the full discretion of the chain owner.
-The auction for a round has a closing time that is `auctionClosingSeconds` (default: 15) seconds before the beginning of the round. This means that, in the default parameters, parties have 45 seconds to submit bids before the auction will no longer accept bids. In the 15 seconds between when bids are no longer accepted and when the new round begins, the autonomous auctioneer will verify all bids, determine the winner, and make a call to the on-chain auction contract to formally resolve the auction.
+;
+
+The auction for a round has a closing time that is `auctionClosingSeconds` (default: 15) seconds before the beginning of the round. This means that, in the default parameters, parties have 45 seconds to submit bids before the auction will no longer accept bids. In the 15 seconds between when bids are no longer accepted and when the new round begins, the autonomous auctioneer will verify all bids, determine the winner, and make a call to the on-chain auction contract to formally resolve the auction.
### Auction contract
Before placing a bid in the auction, a party must deposit funds into the Auction Contract. Deposits can be made, or funds can be added to an existing deposit at any time. These deposits are fully withdrawable, with some nominal delay (2 rounds or 2 minutes by default), so as not to impact the outcome of an existing round. There is no minimum deposit amount, but there is a starting minimum bid of 0.001 ETH (default amount and token) called the "minimum reserve price". The chain owner sets the minimum reserve price, which can be updated at any time up to 30 seconds (default) before the start of the next round to ensure the auction participants will always know the reserve price at least 30 seconds before they must submit their bids. A reserve price can also be set by the chain owner (or by an address designated by the chain owner) as a way to raise the minimum bid, as the Auction Contract enforces that the reserve price is never less than the minimum reserve price.
-Once the autonomous auctioneer determines an auction winner, the auction contract will deduct the second-highest bid amount from the account of the highest bidder and transfer those funds to a `beneficiary` account designated by the chain owner by default. The `expressLaneControllerAddress` specified in the highest bid will become the express lane controller for the round.
+Once the autonomous auctioneer determines an auction winner, the auction contract will deduct the second-highest bid amount from the account of the highest bidder and transfer those funds to a `beneficiary` account designated by the chain owner by default. The `expressLaneControllerAddress` specified in the highest bid will become the express lane controller for the round.
### Default parameters
@@ -97,7 +97,7 @@ Below are a few of the default Timeboost parameters mentioned earlier. All these
| Parameter name | Description | Recommended default value |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------ |
-| `roundDurationSeconds` | Duration of time that the sequencer will honor the express lane privileges for transactions signed by the current round's express lane controller. | 60 seconds |
+| `roundDurationSeconds` | Duration of time that the sequencer will honor the express lane privileges for transactions signed by the current round’s express lane controller. | 60 seconds |
| `auctionClosingSeconds` | Time before the start of the next round. The autonomous auctioneer will not accept bids during this time interval. | 15 seconds |
| `beneficiary` | Address where proceeds from the Timeboost auction are sent to when `flushBeneficiaryBalance()` gets called on the auction contract. | An address controlled by the chain's owner |
| `_biddingToken` | Address of the token used to make bids in the Timeboost auction. It can be any ERC20 token (assuming the token address chosen does not have fee-on-transfer, rebasing, transfer hooks, or otherwise non-standard ERC20 logic). | WETH |
@@ -107,9 +107,9 @@ Below are a few of the default Timeboost parameters mentioned earlier. All these
## Who is Timeboost for, and how do I use it?
-Timeboost is an optional addition to an Arbitrum chain's infrastructure, meaning that enabling Timeboost is at the discretion of the chain owner and that an Arbitrum chain can fully function normally without Timeboost.
+Timeboost is an optional addition to an Arbitrum chain’s infrastructure, meaning that enabling Timeboost is at the discretion of the chain owner and that an Arbitrum chain can fully function normally without Timeboost.
-When enabled, Timeboost is meant to serve different groups of parties with varying degrees of impact and benefits. Let's go through them below:
+When enabled, Timeboost is meant to serve different groups of parties with varying degrees of impact and benefits. Let’s go through them below:
#### For regular users:
@@ -121,17 +121,17 @@ Timeboost represents a unique way to accrue value to their token and generate re
#### For searchers/arbitrageurs:
-Timeboost adds a unique twist to your existing or prospective MEV strategies that may become more profitable than before. For instance, purchasing the time advantage offered by Timeboost's auction may end up costing _less_ than the costs to invest in hardware and win latency races. Another example is the potential new business model of reselling express lane rights to other parties in time slots or on a granular, per-transaction basis.
+Timeboost adds a unique twist to your existing or prospective MEV strategies that may become more profitable than before. For instance, purchasing the time advantage offered by Timeboost’s auction may end up costing _less_ than the costs to invest in hardware and win latency races. Another example is the potential new business model of reselling express lane rights to other parties in time slots or on a granular, per-transaction basis.
### Special note on Timeboost for chain owners
As with many new features and upgrades to Arbitrum Nitro, Timeboost is an optional feature that chain owners may choose to deploy and customize however they see fit. Deploying and enabling/disabling Timeboost on a live Arbitrum chain will not halt or impact the chain but will instead influence the chain's transaction ordering policy. An Arbitrum chain will, by default, fall back to FCFS if Timeboost is deployed but disabled or if there is no express lane controller for a given round.
-It is recommended that Arbitrum teams holistically assess the applicability and use cases of Timeboost for their chain before deploying and enabling Timeboost. This is because some Arbitrum chains may not have that much MEV (e.g., arbitrage) to begin with. Furthermore, we recommend that Arbitrum chains start with the default parameters recommended by Offchain Labs and closely monitor the results and impacts on your chain's ecosystem over time before considering adjusting any of the parameters.
+It is recommended that Arbitrum teams holistically assess the applicability and use cases of Timeboost for their chain before deploying and enabling Timeboost. This is because some Arbitrum chains may not have that much MEV (e.g., arbitrage) to begin with. Furthermore, we recommend that Arbitrum chains start with the default parameters recommended by Offchain Labs and closely monitor the results and impacts on your chain’s ecosystem over time before considering adjusting any of the parameters.
### Wen mainnet?
-Timeboost's auction contract has completed a third-party audit and is rapidly approaching production readiness. Specifically for Arbitrum One and Arbitrum Nova, a [temperature check vote on Snapshot](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0xffe9bb38228fdaf3d121140856fd2d51c2ca7f8e0d1021c07e791cebb541129a) has already passed and the AIP will move towards an on-chain Tally vote next hopefully before the end of Q1 2025.
+Timeboost’s auction contract has completed a third-party audit and is rapidly approaching production readiness. Specifically for Arbitrum One and Arbitrum Nova, a [temperature check vote on Snapshot](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0xffe9bb38228fdaf3d121140856fd2d51c2ca7f8e0d1021c07e791cebb541129a) has already passed and the AIP will move towards an on-chain Tally vote next hopefully before the end of Q1 2025.
In the meantime, please read the following resources to learn more about Timeboost:
diff --git a/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/fast-withdrawals.mdx b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/fast-withdrawals.mdx
new file mode 100644
index 0000000000..3e0414932c
--- /dev/null
+++ b/arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/fast-withdrawals.mdx
@@ -0,0 +1,202 @@
+---
+title: 'Enable fast withdrawals on your Orbit chain'
+sidebar_label: 'Enable fast withdrawals'
+description: 'Learn to deploy Fast Withdrawals'
+author: coopermidroni, tucksondev
+sme: tucksondev
+user_story: As a current or prospective Orbit chain owner, I need to understand how to integrate with the Fast Withdrawal feature.
+content_type: get-started
+---
+
+Optimistic Rollups must sustain a multi-day challenge period to allow time for fraud proofs. This delays finality for users and dApps, resulting in multi-day withdrawal times and cross-chain communication delays.
+
+Fast withdrawals is a new configuration allowing Orbit chains to achieve fast finality. When an Orbit chain operates on Fast Withdrawals, its transactions will be processed by a committee of validators. Transactions reaching a unanimous vote across the committee will be immediately confirmed.
+
+This will allow:
+
+- Setting up a withdrawal frequency of any time period (up to 15 minutes)
+- Users' withdrawals confirmation on the parent chain at frequencies up to ~15 minutes
+- Cross-chain dApps to read the finalized state at the same rate as the fast withdrawal frequency
+
+## Recommended configuration
+
+While any Orbit chain can adopt Fast Withdrawals, we only _recommend_ that fast withdrawals be adopted by AnyTrust chains with a minimum validator and DAC member requirement. We explain both these recommendations below:
+
+### Fast withdrawals for AnyTrust chains
+
+As AnyTrust chains are an optimum (an optimistic rollup using a separate data availability layer), AnyTrust chains are already placing a trust assumption on their Data Availability Committee (DAC) to provide the data needed for fraud proofs and recreating the chain.
+
+The optimal setup for an AnyTrust chain is to have all DAC members _also_ run validators as part of the fast withdrawals committee. This will leverage the existing trust assumption placed on the DAC operators such that **enabling fast withdrawals does not add any new trusted parties.**
+
+It is possible for an Orbit Rollup to adopt fast withdrawals. However, it would technically no longer be a Rollup as the minimum trust assumption will shift to the trust placed in the Fast Confirmations committee.
+
+### Minimum validator and DAC nodes
+
+We recommend that any Fast Withdrawals-enabled chain have at least three DAC members and three validators acting in the fast withdrawals committee. Given that fast withdrawals will enable confirmation of new Rollup state much faster than the usual 6.4-day challenge period (15 minutes for L2s and 15 seconds for L3s), it becomes even more important to have additional parties involved in validation to further reduce trust assumptions. This requirement can be be met with three total operators, who each run a single DAS node and a single validator.
+
+## Technical lower bound for fast withdrawals
+
+Once fast withdrawals is enabled, the committee will confirm transactions at the configured frequency. However, a higher network load can cause the fast withdrawals committee to experience slight delays from the configured rate.
+
+- For low-to-medium activity chains (< 1 Mgas/s), 15 seconds is considered to be the sustained lower bound for Fast Withdrawals.
+- For chains with higher throughput (>1 Mgas/s), the practical lower bound for fast withdrawals is between 1-2 minutes.
+
+Chain owners and operators should be aware that the fast withdrawals committee may take longer to confirm new assertions under conditions with greater network load. This behavior is to be expected and does not interfere with the security or trust model of the fast withdrawals committee.
+
+## Practical lower bounds concerning parent chain finality
+
+While a fast withdrawals-enabled chain can be configured to finality in as little as 15 seconds, there are externalities on the parent chain and from cross-chain messaging layers that must be considered.
+
+For an Ethereum-based Layer-2, we recommend that the fast withdrawal frequency remain above 12.8 minutes, which is the time for Ethereum to achieve finality. For non-Ethereum L1s, we similarly recommend staying above the accepted finality threshold specific to that L1.
+
+For an Arbitrum One-based Layer-3, there are three tiers of finality to consider:
+
+1. Soft finality from the sequencer's confirmation of transaction inclusion (~250ms)
+2. Safe finality from batch inclusion after Arbitrum One's assertion is included in an Ethereum block.
+3. Hard finality after the Ethereum block containing Arbitrum One's batch is finalized on Ethereum (~15 minutes)
+
+Layer-3 Orbit chains can make their own determination about what level of finality to accept. We consider it safe to rely on soft finality, which would practically enable an Orbit chain to configure fast withdrawals down to 15 seconds.
+
+## Adoption instructions (example script)
+
+To enable the fast withdrawals feature, there are three actions to take:
+
+1. Make sure the chain is using nitro-contracts v2.1.0 or above
+2. Activate the fast withdrawals feature
+3. Upgrade the node software to nitro v3.1.2 or above
+
+### Upgrading to nitro-contracts v2.1.0
+
+As mentioned above, the fast withdrawals feature is available for chains that are using nitro-contracts v2.1.0 or above, especially the `RollupAdminLogic` and the `RollupUserLogic` contracts. You can check what nitro-contracts version your chain is using by running the [orbit versioner script](https://github.com/OffchainLabs/orbit-actions/blob/main/README.md#check-version-and-upgrade-path).
+
+If your chain is not running with nitro-contracts v2.1.0 or above, you’ll need to perform an upgrade to enable this version. The [orbit versioner script](https://github.com/OffchainLabs/orbit-actions/blob/main/README.md#check-version-and-upgrade-path) will provide the upgrade paths needed to reach v2.1.0, but basically:
+
+- If the chain is running nitro-contracts v1.1.x, you need to [upgrade first to v1.2.1](https://github.com/OffchainLabs/orbit-actions/blob/main/scripts/foundry/contract-upgrades/1.2.1/README.md).
+- If the chain is running nitro-contracts v1.2.1, you need to [upgrade to v2.1.0](https://github.com/OffchainLabs/orbit-actions/blob/main/scripts/foundry/contract-upgrades/2.1.0/README.md).
+
+Upgrading to the new nitro-contracts version also requires updating the node software. For v2.1.0, validator nodes and the batch poster node should run [nitro v3.1.2](https://github.com/OffchainLabs/nitro/releases/tag/v3.1.2) or above.
+
+Suppose you’re upgrading your nitro-contracts from v1.2.1 to v2.1.0 and using the standard WASM module root (without customizations). In that case, there are [action contracts available in the supported chains](https://github.com/OffchainLabs/orbit-actions/blob/main/scripts/foundry/contract-upgrades/2.1.0/README.md#deployed-instances). If you’re using a customized nitro software, with a different WASM module root, you can still deploy the action contract referencing your modified WASM module root (pre and post upgrade).
+
+### Activating fast withdrawals
+
+Once the chain runs nitro-contracts v2.1.0 or above, the new fast withdrawal parameters will be available in the `RollupAdminLogic` and the `RollupUserLogic` contracts.
+
+Both the Orbit SDK and the Orbit actions repository provide configurable scripts to activate and configure fast withdrawals on an AnyTrust chain. You can use either of those to activate the feature. Both scripts perform the same actions.
+
+
+
+**Orbit SDK script**
+
+The Orbit SDK provides an [example script](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/setup-fast-withdrawal) to set up a fast withdrawal committee by performing the following operations:
+
+1. Create a new n/n Safe wallet with the specified validators as signers
+2. Add the specified validators to the Rollup validators allowlist
+3. Set the new Safe wallet as the `anytrustFastConfirmer` in the Rollup contract
+4. Set the new `minimumAssertionPeriod` if needed
+5. Show how to configure the batch poster and validator nodes
+
+To configure the script, you need to specify the following environment variables:
+
+| Variable Name | Description |
+| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `CHAIN_OWNER_PRIVATE_KEY` | Private key of the account with executor privileges in the UpgradeExecutor admin contract for the chain. It will be the deployer of the multi-sig Safe wallet. |
+| `PARENT_CHAIN_ID` | ChainId of the parent chain. |
+| `ROLLUP_ADDRESS` | Address of the Rollup contract. |
+| `FC_VALIDATORS` | Array of fast-withdrawal validators. They will be added as signers to the multisig Safe wallet and to the Rollup's validator allowlist. It is recommended that these are DAC members of the AnyTrust chain. |
+| `MINIMUM_ASSERTION_PERIOD` | Optional parameter that defaults to 75 blocks (~15 minutes). Minimum number of blocks that have to pass in between assertions (measured in L1 blocks). |
+
+Finally, follow these steps to execute the script (from the `examples/setup-fast-withdrawal` folder):
+
+1. Install dependencies
+
+```shell
+yarn install
+```
+
+2. Create a .env file and add the env vars
+
+```shell
+cp .env.example .env
+```
+
+3. Run the script
+
+```shell
+yarn run dev
+```
+
+**Orbit actions script**
+
+The Orbit actions repository also provides an [action script](https://github.com/OffchainLabs/orbit-actions/blob/main/scripts/foundry/fast-confirm/README.md) to activate fast withdrawals by performing the following operations:
+
+1. Make sure the "Validate fast confirmation" has not been enabled yet
+2. Create a Safe contract for the fast confirmation committee
+3. Set the Safe contract as the fast confirmer on the Rollup
+4. Set the Safe contract as a validator on the Rollup
+5. Set `setMinimumAssertionPeriod` to 1 block to allow more frequent assertion
+
+To configure the action script, you need to specify the following environment variables:
+
+| Variable Name | Description |
+| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `UPGRADE_ACTION_ADDRESS` | Address of the upgrade action to execute. A standard version is deployed in all [supported chains](https://github.com/OffchainLabs/orbit-actions/blob/main/scripts/foundry/fast-confirm/README.md#deployed-instances). If you need to deploy your own action, execute the first step of [this process](https://github.com/OffchainLabs/orbit-actions/blob/main/scripts/foundry/fast-confirm/README.md#how-to-use-it). |
+| `PARENT_UPGRADE_EXECUTOR_ADDRESS` | Private key of the account with executor privileges in the UpgradeExecutor admin contract on the parent chain. It will be the deployer of the multi-sig Safe wallet. |
+| `PARENT_CHAIN_RPC` | RPC endpoint of the parent chain. |
+| `ROLLUP` | Address of the Rollup contract. |
+| `FAST_CONFIRM_COMMITTEE` | Comma-separated list of fast-withdrawal validators. They must be allowlisted validators in the Rollup contract. They will be added as signers to the multisig Safe wallet. It is recommended that these are DAC members of the AnyTrust chain. |
+
+Finally, follow these steps to execute the script (from the `scripts/foundry/fast-confirm` folder):
+
+1. Install dependencies
+
+```shell
+yarn install
+```
+
+2. Create a .env file and add the env vars
+
+```shell
+cp .env.example .env
+```
+
+3. Execute the action. The upgrade can be executed using `cast` CLI command ([cast is a part of the Foundry tools](https://book.getfoundry.sh/cast/)), using the owner account (the one with executor rights on parent chain `UpgradeExecutor`) to send the transaction:
+
+```shell
+(export $(cat .env | xargs) && cast send $PARENT_UPGRADE_EXECUTOR_ADDRESS "execute(address, bytes)" $UPGRADE_ACTION_ADDRESS $(cast calldata "perform(address, address[])" $ROLLUP \[$FAST_CONFIRM_COMMITTEE\]) --rpc-url $PARENT_CHAIN_RPC --account EXECUTOR)
+# use --account XXX / --private-key XXX / --interactive / --ledger to set the account to send the transaction from
+```
+
+**NOTE:** If you have a multisig as executor, you can use the following command to create the payload for calling into the `PARENT_UPGRADE_EXECUTOR`:
+
+```shell
+(export $(cat .env | xargs) && cast calldata "execute(address, bytes)" $UPGRADE_ACTION_ADDRESS $(cast calldata "perform(address, address[])" $ROLLUP \[$FAST_CONFIRM_COMMITTEE\]))
+```
+
+### Configure fast withdrawal on nitro v3.1.2 or above
+
+To be able to use Fast Withdrawal on your chain, the batch poster and the validators of the chain need to be running [nitro v3.1.2](https://github.com/OffchainLabs/nitro/releases/tag/v3.1.2) or above.
+
+The following parameters need to be configured in those nodes.
+
+**Batch poster**
+
+| Option | Description |
+| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `--node.batch-poster.max-delay=0h15m0s` | Since batches need to be posted so validators can create and confirm assertions, the maximum delay should be set to an amount close to the `minimumAssertionPeriod` defined in the Rollup contract. Modify `0h15m0s` to the configured value. |
+
+**Validators**
+
+| Option | Description |
+| ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `--node.staker.enable-fast-confirmation=true` | Enables fast withdrawals in the validator node |
+| `--node.staker.make-assertion-interval=0h15m0s` | Since assertions need to be created for them to be confirmed, the minimum interval to create these assertions should be set to an amount close to the `minimumAssertionPeriod` defined in the Rollup contract. Modify `0h15m0s` to the configured value. |
+
+:::note
+
+Immediately after configuring fast withdrawals - your chain may not be operating fully at speed yet. This is because the validators have to work through the backlog of assertions which were not yet confirmed. You will see a series of NodeCreated and NodeConfirmed events. Once the backlog has been processed, your chain should operate fully at speed.
+
+:::
diff --git a/package-lock.json b/package-lock.json
new file mode 100644
index 0000000000..3c0cfbb0b6
--- /dev/null
+++ b/package-lock.json
@@ -0,0 +1,6 @@
+{
+ "name": "arbitrum-docs",
+ "lockfileVersion": 3,
+ "requires": true,
+ "packages": {}
+}
diff --git a/stylus-by-example b/stylus-by-example
index a4ea27d6d6..fc496b15f8 160000
--- a/stylus-by-example
+++ b/stylus-by-example
@@ -1 +1 @@
-Subproject commit a4ea27d6d6268d506e22e3c505d088763d03239f
+Subproject commit fc496b15f89b5e4f3cb0a3a53f2889f6164b8aaf
diff --git a/website/archive/bold/assets/9Pr_Image_1.png b/website/archive/bold/assets/9Pr_Image_1.png
deleted file mode 100644
index 2d4e114bc9..0000000000
Binary files a/website/archive/bold/assets/9Pr_Image_1.png and /dev/null differ
diff --git a/website/archive/bold/assets/BnF_Image_3.png b/website/archive/bold/assets/BnF_Image_3.png
deleted file mode 100644
index 06eb4a6975..0000000000
Binary files a/website/archive/bold/assets/BnF_Image_3.png and /dev/null differ
diff --git a/website/archive/bold/assets/CRA_Image_4.png b/website/archive/bold/assets/CRA_Image_4.png
deleted file mode 100644
index 3f85ca7f7a..0000000000
Binary files a/website/archive/bold/assets/CRA_Image_4.png and /dev/null differ
diff --git a/website/archive/bold/assets/csI_Image_2.png b/website/archive/bold/assets/csI_Image_2.png
deleted file mode 100644
index 1ec2695c33..0000000000
Binary files a/website/archive/bold/assets/csI_Image_2.png and /dev/null differ
diff --git a/website/archive/build-decentralized-apps/metamask-connect-to-arb-sepolia-2025-01-12.gif b/website/archive/build-decentralized-apps/metamask-connect-to-arb-sepolia-2025-01-12.gif
deleted file mode 100644
index b472952783..0000000000
Binary files a/website/archive/build-decentralized-apps/metamask-connect-to-arb-sepolia-2025-01-12.gif and /dev/null differ
diff --git a/website/archive/build-decentralized-apps/metamask-quickstart-localhost.png b/website/archive/build-decentralized-apps/metamask-quickstart-localhost.png
deleted file mode 100644
index 1fdaef7111..0000000000
Binary files a/website/archive/build-decentralized-apps/metamask-quickstart-localhost.png and /dev/null differ
diff --git a/website/archive/build-decentralized-apps/quickstart-localhost-metamask.png b/website/archive/build-decentralized-apps/quickstart-localhost-metamask.png
deleted file mode 100644
index 1fdaef7111..0000000000
Binary files a/website/archive/build-decentralized-apps/quickstart-localhost-metamask.png and /dev/null differ
diff --git a/website/archive/build-decentralized-apps/remix-metamask-deploy-to-anvil-2025-01-13.gif b/website/archive/build-decentralized-apps/remix-metamask-deploy-to-anvil-2025-01-13.gif
deleted file mode 100644
index 4deeb31b70..0000000000
Binary files a/website/archive/build-decentralized-apps/remix-metamask-deploy-to-anvil-2025-01-13.gif and /dev/null differ
diff --git a/website/archive/how-arbitrum-works/assertionTree.png b/website/archive/how-arbitrum-works/assertionTree.png
deleted file mode 100644
index cbed9fdf50..0000000000
Binary files a/website/archive/how-arbitrum-works/assertionTree.png and /dev/null differ
diff --git a/website/archive/how-arbitrum-works/seq-then-exec.png b/website/archive/how-arbitrum-works/seq-then-exec.png
deleted file mode 100644
index 4e043c12ae..0000000000
Binary files a/website/archive/how-arbitrum-works/seq-then-exec.png and /dev/null differ
diff --git a/website/archive/orbit/assets/orbit_bridge.png b/website/archive/orbit/assets/orbit_bridge.png
deleted file mode 100644
index 133de0d5f1..0000000000
Binary files a/website/archive/orbit/assets/orbit_bridge.png and /dev/null differ
diff --git a/website/archive/stylus/assets/cargo-stylus.png b/website/archive/stylus/assets/cargo-stylus.png
deleted file mode 100644
index f96d856731..0000000000
Binary files a/website/archive/stylus/assets/cargo-stylus.png and /dev/null differ
diff --git a/website/archive/stylus/assets/stylus-wallet.png b/website/archive/stylus/assets/stylus-wallet.png
deleted file mode 100644
index 319a3b2bc3..0000000000
Binary files a/website/archive/stylus/assets/stylus-wallet.png and /dev/null differ
diff --git a/website/package.json b/website/package.json
index aa61f75710..5d0ba6b766 100644
--- a/website/package.json
+++ b/website/package.json
@@ -28,13 +28,17 @@
"dependencies": {
"@arbitrum/sdk": "^3.0.0",
"@cmfcmf/docusaurus-search-local": "^0.11.0",
+ "@mdx-js/react": "^3.0.0",
"@docusaurus/core": "^3.6.3",
"@docusaurus/preset-classic": "^3.6.3",
"@docusaurus/theme-live-codeblock": "^3.6.3",
"@docusaurus/theme-mermaid": "^3.6.3",
- "@radix-ui/react-dialog": "^1.1.6",
- "@react-spring/web": "^9.7.5",
- "@types/styled-components": "^5.1.34",
+ "@radix-ui/react-dialog": "^1.0.5",
+ "@react-spring/web": "^9.7.3",
+ "@types/mdx": "^2.0.11",
+ "@types/prismjs": "^1.26.5",
+ "@types/react": "^18.2.55",
+ "@types/react-syntax-highlighter": "^15.5.13",
"classnames": "^2.5.1",
"clsx": "^1.2.1",
"docusaurus-lunr-search": "^3.3.2",
@@ -45,22 +49,26 @@
"posthog-docusaurus": "^2.0.0",
"posthog-js": "^1.219.6",
"prism-react-renderer": "^1.3.5",
+ "prismjs": "^1.29.0",
"react": "^18.2.0",
"react-dom": "^18.2.0",
+ "react-syntax-highlighter": "^15.6.1",
"sass": "^1.66.1",
- "styled-components": "^6.1.15",
"tippy.js": "^6.3.7",
"trim": "0.0.3"
},
"devDependencies": {
"@docusaurus/module-type-aliases": "^3.3.2",
"@offchainlabs/prettier-config": "0.2.1",
+ "@stitches/react": "^1.2.8",
"@tsconfig/docusaurus": "^2.0.3",
"@types/node": "^22.10.10",
+ "@types/react": "^19.0.10",
"docusaurus-plugin-typedoc": "^1.0.1",
"husky": "^9.1.7",
"markdown-link-extractor": "^3.1.0",
"prettier": "^2.8.3",
+ "styled-components": "^6.1.15",
"ts-node": "^10.9.1",
"typedoc": "^0.25.13",
"typedoc-plugin-frontmatter": "^1.0.0",
diff --git a/website/src/components/InteractiveDiagrams/Timeboost/CentralizedAuction/ButtonComponent.jsx b/website/src/components/InteractiveDiagrams/Timeboost/CentralizedAuction/ButtonComponent.jsx
new file mode 100644
index 0000000000..891c43c553
--- /dev/null
+++ b/website/src/components/InteractiveDiagrams/Timeboost/CentralizedAuction/ButtonComponent.jsx
@@ -0,0 +1,48 @@
+import * as React from 'react';
+
+const ButtonComponent = ({ x, y, width, height }) => {
+ const [isHovered, setIsHovered] = React.useState(false);
+
+ return (
+
+ );
+};
+
+export default ButtonComponent;
diff --git a/website/src/components/InteractiveDiagrams/Timeboost/CentralizedAuction/Modal.tsx b/website/src/components/InteractiveDiagrams/Timeboost/CentralizedAuction/Modal.tsx
new file mode 100644
index 0000000000..c48a11b2a7
--- /dev/null
+++ b/website/src/components/InteractiveDiagrams/Timeboost/CentralizedAuction/Modal.tsx
@@ -0,0 +1,157 @@
+import React, { useState, useEffect } from 'react';
+import { useTransition, animated } from '@react-spring/web';
+import * as Dialog from '@radix-ui/react-dialog';
+import step1Content from './modal-centralized-auction-step-1.mdx';
+import step2Content from './modal-centralized-auction-step-2.mdx';
+import step3Content from './modal-centralized-auction-step-3.mdx';
+import step4Content from './modal-centralized-auction-step-4.mdx';
+import step5Content from './modal-centralized-auction-step-5.mdx';
+import { createPortal } from 'react-dom';
+import { NumberComponent } from './NumberComponent';
+import { MDXProvider } from '@mdx-js/react';
+import type { MDXComponents } from '@mdx-js/react/lib';
+import { PrismLight as SyntaxHighlighter } from 'react-syntax-highlighter';
+import { oneDark, oneLight } from 'react-syntax-highlighter/dist/cjs/styles/prism';
+import javascript from 'react-syntax-highlighter/dist/cjs/languages/prism/javascript';
+import solidity from 'react-syntax-highlighter/dist/cjs/languages/prism/solidity';
+import { useColorMode } from '@docusaurus/theme-common';
+
+// Define the CodeBlock interface
+interface CodeBlock {
+ language: string;
+ code: string;
+}
+
+SyntaxHighlighter.registerLanguage('javascript', javascript);
+SyntaxHighlighter.registerLanguage('solidity', solidity);
+
+const components = {
+ h1: ({ children }) =>