The Corda blockchain is R3's permissioned distributed ledger for regulated businesses. A Corda project means writing a CorDapp in Kotlin or Java and running it on a Corda network where only the parties to a transaction see that transaction. This guide covers how Corda works, how a CorDapp is built, which Corda version to use, and what drives cost.
How the Corda blockchain differs from other blockchains
R3 designed Corda for a problem common in banking: two or more legal entities must agree on the state of a deal, keep the deal private from everyone else, and know for certain who signed what. Corda's main design choices follow from that problem:
- Point-to-point sharing. A transaction goes only to the nodes that are party to it, plus a notary, so a competitor's node on the same network never receives it.
- UTXO-style states. Facts on the ledger are immutable states. A transaction consumes old states and creates new ones, as Bitcoin does with outputs. A changed loan agreement becomes a new state that consumes the old one.
- Notaries instead of mining or global consensus. A notary service confirms that nobody has consumed a state before, which prevents double spends. A validating notary also checks the contract logic. A non-validating notary checks only uniqueness and sees less of the transaction.
- Known identities. The network operator issues each node a certificate tied to a legal identity; Corda does not aim for anonymity.
- JVM languages. Developers write contracts and flows in Kotlin or Java, so enterprise teams reuse their existing skills and tools.
Corda has no shared global state to query, because each node's vault holds only the states that involve that node. Ethereum developers find this the largest change.
The parts of a CorDapp
| Component | What it does | Design questions |
|---|---|---|
| States | Data objects that hold shared facts, such as a trade, an invoice or a token holding | Who are the participants? Which fields must every party see? |
| Contracts | Deterministic verification logic that every signer runs | Which commands are allowed? What makes a transaction valid? |
| Flows | Scripted conversations between nodes that build, sign and finalize transactions. Flows save checkpoints. | Who starts the flow? What happens if a counterparty is offline? |
| Notary | Checks uniqueness, and optionally validity | One notary or several? Validating or not? Who runs it? |
| Vault and queries | Each node's local store of the states that concern it | Which reports do business users need, and from which node? |
| Integration layer | RPC or REST clients that connect the node to core systems | How do existing systems start flows and receive updates? |
For asset projects, R3's Tokens SDK provides fungible and non-fungible token types. The SDK handles issuance, transfer and redemption, so teams do not write that logic from scratch. Bond, deposit and fund projects use it, as described in tokenization platforms.
R3 Corda development: Corda 4 or Corda 5
Corda 4 uses a single-process node, and most production Corda networks run on it.
Corda 5 split the platform into workers that scale out on Kubernetes. In Corda 5, "virtual nodes" let one cluster host many identities, and application networks are the unit of deployment. The programming model still uses states, contracts and flows, but the APIs changed enough that moving a Corda 4 CorDapp to Corda 5 means a port, not a recompile.
The public repositories show which Corda line had development activity in October 2026:
| Line | Public repository activity |
|---|---|
| Corda 4 (open source) | Release 4.14.3 tagged. A 4.15 branch received merges in October 2026. Corda 4.14 builds on Java 17 and Kotlin 1.9. |
| Corda 5 (corda-runtime-os) | The last code merges date from December 2024. Later commits are housekeeping only. |
Confirm R3's current support terms for each line in the Corda documentation or with R3 directly. Also confirm which version your network operator or consortium runs, because counterparties' infrastructure often decides it.
The CorDapp build process
- Model the deal. List the parties, the legal agreements, and every state change: issue, amend, settle and cancel. That list becomes the state and command design.
- Set privacy boundaries. Decide who must see each state, whether the notary sees contents, and whether parties need confidential identities.
- Write contracts and unit tests first. Business rules live in contract verification, and the Corda test DSL checks transaction validity without a running network.
- Write flows that handle failure. Flows save checkpoints and resume after a restart, but they still need logic for counterparties that never respond and for upgrades during a running flow.
- Run a local network. Start several nodes and a notary to test the whole process; in Corda 4, the Network Bootstrapper and the Gradle Cordform tasks build local networks. Then move to a test network that matches the target layout.
- Integrate and harden. Connect core systems through RPC, and set up monitoring, key management (often with HSMs), backups and disaster recovery.
- Plan upgrades. An upgrade to contracts or states in a live network needs every participant to coordinate, so agree on the governance before go-live.
Cost and timeline drivers
The number of organizations that must agree limits a Corda project more than the amount of code does. A proof of concept with one or two flows usually takes six to ten weeks for two experienced JVM developers and a part-time architect. A production rollout across several institutions takes several quarters and includes HSM integration, onboarding procedures, legal agreements and a security review. These figures are estimates, not quotes.
The main cost drivers are:
- The number of counterparties, and how fast each one can deploy and run a node
- Integration with existing payment, booking and reporting systems
- The license choice between open-source Corda and Corda Enterprise, and the support level
- Regulatory review, especially for settlement or custody
When Corda fits
Corda fits workflows between two or a few identified institutions where the law requires confidentiality, such as trade finance, syndicated lending, repo and insurance. See blockchain for finance for related cases.
Corda fits poorly when an app needs DeFi composability, anonymous participants or a token that trades on open markets. For a consortium that shares one ledger, compare Hyperledger Fabric and Quorum-style networks on Besu, which the enterprise blockchain overview compares. If only one organization writes the data, an audited database is enough.
Frequently asked questions
Is Corda a blockchain?
Corda is a distributed ledger with many blockchain properties: chained transactions, signatures and an immutable history. It has no single global chain by design, and R3 calls it a DLT.
What language do I need for CorDapp development?
Most samples and teams use Kotlin, and Java has full support. Experience with JVM concurrency, serialization and testing matters more than blockchain knowledge.
Does Corda have a cryptocurrency?
No. Corda has no native coin and no gas fees, and tokens on Corda represent assets that the network participants agree to issue, such as deposits or securities.
Can a CorDapp work with Ethereum?
Not natively. Cross-ledger settlement relies on bridges, hash-time-locked swaps or trusted intermediaries, and each option has its own trust assumptions. Treat interoperability as a separate project with its own risk review.
Should a new project use Corda 4 or Corda 5?
Most live networks run Corda 4, and the public Corda 4 repository still receives releases. Ask R3 about Corda 5 support before you start a new Corda 5 project.