> For the complete documentation index, see [llms.txt](https://argon-4.gitbook.io/argon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://argon-4.gitbook.io/argon-docs/suresign/covenants.md).

# Covenants

Kaspa covenants in SureSign: the template catalog, how programs are created and spent, covenant identity, and what stays inspect-only.

Since Kaspa's Toccata upgrade, a transaction output can carry a **covenant**: a script that constrains how the coin may be spent next, together with an identity that follows the coin through its lineage. Enclave's vaults and escrow are covenants. SureSign is the only part of the product that constructs, identifies, or spends them.

## Templates and the catalog

SureSign ships a catalog of covenant templates, each a compiled dump of a SilverScript program at a pinned compiler version. The catalog is kernel-owned; the interface renders it and cannot add to it.

| Template                                                                     | Enclave product          | Status                                                                                      |
| ---------------------------------------------------------------------------- | ------------------------ | ------------------------------------------------------------------------------------------- |
| **TimeLock Vault**                                                           | Vaults → TimeLock        | Create and spend                                                                            |
| **Inheritance Vault**                                                        | Vaults → Inheritance     | Create and spend                                                                            |
| **Last Will Vault**                                                          | Vaults → Last Will       | Create and spend                                                                            |
| **Escrow offer**, **Escrow payment**, **Escrow collateral**                  | Escrow and the Deal Desk | Create and spend                                                                            |
| **KCC20, exact qualified program**                                           | Holdings                 | Fixed-supply creation, transfer/split, consolidation, receive settings and borrowed receive |
| Escrow and Last will (RC1 learning pins)                                     | Tools → Covenants        | Lab creation on testnet-10 only; spends refused                                             |
| Mecenas, Hodl vault, Transfer with timeout, 2-of-3 multisig, KCC-20 tutorial | Tools → Covenants        | Inspect only                                                                                |
| Historical compiler dumps (`140bf184`)                                       | Tools → Covenants        | Inspect only                                                                                |

The six purpose-built families support mainnet and testnet-10. New creates use the current shipped program revision; retired purpose-built `v1-rc1-r1` locks remain spendable when their own script matches. This retired program revision is distinct from the historical compiler pin `140bf184`, which remains inspect-only.

The active compiler pin is **SilverScript `v1.0.0`** (`kaspanet/silverscript` at `3ed97333`). Its release executable reproduced the current artifacts unchanged. Existing `@v1-rc1` and `@v1-rc1-r1` program identifiers remain stable for funded locks and imports; those identifiers are not the current compiler release label. Each purpose-built template exists in the dumps SureSign needs to select the right script for the parameters the user chose: for example, time windows are encoded at different byte widths, so the kernel pins one dump per width and picks by the encoded width, never by guessing.

A recognized script that is not in the catalog can be identified (opcodes, family) in the Covenants tool but is never spent. **Recognition is not authorization.**

## Creating a program

A create is a Kaspa transaction whose lock output pays to the P2SH hash of a template instantiated with the user's parameters: heirs, claimant, cold key, buyer, seller, arbiter, and time windows measured in DAA score (Kaspa's block-score clock, about ten ticks per second). The kernel:

1. instantiates the template and computes the lock script;
2. builds the transaction with the lock as output 0, the one Enclave fee when the product carries one, and change;
3. **stamps a KIP-20 covenant identity** on the lock output, authorized by input 0, so the program is born with a name the network keeps;
4. records the program in the wallet's encrypted journal with its parameters, so the wallet can later find and spend it and a counterparty's wallet can re-derive it from a deal card.

Minimum deposit for these purpose-built vault and escrow programs is 0.5 KAS, because a Note carrying a covenant binding weighs as two Notes under storage mass; the kernel refuses smaller creates in plain words rather than shipping an unstamped one.

## Spending a program

Each template exposes a fixed set of entry points, one per role and path: `take`, `refresh`, `inheritPrimary`, `inheritBackup` for Inheritance; `refresh`, `withdraw`, `inherit` for Last Will; `claim` paths for TimeLock; `reclaim`, `join`, `release`, `refund`, `timeout`, `unwind` across the escrow legs. A spend is a transaction whose input 0 is the program's Note, with a signature script that supplies the role's key, the role's Schnorr signature, and the redeem script. The programs pin a nominal miner fee below the network's relay minimum, so SureSign adds one wallet Note as input 1 to pay the difference and returns change at output 1; both appear on the plan as miner fee, never as an Enclave fee.

Program-to-program spends (`join` an offer into a payment lock, `refresh` a vault) **continue** the covenant identity: output 0 carries the spent Note's id. Since the September 2026 revision, the programs themselves require this continuation (`OpAuthOutputCount == 1`, `OpAuthOutputIdx == 0`), so a payment lock provably descends from the offer that named it. Payouts to a party's key carry no binding; that is how a lineage retires. Locks funded before the revision still spend under their original program, which the kernel selects from the Note's own script and labels on the plan.

## Covenant identity

The identity is the KIP-20 covenant id: a hash of the creating input's outpoint and the lock output, computed by the reference implementation's own function. The kernel verifies every binding it builds against the spent Notes before the plan is hashed. The verified ids are part of the ReviewPlan and its hash; signed transaction bytes must match the approved canonical transaction. That post-sign equivalence check is separate from script-engine qualification.

Enclave shows the identity as a readable name derived from the id (the same naming the covenant directory kascov.io uses), with a link to the covenant's page on the directory. A vault keeps the name of its oldest live Note; a deal is named once across its offer, payment, and collateral legs. Nothing is invented: a lock with no identity shows none.

## Fixed-supply tokens

The qualified KCC20 program creates one fixed initial supply across up to three allocations. SureSign shows each recipient, human token amount and exact base units, decimal precision, metadata claims, carried KAS and miner fee. Rust determines the program, amounts, funding and covenant identity. There is no minter or administrator role. The optional artwork URI and digest are issuer claims; the metadata format follows an open proposal, not a finalized standard.

All five base owner schemes and three enabled borrowed-receive schemes have qualified paths. P2SH and covenant-ID authority requires explicitly supported wallet-controlled inputs whose assets return unchanged. Arbitrary controller programs remain refused. Created and later received cells are retained in the encrypted journal; their balance appears only after the selected node confirms each exact unspent cell.

## Verification

The supported purpose-built spend paths have synthetic golden tests in the pinned reference script engine. Current-planner tests execute both the covenant input and wallet fee input for 17 spend/recipient cases, check review fee accounting and HD change, and reject correctly signed mutations of constrained output values, CSV operands, and continuation bindings.

Separate historical testnet-10 fixtures record accepted creates and selected spends, including vault refreshes, escrow joins/resolves, and both post-window escrow timeouts. Post-window Inheritance heir, TimeLock claimant/backup, and Last Will heir acceptance is not fully recorded. Local replay recomputes transaction IDs and checks selected program facts; it does not rebuild historical transactions byte for byte or repeat node validation. See [Verification](/argon-docs/suresign/verification.md).

## What is refused

* Any covenant template outside the catalog, and any catalog template at a compiler pin other than the one it ships with.
* Creating an inspect-only template or a new retired revision-1 lock.
* Spending a program whose script the kernel cannot match to a pinned dump.
* A program-to-program spend of an unstamped Note under the current revision.
* Foreign or unqualified covenant-token programs. Only the exact authored `enclave-kcc20-v1` has the supported creation and spending path; later minting and administrative powers remain refused.