DFNS now supports Bring Your Own Chain. You can register a network on a running DFNS environment, and from that moment it works like any of the 100+ networks DFNS ships with. You can create wallets on it, sign and broadcast transactions to it, and watch addresses on it. Its blocks are indexed and its events arrive as webhooks. There is no code change and no release to wait for.
EVM networks are the first kind supported. That covers a bank’s private Besu as well as a public appchain that a platform runs for its own users. Whatever chain you operate, DFNS now runs on it.
Why the chains you run yourself were the hardest to add
More and more of the chains that matter to institutions are chains they run themselves. Banks run private Besu networks or Canton nodes for shared ledger projects, and consortia run permissioned chains among their members.
The same is happening in public. Tokenization platforms, payment companies and market infrastructures now run their own appchains. These might be OP Stack or Arbitrum Orbit rollups, Avalanche L1s or Polygon CDK chains. They are open to anyone, but they are built for one business and its users. Some serve a dozen participants in a pilot. Others serve millions of consumers. Either way, no vendor was going to add them to its roadmap.
Until now, each of these networks meant a new release. When we brought Besu to DFNS in May, it came through a dedicated connector, enabled client by client. Supporting a chain on DFNS meant adding it to the platform’s code, testing it and shipping it to every environment, including on-premises deployments we cannot reach from outside. That cost makes sense for a public chain with millions of users. It makes no sense for a private Besu that serves one bank, or an appchain that serves one platform. A consortium of twenty banks would have meant twenty releases.
Bring Your Own Chain takes the release out of the picture. Networks now live in a registry instead of in code, and the platform reads that registry while it runs.
How it works
A network is registered through the DFNS API by whoever operates the platform. On a dedicated or on-premises deployment, that is the customer’s own platform team, so they can add their chain themselves without opening a ticket with us. On DFNS-hosted environments, our operations team registers networks on request. Indexing is the heaviest workload in the system, so whoever runs the infrastructure needs to know what a new chain will cost.
For an EVM network, registration asks only for what describes the chain. That means its name, chain ID and JSON-RPC endpoint, along with any headers or TLS material the endpoint needs. It also covers the native token’s symbol and decimals, whether the chain is in production, and whether it is permissioned. You choose a fee model, either legacy or EIP-1559. Most Besu networks still use legacy fees, while most public appchains use EIP-1559. You set a few indexing parameters, such as the block time and how far behind the latest block to read. You can also list any extra event decoders the chain needs.
After that, the network simply exists. You create wallets on it through the same API as any other network. The same key can be used across several chains of the same kind and will give the same address on each, whether it lives on MPC or HSM infrastructure. Transactions go through the full lifecycle. Blocks are indexed from the moment you register the chain, and if one of your wallet addresses saw activity before that, Transaction Replay can bring the transaction into its history by hash. Events arrive as the usual webhooks, labelled with the network’s name. Address Watches work too, so a participant can follow a consortium’s settlement contract or an appchain’s core contracts without holding a key to them.
Built for running your own chain
A few design choices come directly from how institutions and platforms actually run these networks.
A network can be limited to one organization. In an environment where each organization is a different bank, a chain registered for one of them is invisible to all the others. If another organization tries to use it, the platform simply says it does not exist, so nothing leaks.
Endpoint settings are encrypted and never shown again. RPC addresses can contain credentials, and headers and TLS material are secrets. We encrypt them at rest and never include them in any response. You can update an endpoint, rotate a token or change the indexing settings at any time, and the change applies straight away.
Archived names are never reused. When you archive a network, indexing stops, its endpoint settings are erased and its history is kept. Its name is retired for good, so no other chain can ever take it and mix its history with the old one. Custom network names also live in a space that DFNS will never use for its own networks, so a chain you register today cannot clash with one we add later.
Decoders are part of registration. Shared ledger projects and appchains often emit events from their own contracts, such as a settlement contract or a custom token. The business running on them needs those events as clear, structured data rather than raw logs. When you register a network, you can list the extra decoders it needs, and the indexer applies them from the first block. Address Watches use the same decoded events.
The limits, stated plainly
The registry is built to hold more than one kind of chain, and EVM is the first. It was built with Besu in mind and works with any EVM chain, public or private. Decoders are specific to EVM for now. We will design them again for each new kind of chain, and a Cosmos-style appchain is the most likely next candidate.
There are a few other things to know. We do not yet check an endpoint when you register it, so a wrong RPC address will show up the first time the chain is used, and you can fix it with an update. Checks at registration will come later.
Compliance screening providers know nothing about private networks. For that reason, a pre-screening policy on a custom chain will block transfers by default. To allow them, a policy has to waive screening explicitly for networks the provider cannot cover. We think that is the right default for a bank, which would rather make that choice itself than find out about it later.
Asset pricing, swaps and vaults are not yet available on custom networks. Registration happens through the API for now, and a dashboard view will follow.
Where it goes
Bring Your Own Chain joins Bring Your Own HSM, Bring Your Own ABI and Bring Your Own Validator for Canton as the latest “bring your own” building block on DFNS. It shows where the platform is heading. Every network, whether built in or added by you, becomes configuration that you control rather than code we have to ship. Other kinds of chains will follow on the same registry, and our built-in networks will move onto it too.
For institutions building shared ledgers and platforms building appchains today, the effect is simple. The chain you run is now a chain DFNS runs on, from the day you register it.
Get started
- Learn more about onchain core banking: dfns.co
- Explore the platform and documentation: docs.dfns.co
- Talk to our team about Bring Your Own Chain: sales@dfns.co
