# Elements is a Bitcoin sidechain platform with confidential assets and a federated peg

> Elements is an MIT licensed C++ implementation of a Bitcoin protocol extension platform that can run as a sidechain pegged to Bitcoin or as a standalone chain with arbitrary asset tokens. The same binary syncs several pre-set chains through a chain argument, and the project states plainly that testing and code review are its bottleneck.

**ElementsProject/elements** — Open-source implementation of advanced blockchain features extending the Bitcoin protocol

- Repository: https://github.com/ElementsProject/elements
- Stars: 1,170 · Forks: 422
- Language: C++
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/elementsproject-elements

## One binary, several chains, selected by a command line argument

Elements is described as the integration and staging tree for the Elements blockchain platform, a collection of feature experiments and extensions to the Bitcoin protocol. The stated purpose is that the platform enables anyone to build their own businesses or networks pegged to Bitcoin as a sidechain, or run as a standalone blockchain with arbitrary asset tokens.

The operational surface is smaller than that description might suggest, because the syncing mode is a flag. The README lists the pre-set chains that elementsd can sync with, and notes that some of them are intended for QA and debugging only.

```
* Liquid mode: `elementsd -chain=liquidv1` (syncs with Liquid network)
* Bitcoin mainnet mode: `elementsd -chain=main` (not intended to be run for commerce)
* Bitcoin testnet mode: `elementsd -chain=testnet3`
* Bitcoin regtest mode: `elementsd -chain=regtest`
* Elements custom chains: Any other `-chain=` argument. It has regtest-like default parameters that can be over-ridden by the user by a rich set of start-up options.
```

The custom chain case is the interesting one for anyone building on the platform. Any other chain name gets regtest-like defaults, which means a fresh chain starts with test-oriented parameters, and those are overridden through the start-up options. So creating your own network is a matter of naming it and configuring it, which is a much lower bar than writing a chain from scratch.

Two details in that list deserve attention. The Bitcoin mainnet mode carries a warning that it is not intended to be run for commerce, which tells you the mainnet configuration is a compatibility and testing target rather than a production target. And the Liquid mode is the one pre-set chain that is a real deployment, which is the clearest signal of how the platform is used in practice.

## Confidential assets blind the amounts and the asset identity, not the audit trail

Confidential Assets is described as the latest feature in the Elements platform, and the README explains it in one sentence with unusual precision: the ability to issue multiple assets on a blockchain where asset identifiers and amounts are blinded yet auditable through the use of applied cryptography.

That phrase carries the whole design. The blinding is what a user sees, a wallet that shows nothing meaningful about what was transferred. The auditability is what a regulator or an auditor sees, the ability to confirm that the totals in a block balance and that no value was created. Both are properties of the same cryptography, which is why the feature is interesting and why it is hard.

The project links the material a developer would need: an announcement of Confidential Assets, a Confidential Assets whitepaper that was to be presented at Financial Cryptography 2017 in Malta, a Confidential Assets Tutorial as a Python script in the repository at contrib/assets_tutorial/assets_tutorial.py, and a Confidential Assets Demo as a separate repository. There is also an Elements Code Tutorial covering blockchain configuration and the main features, hosted on the project website.

The tutorial being a Python script in the contrib/ directory is a good sign about how the project expects people to learn the feature. Rather than a prose walkthrough that goes stale, there is an executable artifact that runs the issuance flow against a chain you control.

The wider feature set relative to Bitcoin is listed as Confidential Assets, Confidential Transactions, Federated Two-Way Peg, Signed Blocks and Additional opcodes. The README also records what has moved in the other direction: Segregated Witness and Relative Lock Time have been integrated into Bitcoin, and Schnorr Signatures are deferred for additional research and standardization.

## The federated peg and signed blocks are governance as much as cryptography

Two of the platform features are less about mathematics and more about who is in the room.

A Federated Two-Way Peg is the mechanism that lets Elements assets and Bitcoin move between the two chains, and the word federated is the whole point. The peg is not enforced by the Bitcoin consensus rules alone. A set of federation members, signers with keys, attest to the state of the pegged chain, and the trust in the bridge is the trust in that federation. That is a different security model from a lock and burn, and it is a different one from a bridge run by a single company with a custodial balance.

