# Supported networks
Source: https://docs.settlemint.com/docs/architects/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 network patterns fit DALP's EVM model. It does not make a network available by itself. Every platform operation (token issuance, compliance checks, custody signing, indexing, API reads) uses the configured EVM network. You do not need separate product flows per network.
## 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 configuration supplies the chain identity and the RPC transport details DALP needs to operate safely.
DALP is EVM-only. A network can be public, private, consortium-run, or local for testing. DALP can use it only when it exposes the Ethereum JSON-RPC and contract semantics described by the [EVM RPC Node](/docs/architects/components/infrastructure/evm-rpc-node).
The configured EVM control path spans these references:
* [Architecture one-pager](/docs/architects/overview/architecture-one-pager) defines the EVM execution model and says non-EVM execution environments remain outside DALP's native trust model.
* [Principles and scope](/docs/architects/overview/principles-and-scope) defines DALP's responsibility for lifecycle control on configured EVM assets.
* [Broadcast](/docs/architects/components/infrastructure/broadcast) describes how production deployments reach one or more EVM RPC endpoints.
* [Blockchain monitoring](/docs/developers/operations/blockchain-monitoring) describes block-age checks, stall detection, and on-demand-mining behaviour for 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, custody policy, and external-chain operation stay with the client architecture. Use [Bridge and cross-chain security](/docs/compliance-security/security/bridge-cross-chain) when a design includes an external bridge, wrapper, redemption route, or non-EVM leg.
## Choose the right chain pattern [#choose-the-right-chain-pattern]
This table applies that model 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 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. Use the bridge security guidance to define the external route evidence. |
This choice affects where token contracts, identity registries, compliance modules, custody policies, and indexing checkpoints live. Picking a target environment is an operating-model decision, not only an RPC endpoint change.
## Token standards and network fit [#token-standards-and-network-fit]
DALP token operations run on EVM-compatible networks and centre on SMART Protocol assets. The Platform API and the Ledger Index expose whether a token implements SMART and ERC-3643, while external-token registration can also list existing ERC-20-style contracts for visibility and reconciliation. Use this matrix when a network or asset-standard question comes before implementation planning.
"EVM-compatible and bank-approved" means the asset runs on an Ethereum-compatible network that the bank, consortium, or operator has approved for the programme. DALP uses the configured RPC endpoints, deployed contract addresses, custody policy, and identity registries. Compliance modules, the indexer, and the API all operate against the same configured network. The monitoring stack does too. The bank or its appointed operator remains responsible for validator nodes, consensus governance, network membership, RPC exposure policy, infrastructure evidence, business continuity controls, and any regulated-environment approvals.
| Token or network question | Current DALP fit | Decision guidance |
| ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| New regulated instruments that need identity, compliance, lifecycle operations, and operator controls | SMART Protocol asset on a configured EVM network, with identity registries, trusted issuers, and compliance modules configured for the asset | Use DALP's template-backed asset creation path. Choose the asset class, required token features, compliance modules, custody policy, and configured EVM network together. Bind wallets to identities before regulated mint or transfer operations execute. |
| Existing EVM token contract not created by DALP | External-token registration can inspect and register the address, then show metadata, assigned type, detected interfaces, and SMART or ERC-3643 compatibility flags when available | Treat this as a visibility and compatibility-review surface. Registration does not convert the token into a DALP-issued asset or add DALP compliance, supply, reserve, or custody controls to the external contract. |
| Standard ERC-20-like fungible asset used for payments, fees, denomination, or external balances | DALP can read ERC-20 metadata where the contract responds and can use ERC-20 interfaces in supporting flows | Confirm the contract exists on the active EVM network and has the metadata and allowance behaviour the workflow needs. For regulated issuance, prefer SMART Protocol assets rather than a bare ERC-20 contract. |
| Network selection for the same token programme across public, private, or consortium chains | DALP can use built-in viem chains or custom EVM chain definitions when contracts, RPC endpoints, finality settings, and indexing are configured per network | Define the issuer authority, custody policy, compliance scope, and reconciliation model per chain. A token on two EVM networks is not automatically the same legal or operational instrument. |
| Native non-EVM token standard or chain | Outside DALP's native execution model | Model the DALP-controlled side on an EVM network and integrate the non-EVM system through a separately verified bridge, custody, settlement, or operations workflow. |
For regulated tokens, ERC-3643 compatibility is an execution model, not only a metadata flag. Wallets resolve through the asset identity registry to OnchainID identities. Before ordinary transfers and minting, the token checks identity verification and then calls the configured compliance modules for the asset's required claim topics, trusted issuers, and module parameters. Custodian-controlled forced updates are reserved recovery or administrative operations. They do not run that compliance-module pre-check. Burn and redemption flows skip the same transfer-style pre-check. They notify compliance modules after the burn, pass the holder as the checked party, and use `address(0)` as the recipient for module scoping where the operation destroys tokens instead of sending them to another holder.
For evaluators: DALP is EVM-only. It issues SMART Protocol assets for governed tokenization workflows, surfaces ERC-3643 and SMART compatibility on reads, and can register existing EVM tokens for visibility without taking over their contract controls or the bank's infrastructure responsibilities.
For a regulated tokenization program, pick the chain pattern before you pick an RPC provider. Open networks give investors and auditors broad independent visibility but expose settlement activity to public mempools and indexers.
Private Besu or Quorum networks keep validator membership, RPC access, and operational evidence inside the bank or consortium operating model. The operator still needs enough infrastructure to keep independent audit and recovery credible. Custom EVM deployments sit between those models. DALP can connect when the environment behaves like Ethereum JSON-RPC, but the operating team owns the proof that finality, explorer availability, and contract-address data are production-grade.
For gold-backed assets, the network decision does not replace reserve control. The ledger records token state, identity checks, compliance outcomes, and settlement events. The issuer and custodian hold reserve evidence; the verifier and the bank's operating model govern reconciliation.
Choose the configuration that best matches the visibility model: who must see token activity, who may submit transactions, and what evidence auditors need to verify on-chain state and off-chain backing.
## Private or permissioned infrastructure provisioning [#private-or-permissioned-infrastructure-provisioning]
DALP does not require a public chain. The platform can operate against a private or permissioned EVM network. That network must expose Ethereum JSON-RPC with a known chain ID, reachable RPC endpoints, and DALP contracts deployed for the environment. DALP then supplies asset management, identity verification, and compliance enforcement. Custody-signing and indexing run against the same environment. The monitoring stack does as well.
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, Broadcast, 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 Broadcast 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. That baseline depends on managed PostgreSQL, Redis, object storage, backup, and observability tooling. Supported cloud-provider patterns cover AWS, Azure, and GCP managed services. Non-hypercloud or on-premises deployments need an approved self-hosted fallback for those managed services, plus the cluster, storage, ingress, TLS, and security controls listed in the [self-hosting prerequisites](/docs/architects/self-hosting/prerequisites).
The application cluster 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 begins at 4 vCPU and 16 GB RAM with high availability and at least 100 GB storage. Managed Redis begins at a 6 GB high-availability cache. These figures size the DALP application environment. Validator-node sizing, hardware security modules, cloud-provider charges, node-operator fees, and professional services are commercial and infrastructure inputs for the selected permissioned-network design.
A practical provisioning path 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 Broadcast.
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 and transaction submission for that environment. Apply the custody-signing policy, monitoring configuration, backup schedule, and recovery checks.
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/architects/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 environment 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 operating model, not from DALP configuration. 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. You can redeploy the DALP application to another supported EVM environment when that 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.
See [self-hosting prerequisites](/docs/architects/self-hosting/prerequisites) for deployment requirements and sizing, and [installation process](/docs/architects/self-hosting/installation-process) for the managed installation sequence.
## 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 endpoint failover and batching limits [#rpc-endpoint-failover-and-batching-limits]
The RPC configuration accepts either a single `url` or a non-empty `urls` list. Use `url` when one managed address is the whole transport path. Use `urls` when the environment has ordered upstream addresses and DALP should create a fallback transport across them.
The `urls` list is a failover model, not a traffic-splitting load balancer. DALP builds transports for the configured addresses and falls through the list when the active one cannot serve the request. Put the preferred address first, keep backups equivalent for the same network and contract deployment, and set provider limits so log fetching stays inside each upstream provider's safe range.
`wsUrl` is optional and enables WebSocket subscriptions when the environment provides one. Without it, DALP continues through HTTP polling.
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 read calls through a Multicall3 contract when one 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`. Set an explicit depth to prevent a production chain with a reorg window from pruning or indexing against a zero-depth setting 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 your 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 | Optional, set once for the platform. Provide a block explorer base URL only when one explorer is correct for every enabled network. Leave it unset otherwise, and the Console omits explorer links instead of using an incorrect default. | Explorer links in the operator experience apply to every enabled network. DALP never falls back to a public mainnet explorer for a chain-private platform. |
| 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 you provide working RPC endpoints and the required DALP contract addresses for that network in the configuration.
### Explorer link visibility [#explorer-link-visibility]
The block explorer URL is an optional platform-level setting. When a URL is configured, the Console renders explorer links across the operator experience. These include the "View on Explorer" button on activity events, transaction-hash popovers, and the address and transaction links in the token, holder, holdings, and external-token tables.
When no URL is configured, the Console omits these links instead of pointing at a default explorer. DALP never substitutes a public mainnet explorer, because a link to the wrong network resolves to addresses and transactions that do not exist on the chain DALP actually runs on. A blank or whitespace-only value in the configuration normalizes to `undefined`, which the platform treats the same as an unset value: no explorer links are rendered.
Because the explorer URL is a single platform-level value, the Console applies it to every link it renders, regardless of which enabled network a hash or address belongs to. Set it only when one explorer is correct for every network whose transactions and addresses can appear in the Console. In a deployment with multiple enabled networks that do not share one block explorer, leave the URL unset rather than send some links to the wrong chain. For a permissioned or local chain without a block explorer, also leave it unset and rely on the transaction request and receipt endpoints to track on-chain activity. See [Transaction tracking](/docs/developers/operations/transaction-tracking) for the request-status and receipt lookups that do not depend on a block explorer.
## 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 your 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 reads consensus membership from the chain itself, independent of 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. |
| Broadcast 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 environment, 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, and the genesis block, along with storage and network topology. It also supplies node metrics and an optional block explorer service.
2. The DALP application layer points its network configuration at the Broadcast 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 you use it for regulated issuance, confirm these five points. Who controls validator membership? Who can read and call the RPC endpoint? What protects the RPC gateway? How does the deployment measure finality? How do auditors reconcile on-chain token state with off-chain reserve and custody evidence?
## Private and test networks [#private-and-test-networks]
Private and local environments use the same EVM model with explicit configuration:
* Private EVM networks such as Besu and Geth can be configured as custom chains. Each requires an explicit chain ID, RPC endpoints, and a finality depth.
* Anvil, Hardhat, and Ganache test environments can run in test mode. Set the appropriate test flag for each.
* Environments that produce blocks only when transactions arrive 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. The same token name deployed on Ethereum, Polygon, Besu, and Quorum does not automatically represent the same legal or operational instrument on every chain. Keep issuer authority, compliance topics, reserve evidence, custody policy, and reconciliation rules explicit per deployment.
When the same asset class is represented on more than one EVM network, decide whether each 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 operating model must define which system of record owns supply authority, eligibility rules, and backing evidence for each of those chains.
Multi-chain support does not make non-EVM networks native DALP execution targets. If your deployment needs activity on a non-EVM network, model it as an external integration with explicit custody, bridge, settlement, or reconciliation controls.
## Related [#related]
* [Integrations overview](/docs/architects/integrations) for the broader integration surface finder
* [EVM RPC Node](/docs/architects/components/infrastructure/evm-rpc-node) for blockchain access
* [Broadcast](/docs/architects/components/infrastructure/broadcast) for multi-node connectivity
* [Blockchain monitoring](/docs/developers/operations/blockchain-monitoring) for network health, block-age checks, and on-demand mining behaviour
* [Promote from testnet to mainnet](/docs/developers/operations/testnet-mainnet-promotion) for separating environment promotion from chain-state migration
* [Deployment topology](/docs/architects/overview/deployment-topology) for environment architecture