Corda vs Solana for Regulated Financial Infrastructure

The choice between Corda and Solana is often framed as a binary: permissioned ledger versus permissionless chain, enterprise DLT versus public blockchain, institutional infrastructure versus consumer infrastructure. That framing is convenient, but for teams actually building regulated financial infrastructure it is too coarse. The two substrates solve different problems, make different trade-offs, and — increasingly — get deployed in the same system, each doing what it does well. This article walks through the architectural differences in practical engineering terms, sets out where each substrate fits, and explains how Bridge's multi-chain stack bridges the two without compromising the properties that make either worth choosing.

The audience for this comparison is the senior engineer or architect evaluating a ledger choice for a payment rail, a tokenisation platform, a custody service or a settlement network. We assume familiarity with both chains at an introductory level and will focus on the properties that determine fit for regulated use.

Corda and Solana are architecturally opposite. Corda, currently at its 5.2 major version, is a permissioned network of validating nodes that each hold only the state relevant to them. There is no global replicated ledger. Transactions are shared on a need-to-know basis between the parties, validated by a notary to prevent double-spend, and stored in each party's vault. The notary is a separately operated component that commits the consumption of input states. Contracts are deterministic JVM code, written in Kotlin or Java, and run as part of the flow that proposes the transaction. Finality is achieved at notary commitment and is absolute in the permissioned network.

Solana is a permissionless, globally replicated chain with a high-throughput consensus mechanism. Validators replicate all state. Transactions are ordered by a leader in a slot, executed in parallel where the accounts allow, and confirmed by supermajority. Programs are on-chain code, typically written in Rust and deployed to a program address; they can own accounts and enforce invariants. Finality is probabilistic but becomes practically absolute at around 32 slots (roughly 13 seconds) after commitment. The chain targets, and in typical conditions sustains, on the order of two thousand transactions per second across all users.

The architectural consequence for engineering teams is that the two chains give fundamentally different privacy, scale and control properties. Corda privacy is native: a bank's positions are in that bank's vault, not in a global replicated set. Solana privacy is by construction a design problem: all accounts are readable by all validators, and anonymity has to be engineered on top (through confidential transfers, zero-knowledge extensions, or off-chain data). Conversely Solana scale is inherent: validators scale linearly with the chain, and a retail product can expect millions of wallets to interact without bespoke scaling. Corda scale is a product of network design: throughput is the sum of each node's capacity on its own states, and a busy bank that posts its own transactions runs as fast as its nodes can.

For regulated finance the question that matters most is what "settled" means, and when it holds.

Corda settlement is deterministic and permissioned. A transaction is settled when the notary commits the consumption of the input states, and the commitment is recorded with signatures from the notary service. There is no concept of a reorg, no probabilistic waiting period, no "settled after N confirmations". When the notary says committed, the states are consumed and the new states exist, and the parties can rely on that outcome for legal settlement finality. This property is what makes Corda attractive for wholesale settlement — RTGS-on-DLT schemes, central bank pilots, interbank clearing. The finality semantic aligns with what a regulated settlement layer needs to offer.

Solana settlement is probabilistic but practically final on short timescales. A transaction lands in a slot, is confirmed by a supermajority, and is finalised once 32 slots have passed. Under normal conditions a finalised transaction will not be reverted; the chain has rarely experienced a reorg at the finalised depth. For retail payments, tokenised asset transfers, and most application use cases, this is more than sufficient. For settlement layers where legal finality has to be asserted at a specific moment against a specific regulator-recognised event, it is either a gap or a design constraint — the application has to wait for finality before declaring settlement, and the platform has to document its finality model for regulatory review.

A cross-chain design that uses both substrates typically routes "legally final" flows (central-bank money movements, bank-to-bank wholesale) through Corda, and "retail final" flows (customer payments, token transfers, consumer products) through Solana. Our RTGS on DLT pillar covers the wholesale finality argument in more depth.

Corda's identity model is built in. Every node has a certificate issued by the network operator; every transaction carries the identities of the signatories; every flow can authorise participants against the network membership list. Know-your-customer, know-your-business and regulator visibility are natural operations on the identity layer, because the identity layer is primary. A bank running a Corda node is identifiable by the certificate; an unknown party cannot transact with it because the flow refuses to accept unknown identities.

Solana's identity model is, by design, absent. A wallet is a public key. Anyone can hold a wallet; anyone can transact. Identity for regulated purposes has to be added as a layer: attestations stored on-chain (for example, as Solana Attestation Service records), allowlists maintained by a compliance program, or identity tokens that users must hold in order to transact with a regulated asset. The Token-2022 transfer hook pattern — which we covered in our compliance-native fintech API pillar — is the most common way of enforcing identity at the token layer on Solana.

For teams building regulated infrastructure, this means the identity engineering is in different places. On Corda, identity is upfront — network membership is a formal process, certificates are issued and revoked, the onboarding ceremony is a real event. On Solana, identity is per-asset — the mint that represents the regulated asset decides who can hold it, and the compliance programme issues and revokes the attestations. Both approaches work; the trade-off is that Corda gives a single identity surface across the whole network, while Solana gives per-asset flexibility at the cost of having to do the identity engineering once per programme.

