Kaspa developers are aiming for a May 5, 2026 hard fork that prioritizes covenants and native assets, while introducing early groundwork for future programmable features on mainnet, according to reporting amplified by @KaspaHub (community news bot) - @KaspaHub [source]. The same recap circulated widely in community channels as a clarification that the near-term upgrade is infrastructure-first rather than a user-facing programmability release - @DailyKaspa [source].
The discussion also consolidated near-term milestones around the upgrade path, including Testnet 12 resets and sequencing-related work, as summarized by community technical commentary referenced by @KaspaHub and @DailyKaspa - @KaspaHub [source]. The messaging this week focused on scoping: native assets and covenant improvements are framed as the immediate deliverable, with more advanced programmable systems positioned as follow-on work.
A detailed compilation of the developer Q&A was published by @terah4d5 (automated by @ByzntinResrch), threading together key answers about the hard fork scope. The thread confirmed the upgrade is covenant-centric with native assets, with vProgs foundations being laid but not the main event yet. Mainnet target is May 5. Near-term milestones include TN12 reset, a Sequencer Commitment KIP with an ETA of Feb. 12, and the SilverScript high-level language drop by Ori Newman and Michael Sutton. On native assets: atomic transfers are supported for anything running on regular inline covenants (ZK or non-ZK) plus KRC-20. For vProgs assets: non-atomic async transfers only, with wrapped KAS through canonical bridge rather than native L1 KAS. The thread also addressed the Computational DAG (CDAG) as the data structure recording all read/write declarations, and framed vProgs sovereignty as appealing to teams considering appchains or building AI agents on-chain with large state requirements - @terah4d5 [source]
Kaspa’s Testnet 12 relaunch (#2) went live Feb. 9, expanding the test environment for covenants and next-generation scripting work, according to @KaspaHub - @KaspaHub [source]. A detailed feature list circulated the same day: covenant IDs for safer covenant construction, an opcode to access a Blake3-based sequencing commitment, and ZK verification support for Groth16 and RISC0 via precompiles and opcodes - @Kaspa_Commons [source].
Core developer context indicated the reset had been tested and was timed for broader developer participation, reinforcing that the relaunch was operationally staged - @michaelsuttonil [source]. @DailyKaspa later confirmed the reset as live after the relaunch process completed - @DailyKaspa [source].
Developer communications tied the TN12 relaunch to an upcoming scripting toolchain: silverscript, described as a new script compiler intended to make the new covenant and ZK-related primitives more accessible to builders. The feature expectation was highlighted as part of the TN12 relaunch note relayed by @Kaspa_Commons, which said an announcement would share silverscript and its role in simplifying both inline and “based” program access to new opcodes - @Kaspa_Commons [source].
Earlier in the week, @michaelsuttonil previewed TN12 as arriving with “staggering” content and explicitly listed silverscript alongside covenant IDs, sequencing commitment work, and ZK precompiles - @michaelsuttonil [source]. The repeated references positioned silverscript as a practical enablement layer rather than a standalone protocol change.
Ecosystem accounts flagged multiple release candidate mentions for Kaspa software, including a post stating “Release candidate v 1.1.0 (RC 1) is finally out” - @Kaspa_Commons [source]. A separate update referenced “Release Candidate v1.1.0 (RC 3)” in an ICYMI-style post - @Kaspa_Commons [source].
While the tweets did not include a full change log in-line, the repeated RC references suggested active iteration cadence during the TN12 relaunch week. The discussion remained operational: encouraging testing and tracking rather than claiming feature finality.
A visible research debate played out publicly about fee mechanism design as throughput scales, with multiple contributors emphasizing that discussion does not equal a finalized decision. @coderofstuff_ pushed back on claims that an LSZ-based fee market was already decided, stating proposals were still under discussion and not taken lightly - @coderofstuff_ [source].
Related comments from @michaelsuttonil discussed the rationale for exploring earlier-fee-market triggers at roughly 100–200 TPS, suggesting meaningful security-budget contributions could arrive sooner under some designs than under alternatives that might delay a fee market until far higher throughput - @michaelsuttonil [source]. Another core voice, @OriNewman, defended ongoing analysis efforts and cautioned against portraying preliminary drafts as rushed implementation - @OriNewman [source].
A fee market discussion was initiated by @KaspaSilver, questioning current transaction fee dynamics on Kaspa. Core developer @michaelsuttonil responded by pointing to notes by @FreshAir08, confirming that the aim is to introduce a truthful fee market mechanism in the upcoming Covenants++ hard fork. "The aim is to hopefully introduce such a mechanism in the upcoming covenants++ hardfork. The goal would be to establish a truthful fee" - @michaelsuttonil [source]
The exchange highlighted that fee market design is an active area of protocol research tied directly to the May 5 upgrade timeline, with community members providing analytical input alongside core developers.
Igra Labs announced Galleon Test Mainnet is live, running production code with a two-week community testing window designed for deploying contracts, sending transactions, and stress testing - @Igra_Labs [source]. @KaspaHub amplified the launch as an EVM-compatible programmability layer test environment and linked to network details and node instructions - @KaspaHub [source].
Igra positioned the test as accessible without moving user funds off L1, stating that sending any Kaspa transaction on L1 triggers receipt of test iKAS on Galleon while the user’s Kaspa remains in-wallet, and noted a state reset after two weeks - @Igra_Labs [source]. @DailyKaspa also summarized the launch for broader audiences - @DailyKaspa [source].
The announcement landed after Igra’s Galleon Test Mainnet launch and during broader tooling and bridge work that supports testing flows. The partnership messaging emphasized integrations and expansion without providing a technical integration schedule in the tweets.
Igra Labs broadened the test audience beyond human testers by publishing a skill to let AI agents interact with the network directly, encouraging agents to deploy contracts, send transactions, and test the parallel execution environment - @Igra_Labs [source]. Commentary from contributors framed “skills for agents” as a way to remove friction and tighten QA feedback loops for on-chain environments - @emdin [source].
Ecosystem accounts treated the agent angle as a distribution and usability lever for developer experimentation rather than a marketing narrative. The technical message was consistent: automated agents are another stress-testing surface that can increase transaction diversity and improve the odds of catching edge cases during the two-week window.
Igra Labs published a detailed technical article on how transaction finality works on high-BPS chains and why it matters for builders on Igra and Kaspa. The piece explains that the key challenge in importing EVM for Kaspa is constant chain reorganizations (reorgs), which occur more frequently and at greater depth than in traditional smart-contract systems. According to the article, a significant slice of Igra's development effort was spent tightening reorg handling and adapting it to extract Kaspa's internet-speed responsiveness. The post concludes with recommendations for application developers on handling finality differences and links to documentation on the interface Igra provides for managing confirmation states - @Igra_Labs [source]
KAT Bridge testnet work continued to connect multiple networks for experimentation. @Kaspa_KAT said iKAS for the Igra Galleon testnet became available via a ZealousSwap faucet, describing it as essential for testing KAT Bridge flows on Igra L2 - @Kaspa_KAT [source]. On the wallet side, KastleWallet announced its browser extension shipped an update with “full IGRA support,” pointing testers toward using it with KAT Bridge - @KastleWallet [source].
These updates landed alongside Igra’s own reminders about testnet transitions, including a notice that the Caravel testnet would sunset and users should migrate to Galleon - @Igra_Labs [source]. The practical theme this week was operational readiness: faucets, bridge paths, and wallet compatibility updates aimed at increasing test participation and reducing setup time.
On the verification front, Kasplex highlighted that anyone can now verify EVM state transitions using SGX today, with ZK proofs coming next — framing the approach as "verify, don't trust" for scalable L2 construction - @kasplex [source].
Core developer @hus_qy announced the next major pull request introducing the L1-bridge, which establishes a communication interface for the L2 node to receive data from the L1 in a reliable and structured manner. The PR represents a critical infrastructure piece connecting Kaspa's base layer to programmability layers. "Okay guys, it's time for the next big PR - This PR introduces the L1-bridge which establishes a communication interface for the L2 node to receive data from the L1" - @hus_qy [source]
KaspaCom published the KCOM Whitepaper v1.0.0, positioning KCOM as the economic layer of Kaspa DeFi designed to align liquidity, incentives, and long-term growth across the ecosystem. The whitepaper outlines the token's role in coordinating activity across decentralized finance applications built on Kaspa infrastructure. "Designed as the economic layer of Kaspa DeFi, aligning liquidity, incentives, and long-term growth across the ecosystem" - @KaspaCom [source]
The whitepaper release was immediately followed by the KCOM Community Pre-Sale going live, positioning the token as the official utility token powering KaspaCom's DeFi and native infrastructure on Kaspa - @KaspaCom [source]. KaspaCom also announced that its full DeFi stack — including DEX, Lending & Borrowing, and the LFG Launchpad — will expand to Igra L2 - @KaspaCom [source]. These announcements came on the back of a milestone week for the platform, which reported 100M KAS in all-time trading volume, with monthly volume and revenue now 100x higher than early levels and users growing from 1,572 to 16,260 - @KaspaCom [source].
Kaspa received mainstream exposure via a national TV appearance in Israel featuring KaspaCom’s CEO, with subtitled clips shared by KaspaCom and amplified by ecosystem accounts - @KaspaCom [source]. Separately, educational resources continued circulating, including an audiobook version of The Book Of Kaspa shared by @KaspaHub - @KaspaHub [source].
Technical education remained active in parallel with protocol work. A long explainer on push/pull bridge communication and reorg filtering from @hus_qy circulated widely, providing rationale for L1-to-L2 data ingestion design and a later PR implementing a reorg filter - @hus_qy [source]. The week’s content mix combined mainstream visibility with deep technical documentation aimed at builders.
ZealousSwap introduced its Zealous Auctions Protocol (ZAP), bringing fair and transparent token launches to the Kaspa ecosystem powered by Uniswap's Continuous Clearing Auction mechanism. The team noted it leads on Kasplex with more TVL and all-time volume than all other DEXs combined - @ZealousSwap [source]. Meanwhile, Kaspa Finance reported that Phase 1 of its KFC public sale sold out and Phase 2 is now underway - @KaspaFinance [source]
StroemNet announced its testnet launch for February 20th, enabling true crosschain atomic swaps between Kaspa TN10 and Ethereum Sepolia. The project previously teased its capabilities with a Christmas puzzle challenge and is now inviting developers to join ahead of the testnet debut - @stroemfinance [source]
StroemNet also launched a $2,000 USDT bug bounty targeting five Solidity security researchers to audit their HTLC atomic swap contract — a 150-line, formally verified piece handling KAS-to-ETH crosschain settlement logic - @stroemfinance [source].
KastleWallet shipped mobile version 1.14.0 with KNS registration and KNS transfers directly from the dashboard and details pages, and added KRC721 transfer support with UI/UX polish - @KastleWallet [source]. The KNS Domain account confirmed the functions were live inside KastleWallet Mobile and emphasized direct management of .kas domains on mobile - @knsdomain [source].
These are user-facing tooling upgrades rather than protocol changes. The week’s wallet news focused on making identity and NFT transfers more accessible without external tools, which is consistent with ongoing efforts to improve onboarding and everyday usability.
Kaspa Stream shipped a reworked top addresses table that supports the full 10,000 addresses the API provides, according to @supertypo_kas - @supertypo_kas [source]. The same developer later noted additional work to reconfigure a Testnet 12 explorer endpoint following TN12 changes - @supertypo_kas [source].
These updates were discussed as practical monitoring infrastructure rather than speculative analytics. Rich list visibility and updated explorer compatibility are recurring builder needs during testnet resets and network feature rollouts, especially as covenant and scripting experiments require reliable inspection tools.
KasMap introduced a BlockDAG Viewer that shows reordering in real time, including blocks being selected and unselected and the ability to follow a transaction as it happens - @KasMaporg [source]. The tool was presented as an educational and diagnostic interface for users who want to understand how the DAG behaves under real network conditions.
Follow-on posts from ecosystem accounts highlighted the tool’s value as part of a broader pattern of “visualizers” emerging around Kaspa infrastructure, reinforcing that end-user comprehension and developer debugging are both use cases for real-time DAG visualization - @Kaspa_Commons [source].
An in-depth article by @fishtuna explored whether AI agents will need cryptocurrency, concluding that Kaspa is currently the strongest contender for the settlement layer role - not despite its lack of native smart contracts, but because of it. The piece argues that in a modular economy, the settlement layer should be a pure, high-velocity ordering machine rather than one slowed by complex execution logic. With the move to 10 BPS, the DAGKnight protocol, and a possible future of up to 100 BPS, Kaspa offers the sub-second finality agents require to avoid slippage and MEV bot exploitation. The article further notes that Covenants++ features provide exactly the primitive logic agents need for safety while heavy computation is offloaded to L2s, calling Kaspa "the only PoW system fast enough to serve as the heartbeat of a machine economy" - @fishtuna [source]
Multiple posts tracked long-term holding behavior amid continued price weakness. @DailyKaspa reported the share of holders who have held Kaspa for 3+ months climbed to nearly 75%, suggesting supply is concentrated among more patient holders - @DailyKaspa [source]. Separately, @DailyKaspa said long-term supply idle for 2+ years reached a new all-time high at 18.5% of total supply - @DailyKaspa [source].
Accumulation also featured in wallet-cohort updates. @DailyKaspa reported wallets holding 1M–10M Kaspa were net accumulators during the dip - @DailyKaspa [source]. Another post said the top wallet added 19M Kaspa, taking its balance to about 1.34B Kaspa - @DailyKaspa [source].
Separately, on-chain data flagged a known Marathon Holdings wallet continuing to accumulate newly mined Kaspa with no recent outflows, adding institutional accumulation signals to the broader long-term holding trend - @DailyKaspa [source].
Price talk remained a leading theme, with @DailyKaspa placing Kaspa around $0.031 and describing an imbalance between thin downside liquidation liquidity (under $500K) and roughly $20M in potential short liquidations around $0.04 - @DailyKaspa [source]. Earlier in the week, @DailyKaspa said leveraged longs had been largely flushed, framing the remaining downside liquidity as thin and noting an overhang of shorts above - @DailyKaspa [source].
The community also referenced the magnitude of the drawdown: @DailyKaspa reported Kaspa was about 87% below its all-time high as of Feb. 5, with an estimated price near $0.027 versus a $0.207 ATH - @DailyKaspa [source]. Despite frequent technical and development posts, price structure and positioning remained the most common day-to-day discourse.
Offline events were highlighted across regions. @Kaspa_KEF boosted an Hong Kong meetup notice for Feb. 12, shared via a quote of @drcliffordchoi’s post - @Kaspa_KEF [source]. In Europe, KasMap promoted the first Dutch Kaspa meetup and later shared a live link - @KasMaporg [source].
In London, @Kaspa_KEF amplified plans for a Feb. 19 free-to-play poker evening at WolfysBar that includes a 20% discount when paying with Kaspa and mentions ecosystem sponsorship - @Kaspa_KEF [source]. KastleWallet separately highlighted the 20% discount tied to paying with its wallet at the venue - @KastleWallet [source].
Mining updates this week centered on pool operations and miner education. @Kaspa_KAT relayed that dxpoolofficial announced it will shut down its Kaspa mining pool on Feb. 17, with a withdrawal deadline of April 2 - @Kaspa_KAT [source]. The post positioned Katpool as an open-source alternative but focused primarily on the operational timeline for miners needing to move - @Kaspa_KAT [source](2019129837The announcement landed after Igra’s Galleon Test Mainnet launch and during broader tooling and bridge work that supports testing flows. The partnership messaging emphasized integrations and expansion without providing a technical integration schedule in the tweets.