Corda is R3's permissioned distributed ledger for regulated businesses. Building on it means writing a CorDapp in Kotlin or Java that defines shared facts (states), the rules that govern them (contracts) and the multi-party workflows that update them (flows), then running it on a network where only the parties to a transaction ever see it.
How Corda differs from a typical blockchain
Corda was designed around the problems banks actually have: two or more legal entities need to agree on the state of a deal, keep it private from everyone else, and know with certainty who signed what. Its main design decisions follow from that.
- Point-to-point sharing. A transaction travels only to the nodes that are party to it (plus a notary). Your competitor running a node on the same network never receives it.
- UTXO-style states. Facts on the ledger are immutable states that are consumed and replaced, similar to Bitcoin's outputs. A loan agreement that changes is a new state that consumes the old one.
- Notaries instead of mining or global consensus. A notary service confirms that a state has not already been consumed, which prevents double-spends. Validating notaries also check the transaction's contract logic; non-validating notaries only check uniqueness, which preserves more privacy.
- Known identities. Every node has a certificate tied to a legal identity, issued by the network operator. Anonymity is not a goal.
- JVM languages. Contracts and flows are written in Kotlin or Java, so enterprise teams can reuse their existing skills and tooling.
If you are coming from Ethereum, the biggest adjustment is that there is no shared global state to query. Each node's vault holds only the states it is involved in.
The building blocks of a CorDapp
| Component | What it does | Typical design questions |
|---|---|---|
| States | Data objects representing shared facts (a trade, an invoice, a token holding) | Who are the participants? What fields must every party see? |
| Contracts | Deterministic verification logic that every signer runs | Which commands are allowed, and what makes a transaction valid? |
| Flows | Scripted, checkpointed conversations between nodes to build, sign and finalize transactions | Who initiates? What happens if a counterparty is offline? |
| Notary | Uniqueness (and optionally validity) service | One notary or several? Validating or not? Who operates it? |
| Vault and queries | Each node's local store of relevant states | What reporting do business users need, and from which node? |
| Integration layer | RPC or REST clients connecting the node to core systems | How do existing systems trigger flows and receive updates? |
For asset use cases, R3's Tokens SDK gives you fungible and non-fungible token types without reinventing issuance, transfer and redemption. That matters if you are building something in the spirit of a tokenization platform for bonds, deposits or funds.
Corda 4 versus Corda 5
Corda 4 is the long-running, single-process node architecture most production networks were built on. Corda 5 re-architected the platform into a set of horizontally scalable workers designed for Kubernetes, with "virtual nodes" that let one cluster host many identities, and with application networks as the main unit of deployment. The programming model is recognizably similar (states, contracts, flows), but APIs changed enough that moving a Corda 4 CorDapp to Corda 5 is a port, not a recompile.
Before choosing, check R3's current support status for each line in the official Corda documentation, and confirm which version your network operator or consortium runs. In practice, your counterparties' infrastructure often decides this for you.
The build process
- Model the deal, not the database. Write down the parties, the legal agreements, and every state transition (issue, amend, settle, cancel). This becomes your state and command design.
- Decide privacy boundaries. Who must see each state? Does the notary need to see contents? Are confidential identities required?
- Write contracts and unit tests first. Contract verification is where business rules live, and the Corda test DSL makes it cheap to test transaction validity in isolation.
- Write flows with failure in mind. Flows checkpoint and resume after restarts, but you still need to design for counterparties that never respond and for upgrades mid-flow.
- Run a local network. Spin up several nodes and a notary to test end-to-end behavior (in Corda 4, the Network Bootstrapper and the Gradle Cordform tasks generate local networks quickly), then move to a test network that mirrors your target topology.
- Integrate and harden. Connect core systems through RPC, set up monitoring, key management (HSMs are common), backup and disaster recovery.
- Plan upgrades. Contract and state upgrades in a live multi-party network require coordination with every participant. Agree on the governance before go-live.
Cost and timeline drivers
Corda projects are rarely limited by code volume. They are limited by the number of organizations that must agree. A rough, assumption-based estimate: a proof of concept with one or two flows, built by two experienced JVM developers and a part-time architect, typically takes six to ten weeks. A production rollout across several institutions, with HSM integration, onboarding procedures, legal agreements and security review, is more commonly measured in quarters than weeks. The main drivers are:
- Number of counterparties and how quickly each can deploy and operate a node
- Integration with legacy systems (payments, booking, reporting)
- Licensing choice between open-source Corda and Corda Enterprise, and support needs
- Regulatory review, especially for anything touching settlement or custody
When Corda is, and is not, the right tool
Corda fits bilateral or small-group workflows between identified institutions where confidentiality is a legal requirement: trade finance, syndicated lending, repo, insurance and similar financial services use cases. It is a poor fit if you need public composability with DeFi, anonymous participants, or a token that trades on open markets. If your scenario is more about a consortium sharing one ledger, compare it with Hyperledger Fabric and Quorum and Besu, and read the broader enterprise blockchain overview. And if only one organization writes to the data, a well-audited database is probably the honest answer.
Frequently asked questions
Is Corda a blockchain?
Corda is a distributed ledger that shares many blockchain properties (cryptographically chained transactions, signatures, immutability of history) but deliberately has no single global chain. R3 describes it as a DLT; for most buyers the label matters less than its privacy model.
What language do I need for CorDapp development?
Kotlin is the most common choice and what most samples use. Java is fully supported. Experience with JVM concurrency, serialization and testing matters more than blockchain-specific knowledge.
Does Corda have a cryptocurrency?
No. Corda has no native coin and no gas fees. Tokens on Corda represent whatever assets the network participants agree to issue, such as deposits or securities.
Can a CorDapp interoperate with Ethereum?
Not natively. Cross-ledger settlement generally relies on bridges, hash-time-locked swaps or trusted intermediaries, each with its own trust assumptions. Treat interoperability as a separate workstream with its own risk review.