Federachain is a minimal, single-file implementation of a federated ledger.
It’s not “blockchain” in the Bitcoin/Ethereum sense — no proof-of-work, no PoS plutocracy, no thousand-layer complexity.
Instead it’s the distilled version of an idea that predates most of the hype: take a set of known, independent entities, have them co-sign blocks, and advance the log only when quorum is reached.
That’s it. Simple, cheap, fast, understandable.
The original Bitcoin paper was fascinating because it solved Byzantine agreement in an open, permissionless setting with proof-of-work. That breakthrough was new.
What followed — endless altcoins, smart-contract layers, PoS rebrands — has mostly been noise: technical overcomplication, speculation, and little real utility.
From the start, many argued that if you don’t need open membership and Sybil resistance, you don’t need PoW. You can just let a federation of N identified participants sign blocks collectively.
This gives you:
- No energy waste (no mining).
- Low latency (just digital signatures).
- Transparency & auditability (append-only log).
- Resilience (no single trusted party, but a quorum of many).
- Simplicity (hundreds of lines of code, not millions).
Federachain is a working demo of that idea.
-
Model:
Append-only block log. Each block contains:- header (version, height, timestamp, previous hash)
- payload (arbitrary data)
- signatures from federation members
- optionally a configuration section (to change membership or quorum)
-
Consensus:
- Federation members are identified by IDs + public keys.
- Each block is valid if signed by a quorum (e.g. 75% of current members).
- Membership changes (add/remove participants, change quorum percentage) happen via special CONFIG blocks, also signed by quorum.
-
Crypto backend:
- By default: HMAC-SHA256 as a placeholder (for demos only).
- With
-DUSE_LIBSODIUM: real Ed25519 signatures.
-
File format:
- Chain = append-only file of blocks.
- Each block serialized as
[u32 len][payload len bytes]. - Pending blocks exchanged off-band until enough co-signatures are collected, then appended.
-
Scope:
- No networking, no P2P, no VM, no tokens.
- Just a minimal executable model.
cc -O2 -Wall -Wextra -o fc federachain.cOptional with libsodium (for real signatures):
cc -O2 -Wall -Wextra -DUSE_LIBSODIUM -o fc federachain.c -lsodiumfc keygen <name> <outdir>
fc init <chainfile> <quorum_percent> <peers.txt>
fc propose <chainfile> <id> <privkey> <payload.bin> > pending.blk
fc cosign <chainfile> <id> <privkey> <pending.blk> > pending2.blk
fc finalize <chainfile> <pending.blk>
fc verify <chainfile>
fc print <chainfile>
fc reconfig-add <chainfile> <id> <privkey> new_id=new_pubhex
fc reconfig-del <chainfile> <id> <privkey> del_id
fc reconfig-quorum <chainfile> <id> <privkey> new_percent- keygen: create keypair for a member.
- init: create genesis pending block with initial participants.
- propose: propose a new block with payload.
- cosign: add another participant’s signature.
- finalize: append a block once quorum is reached.
- verify: check entire chain integrity.
- print: inspect chain contents.
- reconfig-*: change membership/quorum.
# 1. Generate keys
fc keygen alice keys/
fc keygen bob keys/
# 2. Create peers.txt
# <id> <pubkey-hex>
alice <hex>
bob <hex>
# 3. Initialize genesis
fc init chain.fc 75 peers.txt
# 4. Members co-sign genesis.pending.blk
fc cosign chain.fc alice keys/alice.priv genesis.pending.blk > g1.blk
fc cosign chain.fc bob keys/bob.priv g1.blk > g2.blk
# 5. Finalize
fc finalize chain.fc g2.blk
# 6. Propose a data block
echo "hello" > payload.bin
fc propose chain.fc alice keys/alice.priv payload.bin > b1.blk
...This is intentionally not a production system. It’s a minimal, inspectable reference: a few hundred lines of C you can read in one sitting.
It shows that:
If you need open, permissionless consensus, you need PoW/PoS and accept their costs.
If you just need a reliable shared log between known entities, you don’t need blockchain hype. A federated signature log is enough, and much simpler.
Public domain