diff --git a/arbitrum-docs/arbitrum-bridge/01-quickstart.mdx b/arbitrum-docs/arbitrum-bridge/01-quickstart.mdx index e27ea8c24..f978ef4c9 100644 --- a/arbitrum-docs/arbitrum-bridge/01-quickstart.mdx +++ b/arbitrum-docs/arbitrum-bridge/01-quickstart.mdx @@ -74,7 +74,7 @@ Also make sure your wallet is set to the destination chain so you can see your f :::info There's at least a 7 day withdrawal period for Arbitrum One and Nova networks Once you withdraw your funds from Arbitrum One or Nova through the Arbitrum bridge, you will have to wait for at least 7 days to receive them on Ethereum mainnet. -For more details, see [Arbitrum Bridge: Troubleshooting](/arbitrum-bridge/03-troubleshooting.mdx#how-long-does-it-take-before-i-receive-my-funds-when-i-initiate-withdrawal-from-arbitrum-chains-one-and-nova). +For more details, see [Arbitrum Bridge: Troubleshooting](https://docs.arbitrum.io/arbitrum-bridge/troubleshooting#how-long-does-it-take-before-i-receive-my-funds-when-i-initiate-a-withdrawal-from-arbitrum-chains-one-and-nova). ::: diff --git a/arbitrum-docs/build-decentralized-apps/01-quickstart-solidity-hardhat.mdx b/arbitrum-docs/build-decentralized-apps/01-quickstart-solidity-hardhat.mdx index 17ec2e66f..984e56a4d 100644 --- a/arbitrum-docs/build-decentralized-apps/01-quickstart-solidity-hardhat.mdx +++ b/arbitrum-docs/build-decentralized-apps/01-quickstart-solidity-hardhat.mdx @@ -513,7 +513,7 @@ If you have any questions or feedback, reach out to us on [Discord](https://disc - Visit [How to estimate gas](/build-decentralized-apps/02-how-to-estimate-gas.mdx) to learn how to estimate the gas cost of your smart contract transactions. -- Visit [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx#rpc-endpoints) for a list of public chains that you can deploy your smart contracts to. +- Visit [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx) for a list of public chains that you can deploy your smart contracts to. [^1]: The vending machine example was inspired by [Ethereum.org's "Introduction to Smart Contracts"](https://ethereum.org/en/developers/docs/smart-contracts/), which was inspired by [Nick Szabo's "From vending machines to smart contracts"](http://unenumerated.blogspot.com/2006/12/from-vending-machines-to-smart.html). [^2]: Although application front-ends are usually hosted by centralized services, smart contracts allow the underlying logic and data to be partially or fully decentralized. These smart contracts are hosted and executed by Ethereum's public, decentralized network of nodes. Arbitrum has its own network of nodes that use advanced cryptography techniques to "batch process" Ethereum transactions and then submit them to Ethereum L1, which significantly reduces the cost of using Ethereum. All without requiring developers to compromise on security or decentralization. diff --git a/arbitrum-docs/build-decentralized-apps/precompiles/02-reference.mdx b/arbitrum-docs/build-decentralized-apps/precompiles/02-reference.mdx index e398b3628..37edc16a3 100644 --- a/arbitrum-docs/build-decentralized-apps/precompiles/02-reference.mdx +++ b/arbitrum-docs/build-decentralized-apps/precompiles/02-reference.mdx @@ -179,7 +179,7 @@ import ArbOwnerPublicRef from '../../for-devs/dev-tools-and-resources/partials/p ### ArbRetryableTx -ArbRetryableTx ([Interface][arbretryabletx_link_interface] | [Implementation][arbretryabletx_link_implementation]) provides methods for managing retryables. The model has been adjusted for Nitro, most notably in terms of how retry transactions are scheduled. For more information on retryables, please see [the retryable documentation](/how-arbitrum-works/arbos/introduction.mdx#Retryables). +ArbRetryableTx ([Interface][arbretryabletx_link_interface] | [Implementation][arbretryabletx_link_implementation]) provides methods for managing retryables. The model has been adjusted for Nitro, most notably in terms of how retry transactions are scheduled. For more information on retryables, please see [the retryable documentation](/how-arbitrum-works/arbos/l1-l2-messaging.mdx#retryable-tickets). Precompile address: `0x000000000000000000000000000000000000006E` diff --git a/arbitrum-docs/build-decentralized-apps/token-bridging/bridge-tokens-programmatically/02-how-to-bridge-tokens-standard.mdx b/arbitrum-docs/build-decentralized-apps/token-bridging/bridge-tokens-programmatically/02-how-to-bridge-tokens-standard.mdx index 04294c61d..f54a4a12e 100644 --- a/arbitrum-docs/build-decentralized-apps/token-bridging/bridge-tokens-programmatically/02-how-to-bridge-tokens-standard.mdx +++ b/arbitrum-docs/build-decentralized-apps/token-bridging/bridge-tokens-programmatically/02-how-to-bridge-tokens-standard.mdx @@ -83,7 +83,7 @@ As explained in the conceptual page, there are 2 contracts that we need to be aw For simplicity, in this how-to we’ll focus on the first case: bridging from Ethereum (L1) to Arbitrum (L2). -We’ll explain below what specific contracts and methods need to be called to bridge your token, but you can abstract this whole process of finding the right addresses by using Arbitrum’s SDK. You can use the [deposit](../../../sdk/reference/assetBridger/erc20Bridger.md#deposit) function of the [Erc20Bridger](../../../sdk/reference/assetBridger/erc20Bridger.md) class to bridge your tokens, which will use the appropriate router contract based on the network you’re connected to, and will relay the request to the appropriate gateway contract. You can also use the function [getParentGatewayAddress](../../../sdk/reference/assetBridger/erc20Bridger.md#getParentGatewayAddress) to get the address of the gateway contract that’s going to be used. But don’t worry about any of this yet, we’ll use those functions in the next steps. +We’ll explain below what specific contracts and methods need to be called to bridge your token, but you can abstract this whole process of finding the right addresses by using Arbitrum’s SDK. You can use the [deposit](../../../sdk/reference/assetBridger/erc20Bridger.md#deposit) function of the [Erc20Bridger](../../../sdk/reference/assetBridger/erc20Bridger.md) class to bridge your tokens, which will use the appropriate router contract based on the network you’re connected to, and will relay the request to the appropriate gateway contract. You can also use the function [getParentGatewayAddress](https://docs.arbitrum.io/sdk/reference/assetBridger/erc20Bridger#getparentgatewayaddress) to get the address of the gateway contract that’s going to be used. But don’t worry about any of this yet, we’ll use those functions in the next steps. Now, here’s an explanation of the contracts and methods that need to be called to manually bridge your token: @@ -197,7 +197,7 @@ If you’re going the manual way, you can verify if the message has been execute Finally, let’s find the token contract that has been created on L2. -Using Arbitrum’s SDK, you can call method [getChildErc20Address](../../../sdk/reference/assetBridger/erc20Bridger.md#getChildErc20Address) of the [Erc20Bridger](../../../sdk/reference/assetBridger/erc20Bridger.md) class, which will return the address of the token contract in L2 that corresponds to the L1 token contract sent as parameter. +Using Arbitrum’s SDK, you can call method [getChildErc20Address](https://docs.arbitrum.io/sdk/reference/assetBridger/erc20Bridger#getchildgatewayaddress) of the [Erc20Bridger](../../../sdk/reference/assetBridger/erc20Bridger.md) class, which will return the address of the token contract in L2 that corresponds to the L1 token contract sent as parameter. ```tsx /** diff --git a/arbitrum-docs/how-arbitrum-works/arbos/geth.mdx b/arbitrum-docs/how-arbitrum-works/arbos/geth.mdx index 0868c3f13..6057b6073 100644 --- a/arbitrum-docs/how-arbitrum-works/arbos/geth.mdx +++ b/arbitrum-docs/how-arbitrum-works/arbos/geth.mdx @@ -21,7 +21,7 @@ Please note any links on this page may be referencing old releases of Nitro or o Arbitrum uses various hooks to modify Geth's behavior when processing transactions. Each provides an opportunity for ArbOS to update its state and make decisions about the transaction during its lifetime. Transactions are applied using Geth's [`ApplyTransaction`][applytransaction_link] function. -Below is [`ApplyTransaction`][applytransaction_link]'s callgraph, with additional info on where the various Arbitrum-specific hooks are inserted. Click on any to go to their section. By default, these hooks do nothing so as to leave Geth's default behavior unchanged, but for chains configured with [`EnableArbOS`](/how-arbitrum-works/arbos/geth#EnableArbOS) set to true, [`ReadyEVMForL2`](#ReadyEVMForL2) installs the alternative L2 hooks. +Below is [`ApplyTransaction`][applytransaction_link]'s callgraph, with additional info on where the various Arbitrum-specific hooks are inserted. Click on any to go to their section. By default, these hooks do nothing so as to leave Geth's default behavior unchanged, but for chains configured with [`EnableArbOS`](#enablearbos) set to true, [`ReadyEVMForL2`](#ReadyEVMForL2) installs the alternative L2 hooks. - `core.ApplyTransaction` ⮕ `core.applyTransaction` ⮕ `core.ApplyMessage` - `core.NewStateTransition` @@ -34,7 +34,7 @@ Below is [`ApplyTransaction`][applytransaction_link]'s callgraph, with additiona - `evm.Call` - `core.vm.EVMInterpreter.Run` - [`PushCaller`](#PushCaller) - - [`PopCaller`](/how-arbitrum-works/arbos/geth#PopCaller) + - `PopCaller` - `core.StateTransition.refundGas` - [`ForceRefundGas`](#ForceRefundGas) - [`NonrefundableGas`](#NonrefundableGas) @@ -176,11 +176,11 @@ Represents a user deposit from L1 to L2. This increases the user's balance by th ### [`ArbitrumSubmitRetryableTx`][arbitrumsubmitretryabletx_link]{#ArbitrumSubmitRetryableTx} -Represents a retryable submission and may schedule an [`ArbitrumRetryTx`](#ArbitrumRetryTx) if provided enough gas. Please see the [retryables documentation](/how-arbitrum-works/arbos/introduction.mdx#retryables) for more info. +Represents a retryable submission and may schedule an [`ArbitrumRetryTx`](#ArbitrumRetryTx) if provided enough gas. Please see the [retryables documentation](/how-arbitrum-works/arbos/l1-l2-messaging.mdx#retryable-tickets) for more info. ### [`ArbitrumRetryTx`][arbitrumretrytx_link]{#ArbitrumRetryTx} -These are scheduled by calls to the `redeem` method of the [ArbRetryableTx](/build-decentralized-apps/precompiles/02-reference.mdx#arbretryabletx) precompile and via retryable auto-redemption. Please see the [retryables documentation](/how-arbitrum-works/arbos/introduction.mdx#Retryables) for more info. +These are scheduled by calls to the `redeem` method of the [ArbRetryableTx](/build-decentralized-apps/precompiles/02-reference.mdx#arbretryabletx) precompile and via retryable auto-redemption. Please see the [retryables documentation](/how-arbitrum-works/arbos/l1-l2-messaging.mdx#retryable-tickets) for more info. ### [`ArbitrumInternalTx`][arbitruminternaltx_link]{#ArbitrumInternalTx} diff --git a/arbitrum-docs/how-arbitrum-works/arbos/introduction.mdx b/arbitrum-docs/how-arbitrum-works/arbos/introduction.mdx index dbd7944e5..729f4b72a 100644 --- a/arbitrum-docs/how-arbitrum-works/arbos/introduction.mdx +++ b/arbitrum-docs/how-arbitrum-works/arbos/introduction.mdx @@ -81,7 +81,7 @@ Based on this information, ArbOS maintains an L1 data fee, also tracked as part The L2 pricing state tracks L2 resource usage to determine a reasonable L2 gas price. This process considers a variety of factors, including user demand, the state of Geth, and the computational speed limit. The primary mechanism for doing so consists of a pair of pools, one larger than the other, that drain as L2-specific resources are consumed and filled as time passes. L1-specific resources like L1 `calldata` are not tracked by the pools, as they have little bearing on the actual work done by the network actors that the speed limit is meant to keep stable and synced. -While much of this state is accessible through the [`ArbGasInfo`](/build-decentralized-apps/precompiles/02-reference.mdx#arbgasinfo) and [`ArbOwner`](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner) precompiles, most changes are automatic and happen during [block production][block_production_link] and [the transaction hooks](/how-arbitrum-works/arbos/geth#Hooks). Each of an incoming message's transactions removes from the pool the L2 component of the gas it uses, and afterward the message's timestamp [informs the pricing mechanism][notify_pricer_link] of the time that's passed as ArbOS [finalizes the block][finalizeblock_link]. +While much of this state is accessible through the [`ArbGasInfo`](/build-decentralized-apps/precompiles/02-reference.mdx#arbgasinfo) and [`ArbOwner`](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner) precompiles, most changes are automatic and happen during [block production][block_production_link] and [the transaction hooks](/how-arbitrum-works/arbos/geth.mdx#hooks). Each of an incoming message's transactions removes from the pool the L2 component of the gas it uses, and afterward the message's timestamp [informs the pricing mechanism][notify_pricer_link] of the time that's passed as ArbOS [finalizes the block][finalizeblock_link]. ArbOS's larger gas pool [determines][maintain_limit_link] the per-block gas limit, setting a dynamic [upper limit][per_block_limit_link] on the amount of compute gas an L2 block may have. This limit is always enforced, though for the [first transaction][first_transaction_link] it's done in the [GasChargingHook](geth#GasChargingHook) to avoid sharp decreases in the L1 gas price from over-inflating the compute component purchased to above the gas limit. This improves UX by allowing the first transaction to succeed rather than requiring a resubmission. Because the first transaction lowers the amount of space left in the block, subsequent transactions do not employ this strategy and may fail from such compute-component inflation. This is acceptable because such transactions are only present in cases where the system is under heavy load and the result is that the user's transaction is dropped without charges since the state transition fails early. Those trusting the sequencer can rely on the transaction being automatically resubmitted in such a scenario. diff --git a/arbitrum-docs/launch-orbit-chain/how-tos/customize-arbos.mdx b/arbitrum-docs/launch-orbit-chain/how-tos/customize-arbos.mdx index 5c7c62386..1982278b8 100644 --- a/arbitrum-docs/launch-orbit-chain/how-tos/customize-arbos.mdx +++ b/arbitrum-docs/launch-orbit-chain/how-tos/customize-arbos.mdx @@ -12,7 +12,7 @@ import CustomizeCautionBannerPartial from '../partials/_orbit-customize-caution- ## Cases where you may want to consider customizing your own ArbOS upgrade -1. When you want to make changes to your Nitro code that affect the State Transition Function, or STF (you may refer to the [Customize STF docs](./customize-stf.mdx#Preface)), and +1. When you want to make changes to your Nitro code that affect the State Transition Function, or STF (you may refer to the [Customize STF docs](./customize-stf.mdx#introduction)), and 2. If your desired changes need to be made to a live and operational Orbit chain @@ -26,7 +26,7 @@ Below, you will find 4 examples of ArbOS-related code changes and, generally, ho ### 1. Add a new method to exsiting precompile on a specific ArbOS version: -After you add `sayHi()` to `ArbSys.go` according to the guide in [customize precompile option 1](./customize-precompile.mdx#option-1-Add-new-methods-to-an-existing-precompile), +After you add `sayHi()` to `ArbSys.go` according to the guide in [customize precompile option 1](./customize-precompile.mdx#option-1-add-new-methods-to-an-existing-precompile), you need continue to modify [precompile.go][precompile_main_file_link]. For example, the original code is: diff --git a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-configuring-orbit-chain.md b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-configuring-orbit-chain.md index 1425a1de8..6e4fa3e36 100644 --- a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-configuring-orbit-chain.md +++ b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-configuring-orbit-chain.md @@ -26,7 +26,7 @@ Orbit chains have three areas of configuration: ## 1. Parent chain configuration -Configuring the parent chain is the initial step to setting up your Orbit chain. Most of the parent chain configurations are specified during the setup phase. Detailed instructions can be found in the [Rollup Deployment Parameters](orbit-sdk-deploying-rollup-chain#rollup-deployment-parameter) section of the Rollup deployment guide. +Configuring the parent chain is the initial step to setting up your Orbit chain. Most of the parent chain configurations are specified during the setup phase. Detailed instructions can be found in the [Rollup Deployment Parameters](/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md#rollup-deployment-parameters) section of the Rollup deployment guide. After the initial setup, the chain owner can modify configurations as needed. For instance, the validator set can be updated by invoking the [`setValidKeyset`](https://github.com/OffchainLabs/nitro-contracts/blob/90037b996509312ef1addb3f9352457b8a99d6a6/src/bridge/SequencerInbox.sol#L751) function with a new set of validators. This adaptability facilitates your chain's optimization and management. @@ -53,7 +53,7 @@ You can use these setter functions to configure the child chain parameters: | `setInfraFeeAccount` | Sets the infrastructure fee account address, which receives all fees collected on the child chain. It is meant to receive the minimum base fee, with any amount above that going to the network fee account. | | `setNetworkFeeAccount` | Sets the network fee account address. As mentioned, this address collects all fees above the base fee. Note that if you set this amount to the 0 address on your chain, all fees will be deposited into the infrastructure fee account. | | `scheduleArbOSUpgrade` | If you plan to upgrade the ArbOS version of your chain, this method can help you schedule the upgrade. For a complete guide, please refer to the explanation for the [arbos upgrade](arbos-upgrade.md). | -| `setChainConfig` | We discussed the `chainConfig` in the [Rollup deployment guide](orbit-sdk-deploying-rollup-chain.md#chain-config-parameter) in detail. If you wish to change any field of the `chainConfig`, you need to use this method on the child chain. | +| `setChainConfig` | We discussed the `chainConfig` in the [Rollup deployment guide](./orbit-sdk-deploying-rollup-chain.md#4-chainconfig) in detail. If you wish to change any field of the `chainConfig`, you need to use this method on the child chain. | ### Getter functions diff --git a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-anytrust-chain.md b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-anytrust-chain.md index 5f696f09b..64f56802c 100644 --- a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-anytrust-chain.md +++ b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-anytrust-chain.md @@ -30,7 +30,7 @@ AnyTrust chains implement the Arbitrum AnyTrust protocol, an alternative to the ### Deployment steps -The deployment process of AnyTrust chains is very similar to that of [Rollup chains](orbit-sdk-deploying-rollup-chain.md#rollup-config-param), but with some differences that we'll discuss in this guide. +The deployment process of AnyTrust chains is very similar to that of [Rollup chains](/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md#rollup-configuration-parameters), but with some differences that we'll discuss in this guide. Here are the steps involved in the deployment process: diff --git a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md index 75cd3a563..eefa942a0 100644 --- a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md +++ b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md @@ -194,7 +194,7 @@ The Orbit SDK provides two APIs, `createRollupPrepareDeploymentParamsConfig` and This API is designed to take parameters defined in the Config struct and fill in the rest with default values. It outputs a complete Config struct that is ready for use. -For example, to create a Config struct with a specific chain ID (`chainId`), an owner address (`deployer_address`), and a `chainConfig` as described in the [previous section](/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain#chain-config-parameter), you would use the Orbit SDK as follows: +For example, to create a Config struct with a specific chain ID (`chainId`), an owner address (`deployer_address`), and a `chainConfig` as described in the [previous section](#rollup-configuration-parameters), you would use the Orbit SDK as follows: ```js import { createPublicClient, http } from 'viem'; diff --git a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge.md b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge.md index 41be9bd26..4ff984ea8 100644 --- a/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge.md +++ b/arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge.md @@ -44,8 +44,8 @@ Once an Orbit chain has been deployed and initialized, the bridge contracts need The token bridge deployment process is the same for all Orbit chains types except for the following: -- **Custom fee token Orbit chains** which require [token approval](/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge#step-1). -- **`ETH`-based Orbit chains**, for which you need to [set up a WETH gateway](/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge#step-5). +- **Custom fee token Orbit chains** which require [token approval](#1-token-approval). +- **`ETH`-based Orbit chains**, for which you need to [set up a WETH gateway](#5-setting-up-the-weth-gateway). ::: @@ -93,7 +93,7 @@ Please note that after generating the raw transaction, the deployer must still s Deploying token bridge contracts is the first step in creating a bridge between the parent and the Orbit chain. -The deployment process is the same as Orbit chain contracts', where a primary contract facilitates the deployment of core contracts. The token bridge contracts are deployed on the parent and child chains by `TokenBridgeCreator`. `TokenBridgeCreator` does it in a single transaction using the [ Retryable Tickets protocol ](/how-arbitrum-works/arbos/l1-l2-messaging.mdx#retryable-ticketsO). +The deployment process is the same as Orbit chain contracts', where a primary contract facilitates the deployment of core contracts. The token bridge contracts are deployed on the parent and child chains by `TokenBridgeCreator`. `TokenBridgeCreator` does it in a single transaction using the [ Retryable Tickets protocol ](/how-arbitrum-works/arbos/l1-l2-messaging.mdx#retryable-tickets). Orbit SDK provides an API that automates the deployment by interacting with the `TokenBridgeCreator` contract. The API is `createTokenBridgePrepareTransactionRequest`, which processes the necessary inputs and generates a transaction request tailored for token bridge deployment. diff --git a/arbitrum-docs/launch-orbit-chain/orbit-sdk-introduction.md b/arbitrum-docs/launch-orbit-chain/orbit-sdk-introduction.md index 4950b956b..032fa5e21 100644 --- a/arbitrum-docs/launch-orbit-chain/orbit-sdk-introduction.md +++ b/arbitrum-docs/launch-orbit-chain/orbit-sdk-introduction.md @@ -17,11 +17,11 @@ The Arbitrum Orbit SDK lets you programmatically create and manage your own Orbi There are three types of Orbit chains. Review the following table to determine which type best fits your needs: -| Chain Type | Description | Use Case | -| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -| **Rollup** | Offers Ethereum-grade security by batching, compressing, and posting data to the parent chain, similarly to [Arbitrum One](https://arbitrum.io/). | Ideal for applications that require high security guarantees. | -| **AnyTrust** | Implements the [AnyTrust protocol](/how-arbitrum-works/inside-arbitrum-nitro.mdx#inside-anytrust), relying on an external [Data Availability Committee (DAC)](/intro/glossary#data-availability-committee-dac) to store data and provide it on-demand instead of using their [parent chain](/intro/glossary/#parent-chain) as the Data Availability (DA) layer. | Suitable for applications that require lower transaction fees. | -| **Custom gas token** | An AnyTrust Orbit chain with the ability to specify a custom `ERC-20` gas token. | Ideal for applications that require custom gas fee tokens and lower transaction fees. | +| Chain Type | Description | Use Case | +| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | +| **Rollup** | Offers Ethereum-grade security by batching, compressing, and posting data to the parent chain, similarly to [Arbitrum One](https://arbitrum.io/). | Ideal for applications that require high security guarantees. | +| **AnyTrust** | Implements the [AnyTrust protocol](/how-arbitrum-works/inside-arbitrum-nitro.mdx#inside-anytrust), relying on an external [Data Availability Committee (DAC)](/intro/glossary#data-availability-committee-dac) to store data and provide it on-demand instead of using their [parent chain](https://docs.arbitrum.io/intro/glossary#parent-chain) as the Data Availability (DA) layer. | Suitable for applications that require lower transaction fees. | +| **Custom gas token** | An AnyTrust Orbit chain with the ability to specify a custom `ERC-20` gas token. | Ideal for applications that require custom gas fee tokens and lower transaction fees. | ## 2. Deploy your chain diff --git a/arbitrum-docs/stylus/stylus-quickstart.mdx b/arbitrum-docs/stylus/stylus-quickstart.mdx index 46757859c..cb4605ee8 100644 --- a/arbitrum-docs/stylus/stylus-quickstart.mdx +++ b/arbitrum-docs/stylus/stylus-quickstart.mdx @@ -14,7 +14,7 @@ This guide will get you started with Stylus' 2. [Creating a Stylus project with cargo stylus](./stylus-quickstart#creating-a-stylus-project-with-cargo-stylus) 3. [Checking the validity of your contract](./stylus-quickstart#checking-if-your-stylus-project-is-valid) 4. [Deploying your contract](./stylus-quickstart#deploying-your-contract) -5. [Exporting your contract's ABIs](/stylus/stylus-quickstart#exporting-solidity-abis) +5. [Exporting your contract's ABIs](#exporting-the-solidity-abi-interface) 6. [Calling your contract](./stylus-quickstart#calling-your-contract) 7. [Sending a transaction to your contract](./stylus-quickstart#sending-a-transaction-to-your-contract) @@ -203,7 +203,7 @@ deployment tx total cost: "0.000712373700000000" ETH ### Deployment -Let's move on to the contract's actual deployment. Two transactions will be sent onchain: the contract deployment and its [activation](stylus/stylus-gentle-introduction.md#activation). +Let's move on to the contract's actual deployment. Two transactions will be sent onchain: the contract deployment and its [activation](/stylus/stylus-gentle-introduction.md#activation). ```shell cargo stylus deploy \