Signed Blocks extends the same idea to the chain itself. If the blocks of an Elements chain are signed by a set of signers rather than being authorised solely by proof of work, then the chain can be far faster while still anchored to Bitcoin, because the security of the chain comes from the signers and the peg rather than from hashing. The design also gives the federation a direct role in governance, which is a feature for a regulated or consortium use case and a concentration of power for anyone worried about censorship.

The consequence for an adopter is that the trust model has to be chosen deliberately, and it involves people. Deploying a chain with a federated peg means running or trusting signers, and it means deciding how many and who, and what happens if some of them disappear or disagree. The README links the federated peg and signed blocks documentation on the project website, and that is where the operational detail lives rather than in the repository.

The Additional opcodes feature follows the same pattern of extending the Bitcoin script language, and each of these five feature links resolves to a page on elementsproject.org.

## A Bitcoin codebase with a depends system and CMake presets

The repository layout shows a descendant of a Bitcoin node rather than a project written from scratch, and the details of that inheritance tell you what you are signing up for.

The build is CMake, with a CMakeLists.txt at the root and a CMakePresets.json for the modern configure and build presets. The dependency system is the depends/ directory, which is the pattern Bitcoin uses to build a pinned set of libraries from source, so that a build is reproducible regardless of what the host distribution ships. There is a build_msvc/ directory for the Visual Studio build and a vcpkg.json, which is the modern Microsoft package manager, so there are two supported paths for Windows.

The CI configuration is in ci/ and there is a.cirrus.yml, which is the configuration for Cirrus CI, a service commonly used for BSD and macOS builds. The.github/ directory holds the GitHub side, and the.tx/ directory is the configuration for the translation platform, since the daemon's user-facing strings are translated.

Other files worth noting: an INSTALL.md for the build instructions, a CONTRIBUTING.md, a SECURITY.md which the README points to for vulnerability reporting, a doc/ directory, share/ for data files, contrib/ for the tutorials and helper scripts, src/ for the source and src/test/ for the unit tests, and a top-level test/ for the functional tests.

The.style.yapf and.python-version files show that Python is used in the test and tooling layer. The primary language is listed as C++.

One file is unusual enough to call out, libbitcoinkernel.pc.in. That is a pkg-config template, which means the build can install a shared library with a stable name and headers so that other projects can link against the node's kernel, rather than forking the source. For a project that expects to be extended, that is the difference between a copy and a dependency.

## Review is the bottleneck, and the project says so

The README has a paragraph about development that is unusually candid, and it belongs in any evaluation.

Testing and code review is the bottleneck for development. The project gets more pull requests than it can review and test on short notice, and asks people to be patient and to help out by testing other people's pull requests, while reminding contributors that this is a security-critical project where any mistake might cost people lots of money.

That is a real constraint on a codebase where a bug can be worth money. It also means the project values outside review help, which is unusual to state plainly and is a sign of a maintainer who has run out of reviewer time rather than one who wants to discourage contributions.

The testing story itself is well built for a C++ node. There are unit tests under src/test/ that developers are strongly encouraged to write for new code and to submit for old code, and they are compiled and run with ctest if they were not disabled during the generation of the build system. There are regression and integration tests written in Python under test/, run with build/test/functional/test_runner.py assuming build is your build directory. And the CI systems build every pull request for Windows, Linux and macOS and run the unit and sanity tests automatically.

So the three test layers are unit in C++, functional in Python, and a cross-platform CI matrix. What the project is telling you is that the automated part is covered and the human review part is what is short. For an adopter, that is a signal to prefer tagged releases over branch builds, and to budget more waiting than the release cadence suggests.

## Where Elements is the wrong choice

The first wrong case is an application that needs Bitcoin itself. Elements is a sidechain platform, and a federated peg means a set of signers attests to the link between the chains. If your requirement is to hold or move Bitcoin directly, this is the wrong layer, and if your requirement is trustless bridging, the federation is the reason to look elsewhere.

The second wrong case is a team that wants to be its own chain operator with no third party. Elements supports standalone chains with arbitrary asset tokens, and the custom chain mode has regtest-like defaults that you override, so the chain itself is yours. The federation is where the dependency comes in. A chain that relies on signed blocks needs signers, and those signers are an operational commitment that goes beyond running a node.

The third wrong case is a team expecting a modern protocol team. The release naming is the clearest signal, with tags like elements-23.3.4, and the newest is from 2026-09-09 with the last push on 2026-09-23. The project describes itself as the integration and staging tree, and the branch and staging structure means the tree you are reading is where changes land before they are released, which is a different stability posture from a repository that is the release itself.

