Own the road to the chain

Every read and every transaction the platform makes travels through a node endpoint, and until now that routing lived in a separate component with its own configuration. DALP now runs that layer itself, and you drive it from the Console.

Core Platform

One catalogue, one pool per network, no restart

A platform administrator defines each network and the pool of endpoints behind it: your own nodes, commercial node providers, or both. The platform reads that catalogue on every operation rather than at startup, so a change reaches every organisation's reads and submissions without anyone restarting anything.

Configured in

The Console

Credentials

Encrypted, rotatable

Unhealthy endpoint

Routed around

Change takes effect

Live

RPC routingCopy Anchor Link

Every blockchain is reached over RPC, a request-and-answer interface a node exposes, and an endpoint is one address answering it. A single endpoint leaves no fallback when it fails. An endpoint can also respond with stale state when it lags behind the chain head.

Running that routing in a separate gateway component meant a second thing to configure, a second thing to upgrade, and a second place for an outage to start. It is gone. The routing now lives in the platform, which means one system to reason about and one place where the credentials live.

Health is measured, not assumedCopy Anchor Link

The platform scores every endpoint in a pool on how far behind the chain it is running, both at the tip and at the point where blocks become final. An endpoint past the acceptable lag is excluded outright rather than merely ranked lower, because stale answers are the failure that quietly corrupts a downstream read.

Within the healthy set, traffic prefers the best-scoring endpoint. A transient error retries with backoff, and a dead endpoint fails over immediately. The switching logic deliberately resists flapping: it holds a minimum interval between switches so a pair of endpoints trading places every few seconds cannot turn into churn. If no endpoint can serve the request, the caller receives an error.

1. 1
   Score

   A single coordinated poller measures each endpoint's distance behind the chain tip and behind finality, and shares those scores across the deployment.

2. 2
   Filter

   Any endpoint beyond the acceptable lag leaves the candidate set. A stale answer is never preferred to a slower fresh one.

3. 3
   Route

   The best-scoring healthy endpoint takes the call, with hysteresis and a minimum switch interval so ranking changes do not become churn.

4. 4
   Recover

   A transient failure retries with backoff; a dead endpoint fails over at once. The caller receives a result or a request error.

Endpoint credentialsCopy Anchor Link

An authenticated RPC endpoint needs a credential. Each endpoint carries its own authentication, whether an API key or basic authentication, entered in a form shaped for the provider you picked. The platform stores those credentials encrypted and supports rotating the key that protects them.

The pool is defined for the deployment rather than per organisation, which is the right boundary: the endpoints are infrastructure, not tenant data. Saving a pool validates the addresses you entered before accepting them, and the platform swaps to the new pool by draining the old one rather than cutting it off mid-call.

One organisation, more than one chainCopy Anchor Link

The catalogue is what a platform administrator curates. What an organisation may use is a separate decision, made on the organisation's own page, and multi-chain operation is now an explicit choice rather than an assumption. It is off unless someone turns it on, so no organisation becomes multi-chain by upgrading.

Leave it off and the organisation works on one network: tokens deploy in one place, and one set of transaction history needs reconciling. Turn it on and members pick a network per transaction, a token can exist on more than one network at once, and the organisation takes on tracking activity across each chain separately. Choose it when you actually need presence on several chains, not as a default left on just in case.

A second, platform-wide setting with a near-identical name limits the network a new organisation's first system can deploy to. It does not turn on the organisation's choice. Read how the two switches differ and the order to set them.

A JSON-RPC endpoint of your ownCopy Anchor Link

The same pool is exposed as an authenticated JSON-RPC endpoint, meaning the standard interface that blockchain tooling already speaks. An integrator can point an existing tool at your deployment instead of holding a separate provider contract.

It is built to be handed out safely. Keys are issued, rotated, and revoked, and the platform stores only a hash of each one. The method allowlist is default-deny and read-only, so a key cannot be used to submit a transaction. Each key carries its own rate limit.

CompatibilityCopy Anchor Link

An existing deployment upgrades without action. The endpoints already in your configuration file continue to work, and the pool you define in the Console layers over that file rather than requiring you to move first.

One deployment change is worth planning for: the separate gateway component is removed, so the platform no longer runs it and no longer reads its settings. If your own monitoring, network policy, or dashboards name that component, retarget them at the platform before you upgrade.

Manage the network catalogue → · Choose an organisation's networks → · Issue an API credential →