Sequencing, followed by deterministic execution

This section explores the various methods you can use to submit transactions for inclusion on the Arbitrum chain. We'll discuss the different pathways available—sending transactions to the Sequencer or bypassing it by submitting transactions through the Delayed Inbox contract on the parent chain. By outlining these options, we'll clarify how you can interact with the network, detail the processes involved in each method, and identify the modules responsible for handling these transactions. This overview will enhance your understanding of the initial steps in Arbitrum's transaction lifecycle and prepare you for a detailed exploration of transaction inclusion mechanisms in the subsequent sections.

The first subsection, Submitting transactions to the Sequencer, presents four different methods you can use to send your transactions to the sequencer: via Public RPC, Third-Party RPC, Arbitrum Nodes, and the Sequencer Endpoint. Transactions sent through the first three pathways will route through our Load Balancer before reaching the sequencer. In contrast, the Sequencer Endpoint allows transactions to bypass the Load Balancer and be sent directly to the sequencer.

The second subsection, Bypassing the Sequencer, describes an alternative method where you can include your transactions on the Arbitrum chain without relying on the sequencer. By sending transactions directly to the Delayed Inbox contract on the parent chain, you gain additional flexibility, ensuring that your transactions can be processed even if the sequencer is unavailable or if you prefer not to use it.

This diagram illustrates the various pathways for submitting transactions to the Arbitrum chain. It highlights the options for sending transactions through the sequencer or bypassing it and using the Delayed Inbox contract on the parent chain.

Submitting transactions to the sequencer

This section outlines the different methods you can use to submit transactions to the sequencer on the Arbitrum chain. There are four primary ways to do this: Public RPC, Third-Party RPCs, Arbitrum Nodes, and the Sequencer Endpoint. We'll explore these methods in detail, explaining when to choose one over the other and how to use each to effectively submit transactions to the Arbitrum sequencer.

1. Public RPC

Arbitrum provides public RPCs for its main chains: Arbitrum One, Arbitrum Nova, and Arbitrum Sepolia. Due to their rate-limited nature, these RPC endpoints are suitable for less resource-intensive operations. Public RPCs can be an accessible option for general use cases and light interactions with the network.

For more details on the specific RPC endpoints for each chain, please see the Arbitrum public RPC endpoints section of the documentation.

2. Third-party RPC

You also have the option to interact with Arbitrum's public chains using third-party node providers. These providers are often the same popular ones used for Ethereum, making them reliable choices for resource-intensive operations. We recommend using these third-party providers when performance and scalability are critical.

You can find a list of supported third-party providers in our documentation.

3. Arbitrum nodes

Another approach for sending transactions to the sequencer is through self-hosted Arbitrum nodes. Running a node gives you direct control over your transactions, which go to the sequencer via the Sequencer Feed.

Please see the Arbitrum node documentation to learn more about setting up and running a node.

4. Sequencer endpoint

The Sequencer Endpoint is the most direct method if you're looking to minimize delays in your transactions reaching the sequencer. Unlike standard RPC URLs, the Sequencer Endpoint supports only eth_sendRawTransaction and eth_sendRawTransactionConditional calls, bypassing the load balancer entirely. This endpoint makes it an optimal choice if you require the quickest transaction processing time.

The diagram below shows different ways to submit transactions to the sequencer:

Bypassing the sequencer

This section delves into an alternative method for submitting transactions to the Arbitrum chain, bypassing the sequencer. This page focuses on how you can send your transactions directly to the Delayed Inbox contract on the parent chain rather than through the sequencer. This method offers two distinct paths a transaction can take, with each route interacting with the network differently to achieve transaction inclusion. This approach provides you with greater flexibility and ensures that transactions can still be processed if the sequencer is unavailable or if you choose not to depend on it. This section highlights these alternative submission mechanisms and underscores the robustness and decentralization features inherent in the Arbitrum network.

In Diagram 3, we demonstrate how you can submit your transactions using the Delayed Inbox contract to bypass the sequencer. As illustrated in the diagram, there are two possible paths for transaction handling. When a transaction is submitted to the Delayed Inbox, the sequencer may automatically pick it up, include it as an ordered transaction, and send it to the sequencer feed. However, if the sequencer doesn't process the transaction within 24 hours, you have the reliable option to call the forceInclude function on the SequencerInbox contract. This action ensures that the sequencer picks up the transaction and includes it in the ordered transaction list, providing you with security about your transactions.

To send a transaction to the Delayed Inbox instead of submitting it to the sequencer, you can construct your transaction and then call the sendL2Message function, passing the data of the serialized signed transaction as an argument. This function allows you to send generic child chain messages to the chain, suitable for any message that doesn't require parent chain validation.

If the sequencer isn't back online within 24 hours or decides to censor the transaction, you can invoke the forceInclusion function on the SequencerInbox contract. This action ensures your transaction is included on the chain, bypassing the sequencer's role.

Additionally, the Arbitrum SDK provides the InboxTools class, which simplifies the process of submitting transactions to the Delayed Inbox. You can use the sendChildSignedTx method to send the transaction and the forceInclude method to ensure its inclusion. The SDK also offers helper methods like signChildTx to assist with signing the transaction during the creation of the serialized signed transaction hex string, streamlining the entire process.