For those who would like some context to understand what this tool does, here you go:

There is a type of bitcoin covenant that "sort of" works today called a key deletion covenant, but it has a problem, and Joost wrote a nice little demo tool to prove that you can at least partially solve that problem using something called the taproot annex.

The annex is a transaction field that can optionally be included on the witness stack of a taproot transaction. If included, you can put whatever text you want in that field (as long as it doesn't make your transaction size too large) and it will be ignored by taproot transactions (because its function is not yet defined -- a future soft fork might someday actually do something with the annex but it's not currently used for anything). The annex does not go on the tapscript execution stack (so you can't currently use it in tapscripts) and it is not used anywhere, it is simply dropped onto the blockchain as text without affecting any other part of your transaction. One thing it can be used for is to put data on the blockchain. Kind of like an inscription, except inscription data goes in the witness "script" field, and this would put it on the witness "stack" instead.

Joost proposes using this field to assist with key deletion covenants. But before I say how, let me share what a covenant is, and then what a key deletion covenant is.

A covenant makes it so that a bitcoin address can only be spent from if at least some of the money inside it goes to a set of one or more whitelisted bitcoin addresses. In more technical terms, a covenant encumbers transactions so that any transaction which uses a "covenant address" as an input has a witness script that will return false unless the outputs match a preknown template. In less technical terms, a covenant says something like this: "you can only spend this money if you send X btc to address Y" where X and Y are determined by the terms of the covenant.

Key deletion covenants are a specific type of covenant that has existed in bitcoin since day 1, though some people don't think they count. To make a key deletion covenant, you create a bitcoin address, send some money to it, use the private key of your bitcoin address to sign a transaction that would, if broadcast, send X btc to address Y, and then delete your private key.

This makes it so that you can still move the money that's in your address, but only using the transaction you already signed, which can only send the money to the place you specified, nowhere else. Technically this satisfies the definition of a covenant, but some people say it doesn't count, or at best it is of very limited usefulness. For example, you cannot "prove" you deleted your private key, so no one should trust you if you say you cannot move the money anywhere else. Because if you kept your private key, the covenant doesn't really do anything, you can use your private key to break it and send the money wherever you want.

Key deletion covenants are useful for several things. Ruben Somsen uses them in one of his designs for a forkless spacechain, a project called Revault uses them for bitcoin vaulting software that is like a hacky version of op_vault (except without a soft fork, and not as safe), and I have proposed using them for handcrank, which is a sidechain design that is similar to drivechain, but way worse, and possibly easier to deploy (because it doesn't expect anyone to upgrade their bitcoin software like the "regular" drivechain proposal does).

Although key deletion covenants work right now, they have some downsides, and one of them is, how to find a decent place to store the presigned transaction? It's harder to store than a private key because it's not a key -- it's a 300 byte piece of text, and bitcoin companies have not made consumer-friendly tools for securely storing non-key data. Another problem -- which I already mentioned, but here it is again -- is that you cannot prove to someone else that you deleted your private key, so if you make a key deletion covenant, you can only use it yourself, no one else can trust that the covenant is real.

Joost Jager proposes that one thing we can do with the taproot annex is encrypt a presigned transaction and put it there. That would allow the user to recover the presigned transaction using only the blockchain and their regular bitcoin wallet's private key (which they would use as the decryption key -- this would be separate from the private key of the covenant address, which, as a reminder, the user deleted, because that's how key deletion covenants work), and it would be better than storing it in an inscription because inscriptions require a second transaction to reveal their contents, whereas the annex does not.

Joost's tool demonstrates how this can work. You can install his tool, run bitcoin in "regtest" mode and enable support for the taproot annex, and then experiment with creating key deletion covenants where the presigned transaction is stored in the taproot annex for easy recovery. So his tool demonstrates that there is a limited version of covenants that work today (no soft fork needed), and it at least partially offers a solution to one of their downsides, which is, where do you put the data you need if you actually want to use your presigned covenant. (Joost's tool does not solve the other problem I mentioned, about proving you deleted your key, so that still needs a solution.)

I hope that helps! Please let me know if you have any questions.