Wallet Infrastructure Watch / Developer Tools

In Brief

BRC-177 introduces a mechanism for BRC-100 wallets to place enforceable deadlines on noSend transactions that have been handed to another application or recipient but not yet broadcast. Rather than leaving wallet funds reserved indefinitely, a supporting wallet creates a dedicated funding output and, if the transaction has not been observed on the network before the deadline, can spend that output back to itself. The mechanism does not create a new Bitcoin timelock or consensus-level expiry: the original transaction becomes unusable only once the competing reclaim transaction wins on-chain. (Beersy)

News Report

A newly published Bitcoin Request for Comments defines a way for BRC-100 wallets to recover funds committed to transactions that have been created and released to another party but never broadcast.

BRC-177, “Wallet-Enforced Expiry for noSend Actions,” was authored by Ty Everett, published August 30 and revised September 1. It extends existing BRC-100 transaction workflows through a BRC-111 module label rather than adding a new wallet API method or Bitcoin Script template. (Beersy)

BRC-100 already allows an application to ask a wallet to construct a transaction with the noSend option.

In that mode, the wallet creates the transaction but does not submit it to the network. The transaction can instead be returned to an application, passed to another participant, combined into a larger workflow or later broadcast using BRC-100 mechanisms such as sendWith. (Beersy)

That flexibility creates a particular problem once valid transaction bytes leave the wallet.

Suppose an application asks a wallet to prepare a payment and hands that signed transaction to another party. Until the transaction is either broadcast or abandoned, the wallet has to treat its inputs as reserved because the outside party may still possess a valid transaction capable of spending them.

An application can display a five-minute timer, but the timer itself changes nothing on-chain.

If the recipient still has the signed transaction after five minutes, simply deleting the application’s local record does not make those transaction bytes invalid. Nor does a conventional Bitcoin timelock solve the same problem: a timelock can establish when a transaction becomes valid, but does not ordinarily make it cease to be valid after a later deadline. (Beersy)

BRC-177 addresses this by introducing what the specification calls a revocation anchor.

Before releasing the protected noSend transaction, the wallet first creates and broadcasts a separate funding transaction containing a dedicated wallet-controlled output sized specifically to fund the proposed action and its fee.

The protected transaction then spends that dedicated output rather than reserving an ordinary wallet input that may contain substantially more value than the intended payment. (Beersy)

The wallet records an expiry condition using a BRC-111 label beginning:

p nosend expiry

Three deadline forms are defined:

• a relative number of seconds;
• an absolute Unix timestamp; or
• an absolute block height.

For example, an application can request a protected action valid for 300 seconds. The wallet persists the resulting absolute deadline before releasing the transaction, so restarting the application or wallet does not restart the timer. (Beersy)

BRC-111 provides the underlying extensibility mechanism.

It reserves wallet labels beginning with p for installed permission or behavior modules. If a wallet does not recognize the requested module, it must reject the operation rather than silently treating the label as ordinary organizational metadata. BRC-177 uses that existing framework for its nosend expiry module. (Beersy)

What Happens at Expiry

If the wallet observes that the protected transaction has been submitted to a transaction processor before the deadline, reclamation is canceled and the transaction enters ordinary BRC-100 processing and proof tracking.

If the deadline arrives without such an observation, the wallet checks the status of the protected transaction and its revocation anchor.

Where a valid anchor signature was already released to an outside party, the wallet constructs or retrieves a reclaim transaction spending the same anchor back to a fresh wallet-controlled output and broadcasts it. (Beersy)

That produces two incompatible transactions competing for the same UTXO:

the protected transaction held externally, and the wallet’s reclaim transaction.

Once the reclaim transaction is mined, the anchor has been spent and the old protected transaction can no longer be valid on the same chain.

This distinction is important because the deadline itself does not invalidate anything at the Bitcoin consensus layer.

