A token lock on Kaspa that is meant to last a year could end in a few months if the network speeds up. Michael Sutton wants to stop that before it can happen. He is weighing a KIP that would freeze the clock contracts see at ten ticks a second, even when Kaspa produces far more blocks than that.
A clock that speeds up
Kaspa contracts don't read hours or days. They count time in DAA score, a number that goes up with every block. Today that is about ten times a second, so one day is roughly 864,000 points (SilverScript Studio). Lock times and relative time locks in Kaspa script can be set in DAA score. Builders use them to write rules like "wait 30 days" or "release over a year" (rusty-kaspa).
The catch is that the counter is tied to the block rate. When Kaspa went from one block a second to ten, DAA score started running ten times faster. Some parts of the protocol had to be patched to keep counting real time. The coin emission schedule, for example, still remembers the exact score where the switch happened so it can work out the right month (KIP-14).
More speed is planned. DAGKnight aims for blocks every 25 to 40 milliseconds, and a later upgrade targets 100 blocks a second (kaspa.org). At 100 blocks a second, a DAA-based clock would run ten times faster than it does now.
That is already a real problem for contracts on mainnet. kascov tracks a token vesting lock that releases its tokens over 298.8 million DAA points, about 346 days at today's speed (kascov). At 40 blocks a second the same lock would finish in about 86 days. At 100 it would finish in about 35.
The worry isn't new. When Alex Säfström proposed an opcode that reads the DAA score at which a coin was created, CryptoAspect asked how exposed such contracts would be "if Kaspa rises its BPS rate again" (thread). Säfström called it a fair point that "shows the importance of careful script design". That opcode is now part of Kaspa script (rusty-kaspa), so a contract can measure how long a coin has been sitting by counting DAA points.
Ten ticks a second, for good
Sutton's idea is to make ten a second a permanent promise for contracts. Inside the script engine, time would always move at that pace, whatever the real block rate. "Sub-100ms resolution is not meaningful for apps anyway," he wrote, and a fixed pace gives "a stable mapping from this unit to time, for covenants written today."
He described two ways to do it. The first keeps DAA score itself from speeding up when blocks do, and he leans against it. The second leaves DAA score alone and converts the finer count into ten-a-second units wherever a script sees it, and perhaps in the sequencing commitment data that zero-knowledge apps read as well.
Ori Newman said he had been thinking the same thing and prefers the second way.
Keeping the exact count
Arthur Zhang agreed that app time should be separate from the block rate, but warned against rounding everything. DAA score is also a record of history, used for ordering and proofs. He suggested a stable 10 Hz clock for time rules, with the raw score still available.
Newman pointed out that the exact score is already inside the sequencing commitment, the record each block keeps for zero-knowledge apps, so apps that need it could still get it there (KIP-21). Sutton added that zero-knowledge apps built on Kaspa could also find the steady clock useful, though they can read raw timestamps too. Roman M noted that averaging raw timestamps already gives a reliable measure over a few dozen seconds, though not below one second.
