Knowledge Base Home

Kaleido Tenancy Model

Network Layer

A load balancer fronts the network layer (i.e. resource management layer) of the Kaleido Platform, providing DDoS protection and TLS authentication. TLS auth is enforced on every call (regardless of type), ensuring a secure connection for all resource-related actions. The network layer is accessible through a browser session or via the administrative API/CLI and can be used for CRUD operations against various resources such as environments, nodes, credentials, etc.

Application Layer

Similar to the network layer in the architectural sense, the application tier is fronted by an elastic load balancer that enforces security protocols and manages traffic routing. This layer can be best thought of as the blockchain boundary, where external applications seek a connection to a node’s endpoint in an attempt to R/W data from or to the ledger. Connections at the application layer are protected by strong access authentication tokens that are both member-specific and ephemeral. The plaintext username secret is not stored by the Kaleido backend (rather a salted hash is kept) and is only exposed once to the caller of the API. Application credentials can be combined with a node endpoint and passed to an Ethereum accessible API (e.g. web3.provider.WebsocketProvider) in order to connect with a node via HTTP or WebSocket connection protocols.

Environments and Nodes

All environments exist as isolated virtual networks, with firewalls ensuring no interaction or data leakage across domains. Every node and service is specific to its own environment, and can only be accessed through application credentials generated within its environment. A set of application credentials in Environment A cannot be used to access a node or service in Environment B, regardless if the node or service is owned by the same member.

The platform supports a variety of configurable environments, with multiple clients and consensus algorithms available to accommodate different business requirements. For example, a combination of Quorum + IBFT could be chosen to provision an environment capable of supporting private transactions while still delivering a robust byzantine fault tolerant consensus mechanism with signatures on the block.


Each node is provisioned an isolated file system that is both elastic for on-demand scaling and capable of interfacing with alternate workloads and applications on separate EC2 instances. This interoperability offers great value for integration with existing business processes.

Prev Key Terms Next Kaleido Resource Model