TL;DR: BRC-166, a formal standard from developer Andy Rowe approved in late August, lets AI agents and scripts pay for web services in satoshis—no account, no signup, and no special wallet software required. The standard is designed to coexist with BSV Association’s own HTTP 402 payments work rather than compete with it, and its reference implementation is already live on the BSV mainnet. Any BSV holder can pay per-use fees online, and anyone can verify those payments on the public blockchain.
Key takeaways:
- BRC-166 is an official BSV standard for paying per web request in satoshis over HTTP 402, approved and merged into the BSV BRCs repository on August 28, 2026.
- Payers need only a BSV key and basic signing tools—no BRC-100 wallet, identity keys, or ecosystem software required.
- Every payment goes to a unique one-time address, so anyone can verify settlement on the public blockchain without trusting the service.
- The design complements rather than competes with BSV Association’s x402 proposal (#2890); both modes can coexist on the same network.
- A working implementation has been live on mainnet at bsv.cx for weeks, with a real settlement transaction that readers can check on any BSV explorer.
- The standard was merged by BSV Association developer Darren Kellenschwiler—the same developer whose complementary x402 proposal it coexists with; Rowe calls a standard “the only version of this that outlives me.”
Table of Contents:
AI agents and scripts will need to pay for web services in satoshis—with no account, no signup, and no wallet software beyond the ability to sign a transaction. A new formal standard, recently approved, details exactly how: BRC-166, created by developer Andy Rowe, was merged into the BSV BRCs repository on August 28.
The standard formalizes the payment rail Rowe built for bsv.cx, the proof-and-verification service that CoinGeek covered in August, in which an agent can pay a few hundred satoshis per API call and receive an on-chain receipt that anyone can verify. The rail itself has been live on the BSV mainnet for weeks; BRC-166 turns it from one site’s feature into a standard anyone can implement.
The idea builds on HTTP 402, a “Payment Required” status code the web reserved in the 1990s but never used, and on x402, the emerging industry protocol that finally puts it to work. A server answers a request with “402 – that will be 10 sats,” the client pays, and the resource is delivered, all in one process.
Think of it as a vending machine
The easiest way to picture the design is a vending machine. An alternate BSV proposal (x402 PR #2890, from BSV Association developer Darren Kellenschwiler works more like a stored-value card: feature-rich, with privacy protections, but requiring enrollment in the BSV wallet ecosystem first. BRC-166 is more of a coin slot: exact change, dropped into a one-time slot, usable by anyone holding any amount of BSV with even the most basic tools.
Every invoice gets its own unique slot, so a payment can only ever settle the purchase it was meant for. And because the slots and coins are all on the public blockchain, the machine has a glass front—meaning anyone can later verify that a payment occurred without asking or trusting the service that collected it.
Rowe said two things convinced him the design was necessary. “One is thirteen years watching what actually kills crypto adoption, and it’s always the same wall: install a wallet, write down a seed phrase, fund it, all before you’re allowed to do the thing you came for. Most people bounce at step one,” he told CoinGeek.
“The second is specific to (AI) agents… a human can be cajoled through wallet setup, but an autonomous agent has no email, no card, can’t click ‘I agree.’ Ask it to adopt a whole wallet ecosystem to spend 10 satoshis, and the payment simply doesn’t go through. So the ecosystem requirement isn’t friction for an agent; it’s a wall. That’s what I’m removing.”
Rails not moats
On why to create a formal standard rather than just a bsv.cx feature, he noted: “A payment rail only I can implement isn’t a rail, it’s a moat, and a moat defeats the entire point.”
“The value is that anyone can verify a payment without trusting me, and anyone, including my competitors, can implement the paying side from the spec alone… A standard is the only version of this that outlives me.”
The standard is designed to coexist with Kellenschwiler’s proposal rather than compete with it: both live under the same x402 scheme on BSV, each clearly self-labeled so software never has to guess which kind of payment to construct. Rowe has also proposed a shared umbrella document covering both.
“The two modes aren’t rivals; they solve different problems, and a healthy ecosystem should have both,” he said. “Publishing a competing standard would force a false either/or and fragment an ecosystem far too small to afford it… It also matters to me that Deggen was there first, doing good work; the move is to complete the picture, not plant a flag on top of a colleague.”
Speaking before the approval, Rowe made the case for exactly this outcome: “Two independent efforts arriving at HTTP 402 for BSV and then choosing to harmonize in the open, through the BRC process, rather than fork—that’s how good standards actually form; plenty of the web’s came out of competing drafts that merged.”
Days later, the process passed his test: Kellenschwiler himself merged BRC-166 into the repository on August 28.
A couple of technical points worth noting: the standard rides on a lesser-known milestone. In mid-August, BSV gained its own registered cross-chain identifier, bsv:mainnet, in the industry-standard CAIP-2 namespace (previously, the standard format couldn’t distinguish BSV from BTC). And a fitting detail is that the pull request discloses that the agent-payments standard was itself drafted with substantial AI assistance, directed and reviewed by Rowe, and recorded as such in the commit history per the repository’s guidelines.
BRC-166 is now an adopted standard—the pull request was approved and merged into the BSV BRCs repository on August 28, 2026. And the code it describes is real, not vaporware: the reference implementation is live now, and the spec connects its examples to a real settlement transaction that any reader can verify on a BSV block explorer. Or, as the spec itself says: verify it, rather than trust it.
Frequently Asked Questions:
What is BRC-166?
BRC-166 is an official BSV standard that specifies how software—particularly AI agents and scripts—can pay for web resources in satoshis using the HTTP 402 “Payment Required” status code. It was proposed by developer Andy Rowe and approved by BSV Association in August 2026.
What is HTTP 402?
HTTP 402 is a status code the web reserved for “Payment Required” in the 1990s, but never widely implemented. New protocols such as x402 now put it to work, letting a server request payment for an individual request—the technical foundation of pay-per-use web services.
How can AI agents pay for things online?
Software agents can’t hold credit cards, email accounts, or accept terms of service. Under BRC-166, an agent that receives a 402 response simply signs a BSV transaction, pays the exact amount to the provided address, and retries the request. Payment and delivery happen in a single round trip, with no signup of any kind.
Do you need a special wallet to pay with BRC-166?
No. Any tool that can construct and sign a basic BSV transaction will work—no BRC-100 wallet, identity key, or key-derivation scheme is required. Any holder of BSV can pay.
What is the difference between BRC-166 and the BSV Association’s x402 proposal?
They solve different problems and are designed to coexist on the same network. BSV Association’s proposal (x402 #2890) serves users inside the BSV wallet ecosystem and provides payee privacy; BRC-166 serves payers who can’t or won’t run that software, and makes every payment verifiable by anyone from public blockchain data.
Is BRC-166 live?
Yes. The standard was approved and merged on August 28, 2026, and the reference implementation has been live on the BSV mainnet at bsv.cx for weeks, with a real settlement transaction that anyone can verify on a BSV explorer.
In order for artificial intelligence (AI) to work right within the law and thrive in the face of growing challenges, it needs to integrate an enterprise blockchain system that ensures data input quality and ownership—allowing it to keep data safe while also guaranteeing the immutability of data. Check out CoinGeek’s coverage on this emerging tech to learn more why Enterprise blockchain will be the backbone of AI.
Watch: Can we trust AI? How blockchain and IPv6 could fix accountability
Be the first to comment