The fourth wrong case is expecting Bitcoin feature parity beyond what is listed. The README is specific that Schnorr Signatures are deferred for additional research and standardization, so a design that assumes them is out of scope, and the Bitcoin mainnet mode carries an explicit note that it is not intended to be run for commerce.

## How it differs from other sidechain designs

The comparison worth making is with the other ways of anchoring a chain to Bitcoin, because the anchor is where the trust lives.

A federated peg, which is what Elements implements, uses a set of signers who attest to the state of the sidechain. The security of the bridge is the security of that signer set. It is fast, because the sidechain does not have to wait for Bitcoin confirmations on the peg side, and it is flexible, because the signers can be regulated entities. The cost is that you are choosing a set of parties to trust, and the security of the whole arrangement degrades with the weakest of them.

A lock and burn approach avoids signers by making the peg cryptographically enforced: the sidechain destroys the locked Bitcoin, and an equivalent amount is issued on the sidechain, with a validator set securing the sidechain against issuance without proof of the burn. The trust assumption moves to the sidechain's own security model, which for a proof of work chain means the hash rate and for a proof of stake chain means the stake. The cost is the wait for confirmations on the Bitcoin side and the requirement of a large validator set.

Elements takes a third route with signed blocks, where the chain's own block authorisation is handled by the signers rather than by proof of work. This is what lets the platform serve a consortium model, where a set of known institutions operate a chain between themselves, and it is the same set of parties that runs the peg.

The comparison that matters for an adopter is therefore not between implementations but between trust models. If your requirement is to anchor to Bitcoin without trusting a named set of parties, a federated peg is the wrong starting point, whatever the performance advantage. If your requirement is a chain operated by institutions you already work with, Elements' design fits it directly, and the ability to run the same binary in a standalone or custom chain mode is what lets one codebase serve several of those arrangements.

## Conclusion

Elements fits a team that needs a Bitcoin-anchored chain with its own asset types, or with transaction amounts and asset identifiers blinded but auditable, and it fits researchers who want a place to try protocol extensions before they are proposed to Bitcoin itself. It does not fit an application that needs to hold Bitcoin directly, since a federated peg means a set of signers vouch for the pegged chain rather than the chain being Bitcoin itself, and it does not fit a team without the ability to run consensus-critical infrastructure. Before adopting it, read the federation setup for your intended chain, note that the Bitcoin mainnet mode is explicitly not intended to be run for commerce, and remember that the newest release is elements-23.3.4 from 2026-09-09 with the last push on 2026-09-23.

## FAQ

### What does the Elements blockchain platform add to Bitcoin?

Compared to Bitcoin itself it adds Confidential Assets, Confidential Transactions, Federated Two-Way Peg, Signed Blocks and additional opcodes. Segregated Witness and Relative Lock Time have been integrated into Bitcoin, and Schnorr Signatures are deferred for additional research and standardization.

### How do I run elementsd on a custom chain?

Any other -chain= argument starts an Elements custom chain. It has regtest-like default parameters that can be over-ridden by the user through a rich set of start-up options. The pre-set modes are liquidv1, main, testnet3 and regtest, and the README notes that main is not intended to be run for commerce.

### How are Elements unit and functional tests run?

Unit tests live in src/test/ and are compiled and run with ctest, assuming they were not disabled when the build system was generated. Regression and integration tests are written in Python under test/ and are run with build/test/functional/test_runner.py, assuming build is your build directory.

### What is a federated two-way peg in Elements?

It is the mechanism that lets assets move between Elements and Bitcoin, using a set of federation members who sign attestations about the pegged chain rather than relying on Bitcoin consensus alone. Signed Blocks is the related feature in which the chain's own block authorisation is handled by signers.

### What license is Elements released under?

MIT, with a COPYING file at the root of the repository and the README linking the license text. The project also publishes a SECURITY.md vulnerability reporting guide and a CONTRIBUTING.md, and the newest release is elements-23.3.4 from 2026-09-09.

## Sources

- [ElementsProject/elements on GitHub](https://github.com/ElementsProject/elements)
- [Issues](https://github.com/ElementsProject/elements/issues)
- [License: MIT](https://github.com/ElementsProject/elements/blob/master/LICENSE)
- [README](https://github.com/ElementsProject/elements/blob/master/README.md)
- [Releases](https://github.com/ElementsProject/elements/releases)

---

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