# Cadence: a resource-oriented smart contract language for Flow

> Cadence is the smart contract language of the Flow network, built in Go around resource semantics with move semantics, capability-based access control through entitlements, and contract upgradability with enforced backward compatibility. The language and its interpreter are Apache 2.0 licensed, and the repository is the runtime implementation rather than a standalone tool.

**onflow/cadence** — Cadence: the resource-oriented smart contract programming language of the Flow network. Capability-based security, type safety, and move semantics

- Repository: https://github.com/onflow/cadence
- Website: https://cadence-lang.org
- Stars: 547 · Forks: 153
- Language: Go
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/onflow-cadence

## The whole pitch is that the compiler stops you

Cadence is the native smart contract programming language of the Flow network, and the README is blunt about who it is for and why. It is for developers building on Flow who want compile-time safety, resource semantics and capability-based access control, and the README adds that this is also for teams coming from Solidity who have been burned by reentrancy, unlimited approvals or MEV. The claimed benefit is that Cadence prevents entire vulnerability classes at the compiler level rather than relying on developer discipline, and the two examples are the most recognisable. Assets are resources rather than ledger entries, so they cannot be duplicated, and reentrancy attacks are significantly mitigated because a resource's reference is invalidated when it transfers, and approvals are scoped rather than blanket. The design principles section states the same things in implementation terms, with resource-oriented programming enforced by the compiler, capability-based security through entitlements that restrict functions to callers holding specific authorizations, strong static typing with inference, and contracts being upgradeable by default with enforced backward compatibility and no proxy pattern needed. The status line is that Cadence 1.0 is current, live on Flow mainnet, and open-sourced since 2019.

## Resources and entitlements, the two ideas a reader has to take on

The features list gives the two mechanisms that a Solidity developer will have to unlearn. The first is resource-oriented programming, described as a paradigm that pairs linear types with object capabilities to create a secure and declarative model for digital ownership, ensuring that resources and their associated assets can only exist in one location at a time, cannot be copied, and cannot be accidentally lost or deleted. The second is capability-based security, which enforces access control by requiring that access to objects is restricted to only the owner and those who have a valid reference to the object, refined further by entitlements for fine-grained access control on references. Together they are what the FAQ calls resource-oriented programming, pairing linear types with object capabilities so that a resource can only exist in one location at a time, cannot be copied, and cannot be accidentally lost or deleted. The distinction the README draws against Solidity is specific, that access control is capability-based via entitlements rather than msg.sender checks, and that the reference invalidation happens at runtime when a resource transfers. The compiler is doing the work in both cases, which is the point, and it is why the language is described as designed by smart contract engineers to prevent the vulnerability classes that plague Solidity development.

## A contract, and the tools that check it

The example in the README is a minimal contract with a public function, and the README notes it is the same example the @onflow/cadence-parser package uses to demonstrate parsing.

```cadence
access(all) contract HelloWorld {
    access(all) fun hello() {
        log("Hello, world!")
    }
}
```

The syntax itself is worth pausing on, because access(all) is a newer form than the access(all) and pub forms the language has used before, and the fact that the access level is written on the contract and on the function is the entitlement model in miniature, since the access annotation says who may call what and the entitlements refine it. For a full walkthrough of resources, capabilities and transactions the README points at the tutorial on cadence-lang.org, and for a first taste it points at the Cadence Playground in the browser at play.flow.com, which is the fastest way to see the language without setting anything up. The developer tools for local work are the Flow CLI, described as the primary tool for building on Flow, which includes the Flow emulator, a lightweight tool that emulates the behaviour of the real Flow network, and the VS Code Cadence extension, which enables development, deployment and interaction with Cadence contracts.

## The repository is a language implementation, not a tool you run

The top level of the repository is the shape of a language implementation, and it tells you how much is here. There is an ast/ directory for the syntax tree, a parser/ directory and an old_parser/ directory, a sema/ directory for semantic analysis, an interpreter/ directory, a runtime/ directory, a stdlib/ directory, a values/ directory, and a types.go and values.go at the root alongside their tests, which is where the type and value model actually lives. There is a formatter/ directory, a pretty/ directory for printing, an encoding/ directory, an errors/ directory, and common/ and utils/ for shared code. The bbq/ directory is notable by name alone, and the tree also holds activations/, benchmarks/, cmd/, examples/, fixedpoint/, integer/, npm-packages/, old_parser/, tools/ and test_utils/. The cmd/ directory is where the executable entry points are, and the Makefile shows them, with a parse command built to a native binary, a parse.wasm built for JavaScript with GOARCH=wasm and GOOS=js, a check command and a main command, plus a set of tools built separately, including an analysis tool, a get-contracts tool and a compatibility check tool. The npm-packages/ directory is what makes the parser usable from JavaScript, which is how a web IDE can parse Cadence in the browser. The go.mod requires Go 1.26.0, and the project is Apache 2.0 licensed with a NOTICE file and a CITATION.cff for academic citation.

