Skip to main content

Supported chains

Selecting a base chain is an important step in any application’s design and, especially, for tables.


Chain selection makes a significant impact on the database's usability. Choose a chain that’s too slow or expensive, and it won’t be feasible for table writes to occur frequently. Deploy a cross-chain data model for value layering purposes, and certain onchain access control features are lost. This page explains general chain related concepts; the following chains are supported and described in more detail in the subsequent pages.

Note that in addition to each chain's unique block time, there is also a chain-specific block depth required until SQL data is made available in Tableland. For example, Ethereum has a block time of ~13.5 seconds and a block depth of 1, so it takes ~27.5 seconds for data to be available in Tableland. Since a transaction could be submitted mid-block, it's possible for a transaction to take from ~30-40 seconds to be materialized in Tableland. The chain-specific docs pages (see below) describe this in more detail.

  • ethereum
  • optimism
  • arbitrum one
  • arbitrum nova
  • base
  • polygon
  • filecoin

Chain information

If would like to dive straight into chain-specific overviews, with decision considerations and other chain information (chain ID, contracts, block explorers, faucets, etc.), head to one of the pages below. The full list of chain-specific details can be found in the chain info pages. The following shows the deployed contracts addresses across all mainnet and testnet chains:

ChainEnvironmentChain IDAddress
ethereummainnet10x012969f7e3439a9B04025b5a049EB9BAD82A8C12
optimismmainnet100xfad44BF5B843dE943a09D4f3E84949A11d3aa3e6
arbitrum onemainnet421610x9aBd75E8640871A5a20d3B4eE6330a04c962aFfd
arbitrum novamainnet421700x1A22854c5b1642760a827f20137a67930AE108d2
basemainnet84530x8268F7Aba0E152B3A853e8CB4Ab9795Ec66c2b6B
polygonmainnet1370x5c4e6A9e5C1e1BF445A062006faF19EA6c49aFeA
filecoinmainnet3140x59EF8Bf2d6c102B4c42AEf9189e1a9F0ABfD652d
ethereum sepoliatestnet111551110xc50C62498448ACc8dBdE43DA77f8D5D2E2c7597D
optimism sepoliatestnet111554200x68A2f4423ad3bf5139Db563CF3bC80aA09ed7079
arbitrum sepoliatestnet4216140x223A74B8323914afDC3ff1e5005564dC17231d6e
base sepoliatestnet845320xA85aAE9f0Aec5F5638E5F13840797303Ab29c9f9
polygon amoytestnet800020x170fb206132b693e38adFc8727dCfa303546Cec1
filecoin calibrationtestnet3141590x030BCf3D50cad04c2e57391B12740982A9308621
local tablelandlocal-only nodes313370xe7f1725e7734ce288f8367e1bb143e90bb3f0512

Here's a summary of how the chains works in terms of speed:

ChainAvg. block finalization timeBlock depthAvg. SQL materialize time
Ethereum13.5 seconds130-40 seconds
Optimism2 seconds0<5 seconds
Arbitrum One<2 seconds0<5 seconds
Arbitrum Nova2-3 seconds0<5 seconds
Base2 seconds0<5 seconds
Polygon2 seconds1<10 seconds
Filecoin30 seconds5~4 mins.
tip

Review the cost estimation table that compares the costs of creates and writes across each chain.

Providers

To interact with a chain, developers must run their own node or have access to one. Providers like Infura, Alchemy, and Etherscan operate a large pool of decentralized nodes and provide an API (centralized gateway) to them. They make it extremely easy to get started and develop web3 applications without needing to personally manage the hardware and software for a dedicated node.

Check out the following resources for each of these providers, and note that the Tableland SDK and CLI are both compatible with whatever ethers v6 can support:

Infura

Alchemy

Etherscan

Layer 1 vs. Layer 2

Ethereum (Layer 1, "L1") can be expensive. Tableland extends a base chain’s functionality so that writing data to the blockchain is cheap (stored in event logs) while the Tableland network makes this data functional. But, Ethereum will always be more expensive as well as slower when compared to its scaling solutions (Layer 2, "L2") — these technologies exist for a reason! There is a ton of information on why L2s are needed to the point where these solutions are part of Ethereum’s future roadmap. Thus, choosing the right ETH L2 variant is important since Tableland is an extension of the base chain and depends on the base chain’s execution, consensus, and security, which determine the speed of creating or writing to tables.

L2 variants

The most commonly used L2 types come in two flavors: rollups and sidechains. Currently, Tableland supports rollups like Optimism & Arbitrum, which are both "optimistic" rollups. For reference, there also exists "zero knowledge" ("zk") rollups. The primary difference between the two is that optimistic rollups are optimistic; batches of transactions are posted onchain and assumed valid (unless challenged via fraud proofs). Zk-rollups provide the validity proof by design but are still nascent.

Both rollups and sidechains operate an offchain network. L2 nodes are running the same execution layer as Ethereum ("EVM") and allow users to "bridge" assets to the L2 network using a bridging contract, which locks the assets up on the L1. As users are leveraging an app deployed on L2 for its scaling and associated cost benefits, the L2 data is posted back to Ethereum L1, periodically.

There is plenty of research and resources that describe considerations and differences between optimistic rollups, zk-rollups, and sidechains.

Optimistic rollups

  • Offchain network of nodes running the EVM.
  • Onchain smart contract bridge.
  • Inherits L1 security.
  • Actors periodically post batched transaction data (as calldata) to the L1, using the bridge contract.
  • The bridge contract self-enforces L2 transaction validity with fraud proofs where anyone can make a challenge to the data posted to L1 — if successful, the L2 re-executes the txs and updates the L2 state.

Sidechains

  • Offchain network of nodes running the EVM.
  • Onchain smart contract bridge.
  • Partially inherits L1 security but uses a separate consensus mechanism.
  • Actors periodically post batched L2 transaction data (as calldata) to the L1, using the bridge contract.
  • The correctness of the batched data posted to L1 is not openly challengeable nor self-enforcing but is managed by a set of trusted parties.

The main difference is whether the bridge contract can self-enforce the validity of transactions on the other network or if it must rely upon a trusted set of parties to attest that it is valid. For more information, check out the following article (by Infura).

EVM compatibility

Solutions that Tableland supports are all "EVM compatible." These are layers including or built on top of Ethereum that can still leverage Solidity smart contracts, wallets/addresses, and Ethereum-related libraries. For example, using a wallet on one EVM-compatible chain is possible on another, without much additional setup, besides configuring wallet settings and (likely) bridging assets from the L1 to the L2. Tableland only supports EVM-compatible chains.

Mainnets vs. testnets

In general, all chains have both a mainnet and testnet. Developers should first use a testnet to validate everything is working as expected, and once ready, move everything to production on mainnet. Testnet chains use testnet currency with no inherent value such that developers can request testnet currency for free from faucets. Mainnets require real currency to help provide the proper incentivization mechanisms and payment to nodes for computation and state management.

Be sure to use https://tableland.network on mainnets, and https://testnets.tableland.network on testnets. Learn more about why in the gateway docs.