# Supported networks
Source: https://docs.settlemint.com/docs/architecture/integrations/supported-networks
Reference for DALP network configuration across built-in viem chains,
custom EVM-compatible networks, RPC transport settings, finality controls,
and monitoring behaviour for test and production environments.
DALP supports EVM-compatible networks through configuration. You either select a built-in viem chain by name or define a custom EVM chain with its chain ID, RPC endpoints, native currency, block explorer, contract addresses, and finality settings.
This reference answers which chain patterns fit DALP's network model. It does not make a chain available by itself. Token issuance, lifecycle operations, compliance checks, custody signing, indexing, and API reads use the configured EVM network boundary rather than separate product flows per chain.
## Compatibility requirement [#compatibility-requirement]
A DALP network must expose Ethereum JSON-RPC behaviour that DALP can use for reads, writes, log fetching, transaction submission, and block tracking. The network configuration supplies the chain identity and the RPC transport details DALP needs to operate safely.
DALP is EVM-only at this boundary. A network can be public, private, consortium-run, or local for testing. DALP can use that network only when it exposes the Ethereum JSON-RPC and contract semantics described by the [EVM RPC Node](/docs/architecture/components/infrastructure/evm-rpc-node).
The network model follows DALP's configured EVM control path:
* [Architecture one-pager](/docs/architecture/start-here/architecture-one-pager) defines the EVM execution boundary and says non-EVM execution environments remain outside DALP's native trust boundary.
* [Principles and scope](/docs/architecture/overview/principles-and-scope) defines DALP's responsibility for lifecycle control on configured EVM assets.
* [Chain Gateway](/docs/architecture/components/infrastructure/chain-gateway) describes how production deployments reach one or more EVM RPC endpoints.
* [Blockchain monitoring](/docs/developer-guides/operations/blockchain-monitoring) describes the block-age, stall, and on-demand-mining behaviour that depends on the selected network.
Native non-EVM networks need an external integration layer or an EVM representation before DALP can operate on the asset or workflow. DALP owns the lifecycle control path for configured EVM assets. The selected network, bridge, custody policy, and external-chain operation stay with the client architecture.
## Choose the right chain pattern [#choose-the-right-chain-pattern]
This table applies those boundaries to common chain choices. Public and private EVM rows stay inside DALP's configured EVM network model. The native non-EVM row is included to mark the boundary where the work moves to an external integration design.
| Chain pattern | When to use it | What DALP needs |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Public EVM network | You want DALP assets or workflows on a public EVM chain such as Ethereum mainnet, Sepolia, Polygon PoS, Arbitrum One, Optimism, Base, or Avalanche C-Chain. | A built-in viem chain or matching custom EVM definition, RPC endpoints, deployed DALP contract addresses, and finality settings that match the provider. |
| Private or consortium EVM network | You operate a private Besu, Geth, or comparable EVM network for a regulated environment. | A custom EVM chain definition with chain ID, RPC endpoints, native currency if it differs from ETH, block explorer if available, contract addresses, and an explicit finality depth when the RPC does not support the `finalized` block tag. |
| Local test network | You need a development or sandbox chain that only mines when transactions arrive. | A test network definition for Anvil, Hardhat, or Ganache, with on-demand mining enabled or inferred from test mode. |
| Native non-EVM network | You need to interact with a chain that does not expose EVM contracts and Ethereum JSON-RPC semantics. | Keep the non-EVM system outside DALP's network configuration. Model the DALP side on an EVM chain, then integrate the external chain through a bridge, settlement, custody, or operations workflow that is verified separately. |
This choice affects where token contracts, identity registries, compliance modules, custody policies, and indexing checkpoints live. A chain choice is an environment and operating-model decision, not only an RPC endpoint change.
For a regulated tokenization program, pick the chain pattern before you pick an RPC provider. Public networks give investors and auditors broad independent visibility, but expose settlement activity to public mempools and public indexers.
Private Besu or Quorum networks keep validator membership, RPC access, and operational evidence inside the bank or consortium boundary. The operator still needs enough infrastructure to make independent audit, monitoring, backup, and disaster recovery credible. Custom EVM chains sit between those models: DALP can connect when the network behaves like Ethereum JSON-RPC, but the operating team owns the proof that finality, explorer, and contract-address data are production-grade.
For gold-backed assets, the network decision does not replace reserve control. The chain records token state, identity and compliance checks, and settlement events. Reserve evidence, custody attestations, and reconciliation still come from the issuer, custodian, verifier, and bank operating model.
Choose the network that best matches who must see token activity, who may submit transactions, and how auditors verify both the on-chain token state and the off-chain backing evidence.
## Private or permissioned infrastructure provisioning [#private-or-permissioned-infrastructure-provisioning]
DALP does not require a public chain. It can operate against a private or permissioned EVM network when that network exposes Ethereum JSON-RPC, has a known chain ID, has reachable RPC endpoints, and has DALP contracts deployed for that environment. DALP supplies the asset, identity, compliance, custody-signing, indexing, API, and monitoring layers that use that configured EVM network.
The blockchain network itself is an environment decision. The bank, consortium, cloud provider, or node operator must provide and operate the validator nodes, consensus settings, network membership rules, and infrastructure evidence for the permissioned chain.
| Provisioning area | What DALP covers | What the deployment must define |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| EVM compatibility | DALP connects to configured EVM networks through Ethereum JSON-RPC and contract addresses. | The selected Besu, Geth, Quorum-compatible, or comparable EVM network must expose the RPC behaviour DALP needs for reads, writes, logs, transactions, and block tracking. |
| Network metadata | A custom network can define chain ID, name, native currency, explorer metadata, RPC endpoints, batching limits, finality settings, and deployed contract addresses. | The operator must assign the chain ID, validator membership, consensus parameters, genesis configuration, explorer service, and finality model. |
| Application deployment | DALP Helm charts deploy the DALP application services, API, workflow, indexer, chain gateway, support services, and observability components into Kubernetes or OpenShift. | The target cluster, storage, ingress or OpenShift routes, secrets, managed services, backup tooling, and security controls must be prepared for the environment. |
| RPC access | The Chain Gateway can front one or more upstream RPC endpoints so DALP services call a stable internal endpoint. | The upstream validator or RPC nodes, endpoint authentication, network access, TLS, rate limits, and external exposure policy remain part of the chain-infrastructure design. |
| Contract deployment | DALP contracts and registries are deployed per network, and DALP configuration points to the addresses for that environment. | The programme must decide who can deploy, upgrade, pause, or administer contracts on the permissioned network. |
| Operating control | DALP records and indexes configured EVM activity and applies token, identity, and compliance controls at the asset layer. | Validator-set control, consensus governance, network admission, hardware procurement, cloud provider selection, node-operator contracts, costs, and delivery timeline depend on the selected target architecture and commercial package. |
For self-hosted deployments, DALP's application baseline is Kubernetes or OpenShift with managed PostgreSQL, Redis, object storage, backup, and observability services. Supported cloud-provider patterns include AWS, Azure, and GCP managed services. Non-hypercloud or on-premises deployments need an approved self-hosted fallback for those services, plus the cluster, storage, ingress, TLS, backup, observability, and security controls listed in the [self-hosting prerequisites](/docs/architecture/self-hosting/prerequisites).
The application cluster baseline starts at 3 nodes with 4 vCPU and 16 GB RAM per node. Production planning should use 6 or more nodes with 8 vCPU and 32 GB RAM per node, distributed across at least three availability zones. Managed PostgreSQL starts at 4 vCPU and 16 GB RAM with high availability and at least 100 GB storage. Managed Redis starts at a 6 GB high-availability cache. These figures size the DALP application environment. Validator-node sizing, hardware security modules, network appliances, cloud-provider charges, node-operator fees, and professional services are commercial and infrastructure inputs for the selected permissioned-network design.
A practical provisioning path usually follows this order:
1. Choose the chain pattern: public EVM, private or consortium EVM, local test network, or an external non-EVM integration.
2. Provision the target Kubernetes or OpenShift environment and the private EVM network or node service.
3. Expose stable RPC endpoints to DALP, either directly or through the Chain Gateway.
4. Configure the custom EVM chain with chain ID, RPC transport, finality settings, explorer metadata, batching limits, and default-network status.
5. Deploy DALP contracts to that network and register the resulting contract addresses in the DALP environment configuration.
6. Enable indexing, transaction submission, custody-signing policy, monitoring, backup, and recovery checks for that environment.
7. Record the operating evidence: validator membership, consensus parameters, network access policy, contract addresses, signer policy, monitoring alerts, backup tests, and recovery owner.
Use this planning table when estimating contract-signature to production readiness:
| Workstream | Timeline driver | Cost and procurement driver |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| DALP application deployment | Starts after the self-hosting prerequisites are complete and follows the managed installation stages in the [installation process](/docs/architecture/self-hosting/installation-process): pre-installation verification, platform deployment, post-deployment setup, and verification handoff. | SettleMint commercial package and professional services, plus the Kubernetes or OpenShift cluster, managed PostgreSQL, Redis, object storage, backup, ingress, TLS, and observability services. |
| Private EVM network | Can run in parallel only after the validator topology, consensus model, provider or on-premises footprint, RPC exposure, security controls, backup model, and operating owner are agreed. If those inputs are not ready at contract signature, they sit on the critical path before production readiness. | Besu, Geth, Quorum-compatible, or comparable EVM node infrastructure; validator hosts; optional hardware security modules; network appliances; cloud-provider charges; and any third-party node-operator contract. |
| Production readiness | Complete only when the application cluster, private EVM network, contract addresses, indexing, custody-signing policy, monitoring, backup, recovery evidence, and handoff runbook are verified together. | Joint readiness testing, operator training, audit evidence collection, migration or reconciliation work, and any regulated-environment approvals required by the bank. |
DALP does not require one named cloud provider or one named hardware vendor. AWS, Azure, GCP, private cloud, and on-premises patterns are viable when the environment meets the self-hosting prerequisites and the EVM network exposes the required Ethereum JSON-RPC behaviour. Fixed calendar duration and final cost are therefore not properties of DALP configuration alone. They depend on whether the bank supplies the infrastructure and network controls at contract signature or procures them during implementation.
Bank control over a permissioned network comes from the selected network operating model, not from DALP configuration alone. If the bank owns the validator set and consensus rules, those controls must be implemented in the permissioned network and reflected in the runbook. DALP then uses the approved RPC endpoints and deployed contract addresses for token operations.
Exit planning should separate the application layer from chain state. The DALP application can be redeployed to another supported EVM environment when the new environment has RPC endpoints, contracts, indexer configuration, custody policy, and data migration or reconciliation steps. Moving issued assets, historical chain data, validator governance, or backing evidence from one chain to another is a migration and operating-control exercise for the asset programme, not a single DALP setting.
For deployment prerequisites, sizing, and the managed installation sequence, see [self-hosting prerequisites](/docs/architecture/self-hosting/prerequisites) and [installation process](/docs/architecture/self-hosting/installation-process).
## Network definition types [#network-definition-types]
| Definition type | Use case | Required network fields |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| Built-in viem chain | Target networks already available from `viem/chains`, such as `mainnet`, `sepolia`, or `polygon`. DALP resolves chain metadata from viem. | Built-in chain name, RPC endpoint configuration, and deployment contract addresses. |
| Custom EVM chain | Private EVM networks, consortium networks, local chains, or EVM networks that need explicit chain metadata. The native currency defaults to ETH when omitted. | Chain ID, network name, RPC endpoints, and optional native currency, block explorer, contracts, batching, and finality settings. |
Each configuration must define at least one network. Exactly one enabled network must set `default: true`.
## Network-specific configuration [#network-specific-configuration]
| Setting | Controls | Operational impact |
| ------------------------------ | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| RPC endpoints | One URL or multiple fallback URLs over HTTP, HTTPS, WS, or WSS. | DALP uses the configured transport for chain reads, writes, subscriptions, and failover. |
| RPC limits | Maximum addresses per log call, block range per log call, and concurrent log calls. | Different RPC providers tolerate different log-fetching sizes and concurrency levels. |
| Batching | JSON-RPC request batching and Multicall batching. | Batching can reduce round trips, but each provider and chain has its own safe limits. |
| Contract addresses | Deployment-specific addresses such as the Directory or Multicall3 contract. | DALP must know which deployed contracts belong to that network environment. |
| Finality controls | Support for the `finalized` block tag and confirmation-depth fallback. | Private and proof-of-authority networks often need explicit confirmation depth. |
| Test mode and on-demand mining | Anvil, Hardhat, Ganache, and on-demand block production settings. | Monitoring skips block-age and stall checks for chains that only mine when transactions arrive. |
## RPC and batching limits [#rpc-and-batching-limits]
The RPC configuration accepts either a single `url` or a non-empty `urls` list for fallback transport. `wsUrl` is optional and is used for WebSocket subscriptions when the environment provides one.
The default RPC limits are conservative so providers do not receive oversized log queries:
| Limit | Default | Maximum | Applies to |
| ---------------------- | ------- | -------- | ----------------------------------------- |
| `maxAddressesPerCall` | 50 | 500 | Contract addresses in one `getLogs` call. |
| `maxBlockRangePerCall` | 2000 | 50000 | Block span in one `getLogs` call. |
| `maxConcurrentCalls` | 5 | 50 | Parallel `getLogs` calls per network. |
| `timeout` | 10000ms | 300000ms | RPC request timeout. |
| `retryCount` | 3 | 10 | RPC retry attempts. |
| `retryDelay` | 150ms | 60000ms | Base retry delay. |
JSON-RPC batching and Multicall batching are separate controls. JSON-RPC batching groups transport requests to an RPC provider. Multicall batching groups contract reads through a Multicall3 contract when that contract is available for the network.
## Finality configuration [#finality-configuration]
Built-in and custom networks both expose `supportsFinalizedTag` and `finalityConfirmations`.
| Chain behaviour | Configuration |
| -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| The RPC supports the `finalized` block tag. | Leave `supportsFinalizedTag` at its default value, `true`. `finalityConfirmations` defaults to `0`. |
| The RPC does not support the `finalized` block tag. | Set `supportsFinalizedTag: false` and choose an explicit `finalityConfirmations` depth. |
| Production proof-of-authority or private EVM chain. | Use `finalityConfirmations` of at least `1` when `supportsFinalizedTag` is `false`. |
| Local Anvil, Hardhat, or Ganache test network without the `finalized` tag. | `finalityConfirmations: 0` is accepted with `supportsFinalizedTag: false` only when `test` is set to `anvil`, `hardhat`, or `ganache`. |
When `supportsFinalizedTag` is `false`, DALP derives the effective finalized block from `chainHead - finalityConfirmations`. The explicit depth prevents a production chain with a reorg window from pruning or indexing against a zero-depth boundary by accident.
## Public EVM deployment checklist [#public-evm-deployment-checklist]
Public EVM deployments normally use a built-in viem chain name with environment-specific RPC URLs, contract addresses, and confirmation settings. Examples include Ethereum mainnet or Sepolia, Polygon PoS, Arbitrum One, Optimism, Base, Avalanche C-Chain, and other EVM networks available through the configured viem chain catalog.
Before you enable a public EVM network, confirm these values for that DALP environment:
| Configuration value | What to provide | Why it matters |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Built-in chain name | A `viem/chains` name such as `sepolia`, `mainnet`, `polygon`, `base`, or another supported viem export. | DALP inherits the chain ID, native currency, and default chain metadata from viem. |
| Enabled and default flags | Set the target network to `enabled: true` and make exactly one enabled network `default: true`. | DALP rejects configurations with no default network, multiple default networks, or a disabled default network. |
| RPC endpoint | Use a private or managed RPC URL for real operation. Public fallback URLs are suitable only for disabled examples or low-volume validation. | DALP uses the RPC transport for reads, writes, log fetching, transaction submission, and block tracking. |
| WebSocket endpoint | Provide `wsUrl` when the network and provider expose a stable WebSocket endpoint. | WebSocket subscriptions can reduce polling load; DALP can fall back to HTTP polling when WebSocket is absent. |
| DALP Directory address | Provide the Directory contract address for the contracts deployed on that network. | The Directory is the entry point DALP uses to find the network's deployed system contracts. |
| Multicall3 address | Provide the network's Multicall3 contract address when contract-read batching is enabled. | DALP uses Multicall3 to batch settlement and token-state reads. Without the address, multicall reads fail on chains that do not expose a known Multicall3 contract. |
| Explorer URL | Use the built-in chain explorer when the viem chain metadata is enough, or add a custom `blockExplorers` entry for custom EVM networks. | Explorer links in the operator experience must point to the same network where DALP submits transactions and indexes events. |
| Finality settings | Leave `supportsFinalizedTag: true` when the RPC supports the finalized block tag. Set `supportsFinalizedTag: false` with an explicit `finalityConfirmations` depth when it does not. | DALP needs a safe finalized-block rule before indexing, pruning, or reporting chain state as settled. |
| RPC limits | Tune address count, block range, concurrency, timeout, retries, and batching for the provider. | Public RPC providers often enforce tighter log-query and concurrency limits than private nodes. |
Each DALP environment defines its own enabled network list. A public network is available only after the configuration provides working RPC endpoints and the required DALP contract addresses for that network.
## Private Besu and QBFT deployment checklist [#private-besu-and-qbft-deployment-checklist]
Private and permissioned EVM deployments use the same DALP network model as public EVM deployments. The difference is operational ownership: the bank or consortium also runs the chain infrastructure. DALP can use a Besu/QBFT environment when the chain exposes Ethereum JSON-RPC, has DALP contracts deployed for that chain ID, and provides a stable RPC gateway endpoint for DALP services.
Use this checklist to separate what DALP configures from what the chain operator must prove before production use.
| Area | What to provide | Why it matters |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Custom chain identity | A custom EVM chain definition with the private chain ID, network name, native currency if different from ETH, and optional explorer metadata. | DALP uses the chain identity for signing context, transaction status, explorer links, and contract lookups. |
| Genesis and consensus | A Besu genesis that enables QBFT consensus and matches the validator set used by the environment. | DALP does not infer consensus membership from the application config. The chain must already produce blocks and finalize them according to its own consensus rules. |
| Validator ownership | Validator node keys, node addresses, storage, P2P networking, and operational access controlled by the bank or consortium operator. | Validator management is infrastructure governance. DALP consumes the resulting EVM chain and does not become the consensus authority. |
| RPC nodes | One or more non-validator RPC nodes with the JSON-RPC APIs needed by DALP services, the explorer, and operational tracing. | DALP reads chain state, submits transactions, fetches logs, and monitors block health through RPC endpoints rather than through validator control. |
| Chain Gateway upstreams | eRPC upstream entries that point at the private RPC nodes, commonly through StatefulSet headless-service addresses inside the cluster. | DALP services keep a stable gateway URL while the gateway distributes traffic across the configured private-node upstreams. |
| Finality settings | Set `supportsFinalizedTag: false` when the private RPC does not support the finalized block tag, then set a non-zero `finalityConfirmations` depth for production. | DALP derives the effective finalized block from the chain head minus the confirmation depth when the finalized tag is unavailable. |
| Monitoring and evidence | Chain-node metrics, gateway health, block-age checks, explorer availability, backup evidence, and disaster-recovery procedures. | A private chain keeps activity inside the operator boundary, so independent auditability depends on the operator's monitoring, access logs, backups, and recovery evidence. |
A typical private Besu deployment therefore has two connected configuration layers:
1. The infrastructure layer provisions Besu validators, RPC nodes, genesis, storage, networking, metrics, and optional block explorer services.
2. The DALP application layer points its network configuration at the Chain Gateway URL for that chain and supplies the deployed DALP contract addresses for the same chain ID.
Do not treat a private-chain endpoint as a drop-in production change. Before using it for regulated issuance, confirm five things: who controls validator membership, who can read and call the RPC endpoint, how the RPC gateway is protected, how finality is measured, and how auditors can reconcile on-chain token state with off-chain reserve and custody evidence.
## Private and test networks [#private-and-test-networks]
Private and local networks use the same EVM boundary with explicit configuration:
* Besu, Geth, and other private EVM networks can be configured as custom chains with their own chain ID, RPC endpoints, and finality depth.
* Anvil, Hardhat, and Ganache test networks can run in test mode.
* Networks that produce blocks only when transactions are submitted should use the on-demand mining setting so monitoring does not report false stale-block alerts.
If `onDemandMining` is omitted, DALP infers it for configured test networks. Set it explicitly for a non-test network that only produces blocks after transactions.
## Multi-chain considerations [#multi-chain-considerations]
DALP can run against multiple configured EVM networks at the same time. Each enabled network has its own chain ID, RPC configuration, deployment contract addresses, indexing checkpoint, and transaction status context.
Operationally, this means:
* Identity registries and token contracts are chain-specific.
* Compliance module configuration is applied per token and per chain deployment.
* Indexing state is tracked per chain.
* Custody providers sign for the configured network and wallet policy in their own control plane.
Multi-chain deployments need a clear asset-control model. A token deployed on Ethereum, Polygon, Besu, and Quorum is not automatically the same legal or operational instrument on every chain. Keep issuer authority, compliance topics, reserve evidence, custody policy, and reconciliation rules explicit per chain.
When the same asset class is represented on more than one EVM network, decide whether each network has a separate issuance program, a synchronized mirror with off-chain reconciliation, or an external bridge or settlement process. DALP can coordinate configured EVM networks, but the deployment model must define which system of record owns supply, eligibility, and backing evidence.
Multi-chain support does not make non-EVM networks native DALP execution targets. If a deployment needs activity on a non-EVM network, model it as an external integration boundary with explicit custody, bridge, settlement, or reconciliation controls.
## Related [#related]
* [Integrations overview](/docs/architecture/integrations) for the broader integration surface finder
* [EVM RPC Node](/docs/architecture/components/infrastructure/evm-rpc-node) for blockchain access
* [Chain Gateway](/docs/architecture/components/infrastructure/chain-gateway) for multi-node connectivity
* [Blockchain monitoring](/docs/developer-guides/operations/blockchain-monitoring) for network health, block-age checks, and on-demand mining behaviour
* [Promote from testnet to mainnet](/docs/developer-guides/operations/testnet-mainnet-promotion) for separating environment promotion from chain-state migration
* [Deployment topology](/docs/architecture/overview/deployment-topology) for environment architecture