diff --git a/docs/launch-arbitrum-chain/overview/introduction.mdx b/docs/launch-arbitrum-chain/overview/introduction.mdx index 1b4da8c4e3..d228db80bb 100644 --- a/docs/launch-arbitrum-chain/overview/introduction.mdx +++ b/docs/launch-arbitrum-chain/overview/introduction.mdx @@ -8,48 +8,166 @@ target_audience: technical decision-makers, people familiar with web3 who will d sidebar_position: 1 --- -This document is for developers and decision-makers who want to learn more about **Arbitrum chains**, a product offering that lets you create your own Arbitrum chains. +An Arbitrum chain gives you the flexibility and control enterprises actually want—without the burden of running your own Layer 1. Instead of bootstrapping and subsidizing a validator set (a fixed cost that runs into the billions annually across major L1s), your chain anchors its security and finality to Ethereum's nearly 1 million validators and $78B in staked ETH, turning security into a variable, usage-based expense. -In the programmable economy, markets, transactions, and business processes run in software. Arbitrum provides the infrastructure for those systems to execute with configurable rules and Ethereum settlement. +That economic model is the core reason to choose Arbitrum: your business captures the fee revenue and priority-access value that L1s hand off to validators, achieving 90–98% operating margins because costs scale with usage rather than perpetual subsidies. You also control the economics directly—custom gas tokens, fee policy, and revenue capture—while getting institution-grade settlement: sub-second soft finality for a responsive user experience, configurable hard finality on Ethereum in minutes, and native withdrawals in as little as 15 minutes, backed by a clean, externally legible counterparty-risk story for your risk, audit, and compliance stakeholders. -If you'd prefer to learn by doing, see the [Chain SDK Rollup creation example](https://github.com/OffchainLabs/arbitrum-chain-sdk/tree/main/examples/create-rollup-eth) for step-by-step instructions that walk you through how to use `chain-sdk` to configure and launch your own Arbitrum chain. +Beyond economics, an Arbitrum chain lets you launch fast and customize deeply while offloading the operational complexity of running blockchain infrastructure. You get day-one configuration over high, fully tunable throughput and block times (as low as 100ms), data availability (Rollup, AnyTrust, or external DA), sequencing and MEV rules, KYC/AML and permissioning, privacy, precompiles, governance, and multi-prover settlement—and you automatically inherit every future Ethereum and Arbitrum upgrade, including Stylus, without custom engineering. -## In a nutshell - -Arbitrum chains are dedicated chains built with Arbitrum technology. Teams can configure execution, fee models, governance, data availability, validation, and other chain parameters for their application or business requirements. +Critically, your chain isn't siloed: it plugs directly into Ethereum's deep liquidity and the Arbitrum ecosystem (Arbitrum One alone secures over $16B with 1,000+ apps and millions of users). And you can de-risk your go-to-market with a phased "launch-and-migrate" path—prove your product on the shared, liquid Arbitrum One, then graduate to your own dedicated Arbitrum chain as a seamless continuation on the same stack, not a costly replatforming. -## What's an Arbitrum chain? +## Customization + +### Speed and finality + +Set confirmation speed and settlement behavior for products where timing and certainty matter—payments, trading, treasury, and internal asset movement. + +| Feature | Your benefit | User benefit | Guide | +| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | +| Tune block time | You own the speed-versus-cost tradeoff. Faster blocks let you position the chain as a premium, low-latency venue (trading, gaming, payments) without waiting on a third party to change infrastructure. | Near-instant confirmations make the app feel like a familiar web experience rather than a slow onchain one, reducing the “did my transaction go through?” hesitation. | [Configure chain finality](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/sequencer/chain-finality) | +| Configure delayed inbox and finality for deposits/withdrawals | You match certainty guarantees to your actual risk profile instead of over-provisioning, so you avoid paying for stronger finality than your product needs. | Predictable, well-defined settlement means users know exactly when funds and actions are final—important for anyone moving real value. | [Configure chain finality](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/sequencer/chain-finality) | +| Enable fast withdrawals to reduce withdrawal finality time | Fewer support tickets and complaints about locked-up capital, and a more competitive bridging story when users compare your chain to alternatives. | Users get their funds in minutes instead of waiting the full challenge window, dramatically lowering the friction of exiting the chain. | [Fast withdrawals](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/validation/fast-withdrawals) | + +The 100ms figure is an optional lower bound on block time, not the default. Most chains run at the 250ms default; 100ms is available when you opt into it. + +### Transaction pricing model + +Align costs with your business model, including the option to use a custom gas token that fits customer experience, treasury strategy, or internal accounting needs. + +| Feature | Your benefit | User benefit | Guide | +| ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Use a custom ERC-20 as the native gas token | You can drive utility to your own token, align fee revenue with your treasury strategy, and simplify internal accounting by denominating gas in the unit you already track. | Users pay fees in a familiar or branded token rather than acquiring a separate asset, removing a common onboarding hurdle. | - [Custom gas token (Rollup)](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/costs/custom-gas-token-rollup)
- [Custom gas token (AnyTrust)](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/costs/custom-gas-token-anytrust) | +| Manage the fee parameters that govern what uses pay and fee distribution | Direct control over cost recovery and revenue, so you can tune the chain's economics to be self-sustaining or subsidized as your business model requires. | Transparent, deliberately set fees rather than opaque or volatile costs, which builds trust in the pricing. | [Fee management](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/costs/fee-management) | +| Configure native mint/burn behavior for the gas token, and tune dynamic pricing | Automating supply and fee handling protects your margins during demand swings and reduces manual treasury operations. | More stable, predictable costs even when the network is busy, so users aren't surprised by fee spikes. | - [Native mint and burn](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/costs/configure-native-mint-burn)
- [Dynamic pricing](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/costs/dynamic-pricing) | + +### Throughput and latency + +Handle higher volumes and faster response times for products that cannot degrade during periods of peak demand. + +| Feature | Your benefit | User benefit | Guide | +| ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | +| Reserve dedicated throughput so your chain does not compete for computation and storage resources | Guaranteed capacity means you can make performance commitments (effectively an SLA) to partners and customers without worrying about noisy-neighbor contention. | Consistent performance during peak events—launches, drops, market volatility—instead of degraded speed exactly when demand is highest. | [Launch overview (dedicated throughput)](https://docs.arbitrum.io/launch-arbitrum-chain/overview/introduction) | +| Set the gas target and block gas limit to match your expected load | You right-size capacity to your cost budget and build in headroom for growth, avoiding both overspend and under-provisioning. | Fewer failed or delayed transactions at peak, because the chain has enough room to absorb bursts. | [Gas target guidance](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/costs/gas-target) | +| Tune the block time and gas trade-offs for your performance profile | You optimize the cost-versus-speed balance for your specific workload rather than accepting a one-size-fits-all default. | A responsive app that stays fast without passing along unnecessary fee increases. | [Dynamic pricing](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/costs/dynamic-pricing) | + +### Compliance and privacy + +Create participation rules and data access controls that align with regulated workflows and protect sensitive information. + +| Feature | Your benefit | User benefit | Guide | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | +| Run permissioned validators to vet and restrict who participates in validation—useful for enterprise or regulated environments (for example, KYC for validators) | You can meet regulatory and legal requirements, reduce compliance risk, and make the chain viable for enterprise and institutional partners who can't operate on a fully open infrastructure. | Assurance that the chain operates within a vetted, accountable set of participants — a prerequisite for many regulated financial and enterprise products. | [Validation and BoLD](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/validation/bold) | +| Restrict who can read chain data by keeping data off the public L1 with an AnyTrust data availability committee | You keep sensitive business and user data out of a fully public ledger, satisfying privacy obligations and protecting competitive information. | Greater confidentiality around their activity and data than a fully public chain would offer. | [Configure data availability](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/data-availability/config-data-availability) | +| Move to permissionless validation later via BoLD when you are ready to decentralize | You can launch with tight control and decentralize on your own timeline — no re-platforming required as your product and risk tolerance mature. | A credible path to stronger trustlessness and censorship resistance over time, rather than being locked into a permissioned model forever. | [Validation and BoLD](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/validation/bold) | + +These controls apply at the validator and data-availability layers—who validates the chain and who can read its data. They are not a per-user transaction allowlist; screening which end users may submit transactions is an application-layer concern, not a chain-config setting. + +### Transaction sequencing + +Customize transaction ordering to match your product, whether the priority is wider access, lower MEV exposure, or tighter handling of transaction flow. + +| Feature | Your benefit | User benefit | Guide | +| --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | +| Keep the default First-Come, First-Serve (FCFS) ordering, which protects users from front-running and sandwich MEV | Fair, simple ordering keeps fast block times and avoids the reputational cost of a chain seen as hostile to ordinary users. | Built-in protection from front-running and sandwich attacks, so users aren't quietly taxed by MEV extractors on every trade. | [How the Sequencer works](https://docs.arbitrum.io/how-arbitrum-works/deep-dives/sequencer) | +| Enable Timeboost to auction an express lane, letting the chain owner capture MEV while preserving fair ordering for everyone else | You capture MEV as a revenue stream for the chain rather than leaking it to external searchers. | Non-express transactions keep their fair-ordering protections, while users who genuinely need priority have a transparent way to pay for it. | [Timeboost configuration](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/sequencer/timeboost) | + +### Governance and data availability + +Choose how the chain is upgraded, administered, and backed by data availability based on the balance of cost, transparency, and resilience you need. + +| Feature | Your benefit | User benefit | Guide | +| -------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | +| Define the chain-owner role and access controls that govern upgrades and administration, and plan a path toward progressive decentralization | You retain the control needed for upgrades and incident response early on, then deliberately decentralize as the chain matures—balancing agility with credibility. | Clear accountability for who can change the chain, plus a visible path toward stronger, more decentralized guarantees. | [Ownership and access control](https://docs.arbitrum.io/launch-arbitrum-chain/operate/ownership-and-access) | +| Choose your data availability model—Rollup, AnyTrust, Alt-DA—to trade off cost against transparency and resilience | You dial the cost-versus-security balance directly; AnyTrust can cut data costs substantially, while Rollup maximizes security and transparency. | Lower fees when you choose AnyTrust, or maximum security and Ethereum-grade transparency when you choose Rollup—matched to what your product actually needs. | [Configure data availability](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/data-availability/config-data-availability) | + +## Performance + +On an Arbitrum chain, performance isn’t a single parameter—it’s the combined result of a few independent levers. Each trades one property against another (speed vs. infrastructure load, throughput vs. node stability, settlement speed vs. security), and you tune them to fit your product’s risk tolerance and demand profile. There are four primary parameters to configure, and language support capability is automatically included (no configuration needed). + +### Latency + +How fast blocks are produced. Set the **block time** (250ms default, 100ms opt-in). Lower is snappier for users but heavier on nodes, indexers, and providers. + +| Feature | Your benefit | User benefit | Guides | +| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | +| Block time | Dial block time down to 100ms for a snappier chain, or keep the 250ms default to reduce load on node runners, indexers, and third-party providers — a direct throughput/infra trade-off you control. | Near-instant feedback on payments, transfers, and redemptions, with confirmations landing in a fraction of a second. | [Sequencer timing adjustments](/launch-arbitrum-chain/chain-config/sequencer/sequencer-timing-adjustments.mdx) | -- You can think of Arbitrum chains as **deployable, configurable instances of the Arbitrum Nitro tech stack**. -- You can also think of them as **tailored chains**: chains tailored precisely to **your exact use-case and business needs**. -- This gives you another way to **progressively decentralize** your applications and **incrementally adopt** the properties and security assumptions of Ethereum's base layer. -- Arbitrum One and Arbitrum Nova are owned and governed by the [Arbitrum DAO](https://docs.arbitrum.foundation/concepts/arbitrum-dao). With Arbitrum chains, _you_ determine the way that your chain is governed. +### Throughput + +How much the chain can process. Set the **gas target** and **block gas limit** to raise the TPS ceiling, weighed against the risk of node lag or halting. + +| Feature | Your benefit | User benefit | Guides | +| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| - Gas target
- Block gas limit | Raise the gas target and block gas limit to lift the chain’s throughput ceiling for high-volume workflows—weighed against the documented risk of node lag or halting if demand outruns validator resources. | Headroom to keep transactions moving during busy periods, so apps stay responsive under peak demand instead of congesting. | - [Gas target](/launch-arbitrum-chain/chain-config/costs/gas-target.mdx)
- [Gas optimization](launch-arbitrum-chain/chain-config/costs/gas-optimization.mdx) | + +### Finality and settlement + +How quickly transactions become final and withdrawable. Set the **Delayed Inbox finality**, the **challenge period**, and **fast withdrawals** to balance settlement speed against re-org and security risk. + +| Feature | Your benefit | User benefit | Guides | +| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Delayed inbox, fast withdrawals, challenge period | Delayed Inbox finality, challenge period, and fast withdrawals — to balance settlement speed against re-org and security risk for your risk, audit, and compliance stakeholders. | Faster, more predictable settlement: sub-second soft finality for responsiveness and quicker withdrawals back to the parent chain. | - [Delayed inbox](/launch-arbitrum-chain/chain-config/sequencer/chain-finality.mdx)
- [Fast withdrawals](/launch-arbitrum-chain/chain-config/validation/fast-withdrawals.mdx)
- [Challenge period](/launch-arbitrum-chain/chain-config/validation/challenge-period.mdx) | + +### Cost and fee stability + +How predictable prices stay under load. Use **Dynamic Pricing**, **fee management** (base/surplus minimums), a **gas price floor**, and **batch-poster fee tuning** to smooth spikes and capture revenue. + +| Feature | Your benefit | User benefit | Guides | +| --------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| - Dynamic pricing
- Fee management
- Gas price floor
- Batch poster fee tuning | Shape fee economics directly — Dynamic Pricing (multiple gas targets), base/surplus fee minimums, a gas price floor, and batch-poster fee tuning — to smooth price spikes and capture revenue while costs scale with usage. | More stable, predictable transaction costs under load, avoiding sudden fee spikes during large payout runs or volatile periods. | - [Dynamic pricing](/launch-arbitrum-chain/chain-config/costs/dynamic-pricing.mdx)
- [Fee management](/launch-arbitrum-chain/chain-config/costs/fee-management.mdx)
- [Gas optimization](/launch-arbitrum-chain/chain-config/costs/gas-optimization.mdx)
- [Batch poster fee tuning](/launch-arbitrum-chain/chain-config/batch-poster/fee-tuning.mdx) | + +### Language support + +Stylus is inherited by every Arbitrum chain. It allows developing smart contracts in languages your team may already be familiar with—instead of having to learn Solidity. Out of the box it will allow you to write performant contracts in Rust, C, C++ (and community-tier AssemblyScript) alongside Solidity, reusing mature libraries and keeping full EVM compatibility. + +- [Stylus gentle intro](/stylus/gentle-introduction.mdx) +- [Deploy non-Rust WASM contracts](/stylus/how-tos/deploying-non-rust-wasm-contracts.mdx) + +## Compliance + +### Sanctioned-address screening at the protocol level + +Protocol-level transaction filtering added to the Sequencer and STF, at the chain owner’s discretion. + +| Owner benefit | User benefit | Guide | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | +| Enables filtering as a first-class protocol capability to opt into, rather than building and maintaining bespoke tooling, while retaining full discretion over whether to enable it. | Transactions are screened by the network itself, so protection doesn’t depend on any single app behaving correctly. | [Compliance filtering](/launch-arbitrum-chain/02-configure-your-chain/advanced/compliance-filtering.mdx) | + +### Choose your screening provider (TRM Labs / Chainalysis) + +| Owner benefit | User benefit | Guide | +| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | +| Can reuse an existing provider relationship and risk methodology rather than build screening in-house. | Screening reflects industry-standard sanctions data rather than ad hoc lists. | [Compliance filtering](/launch-arbitrum-chain/02-configure-your-chain/advanced/compliance-filtering.mdx) | + +### Define restriction lists (address-level and event-level rules) + +| Owner benefit | User benefit | Guide | +| ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | +| Can tailor enforcement granularity to policy—addresses, events, or both. | Only the activity that the policy actually targets is blocked, reducing false positives. | [Compliance filtering](/launch-arbitrum-chain/02-configure-your-chain/advanced/compliance-filtering.mdx) | + +### Restriction rules + +| Owner benefit | User benefit | Guide | +| --------------------------------------------------------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | +| A ready-made menu of enforcement actions covering transfers, tokens, and opcodes. | Clearly scoped restrictions keep permitted activity available. | [Compliance filtering](/launch-arbitrum-chain/02-configure-your-chain/advanced/compliance-filtering.mdx) | + +### Continuous monitoring (synchronization pipeline) + +| Feature | Owner benefit | User benefit | Guide | +| -------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- | +| Compliance filtering | The restricted set remains up to date without manual redeployment. | Newly sanctioned addresses are enforced promptly, improving protection. | [Compliance filtering](/launch-arbitrum-chain/02-configure-your-chain/advanced/compliance-filtering.mdx) | +| CLI flags | Can tune update frequency and storage to their operational needs. | Timely list updates mean less exposure to recently restricted addresses. | [CLI flags reference](/run-arbitrum-node/nitro/cli-flags-reference.mdx) | ## What problem do Arbitrum chains solve? +Arbitrum chains are dedicated chains built with Arbitrum technology. Teams can configure execution, fee models, governance, data availability, validation, and other chain parameters for their application or business requirements. + The Ethereum ecosystem is supported by a **decentralized network of nodes** that each run Ethereum's Layer 1 (L1) client software. Ethereum's block space is in high demand, so users are often stuck waiting for the network to become less congested (and thus, less expensive). Arbitrum's protocols address this challenge by offloading some of the Ethereum network's heavy lifting to **another decentralized network of nodes** that support the Arbitrum stack (Arbitrum chains). -## What key features should I consider? - -| Feature | Description | -| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Dedicated throughput | More info | -| EVM+ compatibility | EVM compatibility + more languages like Rust programs supported | -| Account abstraction | Account abstraction | -| Gas & Tokens | Custom gas token or Native ETH | -| Data availability | Rollup (Ethereum DA), AnyTrust, Alt-DA | -| Fast confirmations | Fast withdrawals | -| Security & validation | BoLD, Permissioned validators, Challenge period enforced on L1 | -| Safety Features | Force-inclusion & customizable governance | -| MEV | Timeboost | -| Cost | Data posting costs | -| Infrastructure | Hardware requirements | -| Interop | TBD | - ## How do Arbitrum chains help the Ethereum ecosystem? Arbitrum helps Ethereum move towards a **multi-chain future**. This is valuable for the following reasons: diff --git a/docs/launch-arbitrum-chain/partials/_alt-da-pc.mdx b/docs/launch-arbitrum-chain/partials/_alt-da-pc.mdx deleted file mode 100644 index 8f70ec05d5..0000000000 --- a/docs/launch-arbitrum-chain/partials/_alt-da-pc.mdx +++ /dev/null @@ -1,14 +0,0 @@ -## Pros - -- **Significant cost savings**: Using an Alt-DA can reduce DA fees by 75-95% compared to posting data directly to Ethereum, making it an ideal solution for high-volume or cost-sensitive applications, such as gaming, social platforms, or AI agents. For instance, over 95% of rollup costs often stem from Ethereum DA, and alternatives like Celestia or NEAR DA offer transactions up to 100x cheaper. -- **Improved throughput and scalability**: By separating DA from Ethereum's blockspace constraints, Alt-DA enables higher transaction volumes and better handles data-intensive use cases. -- **Flexibility and modularity**: Using an Alt-DA provider allows portability across ecosystems and custom trust models (Rollup, DAC, Alt-DA). -- **Reduced trust assumptions in some cases**: Compared to a DAC in AnyTrust mode, a decentralized Alt-DA like Avail can lower reliance on a small committee by using broader validator sets (e.g., up to 1,000 validators) and mathematical proofs for DA guarantees. -- **Predictable performance**: Alt-DA often provides stable fees and fast finality, with fallbacks (e.g., Ethereum) to maintain uptime, benefitting consumer-facing apps. - -## Cons - -- **Trade-offs in security and trust**: Alt-DA may introduce mild trust assumptions or different security models (e.g., relying on the Alt-DA network's consensus mechanism), which are potentially less robust than Ethereum's onchain DA, which inherits Ethereum's anti-censorship and verifiability features. This trade-off makes it less suitable for high-total-value-locked (TVL) applications that require maximal decentralization. -- **Operational complexity**: Implementing Alt-DA requires additional monitoring, alerting, data retention policies, and integration efforts (e.g., modifying batchers or bridgers), which increases overhead for development teams and demands operational maturity. -- **Dependency risks**: The chain becomes reliant on the Alt-DA provider's reliability; if it faces congestion, failures, or compromises, it could impact data retrieval and overall chain availability, resulting in potential volatility in costs during periods of high demand. -- **Limited transparency compared to onchain**: Offchain data storage (even with proofs) may reduce immediate verifiability for all users, as nodes must query external sources, which contrasts with Ethereum's direct onchain access. diff --git a/docs/launch-arbitrum-chain/partials/_anytrust-pc.mdx b/docs/launch-arbitrum-chain/partials/_anytrust-pc.mdx deleted file mode 100644 index ef008bcdf5..0000000000 --- a/docs/launch-arbitrum-chain/partials/_anytrust-pc.mdx +++ /dev/null @@ -1,16 +0,0 @@ -## Pros - -- **Ultra-low transaction fees**: By offloading data availability to a Data Availability Committee (DAC) instead of posting all transaction data directly to Ethereum L1, AnyTrust significantly reduces costs, making micro-transactions viable. -- **Higher throughput and speed**: Supports a much larger volume of transactions per second compared to traditional rollups, ideal for high-frequency applications. -- **Faster withdrawals**: Withdrawals to Ethereum can occur immediately if vouched for by the DAC, avoiding the typical seven-day challenge period. -- **Minimal trust assumptions with strong feedback**: Requires only a small number of honest DAC members for normal operation, which is less trust-intensive. If the DAC fails, it automatically falls back to rollup mode, posting data to Ethereum for security. -- **Customization**: Enables flexible configurations like custom gas tokens, governance, and execution logic while inheriting low-cost benefits. -- **Ideal for specific use cases**: Best for high-volume, low-value applications such as Web3 gaming, decentralized social media, NFT platforms, and micro-payment systems where cost efficiency outweighs maximum decentralization. - -## Cons - -- **Introduced trust assumptions**: Relies on the DAC's honesty and availability, which adds a layer of trust not present in full trustless Rollups. This trust assumption could be a risk if committee members collude or fail. -- **Reduced decentralization and security guarantees**: Lacks the full trustlessness, permissionlessness, and censorship resistance of Rollups, as not all data is posted to Ethereum by default. This lack of data posting makes it less suitable for high-value DeFi or applications requiring Ethereum-level security. -- **Potential for fallback mode issues**: If the DAC cannot come to a quorum, the chain reverts to Rollup mode, which could increase costs temporarily and introduce delays similar to standard Rollups. -- **Liquidity and adoption changes**: May face lower liquidity or ecosystem integration compared to Rollup-based chains like Arbitrum One, potentially limiting interoperability with certain apps. -- **Not optimal for all use cases**: For applications handling significant financial value or needing maximum security, the trade-offs in decentralization could outweigh the benefits. diff --git a/docs/launch-arbitrum-chain/partials/_bold-pc.mdx b/docs/launch-arbitrum-chain/partials/_bold-pc.mdx deleted file mode 100644 index 71a82864a8..0000000000 --- a/docs/launch-arbitrum-chain/partials/_bold-pc.mdx +++ /dev/null @@ -1,12 +0,0 @@ -## Pros - -- **Improved Security**: Mitigates delay attacks and ensures only valid states are confirmed, with high bonds (e.g., millions in USD equivalent) deterring malice while allowing trustless defense. -- **Permissionless Decentralization**: Anyone can validate via bonds, reducing reliance on centralized entities and enabling community participation through pools. -- **Bounded Delays**: Caps withdrawal delays at ~12.8 days during disputes, providing predictability. -- **Incentives**: Includes bounties (1% of confiscated bonds) and reimbursements for honest defenders, plus optional chain-specific rewards. - -## Cons - -- **High Economic Barriers**: Large bonds (e.g., 3600 **ETH** for assertions on Arbitrum One) may limit small-scale participation without pools, and disputes impose opportunity costs on users (e.g., ~$3.27M USD/week for Arbitrum One's TVL). -- **Upgrade Disruptions**: Enabling BoLD delays pending withdrawals and requires careful overflow handling during the upgrade. -- **Complexity**: Adds operational needs for proposers and parameter tuning (e.g., bond sizes, resource ratios) to maintain security. diff --git a/docs/launch-arbitrum-chain/partials/_custom-gas-token-pc.mdx b/docs/launch-arbitrum-chain/partials/_custom-gas-token-pc.mdx deleted file mode 100644 index 6650a61622..0000000000 --- a/docs/launch-arbitrum-chain/partials/_custom-gas-token-pc.mdx +++ /dev/null @@ -1,17 +0,0 @@ -## Pros - -- **Enhanced token utility and demand**: Using a custom **ERC-20** token for gas fees creates inherent utility and constant demand for the project's native token, driving value accrual through practical use rather than speculation. This utility is particularly beneficial for ecosystems like gaming or DeFi, where it can support in-app economies and incentivize network participation. -- **Internalized economic value**: Retention of transaction fees within the ecosystem, creating a sustainable model where the community captures the value generated by network activity, rather than relying on external tokens like **ETH**. -- **Improved user experience and onboarding**: Users can pay fees with a single native token, eliminating the need to manage multiple assets (e.g., acquiring **ETH** separately). Using a single token can reduce friction, simplifying fee estimation, and enabling features like gas subsidies where projects pay fees on behalf of users, which is ideal for mainstream adoption in gaming or social platforms. -- **Unified brand and ecosystem identity**: Interactions stay within the project's token economy, reinforcing branding and immersion (e.g., in-game currencies handling all fees). -- **Stability and predictability (with stablecoins)**: Using a stable token like USDC mitigates volatility in transaction costs compared to **ETH**, providing consistent and affordable fees. -- **Integration with existing tools**: Native implementation in Arbitrum ensures compatibility with EVM tooling, deterministic gas accounting, and deployment. - -## Cons - -- **Limited Flexibility (Native Implementation)**: Once deployed, it's difficult to support multiple gas tokens or switch tokens, requiring users to acquire the specific **ERC-20** token, which can complicate onboarding and limit ecosystem diversity. -- **Potential sell pressure and economic risks**: Fees must be converted to the parent chain's token (e.g., **ETH**) for data availability costs, creating systematic sell pressure on the custom token. Significant price declines (e.g., 50%) could lead to operational deficits, necessitating advanced economic modeling for forecasting, hedging, and reserve management. -- **Compatibility issues**: May not work well with applications or tools expecting **ETH**, potentially impacting integration with broader Ethereum ecosystems. -- **Increased complexity (account abstraction implementation)**: This adds infrastructure, such as paymasters and bundlers, which complicates gas estimation, transaction flows, and tooling configuration (e.g., for explorers or indexers), with the risk of inconsistent adoption. -- **Migration challenges**: Changing or migrating the gas token post-deployment involves high technical risks, including contract updates, chain pauses, and potential loss of funds. -- **Requirements and limitations**: The token must meet specific criteria (e.g., standard **ERC-20**). While supported in, it relies on chain-wide adoption, which may not be suitable for all cases. diff --git a/docs/launch-arbitrum-chain/partials/_fast-withdrawals-pc.mdx b/docs/launch-arbitrum-chain/partials/_fast-withdrawals-pc.mdx deleted file mode 100644 index 5bce2e6cd9..0000000000 --- a/docs/launch-arbitrum-chain/partials/_fast-withdrawals-pc.mdx +++ /dev/null @@ -1,13 +0,0 @@ -## Pros - -- **Significantly faster withdrawals and finality**: Reduces withdrawal times from days to minutes, improving user experience and enabling quicker asset movement across chains. This is particularly beneficial for cross-chain dApps, as they can read the finalized state at the same accelerated rate. -- **Enhanced capital efficiency**: Shorter wait times minimize opportunity costs for users, allowing faster re-deployment of funds and better liquidity in DeFi or other applications. -- **Improved performance for AnyTrust**: When combined with AnyTrust mode, Fast Withdrawals leverage existing infrastructure without introducing entirely new trust elements, enabling near-instant withdrawals for non-fungible assets. - -## Cons - -- **Introduced trust assumptions**: Shifts security from the fully decentralized optimistic Rollup model to reliance on a validator committee. For Rollup-mode chains, this means it's no longer a "true" Rollup, as users must trust the committee for fast confirmations. In AnyTrust mode, it assumes at least two honest members in the Data Availability Committee (DAC), which could be a risk if the committee is compromised. -- **Potential delays under high load**: High network throughput can cause confirmation delays beyond the configured rate, with a practical minimum of 1-2 minutes in busy scenarios. Initial setup may also slow the chain temporarily due to backlog processing. -- **Setup complexity and requirements**: Requires upgrading to specific versions, creating a multi-signature Safe wallet for the committee, and running at least three validators. This adds operational overhead and potential costs. -- **Security trade-offs compared to standard withdrawals**: While standard withdrawals maintain full Ethereum-level security via the challenge period, fast withdrawals prioritize speed over decentralization, potentially exposing users to risks if the committee fails or is attacked. -- **Layer 3 setups finality**: For chains settling to Arbitrum One or similar and using BoLD, fast confirmations cannot be lowered below 15 minutes. diff --git a/docs/launch-arbitrum-chain/partials/_native-eth-pc.mdx b/docs/launch-arbitrum-chain/partials/_native-eth-pc.mdx deleted file mode 100644 index 78d46d79a1..0000000000 --- a/docs/launch-arbitrum-chain/partials/_native-eth-pc.mdx +++ /dev/null @@ -1,13 +0,0 @@ -## Pros of using native **ETH** - -- **Simplicity and familiarity for users**: Native **ETH** is the default gas token, making it easier for users already in the Ethereum ecosystem to interact with the chain without needing to acquire or bridge a new token. This reduces onboarding friction and leverages existing wallets and tools. -- **Enhanced security and trust**: By using **ETH**, the chain benefits from Ethereum's established security, decentralized, and market liquidity, which can build user confidence as **ETH** is a well-trusted asset. -- **Interoperability**: Integrates directly with the broader Ethereum ecosystem, including DeFi protocols, exchanges, and bridges, simplifying development and reducing the need for additional custom integrations. -- **Default configuration**: As the standard option for Arbitrum chains, it requires no additional setup for custom token configurations, speeding up deployment. - -## Cons of using native **ETH** - -- **Price volatility**: Gas fees are tied to **ETH**'s market price, which can fluctuate significantly, leading to unpredictable transaction costs for users. -- **Limited customization**: You cannot tailor tokenomics (e.g., inflation, rewards, or deflation mechanisms) to fit your chain's specific needs, missing opportunities to incentivize behaviors like staking or ecosystem participation. -- **Potential for higher costs in certain cases**: For high-volume applications like gaming or social networks, **ETH**-based fees might be more expensive compared to a custom token designed for lower costs. -- **Less ecosystem control**: Without a custom token, there's no ability to create value capture mechanisms or partnerships centered around a native asset, which could limit long-term growth and user engagement in niche ecosystems. diff --git a/docs/launch-arbitrum-chain/partials/_permissioned-validators.mdx b/docs/launch-arbitrum-chain/partials/_permissioned-validators.mdx deleted file mode 100644 index b14a535b2a..0000000000 --- a/docs/launch-arbitrum-chain/partials/_permissioned-validators.mdx +++ /dev/null @@ -1,13 +0,0 @@ -## Pros - -- **Enhanced control and security in trusted environments**: Permissioned validators allow the chain owner to select and vet participants, reducing risks from unknown or malicious actors, which is ideal for enterprise or private chains where trust among validators is present, minimizing the chance of spam or uncoordinated attacks. -- **Regulatory compliance and privacy**: Easier to implement access controls, such as restricting who can read chain data or participate, which helps with legal requirements (e.g., KYC for validators) in regulated industries like finance. -- **Simpler setup and lower operational overhead**: Without needing to support open participation, the chain can operate with fewer nodes, potentially leading to faster consensus, reduced complexity in dispute resolution, and lower costs for maintaining the network. Permissioned validation is beneficial for smaller or specialized Arbitrum chains focused on specific use cases. -- **Established and proven model**: Permissioned validation mirrors the initial setup of chains like Arbitrum One, providing a reliable baseline without requiring additional protocols like BoLD for permissionless features. - -## Cons - -- **Vulnerability to delay attacks**: In permissioned systems, malicious validators can exploit the challenge window by repeatedly posting false claims, forcing honest validators to spend resources on defenses and delaying confirmations or withdrawals. This potential exploitation could raise costs and risks of liveness issues. -- **Centralization risks**: The system relies on a limited set of trusted validators; if they collude, fail, or are compromised, the integrity of the chain could be at risk. This centralization could make the chain less appealing to users who value trustlessness. -- **Limited robustness against adversaries**: Unlike permissionless models, where any honest party can defend the chain, permissioned validation depends on the availability and honesty of the approved set. A single point of failure (e.g., if validators go offline) could halt progress. -- **Potentially for reduced adoption**: Developers or users seeking Ethereum-like decentralization might prefer permissionless options, limiting the chain's appeal in open ecosystems. Enabling permissionless later (via BoLD) requires upgrades and community/DAO approval, adding complexity. diff --git a/docs/launch-arbitrum-chain/partials/_rollup-pc.mdx b/docs/launch-arbitrum-chain/partials/_rollup-pc.mdx deleted file mode 100644 index ce86b77e23..0000000000 --- a/docs/launch-arbitrum-chain/partials/_rollup-pc.mdx +++ /dev/null @@ -1,11 +0,0 @@ -## Pros - -- **Security**: Provides maximum security and decentralization by inheriting full Ethereum-grade security without additional trust assumptions beyond the base layer. -- **Strong Data Availability**: Ensures strong data availability and censorship resistance, as all transaction data is publicly posted on the parent chain, allowing anyone to validate and detect fraud. -- **Trustless and permissionless**: Fully trustless and permissionless operation, requiring only one honest validator for the system to remain secure, making it ideal for high-value applications like DeFi protocols. - -## Cons - -- **Higher costs**: Higher transaction fees due to the cost of posting all data onchain to the parent layer. -- **Withdrawal times**: Longer withdrawal times, typically involving a seven-day challenge period for fraud proofs before funds can be moved back to the parent layer. -- **Throughput**: Potentially lower throughput compared to AnyTrust mode, as the onchain data posting can limit scalability for high-volume, low-value transactions. diff --git a/docs/launch-arbitrum-chain/partials/_timeboost-pc.mdx b/docs/launch-arbitrum-chain/partials/_timeboost-pc.mdx deleted file mode 100644 index 9e19add210..0000000000 --- a/docs/launch-arbitrum-chain/partials/_timeboost-pc.mdx +++ /dev/null @@ -1,11 +0,0 @@ -## Pros - -- Revenue generation for chain owners. Proceeds can fund ecosystems or burn tokens. -- Reduces spam/congestion from latency races; fairer, predictable MEV access for searchers. -- Maintains security (no harmful MEV increase) and fast blocks; open auctions prevent monopolies. - -## Cons - -- Adds ~200ms delay to non-express user transactions (~450ms average response), potentially impacting UX. -- Setup/maintenance costs (e.g., auctioneer servers, Redis) may exceed revenue on low-MEV chains. -- No guaranteed revenue; ineffective without MEV activity. Minor risks like bid limits for DDoS mitigation. diff --git a/docs/launch-arbitrum-chain/partials/config-account-abstraction.mdx b/docs/launch-arbitrum-chain/partials/config-account-abstraction.mdx deleted file mode 100644 index dd5b0cfcc2..0000000000 --- a/docs/launch-arbitrum-chain/partials/config-account-abstraction.mdx +++ /dev/null @@ -1,17 +0,0 @@ -Arbitrum chains support account abstraction (AA) primarily through `ERC-4337`, a standard that enables smart contract wallets without requiring changes to the underlying Ethereum protocol, and more recently via `EIP-7702` integrated in the ArbOS 40 upgrade. This upgrade allows externally owned accounts (EOAs) to temporarily behave like smart contract accounts, embedding custom logic for transaction validation, execution, and features such as batching operations or gas sponsorship. In practice, `ERC-4337` introduces components like `UserOperations` (pseudo-transactions), `bundlers` (to package and submit them), `paymasters` (for gas fee handling), and an `EntryPoint` contract, making wallets more programmable and user-friendly. `EIP-7702` complements this by adding a new transaction type that delegates EOA execution to smart contract code for a single transaction, enhancing flexibility on Arbitrum's low-cost L2 environment while maintaining compatibility with Ethereum's Pectra upgrade. - -## Pros of Account Abstraction on Arbitrum Chains - -- **Enhanced User Experience and Onboarding**: Simplifies wallet interactions by eliminating seed phrases, enabling social recovery, multi-factor authentication, and gasless transactions, making Web3 more accessible for non-technical users and reducing barriers on Arbitrum's efficient L2. -- **Improved Security and Flexibility**: Allows programmable logic for custom validation, preventing private key exposure, enabling self-sovereign recovery, and supporting features like fraud monitoring or multi-ownership, which is particularly secure in Arbitrum's Rollup architecture. -- **Transaction Efficiency**: Supports batching multiple actions (e.g., approve and transfer in one atomic call) and gas sponsorship by apps, reducing costs and steps; on Arbitrum, this leverages low fees and fast confirmations for high-volume use cases like DeFi or gaming. -- **Multi-Chain Compatibility**: Maintains the same wallet address across EVM-compatible chains like Arbitrum and others, easing cross-chain interactions and preventing fund loss from address mismatches. -- **No Permanent Changes Required**: With `EIP-7702`, EOAs can "borrow" smart account features temporarily without migration, fostering innovation like composable flows and interoperability with Arbitrum's Stylus MultiVM for Rust-based contracts. - -## Cons of Account Abstraction on Arbitrum Chains - -- **Infrastructure Complexity**: Relies on additional components like `bundlers`, `paymasters`, and `EntryPoints`, which can fragment wallet experiences, require extra setup, and introduce dependencies on third-party services. -- **Gas Overhead**: Verification of signatures and authorization logic adds minor gas costs, potentially offsetting some efficiency gains, though mitigated on Arbitrum's low-fee environment. -- **Security Risks**: Delegated contracts must be validated to avoid malicious exploits; incomplete abstraction (e.g., `ERC-4337` acts more as a relayer) may not eliminate vulnerabilities like replay attacks if not implemented carefully. -- **Adoption Barriers**: Requires widespread ecosystem support from dApps, wallets, and providers; inconsistent implementations across chains could lead to user confusion or limited interoperability. -- **Not Full Protocol-Level Abstraction**: Depends on higher-layer infrastructure rather than core consensus changes, limiting depth compared to potential future upgrades and potentially increasing reliance on centralized elements like relayers. diff --git a/docs/launch-arbitrum-chain/partials/config-challenge-period-l1.mdx b/docs/launch-arbitrum-chain/partials/config-challenge-period-l1.mdx deleted file mode 100644 index 09ddfc7b3d..0000000000 --- a/docs/launch-arbitrum-chain/partials/config-challenge-period-l1.mdx +++ /dev/null @@ -1,17 +0,0 @@ -Arbitrum chains, as optimistic Rollups, use a challenge period (typically 6.4 days on mainnet chains like Arbitrum One, though customizable in chains) during which assertions about the L2 state—such as batched transactions—are posted to Ethereum (L1) and remain open to dispute. This process enables a validator that suspects an invalid state transition or fraudulent batch to initiate a challenge by submitting fraud proofs to L1 smart contracts. The enforcement on L1 involves the entire dispute resolution process occurring on Ethereum mainnet: assertions occur on L1, challenges trigger an interactive protocol, and if no valid challenge succeeds by the end of the period, the assertion is confirmed, enabling finality for actions like asset withdrawals or cross-layer messages. This protocol leverages Ethereum's consensus and security without requiring immediate onchain verification for every L2 transaction, assuming optimism (i.e., batches are presumed correct unless proven otherwise). - -## Pros of Having the Challenge Period Enforced on Layer 1 - -- **High Security and Fraud Deterrence**: Relies on Ethereum's robust consensus and economic incentives (e.g., staking and slashing) to make fraudulent assertions costly and detectable, ensuring only valid states achieve finality while protecting against malicious sequencers or validators. -- **Permissionless Validation**: Anyone can participate as a challenger on L1, promoting decentralization and reducing reliance on centralized entities, with the period providing ample time to respond to threats like DoS attacks or L1 consensus failures. -- **Cost Efficiency for L2 Operations**: Offloads heavy computation to L2 while using L1 only for disputes, enabling lower fees and higher throughput on Arbitrum chains without compromising on Ethereum's security model. -- **Finality Assurance**: Once the period passes without challenges, L2 states achieve L1-equivalent finality, supporting reliable cross-layer interactions and protecting against reversion of confirmed batches. -- **Customizability**: In setups like Arbitrum chains, the period can be adjusted (e.g., shorter for lower-risk chains), balancing security with specific use case needs while still enforcing via L1 contracts. - -## Cons of having the challenge period enforced on L1 - -- **Withdrawal and Finality Delays**: Users must wait the entire period (e.g., 6.4 days) for L2-to-L1 exits or messages, leading to poor user experience and capital inefficiency compared to faster alternatives like ZK Rollups. -- **Potential for Extended Disputes**: In case of challenges, resolution can add further delays (up to another period or more), and malicious actors could exploit this to disrupt the chain temporarily. -- **Economic and Operational Overhead**: Challengers need to monitor and bond on L1, which can be resource-intensive; additionally, the fixed length (like 6.4 days) may not be optimal for all batches, potentially making low-value transactions overly secure at the cost of efficiency. -- **Vulnerability to L1 Issues**: Depends on Ethereum's stability; events like network congestion, high gas fees, or consensus failures could hinder timely challenges, though the challenge period's design is to outlast such issues. -- **Lack of Dynamism in Standard Setup**: The uniform application across all assertions ignores variables like sequencer reputation or batch value, leading to unnecessary delays. diff --git a/docs/launch-arbitrum-chain/partials/config-customizable-governance.mdx b/docs/launch-arbitrum-chain/partials/config-customizable-governance.mdx deleted file mode 100644 index a6571da706..0000000000 --- a/docs/launch-arbitrum-chain/partials/config-customizable-governance.mdx +++ /dev/null @@ -1,17 +0,0 @@ -Arbitrum chains (as L2 or L3 solutions settling on Ethereum or Arbitrum), feature customizable governance, which refers to the ability for chain creators to define and implement their own governance protocols tailored to specific project needs. This flexibility contrasts with public chains like Arbitrum One, which is governed by the decentralized Arbitrum DAO using the `$ARB` token for proposals, voting, and upgrades. Custom governance can include setting up unique DAO structures, tokenomics, voting mechanisms (e.g., delegation, proportional weighting), treasury management, and even specialized roles like a Security Council for emergencies, all enforced through smart contracts. It allows for progressive decentralization, where chains start with centralized elements (e.g., a "chain owner" role for upgrades and bug fixes) and evolve toward community-driven models, potentially integrating features like time-delayed proposals for user opt-outs or compatibility with Ethereum upgrades. - -## Pros of Customizable Governance on Arbitrum Chains - -- **Tailored Flexibility and Experimentation**: Enables projects to customize governance to fit unique use cases, such as optimizing security models, resource management, or execution environments, fostering innovation and scalability in a multi-chain ecosystem. -- **Progressive Decentralization**: Allows gradual transfer of control from initial centralized roles (e.g., chain owners) to community governance via tokens like `$ARB`, reducing centralization risks while supporting necessary upgrades, bug fixes, and Ethereum compatibility. -- **Community Empowerment and Fairness**: Distributes decision-making to diverse stakeholders through airdrops, delegations, and voting, ensuring ecosystem-aligned changes with built-in protections like review periods and asset withdrawal options. -- **Emergency Handling and Security**: Incorporates customizable elements like a Security Council for rapid responses to vulnerabilities, balancing speed with decentralization through elections and constitutional constraints. -- **Evolvability**: The system can self-modify, allowing the DAO to refine governance (e.g., minimizing centralized roles) as technology and risks evolve, promoting long-term adaptability. - -## Cons of Customizable Governance on Arbitrum Chains - -- **Residual Centralization Risks**: Features like the Security Council introduce permissioned elements that can bypass full community processes, potentially enabling rapid changes without broad input, though mitigated by oversight. -- **Complexity in Implementation**: Customizing governance requires careful design of smart contracts and processes, which could lead to vulnerabilities if not properly audited, and relies on L1 enforcement for upgrades, adding layers of dependency. -- **Initial Power Imbalances**: Early token distributions (e.g., airdrops) might concentrate influence among stakeholders, despite efforts to mitigate Sybil attacks, affecting fairness in nascent chains. -- **Emergency Procedure Vulnerabilities**: Quick actions in crises could risk misuse or lack of transparency, even with requirements for reports and constitutional adherence. -- **Slower Full Decentralization**: The need for progressive steps and community consensus can delay complete decentralization, especially for L2 chains tied to Ethereum's constraints, compared to more rigid but immediate models. diff --git a/docs/launch-arbitrum-chain/partials/config-data-posting-costs.mdx b/docs/launch-arbitrum-chain/partials/config-data-posting-costs.mdx deleted file mode 100644 index a6522b73f9..0000000000 --- a/docs/launch-arbitrum-chain/partials/config-data-posting-costs.mdx +++ /dev/null @@ -1,16 +0,0 @@ -In Arbitrum chains, data posting costs refer to the fees incurred for submitting compressed batches of L2 transaction data to Ethereum (L1) as calldata, ensuring data availability (DA) for security, fraud proofs, and state reconstruction. This process is a core aspect of Arbitrum's optimistic Rollup design, where the sequencer aggregates transactions, compresses them (e.g., using Brotli for efficiency), and posts them to L1 contracts. Cost proration occurs across transactions in the batch and forms part of the overall L2 fee structure. For Arbitrum One, full calldata post to Ethereum for maximum security; Arbitrum Nova uses AnyTrust with a Data Availability Committee (DAC) to post only DACerts to L1 while storing data offchain, significantly reducing costs (e.g., ~10x cheaper for data-heavy apps); custom Arbitrum chains allow flexible DA options like Ethereum calldata, AnyTrust, or integrations with alternatives like Celestia. Costs fluctuate with Ethereum gas prices and batch efficiency, but are typically fractions of a cent per transaction; recent proposals like Dynamic Pricing aim to treat calldata as a distinct resource dimension, enabling more targeted fee adjustments based on demand. - -### Pros of Data Posting Costs on Arbitrum Chains - -- **Enhanced Security and Trustlessness**: Posting to Ethereum L1 inherits its robust DA and consensus, allowing anyone to reconstruct the L2 state for fraud challenges or exits, providing stronger guarantees than offchain alternatives without additional trust assumptions. -- **Cost Efficiency Through Compression and Batching**: Compression reduces calldata size (e.g., by 5-10x), lowering per-transaction costs to cents or less compared to direct L1 execution, making high-throughput apps like DeFi or gaming viable while scaling Ethereum. -- **Flexibility in Custom Chains**: Arbitrum chains allow tailoring DA methods (e.g., AnyTrust for lower costs in trust-minimized setups or third-party DA for further optimization), enabling projects to balance cost with security needs without forking the core protocol. -- **Predictability and Fairness with Updates**: Innovations like Dynamic Pricing separate calldata costs from other resources (e.g., computation), stabilizing fees by adjusting based on demand and rewarding efficient data usage, potentially reducing overall volatility. -- **Lower Overhead for General Use**: Compared to ZK rollups (which post proofs instead), optimistic posting is cheaper for routine operations, as fraud proofs are rare, and batches amortize costs across many transactions. - -### Cons of Data Posting Costs on Arbitrum Chains - -- **Dependency on L1 Gas Volatility**: Ethereum's gas prices dictate the costs, which can spike during congestion (e.g., making posting expensive and unpredictable), indirectly raising L2 fees despite compression. -- **Added Overhead for Small Transactions**: The prorated L1 fee plus sequencer margin can make low-value or simple txs relatively more expensive than on pure L1, especially if batches are small or data-heavy. -- **Trade-offs in Alternative Models**: Options like AnyTrust reduce costs but introduce trust in the DAC, potentially compromising full trustlessness for data-heavy apps. -- **Complexity in Fee Calculation**: Users must account for both L2 and L1 components, and updates like Dynamic Pricing add layers (e.g., multi-dimensional multipliers), potentially confusing developers or requiring more sophisticated gas estimation tools. diff --git a/docs/launch-arbitrum-chain/partials/config-dedicated-throughput.mdx b/docs/launch-arbitrum-chain/partials/config-dedicated-throughput.mdx deleted file mode 100644 index 9414eb7e96..0000000000 --- a/docs/launch-arbitrum-chain/partials/config-dedicated-throughput.mdx +++ /dev/null @@ -1 +0,0 @@ -You may need dedicated throughput if your chain requires high performance or consistent resource availability. Running your chain on its own Arbitrum chain significantly increases resource availability, so you don’t need to compete for computation and storage resources. diff --git a/docs/launch-arbitrum-chain/partials/config-evm-compatbility.mdx b/docs/launch-arbitrum-chain/partials/config-evm-compatbility.mdx deleted file mode 100644 index e7909b26e0..0000000000 --- a/docs/launch-arbitrum-chain/partials/config-evm-compatbility.mdx +++ /dev/null @@ -1,17 +0,0 @@ -EVM compatibility refers to the ability of Layer-2 scaling solutions to fully support and execute smart contracts and transactions designed for the Ethereum Virtual Machine (EVM). This compatibility means that developers can deploy unmodified Ethereum-based code—written in languages like Solidity—directly on Arbitrum, with the chain emulating Ethereum's runtime environment, bytecode, and developer tools. Arbitrum goes beyond basic compatibility by aiming for "EVM equivalence," which replicates Ethereum's architecture, node infrastructure, and behavior almost exactly for maximum consistency. - -## Pros of EVM Compatibility for Arbitrum Chains - -- **Migration and developer familiarity**: Ethereum dApps can be ported to Arbitrum with little to no code changes, allowing developers to leverage existing skills, tools (for example, Foundry, Hardhat), and libraries without a steep learning curve. -- **Interoperability**: Enables easy cross-chain interactions, asset transfers, and data exchange with Ethereum and other EVM-compatible networks, fostering a connected ecosystem for multi-chain dApps. -- **Scalability and Cost Efficiency**: Arbitrum chains offer faster transaction speeds and significantly lower fees compared to Ethereum mainnet, while maintaining EVM support, making it ideal for high-volume applications like DeFi or gaming. -- **Access to Proven Ecosystem**: Benefits from Ethereum's battle-tested security, large developer community, and resources, reducing development time and risks associated with building on less mature platforms. -- **Flexibility for Customization**: While tied to EVM standards, Arbitrum allows for optimizations such as optimistic rollups, enabling custom chains (e.g., via Arbitrum chains) tailored to specific use cases without sacrificing compatibility. - -## Cons of EVM Compatibility for Arbitrum Chains - -- **Subtle Behavioral Differences**: Despite high equivalence, minor variations exist in areas like block timing, RPC methods, gas fees (which include an extra component for posting data to Ethereum), or precompiles, potentially requiring developer adjustments and testing to avoid unexpected issues. -- **Dependency on Ethereum**: Arbitrum chains inherit Ethereum's limitations (e.g., gas mechanics or lack of native parallelism) and are affected by its upgrades, congestion, or security events, limiting independence. -- **Reduced Innovation Potential**: Being tied to the EVM model can restrict the adoption of non-EVM features or alternative virtual machines, potentially stifling unique optimizations beyond Ethereum's design. -- **Cross-Layer Complexity**: Interactions between Arbitrum (L2) and Ethereum (L1), such as bridging or message passing, add layers of complexity, delays, and potential risks like fraud challenges in optimistic Rollups. -- **Varying Decentralization**: While compatible, some Arbitrum setups (e.g., centralized sequencers in early stages) may not match Ethereum's decentralization, raising concerns about censorship or single points of failure. diff --git a/docs/launch-arbitrum-chain/partials/config-force-inclusion.mdx b/docs/launch-arbitrum-chain/partials/config-force-inclusion.mdx deleted file mode 100644 index d206480537..0000000000 --- a/docs/launch-arbitrum-chain/partials/config-force-inclusion.mdx +++ /dev/null @@ -1,13 +0,0 @@ -Force inclusion in Arbitrum refers to a mechanism that allows users to bypass the Sequencer by submitting transactions directly to the Delayed Inbox contract on Ethereum, or if the Sequencer doesn't accept the transactions within 24 hours. After a waiting period (~24 hours), it is possible to force the transaction for inclusion on the Arbitrum chain. This mechanism is designed primarily as a safeguard for rare scenarios, such as sequencer downtime or potential censorship. - -## Pros - -- **Guarantees transaction inclusion and liveness**: Even if the Sequencer is unresponsive, malicious, or censoring transactions, force inclusion ensures your transaction is eventually processed, maintaining the chain's operational continuity. -- **Enhances censorship resistance**: It mitigates risks of transaction censorship by allowing direct submission to Layer 1, aligning with Ethereum's decentralized principles and providing a trustless way to interact with the chain. -- **Permissionless and protective**: Anyone can use it to enforce inclusion, protecting against sequencer failures without needing to rely on centralized components. - -## Cons - -- **Significant delay**: There's a mandatory waiting period of approximately 24 hours before force inclusion is triggerable, making it much slower than the near-instant processing via the Sequencer. -- **Higher costs and inefficiency**: Submitting directly to Layer 1 incurs full Ethereum gas fees, which are typically more expensive than Layer 2 transactions. Force inclusion **is not optimal** for regular use—it's intended only for rare, emergency scenarios. -- **Security vulnerabilities**: It can be exploited in certain attacks, such as the QueueCut attack, potentially leading to double-spending or fund losses in cross-chain scenarios. diff --git a/docs/launch-arbitrum-chain/partials/config-l1-challenge-period.mdx b/docs/launch-arbitrum-chain/partials/config-l1-challenge-period.mdx deleted file mode 100644 index f2f21f91b2..0000000000 --- a/docs/launch-arbitrum-chain/partials/config-l1-challenge-period.mdx +++ /dev/null @@ -1,9 +0,0 @@ -Configuring the challenge period on L1 means deploying your Arbitrum chain as a Layer 2 Rollup that settles directly to Ethereum, where assertions are posted, challenged, and confirmed using L1 contracts and block numbers. A Layer 2 configuration contrasts with a Layer 3 configuration, where the chain settles to Arbitrum and the challenge period runs on the L2. The default challenge period is 6.4 days, but it can be customized via the `confirmPeriodBlocks` parameter during deployment or post-deployment by the chain owner. The chain owner can reset the `confirmPeriodBlocks`, using `rollupAdmin.setConfirmPeriodBlocks`. - -| Feature | Pros | Cons | -| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Security | - Directly inherits Ethereum's full L1 security model, with no dependency on an intermediary L2's assumptions or potential vulnerabilities.
- Challenges are resolved on the most decentralized and tested layer, reducing risks from L2-specific issues | - No significant cons here; L1 offers the highest baseline security, though custom shorter periods could theoretically reduce time for fraud detection. | -| Costs | - Avoids compounded fees from an L2 intermediary, potentially simplifying long-term economics for high-security needs | - Higher operational costs: Posting transaction blobs and resolving challenges uses expensive L1 gas (e.g., calldata fees on Ethereum are higher)
- Less suitable for cost-sensitive applications, as L2 settlement can reduce data availability and posting expenses. | -| Finality & Withdrawal times | Faster overall finality for withdrawals directly to L1: ~7 days default challenge period
- Simpler path to Ethereum mainnet settlement, beneficial for users needing quick access to L1 liquidity | - Still requires a ~7 day wait for standard withdrawals, which can feel slow compared to zero-knowledge Rollups or optimized AnyTrust setups
- No benefit from L2's faster block times for intra-layer operations | -| Customization & Flexibility | - The challenge period is easily customizable (e.g., via `Rollup.setConfirmPeriodBlocks`) to balance security and speed, using reliable L1 block timing
- Suitable for applications requiring high-value transfers or strict L1 alignment | - Less flexibility in leveraging L2-specific features (e.g., cheaper data availability committees in AnyTrust mode)
- Customization options are similar to L2 settlement, but adjustments may incur higher gas costs on L1 | -| Overall usability | - Ideal for projects prioritizing maximum decentralization and direct Ethereum integration, avoiding "security stacking" risks | - May limit scalability for high-throughput apps due to L1 congestion or costs; L3 setups on L2 can offer better performance for specialized use cases | diff --git a/docs/launch-arbitrum-chain/partials/config-other-language-support.mdx b/docs/launch-arbitrum-chain/partials/config-other-language-support.mdx deleted file mode 100644 index 1d738b96c9..0000000000 --- a/docs/launch-arbitrum-chain/partials/config-other-language-support.mdx +++ /dev/null @@ -1,17 +0,0 @@ -Arbitrum Stylus represents the mechanism through which Arbitrum chains support programming languages beyond those native to the Ethereum Virtual Machine (EVM), such as Rust. Specifically, Stylus introduces a coequal WebAssembly (WASM)-based virtual machine alongside the EVM, allowing developers to write, compile, and deploy smart contracts in Rust (or other WASM-compatible languages like C and C++) directly on an Arbitrum chain. These WASM contracts are fully interoperable with traditional EVM/Solidity contracts, meaning a Rust program can call a Solidity function and vice versa, without disrupting Ethereum equivalence. Code interoperability opens expansion possibilities of Arbitrum's ecosystem by bridging Web2 and Web3 development paradigms, leveraging Rust's SDK for integration and enabling access to its vast library ecosystem (e.g., crates for cryptography). - -## Pros of Other Language Support (e.g., Rust) on Arbitrum Chains - -- **Broader Developer Accessibility**: Opens the door to millions of Web2 developers proficient in Rust (over 3.5 million) or C/C++ (13 million), reducing the barrier to entry for blockchain development without requiring Solidity expertise and accelerating ecosystem growth. -- **Enhanced Performance and Efficiency**: Rust-compiled WASM contracts execute faster with significantly lower gas fees (e.g., 4-10x cost savings in AMMs, 100-500x cheaper memory), making compute-intensive applications like onchain AI, generative art, high-frequency DeFi, or games feasible on L2 chains. -- **Improved Security and Safety**: Rust's inherent features, like memory safety and default-disabled reentrancy in the Stylus SDK, reduce common vulnerabilities (e.g., cheaper detection of reentrancy attacks), leading to more robust contracts compared to Solidity. -- **Full Interoperability and Flexibility**: Allows mixing Rust/WASM and Solidity code in the same project, enabling optimizations (e.g., rewriting performance-critical parts in Rust) while maintaining access to Ethereum's liquidity and tools. -- **Innovation and Use Case Expansion**: Unlocks advanced features via Rust libraries (e.g., ZK-proof verification, MPC schemes) for applications like privacy-preserving DEXs, DePIN integrations, or tokenization, which are resource-heavy or impractical on pure EVM setups. - -## Cons of Other Language Support (e.g., Rust) on Arbitrum Chains - -- **Learning Curve for Integration**: Developers familiar with EVM/Solidity may face adjustments when handling MultiVM setups, intentional overrides (e.g., for reentrancy), or mixing languages, potentially increasing development time initially. -- **Variable Language Maturity**: While Rust has strong SDK support, other WASM languages (e.g., those with custom runtimes like Python or JavaScript) are more complex to implement and may lack equally mature tooling or libraries for smart contracts. -- **Potential Interoperability Subtleties**: Although fully compatible, differences in execution models between WASM and EVM could introduce edge cases or require additional testing for cross-contract calls. -- **Newer Ecosystem Risks**: As a relatively recent upgrade, Stylus and Rust support might have less battle-tested tools, audits, or community resources compared to the established EVM ecosystem, potentially exposing early adopters to undiscovered issues. -- **Dependency on WASM Limitations**: Relies on WASM's ecosystem, which, while efficient, may impose constraints on certain features or require developers to adapt Web2 code for blockchain constraints like deterministic execution. diff --git a/docs/partials/_glossary-partial.mdx b/docs/partials/_glossary-partial.mdx index 70bf26d3c4..45c98cf324 100644 --- a/docs/partials/_glossary-partial.mdx +++ b/docs/partials/_glossary-partial.mdx @@ -370,7 +370,7 @@ A protocol that allows users to bridge **ETH** and **ERC-20** tokens from Ethere ### MultiVM {#multivm} -MultiVM refers to Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries. Learn more about [Stylus](/stylus/gentle-introduction) and [language support](/launch-arbitrum-chain/partials/config-other-language-support). +MultiVM refers to Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries. Learn more about [Stylus](/stylus/gentle-introduction) and language support. ### Native Fee Token {#native-fee-token} diff --git a/docs/partials/glossary/_multivm.mdx b/docs/partials/glossary/_multivm.mdx index 057651bd29..6000cde9c7 100644 --- a/docs/partials/glossary/_multivm.mdx +++ b/docs/partials/glossary/_multivm.mdx @@ -4,4 +4,4 @@ key: multivm titleforSort: MultiVM --- -MultiVM refers to Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries. Learn more about [Stylus](/stylus/gentle-introduction) and [language support](/launch-arbitrum-chain/partials/config-other-language-support). +MultiVM refers to Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries. Learn more about [Stylus](/stylus/gentle-introduction) and language support. diff --git a/src/components/FloatingHoverModal/index.js b/src/components/FloatingHoverModal/index.js index 795d4595c5..39edacaf39 100644 --- a/src/components/FloatingHoverModal/index.js +++ b/src/components/FloatingHoverModal/index.js @@ -17,47 +17,10 @@ import { MDXProvider } from '@mdx-js/react'; // Remove Link import - we'll use a span instead to avoid Docusaurus broken link detection (Docusaurus's build will fail if a points to a non-existent page) import './styles.css'; -// Import all config partials statically to avoid CSP issues -import ConfigCustomGasToken from '@site/docs/launch-arbitrum-chain/partials/_custom-gas-token-pc.mdx'; -import ConfigAltDa from '@site/docs/launch-arbitrum-chain/partials/_alt-da-pc.mdx'; -import ConfigDedicatedThroughput from '@site/docs/launch-arbitrum-chain/partials/config-dedicated-throughput.mdx'; -import ConfigNativeEth from '@site/docs/launch-arbitrum-chain/partials/_native-eth-pc.mdx'; -import ConfigHardware from '@site/docs/launch-arbitrum-chain/partials/config-hardware.mdx'; -import ConfigRollup from '@site/docs/launch-arbitrum-chain/partials/_rollup-pc.mdx'; -import ConfigAnytrust from '@site/docs/launch-arbitrum-chain/partials/_anytrust-pc.mdx'; -import ConfigFastwithdrawals from '@site/docs/launch-arbitrum-chain/partials/_fast-withdrawals-pc.mdx'; -import ConfigTimeboost from '@site/docs/launch-arbitrum-chain/partials/_timeboost-pc.mdx'; -import ConfigBold from '@site/docs/launch-arbitrum-chain/partials/_bold-pc.mdx'; -import ConfigPermissionedValidators from '@site/docs/launch-arbitrum-chain/partials/_permissioned-validators.mdx'; -import ConfigL1ChallengePeriod from '@site/docs/launch-arbitrum-chain/partials/config-l1-challenge-period.mdx'; -import ConfigForceInclusion from '@site/docs/launch-arbitrum-chain/partials/config-force-inclusion.mdx'; -import ConfigAccountAbstraction from '@site/docs/launch-arbitrum-chain/partials/config-account-abstraction.mdx'; -import ConfigCustomizableGovernance from '@site/docs/launch-arbitrum-chain/partials/config-customizable-governance.mdx'; -import ConfigDataPostingCosts from '@site/docs/launch-arbitrum-chain/partials/config-data-posting-costs.mdx'; -import ConfigEVMCompatibility from '@site/docs/launch-arbitrum-chain/partials/config-evm-compatbility.mdx'; -import ConfigOtherLanguageSupport from '@site/docs/launch-arbitrum-chain/partials/config-other-language-support.mdx'; +// Import all config partials statically to avoid CSP issues format: import ConfigAltDa from '@site/docs/launch-arbitrum-chain/partials/_alt-da-pc.mdx'; -// Static content mapping -const contentMap = { - 'config-custom-gas-token': ConfigCustomGasToken, - 'config-alt-da': ConfigAltDa, - 'config-dedicated-throughput': ConfigDedicatedThroughput, - 'config-native-eth': ConfigNativeEth, - 'config-hardware': ConfigHardware, - 'config-rollup': ConfigRollup, - 'config-anytrust': ConfigAnytrust, - 'config-fast-withdrawals': ConfigFastwithdrawals, - 'config-timeboost': ConfigTimeboost, - 'config-bold': ConfigBold, - 'config-permissioned-validators': ConfigPermissionedValidators, - 'config-l1-challenge-period': ConfigL1ChallengePeriod, - 'config-force-inclusion': ConfigForceInclusion, - 'config-account-abstraction': ConfigAccountAbstraction, - 'config-customizable-governance': ConfigCustomizableGovernance, - 'config-data-posting-costs': ConfigDataPostingCosts, - 'config-evm-compatibility': ConfigEVMCompatibility, - 'config-other-language-support': ConfigOtherLanguageSupport, -}; +// Static content mapping for modals: 'config-custom-gas-token': ConfigCustomGasToken, +const contentMap = {}; // MDX components for proper rendering const mdxComponents = { diff --git a/static/glossary.json b/static/glossary.json index 89e8447b87..2ed9fd1d06 100644 --- a/static/glossary.json +++ b/static/glossary.json @@ -341,7 +341,7 @@ }, "multivm": { "title": "MultiVM", - "text": "

MultiVM refers to Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries. Learn more about Stylus and language support.

\n" + "text": "

MultiVM refers to Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries. Learn more about Stylus and language support.

\n" }, "native-fee-token": { "title": "Native Fee Token",