Benchmarks on Corda and Solana compare apples to oranges, but the ballparks are useful.

A Corda network's throughput is the combined capacity of its nodes on their own states, bounded by the notary. A well-tuned notary cluster handles hundreds to low thousands of transactions per second; individual nodes handle tens to low hundreds of their own transactions per second. Latency to notarisation is typically in the low hundreds of milliseconds. Cost is operational — running nodes, notary, membership services — rather than per-transaction. This profile fits wholesale settlement: moderate volume, absolute finality, operated infrastructure.

Solana mainnet sustains, in typical conditions, on the order of two thousand transactions per second, with slot times around 400 milliseconds and finality around 13 seconds. Transaction fees are low (fractions of a cent for a standard transfer) but non-zero; complex transactions with multiple account loads can cost more. This profile fits retail payments: high volume, probabilistic finality, public infrastructure.

For a cross-chain architecture the throughput profiles inform routing. Retail-scale payment flows (remittance, wallet-to-wallet, token-to-token) run on Solana where the throughput and cost are a natural fit. Wholesale flows (central-bank money, interbank) run on Corda where the finality and identity are a natural fit. Our Solana patterns and settlement pages cover the routing logic at the product level.

The interesting engineering question is not which chain wins, but when to run both. Bridge's multi-chain stack is designed for that case, and the pattern it uses is worth describing.

A cross-substrate flow typically has a retail leg and a wholesale leg. A customer in Pakistan initiates a remittance from a wallet on Solana; the stablecoin moves on Solana with a Token-2022 transfer and the customer sees confirmation in seconds. The corresponding bank-to-bank leg — the movement of Pakistani commercial bank money into a correspondent's account — settles on Corda with a pacs.008 message and a notary commitment. The two legs are linked by an orchestration flow that treats the whole intent as a single unit of work, commits the Corda leg and the Solana leg in a two-phase protocol, and rolls back either side if the other fails.

The orchestration primitive is stateful: it holds the intent, tracks each leg's status, and decides completion based on the worst of the two. In Bridge's implementation the orchestration runs in a service that consumes Kafka events from both chains and offers a single status to the caller. The Solana leg reaches finality first (seconds); the Corda leg reaches finality on the notary commit (sub-second under normal load). The intent is declared settled only when both legs are confirmed.

A practical consequence is that the identity and compliance surfaces are unified. The identity service holds the customer's verification state once; the policy engine evaluates the intent once; the Travel Rule message is sent once; and each leg is executed with the same decision attached. The client does not see two ledgers — they see a single settlement intent that happens to have a Corda and a Solana component.

For a team choosing a substrate for a new product, the decision reduces to a small number of questions.

Is the product a wholesale or a retail product? Wholesale products favour Corda; retail products favour Solana. Does the product require legal finality tied to a regulator-recognised event? If yes, Corda; if "practical finality in tens of seconds" is sufficient, Solana is viable. Is the participant set bounded and known in advance? Corda is native to that model; Solana requires attestation-based gating. Is the expected transaction volume in the thousands per day or in the millions? Corda handles the first; Solana handles the second without bespoke scaling.

And: does the product need to settle against tokenised assets that have to move retail-scale while the cash leg moves wholesale-scale? Then the answer is both, and the engineering investment goes into the orchestration layer that binds them. Bridge's design starts from this assumption — that most non-trivial regulated products end up multi-chain — and builds the identity, policy, settlement and evidence layers once across the substrates. The individual chains are implementation details below a common intent surface.

Two operational points matter in the choice, beyond the architectural differences, and they are worth spelling out.

First, the staffing model is different. A Corda network requires a team that is comfortable running a permissioned DLT — operating nodes, rotating certificates, upgrading flows, coordinating network changes with counterparties. The skill set is closer to traditional enterprise infrastructure than to public-chain engineering. A Solana deployment requires a team that is comfortable with public-chain programming in Rust, with the Solana runtime's account model and compute constraints, and with the realities of running against a public chain (congestion windows, priority fees, occasional degradations). Both skill sets are available in the market, but they are separate specialisms, and a team that has invested in one does not automatically have the other.

Second, the upgrade tempo is different. Corda networks upgrade on a cadence agreed with the network operator and the participants — typically months between significant changes, with coordinated testing and rollout. Solana upgrades on the public chain's cadence, which is weeks between releases, with the programme owner responsible for keeping their programs compatible. The operational pace is substantially different, and the risk profile is different too: a Corda upgrade is a known event with known participants; a Solana upgrade is a public event whose impact has to be assessed on the fly. Teams that run both substrates build separate release engineering for each.

These realities do not change the architectural conclusions, but they do explain why many teams pick one substrate and stay with it. Moving to a multi-chain design is a deliberate investment that pays off for products whose regulatory, identity, or finality requirements span both sides.

Explore Bridge's multi-chain stack on /settlement and /solana; for deeper discussion of cross-border flows see the cross-border payment infrastructure pillar or contact the team to discuss a specific design.