← All posts
5 min read

BEEFY is live: QBC is now signing its own finality

BEEFY finality proofs are live on QBC: validators are signing portable commitments just behind GRANDPA on every block. Hours after shipping armed and dormant, the proofs QBC was built to hand out are flowing.

Earlier today we shipped BEEFY and MMR to QBC and were careful to say exactly what it was: an additive finality-proof layer, deployed, armed, and correct, but not yet producing anything. The groundwork, not the running system. This is the short follow-up, because the running system is now running. BEEFY is live, and the validators are signing portable proofs of QBC's finality that anyone can verify.

What "live" means here

The point of BEEFY is a small, self-contained proof that a given QBC block is final, checkable by a light client on a phone or a smart contract on another chain without running a full node. That proof is a validator-signed commitment over the MMR root. Until an hour ago there were zero of them. Now beefy_getFinalizedHead returns a real, advancing block on every validator, tracking the GRANDPA finalized head within a handful of blocks. In plain terms: as GRANDPA finalizes a block, BEEFY signs a commitment right behind it, and that commitment is the thing an outsider can trust.

Throughout, GRANDPA finality never moved off its normal cadence. That was the whole design bet: BEEFY runs as an isolated layer, so activating it, or even fumbling it, could never touch block production or finality. It held.

What activation actually took

Two steps, one of them more interesting than expected.

The first was routine. Each validator registered a real signing key for BEEFY, a secp256k1 key of the same family Ethereum uses, chosen deliberately so an Ethereum-side verifier can check QBC's authority set cheaply. We rotated these in without disturbing the existing block-production and finality keys, so there was no authority-set churn.

The second was the interesting one, and it is worth writing down because it is the kind of thing you only learn by turning the system on. BEEFY, when it starts, has to read the validator set from chain state at its genesis block. We had first anchored BEEFY's genesis a few thousand blocks in the past. Most of our validators had that state. One did not: it had joined the network by checkpoint sync and prunes old state, so the block BEEFY wanted to read was long gone from its database. Its BEEFY worker sat waiting for history it would never get, and because a small validator set needs every member to sign, the whole thing stalled on that one node.

The fix was not a heavy re-sync. The BEEFY pallet has a designed reset for exactly this: re-anchor BEEFY's genesis to a recent block, one that every validator still has both the header and the state for. We did that, restarted the validators, and each one initialized cleanly, concluded its first mandatory round, and started signing. No history archaeology, no downtime that touched users. The lesson is now written into our runbook: a BEEFY validator has to keep the genesis block inside its state window, or run with deeper history.

Where this leaves us

BEEFY going live does not change what QBC is today, but it changes what can be built on top of it. The chain now emits a continuous stream of signed, portable finality proofs. That is the exact primitive trustless bridges are made of, and it is the shape of finality proof you want when the validator set grows toward the thousands we are building for. It is groundwork, still, but it is groundwork that is now switched on and carrying load.

The chain that finalizes a mind is now also signing, block after block, a proof of that finality small enough to carry anywhere and check without trusting us. That was the promise. As of today it is live.

Further reading

ShareXLinkedIn

Written by

A
Ash Brown@blockartica
Founder, SusyLabs / QuantumAI Blockchain

Building the post-quantum AI-native L1 with permissionless on-chain training cycles. Writes about consensus, attestation, and the gap between what ships and what's claimed.

Related posts