How does Kaspa keep runtime sigop counting backward compatible?

Kaspa's switch to runtime sigop counting preserves backward compatibility by allowing a transaction to commit to a sigop count that meets or exceeds its actual runtime value. Backward compatibility in a blockchain context means existing transaction formats and tooling continue to work after a protocol change. Here, the mechanism is a flexible commit rule: a transaction may declare a higher sigop count than it ends up using at runtime, so transactions authored under the old static-counting rules still satisfy the new system without modification. For developers and wallet users, this means the efficiency gains roll out gradually without forcing an immediate, disruptive migration to new transaction formats.