BRC-177 explicitly describes the expiry label as a wallet instruction rather than a script condition, miner rule or consensus timestamp. Until one of the competing transactions has established the winning spend, a transaction submitted close to the deadline can race the reclaim. The wallet must therefore continue tracking both possibilities and report whichever transaction is actually proven. (Beersy)

If the wallet has never released a valid signature for the anchor, the situation is simpler. There is no valid outside transaction capable of spending it, so the wallet can abort the unfinished action and return the still-unspent anchor to normal wallet coin selection without broadcasting a reclaim transaction.

Bounding the Funds at Risk

The prefunding design also addresses another problem with long-lived noSend transactions.

Ordinary wallet coin selection might use a relatively large input to make a small payment, expecting most of the value to return as change. If the resulting transaction remains outside the wallet indefinitely, much more wallet value could remain reserved than the amount actually being offered.

BRC-177 requires the wallet to construct a dedicated funding output sized for the protected action. That limits the amount tied to the handed-off transaction to the intended outputs and required fees rather than potentially immobilizing a larger wallet coin. (Beersy)

The funding transaction itself is broadcast immediately. Its normal change, if any, returns to the wallet before the protected transaction is released.

The protected transaction is then built using the dedicated revocation anchor as its only automatically selected wallet input and is not given ordinary wallet change.

Useful Beyond Simple Payments

The mechanism is potentially relevant wherever an application needs to give another party a transaction that remains valid for a period of time without giving that party indefinite control over the wallet’s reserved funds.

That could include temporary payment offers, externally coordinated transactions, agent-to-agent workflows or multi-stage applications in which one participant is responsible for deciding whether and when to broadcast.

The specification also applies when a BRC-100 createAction produces a partially completed transaction that is later finished through signAction. The original expiry continues to run while the transaction waits for the additional signature; completion does not reset the deadline. (Beersy)

Distributed wallets must persist and coordinate the deadline as well. BRC-177 requires the authoritative wallet state or monitor to survive restarts and prevent multiple devices from independently regressing or inconsistently enforcing the transaction lifecycle.

The specification even permits a reclaim transaction to be prepared and stored before the protected action is released. That could allow a trusted storage monitor without access to the wallet’s private keys to enforce the deadline later if the user’s wallet application is offline. (Beersy)

BRC-177 does not establish that current BRC-100 wallets have already implemented this behavior. Its publication defines the interoperable mechanism that supporting wallets would need to follow.

BSV TIMES Read

BRC-177 addresses a subtle consequence of making wallet transactions portable.

If an application can receive a signed transaction from a wallet and hand it to somebody else, the wallet no longer controls whether those bytes still exist or when the recipient may attempt to broadcast them.

An application’s “offer expired” message cannot undo a valid Bitcoin transaction held elsewhere.

BRC-177 therefore moves the expiry mechanism back to something the wallet can ultimately control: the UTXO that funds the transaction.

The wallet does not try to make Bitcoin understand an expiration date. It creates a deliberately bounded funding output and retains the ability to spend that output elsewhere once the agreed period has passed.

That is an important distinction.

The proposal does not introduce transaction expiry as a new consensus rule. It uses ordinary Bitcoin spending rules to create an economic and operational form of revocation.

For applications and autonomous software, that can be useful infrastructure. A wallet can hand another party a temporarily valid transaction without accepting that its funds may remain reserved forever simply because the recipient never completes the workflow.

It also illustrates a broader advantage of the BRC-100 architecture now developing around wallet modules: specialized application behavior can be added while keeping the underlying wallet interface stable. BRC-177 uses the existing createAction, signAction, noSend and label mechanisms rather than adding another proprietary wallet API.

The next threshold will be implementation. Until supporting wallets actually adopt the module, BRC-177 remains a published interoperability specification rather than a generally available wallet capability.

Source Links

BRC-177 — Wallet-Enforced Expiry for noSend Actions

BRC-111 — P Labels: Allowing Future Wallet Action Label Permission Schemes

BRC-100 — Unified Wallet-to-Application Interface

BSV Blockchain — Bitcoin Request for Comments Repository

Posted on September 5, 2026