A stack, not a chain
Most people encounter blockchains as shared public networks. Every application is a smart contract competing for space in the same blocks, under the same governance and schedule. Instead, Cosmos treats the application as its own chain. The Cosmos SDK is the core framework. Its maintainers describe it as a toolkit “tailored for building secure, sovereign application-specific blockchains” (cosmos-sdk README), where the application defines the chain. The Cosmos documentation describes the costs of a shared virtual machine directly. General-purpose chains “can impose constraints around performance, customization, and protocol-level control.” An application-specific chain lets the operator “tailor execution logic, fee models, governance rules, and state transitions directly at the protocol level” (Application-Specific Blockchains). Sovereignty is control over the chain’s protocol and governance. On a shared chain, the underlying network’s governance supersedes the governance of the application running on it.Why a bank runs its own chain
For a bank, who may validate is a control question. Whether and when the software upgrades is a change management question. Data visibility is a confidentiality question: a public chain makes everything visible to everyone. Congestion from an unrelated application is an availability question. On a shared chain, another organization answers all four questions. Running the chain gives the bank the same answer it has for its core banking platform: the bank decides. CTS therefore deploys a private chain alongside the core instead of writing to a public network. See Digital ledger support.The components
CometBFT
CometBFT performs “Byzantine Fault Tolerant (BFT) State Machine Replication” (CometBFT). A set of machines agrees on an identical ordered history, even when some machines fail or behave incorrectly. CometBFT is a fork of Tendermint Core and implements the Tendermint consensus algorithm. Its safety property is conditional: the specification assumes that at most one third of validator voting power is Byzantine (consensus spec). Under that assumption, two conflicting blocks cannot be committed at the same height. Above that threshold, the guarantee does not hold. In a private deployment where the bank operates the validators, the threshold mainly describes tolerance for machine and data centre failures, not defense against an adversarial validator set.Cosmos EVM
Cosmos EVM embeds the Ethereum Virtual Machine in a CometBFT chain. It implements the full Ethereum JSON-RPC API and standard Ethereum transaction formats. Therefore, “if you already deploy to Ethereum or EVM rollups, you can deploy to a Cosmos EVM chain with no contract changes” (Cosmos EVM). Hardhat, Foundry, and standard client libraries work unmodified. The relevant contract skills, audit firms, and tooling are the widely available Ethereum ones.IBC
Each chain “uses the light client of the other chain to quickly verify incoming messages” (IBC introduction). The two chains verify each other directly instead of trusting an intermediary operator. This mechanism distinguishes IBC from a bridge, as covered in Inter-Blockchain Communication.Finality, and why it is a settlement question
Probabilistic finality is confidence that accumulates without reaching complete certainty. Waiting for several confirmations is therefore standard practice. The receiving institution must choose a confirmation depth and carry the exposure until that depth is reached. CometBFT does not use probabilistic finality. A block is committed after more than two thirds of voting power has precommitted it, and it is then final. There is no confirmation depth or reorganization to plan for. A transaction is either in a committed block or it did not happen. This turns an operational problem into a technical fact. The mechanism does not settle the legal question, which depends on the rail and jurisdiction, not the chain. See Finality.Permissioned and private deployment
The stack does not require a public chain, public token, or public interface. The Cosmos SDK publishes enterprise modules for “permissioned networks, institutional chains, and enterprise deployments that need features beyond a public blockchain architecture” (Enterprise modules). These modules include Proof of Authority for permissioned consensus. It supports “networks run by a known set of operators without staking or tokens.” An administrator account manages the validator set and can be a governance address, multisignature wallet, or contract (Inside the PoA module). Every validator-set change is an explicit on-chain transaction. This makes the validator roster auditable instead of emergent. In a Suite deployment, the bank operates the chain, validators provide availability and redundancy, and the chain exposes no public interface. See Digital ledger support.Maturity and adoption
The software is neither new nor niche. The Cosmos Hub was the first production chain built on the SDK, and it launched in March 2019. The SDK is now “used by 200+ chains in production” (cosmos-sdk README). The reference IBC implementation “has been used in production by the majority of the 200+ chains that have utilized IBC” (ibc-go README). CometBFT describes itself as “the most widely-adopted, battle-tested consensus engine in blockchain today” (CometBFT). That statement is a claim by its maintainers, not an independent measurement. This record shows that the consensus engine, framework, and interoperability protocol have operated continuously at scale for years across many independent teams. It establishes nothing about a specific bank’s deployment. Throughput and sizing for the chain operated by CTS are documented separately, with their measurement conditions, on Cosmos EVM.Next
- What is the Cosmos Tokenization Suite for what is built on this stack
- Cosmos EVM for the recommended chain and its published performance figures
- Inter-Blockchain Communication for how the bank’s chain reaches counterparties