design: the covenant is signature-free so anyone can broadcast the claim — but exactly-one-output rules out an in-transaction bounty

[Zyrtnin]

The property

The HTLC covenant contains zero OP_CHECKSIG. Both branches are signature-free:

• claim — scriptSig <preimage> <OP_0>
• refund — scriptSig <OP_1> only ("no preimage, no sig")

Destination is enforced by the covenant pinning hash256(tx.outputs[0]) to the taker's (claim) or maker's (refund) holder script.

Two consequences follow, and the first is an opportunity rather than a defect:

1. Once the maker reveals p, anyone can broadcast a claim that pays the taker. No authorisation exists to withhold, and a third party cannot redirect the output. So the requirement is not "the taker must be online" — it is "someone must pay a fee."
2. README.md's "the RXD covenant claim is not pre-signable" is about the fee input, not the covenant. The watchtower's hot key is a fee key, not one that can move swap value. Smaller blast radius than the phrasing implies.

The idea

Fund a bounty that pays whoever broadcasts the claim, turning a liveness dependency on one party into an open incentive. This is structurally the Lightning watchtower-incentive pattern.

The objection that makes the naive version wrong

A bounty for broadcasting pays for speed, and on a chain with low reorg cost speed is exactly the wrong thing to buy. The whole assess_claim_finality / value-scaled-burial apparatus exists to make the claim wait. A first-to-broadcast bounty pushes directly against it.

It compounds with #511: because the refund is signature-free too, once CSV matures anyone can broadcast the maker's refund. Both sides are permissionless, so a bounty would fund one side of a race a reorg can re-run.

The inversion that might work

Pay for burial, not for broadcast. Let the claim create a second output — a bounty spendable by anyone only after N blocks via OP_CHECKSEQUENCEVERIFY, which on Radiant is consensus-enforced and relative to that transaction's confirmation. If the claim is reorged out, the bounty output ceases to exist with it. The hunter is paid only if the claim stuck for N blocks, which is the property the taker actually cares about.

That converts a race into an alignment, using a primitive the chain definitely has.

Unverified — needed before anyone builds this

• Does the covenant constrain the number of outputs? It pins outputs[0]; if it also fixes the output count there is no room for a bounty output.
• Fee cost of the larger claim transaction against Radiant's relay floor, on a chain with no RBF and no CPFP — a bounty that makes the claim unaffordable is worse than none.
• Where the bounty is funded from. Most plausibly out of the claim amount, i.e. the taker trades a slice of proceeds for liveness.
• Interaction with The signature-free refund makes an UNCONFIRMED claim sitting through CSV maturity unsafe (eviction/reorg, not a lost mempool race) #511's eviction analysis, which is about exactly this window.

Scope note

This does not help the gBTC direction. That is constrained by what Bitcoin script can verify about a Radiant burn, and by an economic-security ceiling near RXD's own market cap — neither of which an incentive mechanism moves. A bridge also pools risk, where a swap bounds it per-swap, so value-scaled burial does not transfer.

Design direction, not a defect. Filed for scrutiny before anyone builds it.

[yaegerbomb42]

/attempt

[Zyrtnin]

Correction to the original description — the covenant semantics above are stated wrongly, and the error matters for the proposal.

I wrote "the destination is enforced by the covenant pinning hash256(tx.outputs[0])". Verified against the compiled artifacts (src/pyrxd/gravity/artifacts/GravityHtlcCovenant{Rxd,Nft,Ft}.artifact.json), it is two separate checks, and the value half differs per variant:

Destination — OP_0 OP_OUTPUTBYTECODE OP_HASH256 <expectedHash> OP_EQUAL. That is hash256 of output 0's scriptPubKey, not of the serialized output (which would also commit to its 8-byte value). Present in all three variants.

Value — a separate check, differently shaped in each:

