A detailed look at how Kaleido manages public chain nodes, deploys and governs permissioned networks, and connects to third-party hosted chains through its remote node architecture.
Every blockchain application requires reliable chain connectivity, particularly for enterprises operating at scale. Running a production blockchain node is not like spinning up a web server. Nodes require continuous protocol-level maintenance, careful peer configuration, genesis management, consensus tuning, security patching, and graceful handling of network forks and upgrades. For teams building financial applications, supply chain workflows, or digital asset platforms, this infrastructure work is a distraction from the actual product.
Kaleido Chain Infrastructure is the layer that removes that distraction. It is a fully managed, multi-cloud, protocol-agnostic runtime for blockchain nodes, networks, and the services that surround them. It spans three distinct operating modes: connecting to public permissionless networks (where you consume blockspace you do not own), deploying and governing permissioned private or consortium networks (where you define who participates), and bridging into third-party hosted chains via a remote node architecture (where the node lives elsewhere but Kaleido provides the tooling around it).
Kaleido has operated blockchain infrastructure in production since 2017, and the platform carries SOC 2 Type 2 and ISO 27001 certifications. The infrastructure layer sits at the base of the full Kaleido stack, with the Web3 Middleware and Digital Assets product lines building directly on top of it.
Figure 1. The Kaleido platform stack. Chain Infrastructure sits at the base, providing the blockchain runtime that Web3 Middleware and Digital Assets build upon.
When your application needs to interact with a public blockchain, you have two options: run your own node, or connect to someone else's. Running your own node sounds straightforward until you account for the operational realities: storage growth, peer synchronization, protocol upgrades that require node restarts, and the availability expectations that come with any production service. Kaleido's Public Chains offering handles all of this for you.
A Kaleido-managed public chain node is not simply a proxied RPC endpoint. It is a dedicated node instance running the official client software for that protocol, maintained by Kaleido's protocol engineering team, and exposed to your application through a hardened API gateway. You receive:
Kaleido provides managed node access across the major EVM and non-EVM ecosystems in active enterprise use. The protocols diagram below reflects the current breadth of coverage. For EVM-compatible chains, Kaleido normalizes the JSON-RPC surface so your application code can work against multiple chains with minimal changes.
Figure 2. Supported chains and protocols across the Kaleido platform.
Sitting in front of every node cluster is Kaleido's EVM Gateway. This component does two things that matter in practice: it enforces authentication and permissions on who can make which RPC calls, and it load-balances traffic across the available node instances. For teams that need to control developer or service-level access to a chain endpoint without building that access control into every application, the gateway provides a clean separation: your application authenticates to the gateway, and the gateway handles the relationship with the node pool.
Figure 3. The EVM Gateway enforces permissions and distributes load across the blockchain node pool before requests reach the chain.
Not every blockchain application belongs on a public chain. When your use case requires control over who participates, predictable transaction costs (no gas market), data privacy between participants, or the ability to set custom governance rules, a permissioned network is the right answer. This is where enterprise blockchain started, and where many of the most serious production deployments still operate today.
Kaleido's Permissioned Chains product lets you launch and operate a private or consortium blockchain with production-grade tooling, without becoming a distributed systems engineer in the process.
When you create a permissioned network in Kaleido, the platform handles the genesis block construction automatically. For a Hyperledger Besu network, for example, you configure your consensus parameters, initial allocations, and chain ID, and Kaleido generates a valid genesis configuration and provisions your first node against it. Subsequent nodes joining the network discover the genesis configuration and their peers automatically through the platform's network registryyou do not manually distribute configuration files or manage a static peer list.
Key distinction: the Networks concept in Kaleido is a platform-level object, not just a chain ID. A Network resource carries the identity information, bootstrap configuration, and peer discovery records that all services joining that network need. This is what allows Kaleido to automate multi-node deployments without manual peer coordination.
Permissioned networks on Kaleido support configurable consensus mechanisms. For EVM-based permissioned networks running Hyperledger Besu, this includes IBFT 2.0 (Istanbul BFT) and QBFT, both Byzantine fault-tolerant consensus algorithms suited to known-validator environments where you need finality guarantees rather than probabilistic confirmation. These algorithms are meaningfully different from the proof-of-work or proof-of-stake mechanisms on public chains: in a permissioned network with IBFT, a transaction is final as soon as a sufficient quorum of validators agree, typically within seconds, with no concept of chain reorganization.
This matters for financial applications in particular, where settlement finality is a hard requirement. A central securities depository or a tokenized bond platform cannot operate on a chain where a transfer could theoretically be unwound by a deep reorganization.
Once a network is running, Kaleido manages the full node lifecycle: provisioning new nodes (whether for additional validators or for read-only participant organizations), applying protocol patches, handling node restarts, and coordinating planned network upgrades across the validator set. The platform exposes this through both a UI and its API surface, so consortia that need to govern network changes programmatically, triggering upgrades as part of a CI/CD pipeline or a governance workflow, can do so without manual intervention.
Permissioned networks also support multi-cloud and multi-region node placement. Different consortium members can run their validator or participant nodes in different cloud environments or on-premise, while Kaleido's control plane provides a unified view of network health, peer connectivity, and block production.
The third mode is the least visible but increasingly important for enterprise deployments: what happens when the blockchain node you need to connect to is not managed by Kaleido at all? This is the case for network operators who run their own node infrastructure independently, industry consortia with existing node deployments, regulated environments where the node must remain on-premise, and chains like Canton that have their own node management model.
The remote node pattern decouples the Kaleido platform services from the physical location of the node. Your node continues to run wherever it currently runs (your own data center, your cloud account, a third-party operator) and Kaleido connects to it by registering a Remote Node entry that describes how to reach it. From that point, the full Kaleido toolchain becomes available against that external node: the EVM Gateway can route and authenticate traffic to it, the Block Indexer can track its chain state, the Web3 Middleware can submit and manage transactions against it, and the Digital Assets layer can track asset activity on it.
Practical implication: an institution that already operates a Besu node in its own AWS account, or participates in a consortium that uses an external node operator, can onboard to Kaleido by registering a Remote Node rather than migrating infrastructure. They get Kaleido’s transaction management, event indexing, and digital asset tooling without touching the node itself.
One of the most practically useful services that overlays any node, whether Kaleido-managed or remote, is the Transaction Manager. Submitting a transaction to an EVM chain is not a single atomic operation: your application must manage the account nonce (a per-address sequence number that prevents replay attacks), estimate gas, handle cases where a transaction is not mined within an expected time window, and decide whether to resubmit with higher gas or treat the submission as failed.
Kaleido's Transaction Manager handles all of this automatically. It maintains an internal nonce counter per signing address, tracks pending transactions, applies gas optimization based on current network conditions, and retries stalled transactions. Your application submits a transaction request and receives confirmation when it is on-chain; the retry and resubmission logic is invisible.
Figure 4. The Transaction Manager handles nonce sequencing, gas optimization, and automatic retries so application code does not need to manage these details directly.
The Block Indexer is available regardless of whether the underlying node is Kaleido-managed or remote. It subscribes to the chain's block stream and processes new blocks in real time, extracting the event logs emitted by smart contracts and making them available to downstream consumers. For applications that need to react to on-chain activity (a deposit arriving, a transfer completing, a contract state changing) the Block Indexer provides a durable, queryable event feed rather than requiring your application to poll the chain directly.
This matters more than it might appear. Polling a blockchain node for events is unreliable in practice: nodes can be briefly unavailable, blocks can arrive faster than your polling interval, and RPC rate limits can cause you to miss events. The Block Indexer solves the delivery guarantee problem: events are captured and stored in the platform, and your application can subscribe to them as a reliable stream without managing the block-level polling logic itself.
Chain Infrastructure is not only about the nodes themselves. Several platform-level services complete the picture for production deployments.
Blockchains are poor storage systems for large data objects: storing a file directly on-chain is expensive and impractical beyond a few kilobytes. The conventional pattern is to store data off-chain and record a hash on-chain, using the hash as a tamper-evident reference. Kaleido provides a managed IPFS (InterPlanetary File System) network as part of Chain Infrastructure. You deploy IPFS nodes through the same control plane as your blockchain nodes, and they form a private decentralized content-addressed store visible to your network participants. This gives you content-addressed off-chain storage with the same access controls and operational model as the rest of your network.
The Smart Contract Manager is a cross-platform tool that connects directly to Chain Infrastructure. It provides a registry for your compiled contract ABIs, manages versioning across contract upgrades, and generates typed REST APIs from the ABI automatically. For developers who need to interact with a contract without writing raw JSON-RPC calls, the generated API provides a typed, documented interface that maps directly to the contract's functions and events. Contract registrations persist in the platform, so teams share a single source of truth for deployed contract interfaces rather than managing ABI files across repositories.
All of the above (public chain nodes, permissioned networks, remote node connectivity, IPFS, block indexing) runs across AWS, Azure, Google Cloud, and Alibaba Cloud, with on-premise Kubernetes deployment available for environments that require it. A single Kaleido control plane manages all of this regardless of where the nodes physically run. This is particularly relevant for multi-geography deployments and for regulated institutions that need certain nodes to remain within a specific jurisdiction.
The design philosophy throughout Kaleido Chain Infrastructure is that the infrastructure layer should be invisible to application teams in day-to-day operation, while remaining fully configurable for teams that need to reason about it. Protocol engineers who need to tune consensus parameters or manage validator sets can do so through the platform APIs. Application developers who simply need a reliable JSON-RPC endpoint to submit transactions can get one without understanding the node topology behind it.
This also means that the choice between public, permissioned, or remote-node operation is not permanent. Teams prototyping on a permissioned testnet can connect the same application logic to a public mainnet node by updating the chain endpoint configuration. Teams that start with a remote node can migrate to a Kaleido-managed node later. The platform abstraction remains consistent across all three operating modes, so the choice of infrastructure model does not require rewriting application code.
For teams building with the Web3 Middleware or Digital Assets product lines, Chain Infrastructure is the layer you configure once and then stop thinking about: it handles the operational reality of blockchain nodes so those higher-level products can focus on transactions, events, and asset state.
Your guide to everything from asset tokenization to zero knowledge proofs
Download Now
Learn how Swift, the world’s leading provider of secure financial messaging services, utilizes Kaleido in its CBDC Sandbox project.
Download Now
.png)
