CCF: a framework for multi-party applications on a Byzantine fault tolerant ledger

What the framework is for

The Confidential Consortium Framework, CCF, is an open-source framework for building a new category of secure, highly available and performant applications that focus on multi-party compute and data. That phrase is doing the work, and the repository topics make it concrete: confidentiality, consortium, distributed systems, governance, integrity, ledger, and a distributed ledger among them. The idea is that the application state is not held by one trusted party. It is replicated across a set of nodes that reach agreement through a consensus protocol, and the application logic runs on that replicated state, so the interesting property is that no single participant can quietly change what the others believe. A consortium framework is the case where the participants are known to each other, which is what makes it usable for organisations that would not run a public chain but would still rather not hand over the data. The primary language is C++, the licence is Apache-2.0, the last push was on 2026-10-19, and the recent releases are 7.0.21, 7.0.20 and 7.0.19 from the same three days in October 2026.

The getting started path is a sequence, not a download

The readme gives a five step path and the order matters, because each step assumes the previous one. You read the CCF overview and become familiar with the core concepts, which is the documentation's own framing of where the difficulty is. You install CCF on Linux. You become familiar with the core developer API with the template CCF app, which is a separate repository, so you get a working skeleton rather than an example to read. You quickly build and run the sample CCF apps, another separate repository. And then you build new CCF applications, in TypeScript or JavaScript or C++, with the documentation covering the whole application build area. The split into the framework repository and the two application repositories is a deliberate one, and it means the thing you copy when starting a project is a template, not a sample. The homepage is ccf.dev, and the documentation is hosted under the microsoft.github.io path for the main branch.

Applications are written in three languages

The top level of the repository is where the shape of the framework becomes visible. There is a src directory for the framework itself and an include directory for its public headers, and then there are three separate application language directories, js, python and ts. The js directory is the JavaScript application runtime, the ts directory is the TypeScript one, and the python directory is a Python runtime, and the build new applications line says TypeScript or JavaScript or C++, so the C++ path is the framework's own native one. The other directories are less obvious and more interesting. There is a tla directory, which is where a TLA+ specification of the protocol would live, and a cddl directory, which is where the CDDL, the Concise Data Definition Language used for describing the wire format, would be. There is a lean directory, which points at formal verification in Lean. A reproduce directory suggests the artifacts needed to reproduce the published verification work, and a 3rdparty directory holds vendored dependencies.

Three published papers, in the repository

Three PDF files sit at the repository root, and their names are the clearest statement of what has been verified. CCF-PAPER-VLDB-2023 is the earlier systems paper, presented at the Very Large Data Bases conference. CCF-TECHNICAL-REPORT is the technical report version of the same work. And CCF-VERIFICATION-NSDI-2025 is the more recent verification paper, for the 2025 symposium on network and distributed systems security. Having the verification paper in the repository rather than only a citation is unusual, and combined with the tla, cddl and lean directories it says that the protocol is specified in machine-checkable notation as well as in prose. The documentation also has a research papers section that collects them, and a separate section for the documentation generally, which is where the overview and the developer API material live.

The samples directory is a map of what a CCF application looks like

The samples directory is organised so you can read it as a progression. There is a CMakeLists.txt at the top of it, so the samples build as part of the framework's own build, and then an apps directory, a config directory, a constitutions directory, a minimal_ccf directory, a scripts directory and a templates directory. The constitutions directory is the interesting one for understanding the model, because a constitution is the set of rules the participants agree on: who can propose, who can vote, what a proposal needs to pass, and how members are admitted and removed. The minimal_ccf directory is the smallest complete application, which is the one to read first if you want to know what the framework requires of you as opposed to what it provides. The templates directory is where the scaffolding for new applications lives, and the scripts directory holds the helpers for running them.

The build and tooling are set up for a large C++ codebase

The build is CMake at the root, and the surrounding configuration tells you the project is maintained with the usual care for a C++ codebase of this size. There is a .clang-format and a .clang-tidy for the C++ side, a Doxyfile for the generated documentation, a .ruff.toml for the Python parts, a .prettierignore for the JavaScript and TypeScript parts, and a .CodeQL.yml for static analysis. There is a .devcontainer directory, so the build environment is reproducible as a container, and a .pipelines directory, which points at the release pipeline rather than a single continuous integration job. There is a .backportrc.json, which is a configuration for how changes get backported to older release branches, and the release history shows why that matters, since 7.0.19, 7.0.20 and 7.0.21 landed within four days. A .gitconfig in the repository root and a .gersemirc for commit message formatting sit alongside them.

Attribution, security and the parts of the repository you should not ignore

Three things in the tree are worth pointing at specifically. THIRD_PARTY_NOTICES.txt is the attribution file for the several open source third-party components the project relies on, and a framework of this size vendors a lot, so that file is the record of what is included. SECURITY.md is the security policy, which is the first file to read for a framework whose central claim is about confidentiality and integrity. And the cgmanifest.json is a component governance manifest, the file that records the provenance of the shipped dependencies, which pairs with the 3rdparty directory and with the fact that a manifest exists at all. The readme also has a note that the project welcomes contributions and points at the contribution guidelines, with separate issue templates for bugs and feature requests and a discussions board for questions and proposals, so the difference between a bug report and a design conversation is already settled by the tooling.

Editorial conclusion

CCF suits an organisation that needs several parties to share state without trusting any one of them, and that is willing to operate a replicated service and to write its application logic against the CCF API rather than against a database. It does not suit a project where a single operator is trusted and the operational cost of consensus buys nothing. Before you start, read the overview and the core concepts pages in the documentation, because the mental model of a replicated ledger is the hard part and the sample applications are the fastest way to get it, and read the security file before deploying, since a framework that makes strong claims about confidentiality and integrity should be read rather than assumed.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. microsoft/CCF on GitHub
3. Project website
4. README
5. Releases