8 standards
Covenants
A script can inspect the transaction spending it, which lets an output impose rules on whatever comes after: a royalty that has to be paid, or a value that has to be carried forward. These are the standards that use that trick.
Also searched as OP_PUSH_TX, Push TX, PushTX, enforced in script, covenant.
Filed under
8 standards, spread across 4 of the 12 topics.
Start with
BRC-21
Push TX
A script can normally only see the coins it is unlocking, not the wider transaction doing the spending. This describes a technique that lets a script inspect that whole transaction and impose conditions on it.
Filed under Scripts
Standards about this
Covenants is the main subject of these 2.
21 215 Block-Height Deadline Covenant Templates (OP_PUSH_TX)
On BSV, the usual "spend after a certain block height" protections in Bitcoin scripts have been turned off, so there was no safe way to give one person a key that works right away and another person a key that only works after a deadline. Anyone trying to build this by hand could accidentally create a lock that looks safe but can actually be spent immediately, or one that can be used to jam the other party's ability to act before the deadline.
Standards that touch it
These are about something else, and deal with covenants on the way.
171 Fixed-Width State in a Covenant's Own Locking Script
A Bitcoin contract that needs to change some stored value on every spend has only one trustworthy place to keep that value: inside its own locking script. But Bitcoin Script can only cut a script apart at fixed byte positions, so two developers solving this independently end up with two incompatible layouts, and neither their tools nor anyone else's contracts can read the other's state. This describes a shared, self-describing way to lay out that state so any script, wallet, or third-party contract can find and read it without being told anything else about it.
172 Giving an AI Agent Control of a Delivery Vehicle Without Giving It a Wallet
Letting a computer program spend Bitcoin on its own usually means handing it a private key, and a key can sign for anything, not just the one task it was meant for. Even a lightly funded key is a full custodian, which is risky when the program is something like an AI agent reading untrusted instructions. This describes a way to let a program trigger on-chain steps and pay their fees automatically, without ever holding a key that could send money elsewhere.
173 Bitcoin Script to and from Bitcoin BASIC — a compiler and a decompiler
Bitcoin Script is a low-level stack machine with no names or structure, so a script of any real size is nearly impossible to read, review, or safely edit once written. Because a published covenant can never be changed after it is funded, mistakes hidden in that unreadable stack manipulation are typically found only after it is too late to fix. This gives developers a way to write covenant logic in a readable form and, just as importantly, to read back and verify a script someone else already deployed.
197 Accumulating Right-of-Sale Listings and Purchase Orders
Selling something once on Bitcoin is easy, but selling it over and over from the same listing without the seller babysitting every sale is hard. Normally you would need the seller online to approve each purchase and each payout to collaborators, which breaks down once there are multiple recipients sharing revenue or the seller wants to walk away. This makes it possible to run a listing that buyers can purchase repeatedly, that pays out to a fixed set of recipients automatically, and that anyone can wind down or settle after a deadline even if the seller disappears.
198 LCH Acquisition through Private Overlays and Listing Covenants
Buying access to licensed digital content on Bitcoin SV normally means every app invents its own payment flow and licensing format, so content bought through one app's purchase method cannot be unlocked or re-issued through another. This makes it hard to build a marketplace where sellers set a price once and many different apps can sell and deliver the same protected content correctly.
226 Miner-Enforced Resale-Royalty Covenant Tokens (OP_PUSH_TX)
A creator's cut on resale only holds while the marketplace chooses to honour it. This builds the rule into the coin itself, so any transfer that skips the payment is rejected by the network rather than by a platform.
Usually read alongside
Concepts that keep appearing on the same standards as this one.
Was this helpful?