I present a challenge for all the covenant aficionados out there, and your favorite opcode. I’m looking for specific covenant proposals which accomplish the following:
Background
Braidpool (A decentralized mining pool) will need to custody coinbase rewards across multiple blocks. For this I have proposed using a FROST federation which signs two chained transactions RCA and UHPO for this:
Coinbase → RCA → UHPO
Rolling Coinbase Aggregation (RCA): This is an Eltoo transaction on-chain that aggregates the most recent coinbase with the previous (aggregated) coinbase(es).
Unspent Hasher Payout Object (UHPO): One or more transactions that spends the RCA and pays all hashers in proportion to the work contributed. This transaction is timelocked and cannot be broadcast until the end of a difficulty adjustment window (the “settlement period”), at which time the most recently created UHPO is broadcast (with all previous UHPOs invalidated by the Eltoo mechanism of its parent RCA) and pays all miners for the preceding settlement period.
I have proposed using a FROST federation in development by @jungly for this. Our construction has the following properties:
The UHPO transaction is constructed and signed or committed to first. All federation signing nodes can independently construct and verify the payouts in the UHPO transaction because they each have a copy of the Braidpool DAG with share information.
The RCA transaction is signed or committed to after the UHPO transaction is signed by a quorum of federation nodes.
The Byzantine fault tolerant signing quorum is 3f+1 or 67% of the signing nodes.
The FROST Federation has a number of drawbacks, not the least of which is a 51% attack (or 67% attack) on the pool, if federation membership is decided by PoW, which could steal all funds. If federation membership is decided by some other manner this results in a highly political process at odds with the decentralized nature of Bitcoin, and theft is still a possibility. I wish to consider a covenant-based alternative which eschews the need for custody entirely, or achieves a “can’t-be-evil” philosophy where only the correct payouts can happen.
Requirements
The RCA transaction must either: be aggregated with another coinbase to create a new RCA transaction (Eltoo) OR (after a timelock) be spent in a UHPO transaction. It must not be spendable in any other way.
A block with an incorrect payout not satisfying the requirements of the RCA or UHPO must be spendable (after a possible timelock) as solo-mined block, and will not be considered a “share” by the pool.
Coinbase outputs must have a timelock that falls back to solo mining, so that in the event of a pool failure (RCA not constructed/mined), all miners with blocks not aggregated in the RCA can claim their blocks as solo mined blocks.
Each new block found by the pool modifies the set of payouts in the next UHPO, so the UHPO from the previous block can’t know the correct payouts in the next block and can’t commit to it.
In the event of an incorrect RCA or UHPO transaction or 51%/67% attack on the FROST federation signing, and a theft attempt is broadcast or otherwise detected against the RCA or UHPO, the “last-known-good” UHPO transaction must become immediately broadcastable, evading its usual timelock, and ensuring that the RCA Eltoo mechanism is invalidated for future blocks. The pool becomes entirely solo-mining or shuts down in this case.
Assume that information necessary to construct the UHPO is known at the time a block template is constructed, and can be committed to in a block. (It’s the INPUT to this UHPO tx that requires custody across multiple blocks)
You must take into account the 100 block coinbase maturity rule.
A couple suggestions:
You MAY choose that the UHPO has all the same outputs as the previous UHPO, with amounts that are greater than or equal to the previous UHPO, with additional outputs added.
You MAY spend the entire RCA to fees if it is included in a pool’s block, in order to get rid of the RCA and have the UHPO directly committed to by the coinbase output. (As long as this can’t be stolen by another miner)
You MAY eschew the RCA mechanism in favor of taking all coinbase outputs from the previous settlement period as inputs.
Something deviating from the above outlined structure is welcome as well, if it achieves the goal of ensuring that everyone gets paid correctly and uses covenants.
A proof of impossibility would be welcome as well.
P.S. I have avoided describing other approaches that we might take here to keep it concise. (e.g. the P2Pool/Eligus/OCEAN mechanism of paying PPLNS in coinbases – we can always fall back on that but it’s been done has well known drawbacks) If that info would be helpful I can write it up in a separate post or doc on the Braidpool github. (msg me privately if that is of interest)
This suggests that Braidpool-style rolling aggregation can be implemented as a sequence of per-round covenant updates, rather than requiring a single persistent commitment across blocks.
The key insight on Req 4
Req 4 looks like a contradiction — CTV commits to a static hash, but UHPO payouts change every block. It dissolves when you treat each APO replacement as atomic with its CTV update:
APO handles the input side: the update signature doesn’t commit to the previous RCA’s txid, so you can pre-sign the next state before the current one hits the chain.
CTV handles the output side: each new RCA commits to the current period’s UHPO template. When the old RCA gets spent, its UHPO loses its input and can never be broadcast. Only the latest RCA survives, so only the latest UHPO can settle.
Dynamic payouts through a sequence of per-round static commits. APO and CTV fire together on every update — no single commitment needs to span multiple blocks.
The RCA script shape
Each RCA output is a three-leaf Taproot tree:
leaf 1 — ctv_uhpo: OP_CHECKTEMPLATEVERIFY
locks spend to the committed UHPO template
leaf 2 — apo_update: <0x01||xonly_pubkey> OP_CHECKSIG (BIP118)
next RCA can replace this one without knowing the txid
leaf 3 — csv_escape: <N> OP_CSV OP_DROP <pubkey> OP_CHECKSIG
timeout fallback for solo mining recovery
Demo 1 — APO rebinding
Two UTXOs, same script, same amount, different txids. One APO signature spends both — witness bytes are byte-for-byte identical across the two spend transactions, only the prevout differs. This is what makes pre-signing the next RCA state possible before the current one hits the chain.
The two spend txs look identical on the surface (same script, same amount, same output address) — that’s by design. The proof is in the input: each spends a different prevout, but the witness bytes are identical. SIGHASH_ANYPREVOUT does not commit to the outpoint, so the same signature validates against either UTXO.
Witness: three stack items (BIP118 signature + 0x01‖xonlyOP_CHECKSIG leaf + control block). Stacks are byte-for-byte identical on both spends; only vin outpoints differ.
Witness — APO updates (v1→v2, v2→v3): same three-part shape each time (BIP118 signature + leaf + control block), but each step uses a new signature (new state).
Witness — CTV settlement: two elements — 32-byte template hash push + control block. No Schnorr signature. nSequence is 0xffffffff. Explorers show the opcode as OP_NOP4.
Requirements mapping
Req
Status
Note
1
✓
Three leaves are the only spending paths
2
partial
csv_escape leaf exists; “incorrect block → solo claim” not fully demoed
3
partial
CSV timeout present; demo uses normal UTXOs not real coinbase
4
✓
APO + CTV atomic update dissolves the dynamic commitment problem
5
open
See below
6
✓
UHPO template committed into RCA at block template construction time
7
partial
Real coinbase maturity needs extra timelock layering
Trade-offs
Each pool aggregation round that advances the UHPO snapshot uses its own on-chain RCA update (one APO spend) — one covenant step, one update tx.
On-chain footprint scales with how many rounds you run.
Complexity shifts from script expressiveness to transaction orchestration outside the script.
On Req 5
No solution here. “Detect an attack and immediately unlock” requires the script to observe external chain state — none of the current opcodes can do this. CSFS can verify an authorization signature, but whoever holds that key becomes a new trusted party, reintroducing the centralization you’re trying to remove. A minimal additional primitive enabling conditional unlock based on external chain state (something like OP_VAULT’s trigger mechanism) would close this gap.
Note on FROST
Demo uses a single key where production Braidpool would use a FROST aggregate — on-chain they look identical (64-byte Schnorr signature either way). The covenant layer limits FROST’s role: whatever key signs the APO update, the CTV commitment means they can only produce a valid UHPO. FROST goes from “decides payouts” to “triggers the update.”
Curious whether others see a path to Req 5 without introducing new trust assumptions.
This discussion around RCA / UHPO state aggregation is very interesting.
In our research group we have been exploring a related approach for modeling continuous-state UTXO machines without consensus covenants, by moving the enforcement to the signing layer.
The architecture we are experimenting with encodes the evolving state algebraically into a Taproot key tweak (what we call the Astrolabe pattern), while a local Simplicity VM evaluates the covenant logic before a Schnorr signature is produced.
In other words, the covenant is enforced client-side at signing time rather than by the network.
Obviously this does not provide the same trust model as consensus covenants or ANYPREVOUT, but it allowed us to experiment with continuous-state machines (CDPs, AMMs, etc.) on signet/mainnet without pre-signing large transaction trees.
I’m curious whether something like this could be useful as a research testbed for Braidpool-style payout orchestration before consensus primitives are available.
Would a “soft covenant” approach at the signing layer provide any useful insights for RCA/UHPO design, or do you see fundamental limitations that would make it irrelevant for this class of protocol?
Challenge Follow up：Dynamic coinbase aggregation on Inquisition signet — multi-input APO with growing amounts (Braidpool RCA)
Picking up from my reply in the Braidpool covenants challenge thread (where I walked through how the covenant stack could meet the pool’s constraints), I later posted an on-chain Eltoo state chain demo as a closed system: one input per round, amounts only moving downward. After the Eltoo demo, the next question that kept bothering me was what happens once new coinbase keeps arriving and the pool actually grows? This is the motivating shape of Braidpool’s rolling coinbase aggregation.
I tried to answer that by actually constructing the transactions on-chain.
What changed
Each aggregation round is now a two-input transaction:
Input 0: RCA state UTXO — APO script-path (BIP 118, 3-leaf TapTree)
Input 1: New coinbase — bare P2TR key-path (different address)
Between R2 and R3, what surprised me a bit is that the control block makes the state evolution very explicit — you can literally see which part changed across rounds:
As expected in hindsight, the CTV leaf hash changes every round as the payout template evolves. The CSV escape hatch, on the other hand, stays completely unchanged — which is exactly what you’d want from a protocol constant.
CTV settlement
The final transaction (7669e251...) spends RCA v3 via the CTV leaf:
Input 0: RCA v3 (92,750 sats) — CTV script-path spend
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
P2TR tapscript:
OP_PUSHBYTES_32 ee9a9088aecc7bd5df75a7dbe80d2031
c1f02e87a84fa330d9d696ccb6d2b866
OP_NOP4
^^^^^^^^^^^^
= OP_CHECKTEMPLATEVERIFY (opcode 0xb3)
nSequence: 0xffffffff (CTV requires this)
The template hash commits to exactly 3 outputs at exactly these amounts.
Any deviation → script fails → transaction invalid.
Output 0: 40,387 sats → Miner A (45% of pool - fees)
Output 1: 31,412 sats → Miner B (35% of pool - fees)
Output 2: 17,951 sats → Miner C (20% of pool - fees)
The sighash detail that matters
BIP 118 Msg118 for input 0 includes sha_amounts and sha_scriptpubkeys covering all inputs — including the coinbase from a completely different address. If the coinbase input’s scriptPubKey is missing from the array, the sighash digest is wrong and the signature is invalid.
I didn’t expect this at first, but dynamic aggregation turns out to be trickier than the single-input Eltoo case: every additional input changes the sighash context for the APO-signed input.
What this proves beyond the previous post
Property
Previous (Eltoo chain)
This experiment
Inputs per round
1 (same address)
2 (different addresses)
Amount trend
Decreasing
Increasing
Input scriptPubKeys
Homogeneous
Heterogeneous
Pool pot
Static
Grows: 32k → 63k → 92k
UHPO allocation
Fixed ratios
Evolving: 100% → 50/50 → 45/35/20
Braidpool applicability
LN-Symmetry analog
Dynamic coinbase aggregation
What it doesn’t prove (yet)
100-block coinbase maturity (wallet-funded proxies — addressed in follow-up)
Solo-mining fallback (no CSV leaf on coinbase — addressed in follow-up)
FROST federation threshold signing (single key in demo)
With the CSFS equivocation penalty from our previous experiment:
Building block
Opcode
On-chain
RCA Eltoo state chain
APO
yes
Dynamic coinbase aggregation
APO
yes (this post)
UHPO deterministic payout
CTV
yes
Signer accountability bond
CSFS
yes
The unsolved parts of mcelrath’s Braidpool challenge (maturity handling, emergency broadcast, solo-mining fallback) are protocol-layer constraints, not signing-primitive gaps. The covenant building blocks are individually validated.