Hey stackers. I'm Ben. I've spent the last year building satd
(https://github.com/epochbtc/satd), a Bitcoin Core-compatible full node in Rust,
aimed at self-custodians and people running nodes at home. v0.3.0 just shipped.

The problem I kept running into: if you want a node your wallets can actually
talk to, you end up babysitting a stack of processes. bitcoind, then electrs
or Fulcrum, then esplora, then nginx for TLS, then Prometheus, then some
ZMQ glue to tie it together. satd folds all of that into one daemon. One
process, one RocksDB, one systemd unit.

What's in the box:

Wallets connect with no sidecars. The Electrum protocol (1.4), an
Esplora-style REST API, and BIP 157/158 filters are all built in, with TLS, so
Sparrow, Nunchuk, BlueWallet, and Zeus just connect. The indexes live in the
same RocksDB as the chainstate and get written in the same batch as each block,
so they can't fall behind or race the tip the way a separate indexer can.

You can change relay policy without restarting. satd exposes the same
mempool/relay flags Core does (-datacarrier, -datacarriersize,
-permitbaremultisig, -dustrelayfee, ancestor and descendant limits). The
real difference from Core is that you edit bitcoin.conf, run systemctl reload satd (SIGHUP), and the new policy takes effect live, no restart, without
dropping your peers. A programmable policy engine (filter by script type
or fee logic without waiting on a release) is on the roadmap
(https://github.com/epochbtc/satd/blob/master/ROADMAP.md).

The status quo is the default. The BIP policy is written down in the
MANIFESTO: satd won't unilaterally activate a consensus change, and if an
upgrade is contentious it stays on the existing rules. Your node, your veto.

Why a second implementation, and how it avoids forking you off. This is
really the reason I started satd. Almost the whole network runs on one C++
codebase, which means a single bug in Core is a bug for nearly everyone at the
same time. The Core maintainer group is a single point of failure. More than one serious implementation makes the network more resilient. That's the longer argument in the MANIFESTO
(https://github.com/epochbtc/satd/blob/master/MANIFESTO.md). The risk is that a
second implementation is also exactly how you accidentally split consensus, so
satd is built specifically not to. It runs two script engines at once, an
independent Rust verifier and Core's actual C++ libbitcoinconsensus, and
checks them against each other at runtime. Zero divergence so far on every
script from genesis to the tip on mainnet, testnet4, and signet. Block
acceptance gets held to Core too, with fixtures ported from Core's own test
suite plus a fuzzer that throws adversarial blocks at both satd and a live
bitcoind and flags any disagreement. That said, obviously it's young software not
yet proven over many years. I use satd as my primary bitcoin node and backend for
wallets, but treat it as beta software.

You can see what it's doing. There's a built-in TUI (sat-tui) with an IBD
bitmap, a peer table, and a mempool view, plus a Prometheus /metrics endpoint
and a persistent reorg log you can point a webhook at. There's an optional MCP server if you want
to connect your node to AI tooling for block exploration or transaction automation.

GitHub: https://github.com/epochbtc/satd
Core differences: https://github.com/epochbtc/satd/blob/master/CORE_DIFFERENCES.md
Operator manual: https://epochbtc.github.io/satd/

Happy to answer anything, especially on the consensus testing or how the
indexing works.