I'm Ben, and I've written a modern, independent implementation of the Bitcoin protocol in Rust. The primary problem I wanted to tackle was monoculture:
the Bitcoin network and community has been based on a single C++ implementation for 15 years, a descendant of the original Satoshi-authored codebase.
This codebase and the small Core committee are a single-point-of-failure, and is a potentially attractive target for those who would seek to damage or disrupt the network.
On top of that, while the Core team has done a great job at stewarding and improving the codebase, it can't help but be a big, complex
tree of largely legacy C++. I wanted something modern, easier to maintain and with batteries included:
- Native TLS (including mTLS) out of the box
- Built-in (optional) API services for Electrum (based on electrs) and Esplora (no sidecars or separate services needed to run a wallet backend)
- Atomic indices with a single RocksDB data store (address index can't lag core block index, for example)
- Robust authn/authz system with granular permissions
- Novel Streaming Consumer API with modern grpc and JSON websocket transports for integrators (including a privacy-preserving txn subscription option)
- ratatui-based TUI (sat-tui) for operator observability
- Optional, built-in MCP server for AI tooling integration
- Prometheus metrics exporter built-in
- Signed binaries + reproducible builds via Nix
On top of that, it has some additional enhancements:
- Optimized IBD with BitTorrent-style swarm block downloads
- bitcoin.conf compatibility (mostly Core v30-compatible, unsupported keys produce clear errors with guidance)
- JSON-RPC compatibility and sat-cli (similar to bitcoin-cli)
- Legacy deprecated functionality like wallet management and Bloom filters are omitted by design (BIP157/158 compact block filters supported)
To ensure no chain splits or consensus divergence with Bitcoin Core, satd performs dual engine shadow verification by default, using its own Rust consensus engine combined with Core's C++ libbitcoinconsensus FFI crate as a cross-check. The latter is authoritative by default, and any mismatches with the Rust engine are loudly logged. The operator can choose to make Rust or C++ the authoritative engine (with or without the other as a cross-check). The Rust engine has the same method signatures as Core but is 100% Rust and passes the same consensus test suite as Core. No divergence has been
observed on mainnet, signet or testnet4 from genesis to current tip (I saw a few divergences in early development, but none in the months since). For block acceptance, satd runs the same test suite as Core and there's an additional adversarial fuzzing test executed nightly.
While I use satd as my primary set of nodes and wallet backend, it obviously hasn't been battle-tested over many years like Core has, so treat as early beta software with appropriate caution.
On top of that, while the Core team has done a great job at stewarding and improving the codebase, it can't help but be a big, complex tree of largely legacy C++. I wanted something modern, easier to maintain and with batteries included:
- Native TLS (including mTLS) out of the box
- Built-in (optional) API services for Electrum (based on electrs) and Esplora (no sidecars or separate services needed to run a wallet backend)
- Atomic indices with a single RocksDB data store (address index can't lag core block index, for example)
- Robust authn/authz system with granular permissions
- Novel Streaming Consumer API with modern grpc and JSON websocket transports for integrators (including a privacy-preserving txn subscription option)
- ratatui-based TUI (sat-tui) for operator observability
- Optional, built-in MCP server for AI tooling integration
- Prometheus metrics exporter built-in
- Signed binaries + reproducible builds via Nix
On top of that, it has some additional enhancements:
- Optimized IBD with BitTorrent-style swarm block downloads
- bitcoin.conf compatibility (mostly Core v30-compatible, unsupported keys produce clear errors with guidance)
- JSON-RPC compatibility and sat-cli (similar to bitcoin-cli)
- Legacy deprecated functionality like wallet management and Bloom filters are omitted by design (BIP157/158 compact block filters supported)
To ensure no chain splits or consensus divergence with Bitcoin Core, satd performs dual engine shadow verification by default, using its own Rust consensus engine combined with Core's C++ libbitcoinconsensus FFI crate as a cross-check. The latter is authoritative by default, and any mismatches with the Rust engine are loudly logged. The operator can choose to make Rust or C++ the authoritative engine (with or without the other as a cross-check). The Rust engine has the same method signatures as Core but is 100% Rust and passes the same consensus test suite as Core. No divergence has been observed on mainnet, signet or testnet4 from genesis to current tip (I saw a few divergences in early development, but none in the months since). For block acceptance, satd runs the same test suite as Core and there's an additional adversarial fuzzing test executed nightly.
See the README for quick 2min start using Docker and the operator manual (https://epochbtc.github.io/satd/) for full details.
While I use satd as my primary set of nodes and wallet backend, it obviously hasn't been battle-tested over many years like Core has, so treat as early beta software with appropriate caution.
All feedback welcome!