This week in Kaspa R&D (25 October to 1 November 2026) had two threads. One was a new idea for how smart-contract-style rules, called covenants, should measure time. The other was a long-awaited covenant index feature moving through its final review.
The stakes are practical. Apps that lock or release funds based on elapsed time need a clock that does not drift when the network speeds up. Builders also want a tool that makes covenant data easier to look up.
The clock idea is the bigger story. Michael Sutton proposed that Kaspa commit to a fixed pace of 10 time units per second for covenant scripts, whatever the block rate becomes. It is a proposal, not a decision, and no formal write-up exists yet.
The week in one minute
- A stable covenant clock was proposed. Michael Sutton floated a KIP (a formal Kaspa improvement proposal) that would keep script-visible time at 10 units per second, even if the block rate rises. It is an early discussion. (source)
- Two designs are on the table. One keeps the underlying counter itself at a fixed pace. The other keeps the fast counter and converts it at the points where scripts read it. Sutton leans against the first, and Ori prefers the second. (source)
- The covenant index is close to merging. Reviewers said they were happy with the current state, subject to passing tests. A merge was not confirmed in this week's archive. (source)
The big story: Covenants may get a clock that does not speed up with the network
Sutton's proposal is to give covenants a clock that stays at 10 ticks per second, even if Kaspa later produces blocks faster than that. (source)
The problem: a timer built on a speeding-up clock
Kaspa tracks progress with a counter called the DAA score. Scripts can use its progress as a measure of time. If the network's block rate (bps) rises, a counter tied to blocks could tick faster.
Imagine a covenant written today that says "release these funds after 600 ticks." Today that may be a predictable stretch of time. If the counter later ticked ten times faster, the same covenant would unlock far sooner than its author planned. That example is an illustration, not something quoted in the archive, but it matches Sutton's stated goal of a stable mapping from this unit to time for covenants written today.
His argument for 10 per second is that resolution finer than 100 milliseconds is not meaningful for apps anyway. (source)
Two ways to get there
Sutton laid out two options:
- Keep the DAA score's progress independent of the block rate. He leans against this.
- Keep the finer-grained score, but translate it into the 10-per-second unit at every point where the script engine uses it. He suggested the sequencing commitment data might get the same treatment. (source)
Ori said they had similar thoughts and preferred the second approach. (source)
For developers: The second option means conversion at "script engine boundaries." The archive does not list those boundaries or say how rounding would work. Those details are undecided.
A caution: do not flatten everything
Arthur Zhang agreed that separating application time from block rate is the right abstraction. But he warned that DAA scores can also serve as historical consensus data, especially with transaction introspection and sequencing commitments, so he would not normalize everything indiscriminately. (source)
His suggestion was to expose a stable 10 Hz logical clock for time-based rules and keep raw DAA scores available for ordering and proofs. (source)
Ori noted that the sequencing commitment includes the DAA score, as they recalled it, so it could be a way to reach the exact value. (source)
Sutton added that "based" zk apps could also find the stable clock useful, though they can already read raw timestamps. (source, source)
Status
This is a proposal under early discussion. Sutton asked for thoughts and rejections, and the replies were supportive, with reservations about scope. There is no written KIP in the archive, no agreed design, and no implementation.
For builders, the possible payoff is that a covenant written now would keep its intended timing as the network evolves. Whether that holds depends on which design is chosen.
What else moved forward
The covenant index is nearly ready, with one small budget question left
The covenant index feature came out of the week with reviewers broadly satisfied. IzioDev called it "long awaited." (source)
The archive does not explain the feature in detail. The discussion thread and a start-up flag, --covenant-index, show that it is an optional index for covenant data. The archive does not describe how it works internally.
One review point concerned queries that do not name a specific list of script public keys (abbreviated "spk" in the chat). Reviewer Ds left two optional comments on how the budget should work in that case, and said they were fine merging as is if tests pass. (source)
Maxim Biryukov, who authored the change, said the idea is to align the budget and the limit for such queries, and that it "doesn't change a lot." (source) IzioDev preferred the simpler approach, saying limits matter little in practice. (source)
Biryukov then asked reviewers to approve or list required changes. (source) IzioDev said he would check shortly. Biryukov could not recall anything meaningful still pending. (source)
Ds added one cosmetic note: the flags --utxoindex and --covenant-index use different separators, and they dislike the inconsistency. They called it unimportant. (source)
For developers: The open points are the optional budget/limit comments for no-spk queries and the flag naming. Neither was described as blocking.
The takeaway: this feature looks close to done, but the archive shows no merge, so it is not yet confirmed as landed.
What is decided, and what is not
Confirmed this week
- Nothing in the archive records a merge, release, or completed test.
Close to done
- Covenant index: reviewers said they were fine with the current state if tests pass. The no-spk budget/limit comments were optional. The flag naming was a minor gripe.
Proposals and active discussion
- A KIP to hold script-visible DAA score progress at 10 per second. Sutton raised it, and no decision has been made.
- Which design to use: fixed counter (Sutton leans against) or conversion at script engine boundaries (Ori prefers it).
- Zhang's suggestion of a 10 Hz logical clock alongside raw DAA scores is an individual idea.
Open questions
- Which script boundaries would convert the score, and whether sequencing commitment data would be converted too.
- How to keep raw DAA scores available for ordering and proofs.
- Whether
--covenant-indexwill be renamed.
What happens next
The archive names few concrete steps. IzioDev said he would check the covenant index shortly, and Biryukov asked reviewers to approve or request changes. (source)
For the clock idea, Sutton asked for feedback on a possible KIP. Nobody named a timeline, so the open questions above remain open.
Closing
The week's two threads share a theme: making covenants more usable. One makes them easier to look up, and the other aims to keep their timing predictable. The index looks nearly there, while the clock is still just a conversation. The next edition may show whether the covenant index is merged and whether the 10-per-second idea turns into a written proposal.