variant	opcodes	meaning
RXD	OP_0 OP_OUTPUTVALUE $amount OP_GREATERTHANOREQUAL	a floor — output 0 must pay at least the amount
NFT	OP_0 OP_OUTPUTVALUE $nftCarrierValue OP_NUMEQUALVERIFY	exact
FT	OP_REFVALUESUM_OUTPUTS $amount OP_NUMEQUALVERIFY — no OP_OUTPUTVALUE at all	the token refValueSum (see #505)

OP_CHECKSIG count is 0 in all three, so the signature-free claim in the original description holds — but only for the covenant input. The spend transaction's fee input is signed normally (htlc_spend.py), which is what the watchtower README means by "not pre-signable".

Why the correction helps rather than hurts the proposal

The covenant constrains output 0 — its script and its value — and nothing observed so far constrains the number of outputs. So an additional output 1 carrying a burial-contingent bounty looks structurally available, which was the main open question. RXD's floor semantics are also permissive in the useful direction: overpaying output 0 is allowed, so a design could route the incentive through output 0 rather than a second output if that turns out cheaper against the relay floor.

Still unverified, and still the blocking questions: whether anything elsewhere in the spend path constrains output count; the fee cost of a larger claim transaction on a chain with no RBF and no CPFP; and the #511 interaction.

Method note, since it is the point of several sibling issues: the original claim here was written from reading the builder rather than the compiled script, and was wrong. It was caught by a verification pass run specifically against the artifacts before publishing further.

[Zyrtnin]

Second correction — this one closes the main proposal, so recording it rather than leaving the idea looking viable.

Checking the compiled artifacts for a different fix turned up:

OP_TXOUTPUTCOUNT OP_1 OP_NUMEQUALVERIFY

in all three variants (Rxd, Nft, Ft). The covenant requires the spending transaction to have exactly one output.

That removes the "unverified" caveat in the original description by answering it in the negative: there is no room for an output[1] carrying a burial-contingent bounty. The earlier correction said the floor semantics looked permissive and that nothing observed constrained the output count — the second half of that was simply not checked far enough.

Consequences for the idea:

• A bounty output is not expressible. With exactly one output, the claim transaction is: covenant input + fee input → one output to the taker's pinned script. Whatever the fee input carries beyond the fee is burned as fee, not returned.
• So a third party who broadcasts gets nothing back on-chain. The incentive would have to be out-of-band — a pre-signed later payment, an off-chain agreement, or a separate contract — none of which inherit the CSV-burial property that made the design attractive in the first place.
• The permissionless-broadcast property still holds and is still useful: anyone knowing p can push the claim, and cannot redirect it. That remains the strongest liveness lever here. It just cannot be paid for inside the same transaction.

The single-output constraint is presumably deliberate — it is what makes hash256(outputs[0]) a complete statement about where the value went, rather than one output among several.

Leaving this open as a design note rather than closing it: the liveness gap is real, and "anyone can broadcast, nobody is paid to" is a sharper framing of it than the original.

Method note, since it is the third correction on this issue: the original claim came from reading the builder, the first correction from reading the ASM around one opcode, and this from enumerating every output-related opcode in all three artifacts. Each pass was more thorough and each found the previous one wrong.

[Zyrtnin]

Tracker audit — retitled. The title asked a question this issue's own comments answered NO three months of reading ago, and the body still reads as if the bounty were viable.

Re-verified independently against origin/main (558e49e), by enumerating every output- and signature-related opcode in all three compiled artifacts (src/pyrxd/gravity/artifacts/GravityHtlcCovenant{Rxd,Nft,Ft}.artifact.json):

Rxd:  OP_TXOUTPUTCOUNT OP_1 OP_NUMEQUALVERIFY
Nft:  OP_TXOUTPUTCOUNT OP_1 OP_NUMEQUALVERIFY
Ft:   OP_TXOUTPUTCOUNT OP_1 OP_NUMEQUALVERIFY

OP_CHECKSIG count is 0 in all three. So both halves stand:

• the permissionless-broadcast property is real — anyone holding p can push the claim and cannot redirect it;
• an in-transaction bounty is not expressible — exactly one output, which is what makes hash256(outputs[0]) a complete statement about where the value went.

The title has been changed from a live question to the settled finding. The body above is superseded on two counts and should be read only alongside the corrections: it describes the destination check as pinning hash256(tx.outputs[0]) (it is hash256 of output 0's scriptPubKey, with value checked separately and differently per variant), and it lists the output count as unverified when it is the constraint that closes the proposal.

Staying open as a design note: the liveness gap — "anyone can broadcast, nobody is paid to" — is unresolved, and any future incentive design has to be out-of-band and will not inherit the CSV-burial property.