Kaspa covenant IDs and sequencing commitments entered Rusty Kaspa’s Covenant++ development branch through PR #813 on January 21, 2026. The merge added deterministic UTXO covenant identity, output-to-input authorization bindings, script access to recent ordering commitments, and supporting consensus context, but it was experimental branch work rather than a mainnet feature announcement.

Key takeaways

• A new covenant-ID helper hashes a transaction outpoint – transaction ID plus output index – into a 32-byte identifier.
• Transaction outputs gained an optional CovenantBinding containing an authorizing input index and covenant ID; UTXO entries gained the corresponding optional ID.
• New covenant context and script operations let validation reason about which outputs continue a covenant authorized by a particular input.
• The sequencing accessor checks selected-chain ancestry and exposes a bounded recent commitment derived from a block header.
• PR #813 merged into covpp-reset1, not the main branch, and its history included mainnet-disable work. It was infrastructure for review and parallel development, not activation.

What did PR #813 actually merge?

The official rusty-kaspa PR #813 is titled “Covenant id scheme + Seq commit opcode.” GitHub records 14 commits, 85 changed files, 2,381 additions, and 731 deletions, merged January 21, 2026 into the covpp-reset1 branch.

The diff spans consensus transaction models, hashing, UTXO validation, script context, opcodes, P2P, RPC, wallet and PSKT paths, tests, and an example.

The maintainer’s merge comment said pending client and RPC work remained and that merging would let multiple contributors fix issues and build on the branch. That is integration-branch language, not a declaration of production completion.

How is a Kaspa covenant ID derived?

The added covenant_id function is small and explicit. It creates a domain-specific CovenantID hasher, feeds it the originating outpoint’s transaction ID, then feeds the output index in little-endian form. The result is a deterministic hash tied to one specific UTXO origin.

This creates a stable covenant namespace without a central registry. Different outpoints have different preimages; collision resistance remains a hash assumption.

An identifier alone does not enforce behavior. Enforcement comes from script and consensus rules that check how inputs carrying an ID authorize outputs that continue it.

What is a CovenantBinding?

PR #813 added an optional CovenantBinding to transaction outputs. The structure contains authorizing_input, a 16-bit input index, and a covenant_id hash. A UTXO entry stores the optional covenant ID after the output enters the UTXO set.

The authorizing-input field connects an output to the input whose covenant rules permitted its creation. Script context can then group continuation outputs by input, count them, and retrieve their transaction indexes. Tests in the diff exercise operations such as covenant-output count and covenant-output index.

UTXO state moves through consumed inputs and new outputs rather than one mutable account. The ID marks the lineage; the binding records which input authorized each continuation.

The companion article Kaspa Covenant Fields Across RPC, PSKT, UTXO, and JavaScript APIs explains why the same data must be carried consistently outside consensus validation.

What is a sequencing commitment in this merge?

The initial SeqCommitAccessor exposed two checks to the script engine. First, it could determine whether a supplied block hash was a selected-chain ancestor from the current point of view. Second, it could return that header’s accepted_id_merkle_root only when the block was within a configured blue-score depth threshold.

This gives a covenant bounded access to an ordering-related commitment without allowing an unconstrained scan of arbitrary old DAG state. A script can reason about recent selected-chain context while validation supplies the expensive consensus data through a controlled interface.

It is not a wall-clock timestamp, an oracle, or a promise that every parallel block appears in one simple linear order. It is a specific commitment and ancestry query defined by the branch’s consensus view. Later sequencing-commitment work could refine its representation and proof model, so applications should not freeze an early branch interface as a permanent standard.

Why combine covenant identity and ordering context?

A programmable UTXO may need to prove two different things: which state lineage it belongs to, and whether an allowed transition occurred in an acceptable network context. Covenant IDs address the first. Sequencing commitments provide a building block for the second.

Together they can support state machines that advance through authenticated outputs and recent consensus-recognized ordering evidence. PR #813 itself ships no complete application.

The initial SilverScript SDK overview covers the higher-level tooling needed so developers do not have to assemble every opcode manually.

What did the merge not provide?

It did not turn Kaspa into an account-based virtual machine, deploy a token standard, solve data availability, or authenticate external prices and events. It also did not prove that covenant applications were audited or economically secure.

The PR targeted an experimental Covenant++ branch, included temporary limits and TODOs, and had follow-up client and RPC work pending. Its large diff required further integration, testing, specification review, resource pricing, activation planning, and operator coordination before any production use.

An ordering commitment can prove defined chain context; it cannot prove that an off-chain statement is true. A covenant can enforce encoded rules; it cannot prevent a designer from encoding the wrong rules.

What were the roadmap and price implications?

The merge showed Kaspa’s programmability research reaching cross-cutting reference code. State identity and bounded consensus context are meaningful UTXO-application foundations.

They remain foundations. Adoption depends on stable specifications, secure implementations, usable SDKs, application teams, audits, node activation, and user demand. None of those follows automatically from one branch merge, and the source supports no KAS price target or guaranteed market reaction.

Frequently asked questions

Is a covenant ID the same as a token ID?

No. It identifies a covenant lineage derived from an outpoint. A token system would require additional issuance, transfer, conservation, metadata, and validation rules.

Can two outputs continue the same covenant?

The binding and context model supports multiple outputs associated with an authorizing input, and the diff includes count and index operations. The covenant script decides which pattern is valid.

Does a sequencing commitment reveal every BlockDAG relation?

No. The accessor in this merge offers selected-chain ancestry plus a bounded header commitment. It is not a general DAG query interface.

Was PR #813 active on Kaspa mainnet in January 2026?

No evidence supports that claim. It merged into the covpp-reset1 development branch, and the commit history explicitly included disabling mainnet for the experimental work.

Source and verification note

This article is based on merged kaspanet/rusty-kaspa PR #813, including its conversation, commit list, changed-file record, and public diff. Exact field and hashing descriptions come from the added Rust code. The source establishes a January 21, 2026 development-branch merge; it does not establish mainnet activation, a completed application platform, independent security review, or price impact.