## Licensing permits a fork, but the runtime is Flow's

The FAQ is direct about scope. Any Flow Access Node can accept Cadence transactions, and there is no requirement for a specific Flow client. But the README also says the Cadence implementation in this repository is designed as the runtime for the Flow network, and that the language and its interpreter are licensed under Apache 2.0, so forking and embedding are permitted, while the canonical execution environment is Flow's own. That is a carefully worded permission, and it is worth reading as what it is. The code is open, so an audit of the interpreter is possible, and the licence does not restrict who may build on it. What it does not do is make Cadence portable in practice, because the language's ecosystem, the tooling, the standard library conventions and the deployment path are all Flow shaped, and the entity model that the resource system is designed around lives on the Flow network. The README also states the current release is v1.10.2 while the release list in the repository shows v1.10.6, which is the kind of small discrepancy that tells you the README text is not regenerated on every tag. The most recent pushes were on 2026-09-02, the repository is not archived, and the release cadence is regular with several 1.10.x releases in the second half of 2026.

## Where Cadence is the wrong choice

The first limit is the network, and it is not a technicality. Cadence exists to be the language of Flow, so a team that needs its contracts to run on Ethereum, on another chain, or on a chain-agnostic settlement layer has to look elsewhere, and forking the interpreter does not give you the ecosystem, the tooling or the user base. The second is the cost of learning a new ownership model. The resource and entitlement system is not a small addition to a familiar language, it is a different mental model, and a team that writes Solidity quickly will spend real time internalising it, particularly around the fact that a reference is invalidated at runtime when a resource moves, which changes how a function that appears to be a getter can have side effects on the caller's ability to use the value. The third is that the guarantees are relative to a model, not absolute. The README says reentrancy is significantly mitigated rather than impossible, and that is the honest framing, since a language that removes one attack class does not remove the need for care about the others. The fourth is the maturity of the surrounding tooling, with a 1.0 language that introduced entitlements relatively recently, an interpreter that is still changing, and a repository carrying a ROADMAP.md, meetings/ directory and a compat/ directory for compatibility work, which all point at a project still settling. And the fifth is the pragmatic one about skills, since a Cadence developer is a narrower pool than a Solidity developer, and for many teams the cost of hiring or retraining outweighs the benefit of a better type system on a chain that is not theirs.

## Conclusion

Adopt Cadence if you are building on Flow and want assets modelled as resources with compiler-enforced move semantics, or you are coming from Solidity and want reentrancy and approval scope handled by the type system rather than by review. Skip it if you need to target Ethereum or another chain, since the language and interpreter are designed as the runtime for Flow even though forking is permitted. Verify first which Cadence version your Flow tooling expects, since the current release line is 1.10 and the README text refers to an earlier 1.10.2, and that the entitlements model you rely on exists in the version you are deploying.

## FAQ

### What problem does the Cadence language solve?

Cadence is the resource-oriented smart contract language of the Flow network, and it is designed to prevent entire vulnerability classes at the compiler level rather than relying on developer discipline. Assets are first-class resources with move semantics that cannot be duplicated, implicitly destroyed or accessed after being moved, and access control is capability-based through entitlements rather than sender checks, which significantly mitigates reentrancy and scopes approvals.

### How do I start writing Cadence contracts?

The fastest route is the Cadence Playground in the browser at play.flow.com, and the language reference is at cadence-lang.org with a tutorial on resources, capabilities and transactions. For local development the Flow CLI includes the Flow emulator, which emulates the behaviour of the real Flow network, and the VS Code Cadence extension supports development, deployment and interaction with contracts.

### Can I use Cadence outside the Flow network?

The README says the implementation in this repository is designed as the runtime for the Flow network, and that the language and its interpreter are licensed under Apache 2.0, so forking and embedding are permitted, but the canonical execution environment is Flow's. Any Flow Access Node can accept Cadence transactions, and no specific Flow client is required.

## Sources

- [License: Apache-2.0](https://github.com/onflow/cadence/blob/master/LICENSE)
- [onflow/cadence on GitHub](https://github.com/onflow/cadence)
- [Project website](https://cadence-lang.org)
- [README](https://github.com/onflow/cadence/blob/master/README.md)
- [Releases](https://github.com/onflow/cadence/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/onflow-cadence