Skip to main content

How to run a local dev node with Stylus support


Stylus is currently tagged as an alpha release. The code has not been audited, and should not be used in production scenarios. This documentation is currently in public preview.

To provide feedback, click the Request an update button at the top of this document, join the Arbitrum Discord, or reach out to our team directly by completing this form.

This how-to guides you through the process of setting up a local Arbitrum Nitro dev node, with Stylus support, to help you deploy and test smart contracts written in Solidity or any of the languages supported by Stylus in a fully controlled environment. By following these steps, you'll deploy and run a full development environment on your local machine that includes a Nitro dev node (L2), a dev-mode geth parent chain (L1), and multiple instances with different roles.

Step 1. Install prerequisites

You'll need docker and docker compose to run your node. Follow the instructions in their site to install them.

Step 2. Clone the nitro-testnode repo

You'll need the stylus branch.

git clone -b stylus --recurse-submodules && cd nitro-testnode

Step 3. Run your node

./test-node.bash --init

Step 4. Successive runs

To relaunch the node after the first installation, run the following command.

Clear local data

Note that running with the --init flag will clear all chain data and redeploy!

Rollup contract addresses and chain configuration

You can obtain the rollup chain configuration by running the following command. The chain configuration also includes the addresses of the core contracts.

docker exec nitro-testnode-sequencer-1 cat /config/l2_chain_info.json

You can find other available configuration files by running:

docker exec nitro-testnode-sequencer-1 ls /config

Token bridge

An L1-L2 token bridge can be deployed by using the parameter --tokenbridge. The list of contracts can be found by running:

docker compose run --entrypoint sh tokenbridge -c "cat l1l2_network.json"

Running an L3 chain

An L3 chain can be deployed on top of the L2 chain, by using the parameter --l3node. Its chain configuration can be found by running:

docker exec nitro-testnode-sequencer-1 cat /config/l3_chain_info.json

Additional arguments

You can find a list of additional arguments to use with test-node.bash by using --help.

./test-node.bash --help

Helper scripts

The repository includes a set of helper scripts for basic actions like funding accounts or bridging funds. You can see a list of the available scripts by running:

./test-node.bash script --help

If you want to see information of a particular script, you can add the name of the script to the help command.

./test-node.bash script send-l1 --help

Here's an example of how to run the script that funds an address on L2. Replace 0x11223344556677889900 with the address you want to fund.

./test-node.bash script send-l2 --to address_0x11223344556677889900 --ethamount 5


Nitro comes with a local Blockscout block explorer. To access it, add the param --blockscout when running your node.

./test-node.bash --blockscout

The block explorer will be available at http://localhost:4000

Default endpoints and addresses

Node RPC endpoints are available at:

NodeChain idRPC endpoint
L1 geth devnet1337http://localhost:8545
L2 nitro devnet412346http://localhost:8547 and ws://localhost:8548
L3 nitro (if enabled)333333http://localhost:3347

Some important addresses:

RolePublic addressPrivate key
L2 rollup owner0x5E1497dD1f08C87b2d8FE23e9AAB6c1De833D9270xdc04c5399f82306ec4b4d654a342f40e2e0620fe39950d967e1e574b32d4dd36
L3 rollup owner (if enabled)0x863c904166E801527125D8672442D736194A33620xecdf21cb41c65afb51f91df408b7656e2c8739a5877f2814add0afd780cc210e
L3 sequencer (if enabled)0x3E6134aAD4C4d422FF2A4391Dc315c4DDf98D1a50x90f899754eb42949567d3576224bf533a20857bf0a60318507b75fcb3edc6f5f
Dev account (prefunded with ETH in all networks)0x3f1Eae7D46d88F08fc2F8ed27FCb2AB183EB2d0E0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659

You can fund other addresses by using the scripts send-l1 and send-l2 as explained here.

Private keys publicly known

Do not use any of these addresses in a production environment.