Autonomous Agent Infrastructure Watch / Network & Protocol

In Brief

BRC-172 introduces a self-funding Bitcoin covenant model designed to let autonomous software trigger on-chain actions without giving the software a conventional wallet or unrestricted spending key. The proposed “battery” carries its own BSV transaction-fee funding and constrains how its state and value can advance, allowing an agent to initiate permitted steps without gaining general custody over the funds. The mechanism has already been demonstrated through mainnet covenant implementations, although the specification’s delivery-vehicle use case remains conceptual.

News Report

A newly published Bitcoin Request for Comments defines a way for autonomous software to perform repeated on-chain actions while avoiding one of the most obvious security problems in agent-based payments: handing an AI agent a private key capable of spending freely.

BRC-172, published August 28, describes a self-funding covenant, called a “battery,” that carries its own transaction-fee funding and enforces the permitted form of its next state through Bitcoin Script.

The design starts from a practical distinction between authority to perform an action and custody over money.

A conventional autonomous agent that needs to create Bitcoin transactions would normally require access to a wallet or private key. Even if that wallet contains only a small balance, the key itself can generally authorize whatever transactions its holder is capable of constructing.

BRC-172 instead places the rules for the permitted action inside the covenant.

Each output carries both its current state and a quantity of satoshis described by the specification as fuel. When the covenant advances one step, the next transaction recreates the covenant with its updated state while allowing a bounded amount of its carried value to be consumed as the transaction fee.

The agent therefore does not need a separate funding UTXO for each action.

In the simplest form, a complete step can consist of one covenant input and one successor covenant output. The script verifies the transaction preimage, calculates what the next state is allowed to be and rejects a transaction whose successor does not conform to those rules.

This changes the authority granted to the agent.

Rather than being given a key that can construct arbitrary payments, software can be permitted to advance the covenant only along paths already authorized by its script. BRC-172 also allows an optional “driver” key that authorizes state advancement while remaining distinct from an “owner” key capable of exercising rights over the covenant’s value.

The separation is intended to prevent an operational credential held by an autonomous program from automatically becoming a general spending credential.

BRC-172 also defines how the covenant funds its own continuation.

The current output value is treated as a fuel gauge, and each permitted step must leave the successor with at least the previous value minus a predetermined maximum fee. That MAX_FEE must be calculated by serializing and measuring a real worst-case transaction rather than estimating the cost from the script alone.

When the remaining value becomes insufficient to fund another step, the covenant becomes “flat” rather than permanently terminated. Because the value rule is a floor rather than an exact equality, additional funding can be added and the covenant can resume from its existing state.

That provides a potential model for long-running autonomous processes: the computation or physical process can retain its state on-chain, consume its own operating balance as it progresses, stop when that balance is exhausted and continue after being funded again.

The specification is careful not to describe this as unlimited agent autonomy.

It states explicitly that the mechanism constrains on-chain actions, not the agent’s reasoning. An AI system may make decisions elsewhere, receive untrusted information or produce incorrect conclusions; the covenant only restricts which blockchain state transitions the agent is capable of causing.

The design also acknowledges an important fee-security issue.

Simply imposing a maximum reduction in covenant value does not guarantee that every permitted reduction actually becomes a miner fee. If a transaction structure leaves unconstrained output space, a caller could potentially route some of that allowance elsewhere. The specification therefore emphasizes keeping the maximum fee close to the measured transaction requirement or explicitly constraining any surplus.

This warning comes partly from the project’s own deployed testing. BRC-172 documents an earlier fuel-depot covenant in which a transaction path left 844 satoshis per spend available for extraction. Rather than remove the flawed example, the specification retains it to illustrate why the tighter conformance rule is necessary.

The broader covenant architecture is already represented on BSV Blockchain mainnet.

BRC-172 documents a Bitcoin Battery implementation that performs one Mandelbrot calculation iteration per transaction. Its covenant carries nine state fields, has a measured transaction size of 3,092 bytes and uses a 310-satoshi fee in the documented implementation.

A second implementation models a quarter-mile vehicle/racing process using a larger stateful covenant. The specification explicitly notes that no actual delivery vehicle has been built; the vehicle is a proof of concept for the mechanism rather than evidence of a deployed autonomous logistics system.

BRC-172 builds directly on another new specification, BRC-171, which standardizes how mutable covenant state can be laid out as fixed-width fields inside a locking script. That shared structure is intended to let a covenant, wallet, indexer or another covenant locate and interpret state without requiring a custom byte layout for every implementation.

The BRC-171 specification says the convention is already being used by several covenant families on mainnet, including a case where one covenant reads another covenant’s state without sharing its code.

Together, the two standards separate two problems: BRC-171 defines how mutable state can be represented consistently inside a covenant, while BRC-172 defines how such a covenant can fund and constrain its own successive actions.

BSV TIMES Read

The interesting part of BRC-172 is not simply that an AI agent can initiate a Bitcoin transaction. Software has been able to control wallets for years.

The more important question is how much authority the software has to be given.

Giving an autonomous program a private key creates a broad capability. The software may have been intended to pay one service, advance one machine or perform one narrow process, but the credential itself can potentially authorize much more.

A covenant reverses that relationship. Instead of trusting the agent to behave within a policy, the permitted action can be embedded in the transaction logic, while the value required to continue operating remains inside the process itself.

That creates an interesting infrastructure model for autonomous machines and agents: control without general custody.

BRC-172 is still an early architecture, and its own documentation is unusually explicit about implementation risks, fee leakage and the difference between a proof of concept and a real autonomous vehicle. Those limitations matter. But the mainnet examples also mean the idea has moved beyond a purely theoretical agent-payment proposal.

For autonomous systems, the longer-term significance may be that a machine does not necessarily need to “own a wallet” in the human sense at all. It may instead be given narrowly bounded authority over a process whose permitted state transitions and operating funds are already defined by the infrastructure.

Source Links

BRC-172 — Giving an AI Agent Control of a Delivery Vehicle Without Giving It a Wallet

BRC-171 — Fixed-Width State in a Covenant’s Own Locking Script

BSV Blockchain — Bitcoin Request for Comments Repository

Posted on August 30, 2026