Kaspa ($KAS) core R&D - what developers discussed, debated, and shipped. Feb 23 - Mar 6, 2026.
v1.1.0 Ships
Rusty Kaspa v1.1.0 went stable on March 4.
Sutton had been preparing the release for a few days. On the 4th he shared the release notes draft with the team - Ori Newman, Maxim, coderofstuff, IzioDev, FreshAir08 - asking them to review the wording. (draft) Ori replied "Approved." (approval) coderofstuff: "Lgtm. Send it." (response) Sutton published it minutes later. coderofstuff's response: "Parallel processing lol." (banter)
The release notes Sutton wrote described the main story as "not one feature, but a meaningful step forward across integration UX, sync/catchup behavior, and node efficiency." He was direct about what it matters for: "it gives us a cleaner/stabler/more performant base before the upcoming covenants++ releases."
Three main things improved: exchanges and wallets that track confirmed transactions now get a cleaner, single data feed instead of having to pull from multiple sources and stitch it together themselves; syncing a fresh node from scratch is roughly 3x faster in the early phase; and a bug was fixed where a node could get stuck mid-sync if the node it was downloading from moved its checkpoint during the process.
The Kaspa Stratum Bridge - software mining pools use to connect to the network - was included as an official beta release for the first time.
One small inconsistency was flagged during testing by wbbw55, who was adapting the KRC-20 node to work with the new data feed: a field is called "value" in one place in the code and "amount" in another. (detail) Minor, but noted.
KIP-21: Anchoring Layer 2 to L1
On Feb 24, Sutton published KIP-21 - a proposal for how second-layer networks built on top of Kaspa can prove their activity is genuinely anchored to L1. He tagged the full team: "pls give it a thorough & critical read." (announcement)
Ori reviewed it and left comments - mostly around clarity, with some on design specifics. (review)
Maxim pushed back on a practical point: whatever commitment structure KIP-21 uses, the data needs to be readable through Kaspa's standard API. "Otherwise it's required to follow every lane and their changes to recalculate commitment locally. Without that it's impossible to produce proof." (point) Sutton agreed: "yes, definitely. there will be a need to design a rpc layer over this." (response)
Also this period: coderofstuff announced that DagKnight - Kaspa's next-generation consensus algorithm - now has its own branch in the main codebase. (link) hashdag asked whether the current implementation also includes "free colouring" - a specific part of the algorithm Sutton had mentioned might be skippable. (question) Sutton: "currently not. the coloring algo only considers agreeing blocks." He added he's hoping to prove that's sufficient. (reply) hashdag: "this is exciting!" (reaction)
Covenant Declarations
On Feb 23, Sutton shared a proposal to make writing Kaspa smart contracts significantly less painful. (announcement)
Kaspa covenants are on-chain contracts that control how coins can be spent - rules enforced by the network itself with no middleman. They are currently live on testnet-12 and will come to mainnet with the upcoming hard fork, expected in May. Writing them today means assembling everything manually from low-level operations. The proposal: developers write just the rules they care about, and the compiler fills in all the surrounding machinery automatically. The full spec document is public: DECL.md.
Ori's immediate response: "Generally it looks good" - but he raised a design concern. The approach ties one set of rules to one function, which doesn't work when a contract needs to behave differently depending on what triggers it. (concern) Sutton replied that this limitation goes away if the annotation stays on the function rather than the whole contract - multiple entry points remain possible. (reply)
Ori then asked whether it would be possible to inspect the resulting state in transition functions - useful for debugging. (question) Sutton said yes, and suggested it could be integrated with manyfestation's debugger. (reply)
manyfestation's reaction to the full proposal: "This is fantastic." (reaction)
PR #47 landed on March 5. (PR)
Designing the Contract Creation API
On Feb 26, Sutton proposed a specific API for how developers actually create a new covenant in practice. (proposal)
The question: when you create a contract, you need a way to declare which transaction input authorises it and which outputs belong to it. Sutton proposed a clean structure with full validation built in - bounds checking, ordering, no duplicates, no overwriting existing contracts - all verified before anything is written.
IzioDev: "It seems convenient, let me play a bit around in different context with this." (response) smartgoo_v agreed: "More so than a fn that only computes covenant ID. Removes a good amount of the lift for the creator." (agreement)
Sutton then PRed the implementation directly over smartgoo_v's branch. (PR)
IzioDev raised a question about the ordering requirement: should the developer care about keeping outputs in strictly increasing order, or should the API just sort them automatically? (question) Sutton: "You mean we should sort internally rather than err." IzioDev: "Yes, 100%, I mean the lowest level util can validate this ordering (and err you), but public facing surface can order for you." (exchange)
Then a recurring problem came up: JavaScript developers building web wallets can't easily use certain Rust data types in their code. IzioDev: "That's a recurring pain point we faced, Charles can relate on it too." The current workaround involves writing manual type conversion code each time. (detail)
Measuring Contract Costs
Sutton proposed adding a new field to transactions called script_mass - a number that reflects how much computational work a contract script actually did. The network multiplies it to get the real cost. (proposal)
The motivation: covenants can run complex logic. The existing fee calculation doesn't account for that work properly. IzioDev asked what the arbitrary multiplier represents. (question) Sutton explained: it's a precision trade-off that also maintains backwards compatibility - old transactions still work exactly as before. (detail) Ori: "Yeah, makes total sense to me." (response)
SilverScript Developer Tools
manyfestation's visual script debugger was merged on March 5. Ori announced the merge: "You should all look at manyfestation's debugger, it's really cool." (merge) Sutton: "Congratulations." (reaction)
On Feb 26, manyfestation had laid out his next goals: "I aim to support TX context during debug session. This would allow to debug/run covenant logic, based on scenario files. My goal is to allow creating and running tests while developing Silver covenants." (plan) He also raised an open design question: should the debugger show the developer's own code, or the compiled version including all the generated boilerplate? "I think it would be more UXy to debug only the specific transition logic and skip all the covenant preservation code." (question) Ori said he'd want both, with breakpoints to focus on what he cares about at any moment. (reply)
IzioDev, meanwhile, posted an update on his language server - which gives live error highlighting as you write contract code. "Still some things to be done, especially with diagnostic displays. But we're getting there." He shared a screenshot showing a parsing error being flagged live. "Next step: intellisense - as I type I get proposed by the IDE to accept known values / functions." (progress)
He was clear that the two tools are meant to work together: "The LSP is useful at the time of writing the script and the debugger is useful to understand what's being done at script execution time." (IzioDev)
Sutton responded to seeing the LSP in action: "feat request: special appearance for Op* calls." (feedback)
Also: manyfestation ran into a problem connecting to testnet-12 - which is where covenant scripts are being tested - and posted the error. (question) Sutton: "I'm not sure there are pnn nodes on tn12." (reply) IzioDev offered an alternative connection point. (workaround) manyfestation: "Connected, TY very much!" (resolved)
Can Contracts Know What Time It Is?
On Feb 23, Sutton asked saefstroem about a planned opcode that reads the timestamp of a coin being spent: "i was wondering, what's the usage of the input daa opcode if there's no way to get the current accepting daa to compare against?" (question)
saefstroem explained: the opcode enables temporal logic on contracts. "We can enforce temporal logic on which utxo can be allowed to spend this output" - for option contracts, prediction markets, anything where you need to prove participation happened before a deadline. (answer)
Sutton suggested combining it with the existing lock_time field. (suggestion) Ori added a pattern that works today without any new opcode: "you can generally make something like this: I want to require the user to make an action in the following hour, so I let him spend this UTXO only by attaching another UTXO that was created in the last hour." (workaround)
The Proof of Reserves Question
BitCat1234 asked whether a new opcode reading Kaspa's running coin fingerprint could enable cryptographic proofs of reserves - letting an exchange prove it holds what it claims to hold without revealing anything else. (question)
Sutton: "You're aware that the utxo commitment can be used to prove anything only if you provide the full utxo set as preimage?" (response) And then: "It will need to hash and aggregate the full utxo set, with blake2b, chacha20 and muhash ops per entry" - a very large computation. (detail)
BitCat1234 asked whether the preimage could be a private input to the proof. (question) Sutton confirmed yes, technically - but it's still a massive proving job. (response)
Maxim stepped in with a lighter alternative: using the difference in the coin fingerprint between two points, you can prove a balance changed by X without proving the full set. "We can't prove reserves itself, but we can prove it was increased or decreased by x." (detail)
The thread continued with Max asking whether a simpler existence opcode was feasible. Sutton: "It's possible but it makes the script surface more and more dirty. I'd avoid it unless proven to be super important." (response) Sutton also noted Solana has a similar proposal in the works. (aside)
Security Budget: The Debate Gets Sharper
This has been the most contentious ongoing thread. Kaspa's security budget - total miner income in $KAS - determines how expensive it would be to attack the network. As the block reward decays toward zero, fees need to grow to compensate. Right now they don't come close.
FreshAir08 started the period with a clear warning: "The worst we can do is again not do anything regarding the security budget during the upcoming HF. Be it my suggestion, adaptive blocksize suggestions, or something else completely - something needs to be done, and to treat it as less important than other matters is a mistake." [1]
Ori published comparison charts for different penalty formula approaches. (charts) His own observation: "I think both linear and quadratic (not Monero's quadratic) look OK." (opinion) He also pointed out: "the Monero formula is too aggressive when the median is very small. E.g. when median is 1 tx and adding 1 tx doubles it." (detail)
Sutton pushed back on the broader approach: "my problem with monero formula is that it couples the tx fees with order of magnitude of block rewards while we wish to decouple it." And the harder constraint: "in the best case you're only doubling current rewards. I don't think that's sufficient." (response)
Ori proposed an alternative: block size as a function of minimum fee inside the block. High minimum fee unlocks larger blocks. No penalty on the reward. (proposal) Sutton: "this part obviously feels a bit unsound. idk, i need to hang on the idea a bit." (reaction)
Then Ross_ku_963 - newly invited by FreshAir08 - joined and named the structural problem with copying Monero directly: Monero has permanent coin emission, so coinbase permanently dominates miner income and the penalty always bites. Kaspa has decaying emission. "Short term: coinbase >> fees. Medium term: coinbase ≈ fees. Long term: coinbase << fees." As fees take over, a coinbase-only penalty becomes meaningless. His fix: apply the penalty to coinbase plus fees combined. (argument)
Sutton welcomed him: "Welcome Ross_ku_963." (welcome) No one disagreed with the structural argument. The debate on which mechanism to use is still open going into the hard fork.
The JavaScript SDK Problem
elldeeone raised something straightforward: the official Kaspa JavaScript libraries haven't been updated in roughly two years. "npm i kaspa is the top result that agents always gravitate towards because of the naming when you initiate a basic prompt of trying to build on kaspa." (point)
Aspectron: "I am afk / unreachable this week but we can perhaps look next week and do updates." (response) elldeeone: "That would be great if you've got time next week, pls ping me if i can ride along/help out." (followup)
Python SDK v1.1.0
smartgoo_v released the Kaspa Python SDK v1.1.0 on March 5. Now on PyPI - pip install kaspa - meaning Python developers no longer have to build it from source. He credited elldeeone specifically for bringing in key components. (announcement)
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.
#Kaspa #KAS #BlockDAG #Web3 #Crypto #DeFi #Layer2 #SmartContracts
