Add BRC-Y: Giving an AI Agent Control of a Delivery Vehicle Without Giving It a Wallet - #226
Merged
sirdeggen merged 14 commits intoAug 28, 2026
Merged
Conversation
An agent that acts on Bitcoin is normally given a wallet, and a wallet is a key — unbounded capability that will sign anything for whoever comes to hold it. Funding a small hot wallet bounds the amount at risk without bounding the behaviour, so it buys being robbed in small amounts, repeatedly. This proposes the alternative already running on mainnet: a covenant that carries its own fuel, pays each step's fee out of the value it already holds, and enforces its own successor state, so the authority to act correctly sits in the script rather than in anybody's possession. The agent is given control and never custody. Normative: the value rule is a FLOOR, not an equality, which is what makes a top-up just another advance and is the difference between a covenant that can be refuelled and one that dies at the end of its pot. The fee ceiling is a permanent script literal that MUST be derived by serializing a worst-case spend. Ownership and control by public key are both permitted, in three named configurations, with one invariant across all of them: authority must be enumerated in the script, and the key that can direct value MUST be distinct from the key that merely advances the covenant once the latter is delegated. Evidence is measured from the chain rather than read out of the implementation: the deployed instance is 18e3193687078c40…, a 1,428-byte lock carrying nine state fields under BRC-X, advancing on 3,092-byte transactions that pay 310 satoshis — one input, one output, no funding and no signature over any secret. Walking its computation trace twenty steps reproduces the reference implementation's twentieth state byte for byte. The reference implementation is cited as a txid rather than a URL, because a standard whose implementation can be deleted is a standard that can stop being verifiable. ⚠ No delivery vehicle has been built. §10 says so in its opening paragraph: the vehicle work on chain is a quarter-mile drag race, and the title names the use case the mechanism is for rather than an application that has shipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
BRC-226 is Miner-Enforced Resale-Royalty Covenant Tokens, authored by the same author as this proposal and merged from BRC-146. A battery declaring BRC-226 in its genesis OP_RETURN is therefore stating what it conforms to: it reconstructs its own locking script from the preimage's scriptCode exactly as that standard describes. What this document adds is the funding model and the authority rules on top of it. The previous wording called that label a number the instance had not been assigned, which was wrong about the authorship and would have had a reader distrust a correct citation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
At 671 lines this read as an essay wearing a standard's clothes, with 233 lines of motivation before the first MUST. It is now 332 lines with 59 before the specification, which is roughly where BRC-X sits. What went: the two-loads framing, the wallet-versus-battery comparison, the visible-load argument, and the separate section arguing that permission to drive is not permission to spend. None of it was wrong and none of it is deleted — it is the substance of a companion essay, kept outside this repository. What stayed is everything a second implementer needs, and each idea now has one home instead of several. The key-separation requirement appeared six times and now appears once, in §3 where it is normative. The same was true of the no-secret property. The measured evidence is untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
§5 opened by requiring MAX_FEE to be a literal baked into the script. That is what the deployed instances do; it is not the only way, and stating it as the rule made the standard narrower than the technique and contradicted §10, which already describes recovering from a bad constant by re-minting. Three mechanisms are now named, with what each costs when the value is wrong: a literal, permanent and remedied only by re-minting; a field an owner key may update, which is recoverable but forfeits the ownerless configuration; and retiring the instance to mint a corrected one, which every configuration has and which is the real escape hatch. The requirement that survives all three is the one that has actually gone wrong in practice: derive the ceiling by serializing a real worst-case spend. An owner-updatable ceiling is an owner authority under §3, so it inherits the key-separation rule. It is not a theft vector, since the covenant still cannot direct value to a party — but a ticker who also mines captures the fee, so an unnecessarily high ceiling extracts rather than merely wastes. §10's predecessor is relabelled as what it is: option (c) in the wild, showing that the escape hatch costs identity rather than funds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
§5 offered retirement-and-re-mint as the universal remedy for a wrong ceiling. Retirement needs an owner path, and a genuinely ownerless covenant has none, so the remedy as written was unavailable in the configuration that needs it most. The actual remedy is to supersede and stop funding: mint a corrected instance and leave the flawed one unfunded. It goes flat and stays flat. Nothing is signed, no retirement path need exist, and it does not depend on the old covenant cooperating. Burning is now listed separately as what it is — an optimisation that reclaims a UTXO and forecloses revival, requiring an owner path, and worth adding only where tidiness outranks the ownerless configuration. The cost of abandonment is stated too, because §8 makes it real: a flat covenant resumes on a top-up from anybody, so an abandoned instance is dormant rather than deleted and its behaviour stays permanently available. A published covenant cannot be withdrawn, only left alone — which is a reputational cost rather than a financial one. §10's predecessor is retold accordingly: it was never burnt, it is merely unfed, and anyone could wake it tomorrow to resume drawing its blob from the iteration it stopped on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"Pot" is racing vocabulary. In the covenant family this came from it means the prize an entrant forfeits by failing, and the racing shell carries a pool field for exactly that — neither of which has anything to do with the value a battery spends on its own steps. Using it here invited a reader to look for a prize. Every use is now "fuel", which the document already used as the gloss and which matches the rest of its vocabulary: the fuel gauge, going flat, the top-up. One sentence changed sense rather than wording — the ceiling bounds what leaves the covenant, not what leaves a pot, since a sponsored top-up may pay a larger fee than the ceiling without violating anything. §3's remedy for a bad constant also now matches §5: supersede the instance rather than retire it, since retirement needs an owner path an ownerless covenant does not have. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
§5 described a burn as reclaiming a UTXO, which understated it to the point of being wrong about why anyone would add one. The signature that authorises a burn commits to every output, so the owner says where the value goes — ordinarily back to their own wallet. Recovery is the purpose; the freed UTXO is incidental. That also corrects the claim that superseding an instance costs nothing. It costs no authority, and it costs whatever fuel the abandoned instance still holds, permanently. An instance funded for a long run and abandoned three steps in keeps the remainder forever. So instances built for testing should be burnable, and the document now says why: a development cycle mints covenants that are expected to be wrong, and without a burn each one takes its funding with it. The underlying trade is stated where it belongs, in §8: an ownerless instance's fuel can never be recovered by anybody, including its author, and that is not an accident but the same rule that makes the covenant nobody's. A burn path cannot be added after genesis, so the decision belongs to intent — testing and variants under proof get one, monuments meant to outlive their author do not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
I had been writing about burn paths from first principles while a document existed that settled the question, and getting it wrong in a specific way: I called an abandoned covenant's fuel "stranded". It is not. A battery has no terminal state, so every satoshi in it stays spendable by advancing it, and any stranger can tick an abandoned instance to flat. The value is dedicated, not lost, and "ticks forward or waits for recharge" is a complete life cycle. §8 now carries the law with its actual test, which is not "can the money come back" but bounded-and-intentional against unbounded-and-incidental. One immortal output on purpose is a monument. One per race, per mint or per use is a leak, and the quantity that matters is the number of unspendable outputs rather than the value in them — a covenant with a terminal state leaves one every time it is used, and every node carries all of them. It also states why ownerless and burnable cannot be combined: a burn needs a signature, a signature needs an owner, and an owner destroys the property the design exists for. Attempting the combination yields a covenant free to the first passer-by. The keyless alternative that gets proposed instead — let anybody sweep it once it falls below one tick — is recorded as rejected, because it makes draining profitable and gives a monument an ending it should not have. And the four guards are written down, guard 4 with its measured attack: an unclaimed instance's owner field is zero, the signature check above it is skipped rather than failed, and a passer-by wrote their own key into it, became the owner, and could burn it for the fuel. Load, own, burn. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The previous commit over-corrected. A correct battery has no terminal state, so its fuel is always spendable by advancing it — but that is a property of the design, not a guarantee about the artefact. A state machine with a condition no spend can satisfy locks its whole balance on arriving there, the condition need only be reachable rather than intended, and until it arrives the covenant is indistinguishable from one that works. Everything anybody contributed is inside it. So §5 now says what makes "be right before minting and funding" hard to obey, which is not arithmetic. A covenant of useful size cannot be read back, so what gets verified is a model of the script rather than the script. One modification to a complex script invalidates that model — offsets, depths and derived constants all move behind the change — and whoever holds the model loses it exactly when the change is made. The covenant is therefore proved correct in good faith and found to be wrong after minting and after funding, at the one moment nothing can be altered. Hence the requirement that an implementation be able to READ its covenant back rather than only write one, and hence the tooling note, rewritten to describe what the reader is for instead of listing it as a convenience: a script rendered as a short program, that dialect compiling forward again, and a disagreement between the two being the bug report. 1,108 opcodes read back as 253 lines. The section closes on the evidence rather than an assertion: this requirement was satisfied twice by a test suite that passed while the bound underneath it sat below the relay floor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Five things were settled in notes I had not read, and the document was weaker or wrong without them. §4.1 states the threat model instead of implying there isn't one. If anybody may advance a covenant then anybody may drain it, and the honest claim is narrower than it sounds: anyone can empty it, nobody can take it. Measured on a sibling covenant, a 100,000 satoshi tank attacked with no key and nothing funded put 95,815 beyond the attacker's reach, 4,185 to miners and zero to the attacker, with 93,815 recovered — a 6.2% cost, all mining fees. For a battery the vector nearly closes itself, since draining one performs the work it was funded for. Mitigation is operational — fund lightly, top up — and that is a griefing limit, not a theft limit. The ladder's third rung is corrected: a covenant has no clock but nLockTime, and gating on it restricts honest use identically, so capping value per unit of time is not available and must not be claimed. §2.1 records the composability trap. Two covenants that each rebuild at output 0 cannot share a transaction, which is discovered when the second is written and the first is already deployed. One must tolerate an output offset and recognise its counterparty by shape rather than by a hash of a script at rest. Its companion lesson is included because it cost more than the bytes did: when the build cannot do what the specification says, that is a bug in the build. §3 gains the method for the property it already required. A DER signature cannot be grepped for — a script of this kind is mostly preimage material, so a short hex pattern occurs by chance, measured at ~1.6% of runs. Walk the parsed chunks, and provoke the detector in the same test or "none found" is indistinguishable from "cannot find any". §5 case 1 now requires the bound to cover the worst spend any legal variant can produce, and to be measured on the transaction the covenant exists for: one ceiling sat at 97.2 sat/KB against a 100 floor because a later change made a different configuration the larger one, and another was 61.8 sat/KB on the composite spend that was its actual purpose. §8.3 closes on why green is not evidence: a rule no test has provoked is a rule no test has examined, and a passing check is a hypothesis wearing a costume. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
6,552 words was four times too long for a proposal, and longer than any BRC this author has had accepted: 999, 1,234 and 1,760 words respectively. Every requirement survives. What went was explanation of requirements rather than the requirements themselves — the worked measurements, the war stories behind each rule, the three-way analysis of size variation, the four burn guards in full, and the argument for why a reader is needed rather than the one sentence requiring one. Those belong in a companion essay and are kept outside this repository, where they can be told properly instead of compressed into a specification that a reviewer has to read before deciding whether to care. Thirty-one MUSTs remain, and the conformance list is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A last pass over wording rather than substance. Every conformance requirement is retained and the numbered list is unchanged; what went was repetition inside §5 and §7, and the restatement of why a reader is needed after the requirement had already said it. Length is settled here rather than cut further. At 2,272 words it sits alongside the author's other open proposal, and the material that would have to leave to reach 1,500 is the reasoning behind the rules rather than the rules — which reads better in a companion essay than compressed into a specification. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The document specified parameters without once showing them used, which is a poor omission in a standard about a language almost nobody reads. §8 is now the value rule as it actually stands on chain: the last eighteen bytes of the deployed locking script, annotated, with MAX_FEE visible as the three bytes 02 3a 01. Directly beneath it, the same script as its decompiler renders it — "VERIFY BIN2NUM(newValue) >= BIN2NUM(t135) - 314", one line out of 216 for the whole 1,428-byte script. Both are needed: the bytes because that is what a node enforces, and the line because that is what a person can check. Showing them together is the argument of §5 rather than a restatement of it. The appendix carries the complete locking scripts of the deployed depot and the vehicle it fuels, 875 and 1,744 bytes, copied from chain and verified against it. They are unreadable on purpose. Between them they hold a fee ceiling, a tank ceiling, an owner check, a burn branch, a driver gate, thirteen state fields, a phase machine, quadratic drag and a cross-covenant read — and none of it can be found by looking, which is the case for the reader this standard requires and for the proposal that describes one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ming The Appendix was headed "two conforming covenants, in full" and said "Every rule in this document is in here somewhere". One of the two does not satisfy §3.1. unlocking stack [ prefixOutputs, burn, sig, pubKey, spenderOutputs, newValue, preimage ] the binding HASH256( prefixOutputs || newValue || myOwnScriptCode || spenderOutputs ) == hashOutputs the arrival rule carValue >= (V - out_depot) - MAX_FEE spenderOutputs is supplied by the spender and constrained only by being committed to in the sighash, which §4 expressly permits. The arrival rule leaves MAX_FEE of slack. So a spender takes the draw, hands the vehicle (V - out_depot) - MAX_FEE, and directs the difference to an output of their own: 844 satoshis per spend, to anyone, with no key. That is what §3.1 forbids. Kept in the document rather than swapped for a clean example, because it demonstrates the thesis better than a clean one could: the defect is invisible in the bytes, and it was found by MEASURING a spend after the covenant had passed seventy-three tests. AND §4 STATED A FALSEHOOD, which is the same defect written as prose: "every satoshi that leaves is bounded by this rule and lands where the script says -- never at an address of the attacker's choosing." The value floor bounds what LEAVES; it does not decide where the surplus LANDS. The bound is now exact: extractable per tick = MAX_FEE - the fee the transaction must actually pay to relay So the headroom §5 asks to keep modest IS the extraction surface, and §4 does not deliver §3.1 on its own. Stated, because an implementer reading §4 alone would have believed the floor was enough -- which is exactly what happened here. WARN Word count 2,596 -> 3,054. His ceiling was "at 2500 it is fine", and his own merged BRCs are 999 (224), 1,234 (227) and 1,760 (226). This needs his read and probably a trim. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request:
Proposes a new standard by creating a new markdown file in the appropriate directory and requests discussion and assignment of a BRC number
Summary
Defines a battery: a covenant that carries its own fuel and pays each step's transaction fee out of the value it already holds. Because
OP_PUSH_TXauthorises the advance with a proof about the transaction rather than a signature over an identity, the authority to act correctly sits in the script instead of in anyone's possession — so an autonomous agent can be given control without custody, at most a credential that advances the covenant and cannot direct value anywhere.The problem it addresses is that an agent transacting on chain is normally given a wallet, which is a key, and a key is unbounded capability. Funding it lightly bounds the amount at risk without bounding the behaviour.
Normative content, briefly:
out0.value ≥ V − MAX_FEE) and never an equality. That single choice is what makes a top-up just another advance, needing no separate code path and no privileged key — and under an equality the covenant can never be refuelled by anyone and dies permanently, with no symptom until the day it stops.Evidence. Two instances are deployed on BSV mainnet, and every figure in the document was measured from the chain rather than read out of the implementation. Walking the battery's spend chain twenty steps produces a locking script byte-identical to the reference implementation replayed twenty times from genesis.
§8 shows the rules as Script: the last eighteen bytes of the deployed locking script, annotated, with the fee ceiling visible as the three bytes
02 3a 01— set beside the same script decompiled to a single readable line. The appendix reproduces two complete deployed covenants, 875 and 1,744 bytes, copied from chain and verified against it. They are included precisely because they cannot be read, which is the case the document makes for a covenant needing to be readable back before it is funded.The reference implementation and its test suite are cited as an on-chain payload rather than a URL, because a standard whose implementation can be deleted is a standard that can stop being verifiable.
⚠ No delivery vehicle has been built. The title names the use case the mechanism is for. The vehicle work on chain is a quarter-mile drag race, and the Implementations section says so plainly rather than leaving a reader to infer it.
Related: BRC-226 establishes the
OP_PUSH_TXself-reconstruction this depends on; the contrast is the funding model, since BRC-226's spends are paid for by the party transacting and it has a party transacting. The state layout is the subject of a separate open proposal.Filed as BRC-Y for number assignment.