Skip to main content

​
Chain Specific ENVs

The following ENVs are specific to different types of chains and rollups. To use these specific variables you will also need to set the CHAIN_TYPE variable to the appropriate value.

​
Runtime vs Compile-time Chain Types

Prior to v8.0.0, updating CHAIN_TYPE variable required recompilation. Starting with v8.0.0, many chain types can be configured at runtime.

​
Runtime-Configurable Chain Types

These chain types can be configured by simply setting an environment variable with the standard image:
  • default (standard EVM chain)
  • neon
  • stability
  • blackfort
  • shibarium
Example:

​
Compile-time Chain Types

These specialized chain types still require recompilation and dedicated images:
  • ethereum
  • optimism
  • optimism-celo (Celo on OP Stack)
  • arbitrum
  • rsk
  • scroll
  • suave
  • zetachain
  • filecoin
Example:
You can browse all available image variants in the Blockscout GitHub Packages repository. Each image variant includes specific tags and documentation for deployment options.

​
Time format

Can be set in format 1h for 1 hour, 1m for 1 minute, 1s or 1 for 1 second, 1ms for 1 millisecond. If no unit is provided, the value will be interpreted as seconds.
Note : Before release 5.1.2, all environment variables of time format supported only integers in seconds (without dimensions) as values.

​
Ethereum Management

​
Rootstock Management

​
Scroll management

​
Shibarium Management

​
Optimism Rollup Management

Supported together with ENV setting CHAIN_TYPE=optimism

​
zkSync Rollup Management

Supported together with setting CHAIN_TYPE=zksync

​
Arbitrum Management

Supported together with setting CHAIN_TYPE=arbitrum

​
Celo Management

Supported together with setting CHAIN_TYPE=optimism-celoStarting from v9.3.0, Celo runs on the OP Stack infrastructure while maintaining Celo-specific features including:
  • Epochs
  • Election rewards
  • Token duality
  • All standard Optimism features (deposits, withdrawals, batches, etc.)
Migration Notice: Prior to v9.3.0, Celo used CHAIN_TYPE=celo. This has been changed to CHAIN_TYPE=optimism-celo to reflect Celo’s migration to the OP Stack while preserving Celo-specific functionality.For instances deployed before v9.3.0, you must:
  1. Update CHAIN_TYPE from celo to optimism-celo
  2. Use the optimism-celo Docker image
  3. Configure both Optimism and Celo-specific environment variables
  4. Expect heavy migrations!

​
Required Optimism ENVs for Celo

Since Celo runs on the OP Stack, you must also configure all applicable Optimism environment variables from the Optimism Rollup Management section above.
For Celo network configurations, contract addresses, and deployment assets, refer to the official Celo Network Config & Assets documentation.
The CELO network includes several core contracts that are central to its operation. These core contracts manage various aspects of the Celo network, including its stablecoins, governance, identity, and more.All these contracts can be obtained by querying the Registry contract, which is deployed at the genesis block with the address 0x000000000000000000000000000000000000ce10. This contract serves as a repository for the addresses of all core contracts on the Celo network.Fortunately, core contracts are not updated frequently, so we store information about core contracts statically under the CELO_CORE_CONTRACTS variable, which is a JSON object of a specified structure.In case the contracts are updated, maintaining the Blockscout instance will require updating the CELO_CORE_CONTRACTS variable and manually setting blocks for refetch (all blocks produced after the core contracts’ update).The structure of the JSON value for the CELO_CORE_CONTRACTS variable is detailed in this gist.The JSON structure may change. To assemble the CELO_CORE_CONTRACTS environment variable, run mix fetch_celo_core_contracts in the root of the Blockscout repository. This task will index the chain from block 0 to the latest block number, providing the most up-to-date values.The JSON structure in the gist contains two main sections: addresses and events.
  • addresses: This section maps contract names to the list of respective addresses and the block number at which they were updated. For example:
    • "Accounts": [{ "address": "0xed7f51a34b4e71fbe69b3091fcf879cd14bd73a9", "updated_at_block_number": 574 }]
    • "Election": [{ "address": "0x1c3edf937cfc2f6f51784d20deb1af1f9a8655fa", "updated_at_block_number": 592 }]
  • events: This section maps contract addresses to the events associated with them, including any parameters and the block numbers at which these events were emitted. For example:
    • "EpochRewards": { "0xb10ee11244526b94879e1956745ba2e35ae2ba20": { "CarbonOffsettingFundSet": [{ "address": "0x22579ca45ee22e2e16ddf72d955d6cf4c767b0ef", "updated_at_block_number": 15049265 }] } }
    • "FeeHandler": { "0x90d94229623a0a38826a4a7557a6d79acde43f76": { "BurnFractionSet": [{ "updated_at_block_number": 19732579, "value": 0.7999999999999999 }] } }

​
Filecoin Management

Supported together with setting CHAIN_TYPE=filecoin

​
Blackfort Management

Supported together with setting CHAIN_TYPE=blackfort

​
Arc Management

Supported together with setting CHAIN_TYPE=arc