Dire 𐤊rypto

That's a really good question, but it's hard to answer in a single tweet because our mission is quite extensive, and it requires a lot of background knowledge to really understand what sets Kaspa apart. Currently, a lot of people see Kaspa as “Bitcoin’s crazy little brother” that improves time-to-finality by leveraging the benefits of DAG-based consensus protocols without accepting their traditional drawbacks, such as decreased decentralization or a limited validator set. This perception is somewhat accurate, but it falls short of conveying the full picture, because Kaspa’s vision extends far beyond just trying to be a better Bitcoin. Anyone willing to study Kaspa and its broader vision will discover similarities to nearly all major existing DLT designs: from Bitcoin, to Ethereum, to Solana, Sui, Celestia, and beyond. My personal view is that “research” in the DLT space is approaching a point of convergence. We increasingly understand how to push distributed systems close to the limits of what physics permits. The frontier is no longer only about raw throughput or faster finality. The attention is shifting toward game theory, incentives, sequencing, MEV, alignment, and how to build systems where the economic incentives of users, builders, miners, validators, applications, and infrastructure providers do not work against each other. That is why debates like based rollups versus arbitrary sequencing, shared sequencing, MEV mitigation, proposer-builder separation, and execution-layer incentives matter so much. These are not niche technical details. They determine whether a network can remain neutral, decentralized, and aligned while scaling to global usage. And this is where I think Kaspa is pushing the boundaries in a very important way. Kaspa is not merely trying to be “fast.” The goal is to build an L1 where speed, decentralization, security, and incentives are aligned at the base layer. A system that does not scale by hiding complexity behind trusted committees, privileged sequencers, centralized validator sets, or opaque coordination mechanisms, but instead tries to preserve the spirit of proof-of-work while extending what an L1 can realistically do. Because Kaspa arrived later than many other major projects, it does not carry the same degree of technological debt. It can absorb lessons from Bitcoin, Ethereum, rollups, modular blockchains, high-throughput monolithic chains, DAG research, MEV research, and the broader history of decentralized systems, and combine those lessons into something more optimal. To me, that is what Kaspa is building: not just a faster blockchain, but a more incentive-aligned decentralized infrastructure layer. But this also creates a different challenge. Kaspa’s biggest problem today is not its technology. It is the lack of centralized coordination around communicating the vision. And because Kaspa is a grass-roots movement, that responsibility does not belong to a marketing department, or a single leadership team. It belongs to the community. That also means the community has a different role to play. There will always be holders who are mainly interested in price, and that is completely fine. But there also need to be people who are here because they want to use the technology to build a different future. People who care about the architecture, the incentives, the open questions, the trade-offs, and the long-term trajectory of decentralized infrastructure. I am one of those people. I am not interested in DLTs merely as a way to generate wealth. I am interested in them because I believe they can change the trajectory of humanity as a whole. For that reason, I want to use this opportunity to announce a regular community hangout where we discuss the current state of development, the open questions, and where we can align our vision together. The first session will be on Tuesday, June 9th, 2026. We will talk about the vProgs framework, how the codebase works, what sets Kaspa apart, where we improve on existing solutions, and what still needs to be done. The goal is for this to become a regular, possibly bi-weekly, event where we as a community come together to discuss the future and understand the technology. Eventually, we can invite people from other projects as well, but the main focus at the beginning will be explaining and communicating how things work under the hood. There is still a lot of work to be done, and I do not want to waste precious time. So the first sessions may feel a little improvised, but we can improve as we go. The important thing is that we start. So mark the date: Tuesday, June 9th, 2026.

Yes of course my Pal ! This is a 10ft ethernet cable which connected RustForce1 to the world :) RustForce1 is a high end gaming machine spec tower I built as a DEV machine so @michaelsuttonil could compile and test all versions up to and including the RUST main net release. A WAN IP, loaded RAM and flagship @intel CPU offered faster more efficient software development environment than laptops. After release of RUSTY $KAS , I rearranged all of the machines in my office and it struck me that 'all of the 1's and 0's IN RUST passed through this cable BEFORE it took over the World" - therefore Sir Sutton might want to hang onto it as a Lifetime Story Souvenir!!

checkmate is coming to kaspa

why I’m personally excited about Kaspa’s upcoming Toccata covenants - for the first time, I can build creative, complex apps directly over infrastructure I helped design and build - we designed under architectural constraints, but the result came out surprisingly expressive and powerful - Silverscript is cool as hell - I can literally open a *.sil file and write a complex contract that will be fully verified on Kaspa L1 - (nottoself: create a 10-minute video showing the building of such an app e2e) - I can design my own vaults and safeguards, and manage funds securely without risking a heart attack each time I touch a wallet - covenant ids, contract templates, and inter-covenant communication (ICC) feel like a new set of axioms, or a new algebra to work with and discover - sig verify from stack / sighash anyone-can-pay + covenant ids can allow interesting shared-state covenants (requires a non-consensus miner policy; kudos to @maxibitcat for pushing this line of thinking) - complex contract systems can be deployed in one spk hash. no storage rent, no deployment tax; users pay only the transient mass for tx data as they use it - as I’ve mentioned in the past, this becomes especially interesting for AI/agentic environments, where bots could cheaply create one-time agreements between themselves - I didn’t even mention based apps yet. That’s a whole vertical that isn’t ready for exploration yet, but will be very soon

Kaspa.org has been refreshed. Kaspa has a lot going on, but the main site does not need to put it all at the front door. Its first job is simple: help someone arrive, understand what Kaspa is, and know where to go next. The previous site accumulated more over time. Pages, explanations, resources, and audiences were added. This version starts smaller, so it can grow with Kaspa from here. The refresh is not just visual. The wording, structure, and narrative direction all needed attention IMO. The content traces back to @hashdag’s writing, simplified for a first read. Kaspa is already deep enough. The first read should not make people work harder than necessary. There are many true ways to talk about Kaspa, but Kaspa.org cannot carry twenty narratives at once. For this version, the strongest one to unify around is real-time decentralisation. Part of the refresh was also about making the builder path easier to follow. Kaspa.org gives people the overview of what exists, why it matters, and where to go next. Docs.kaspa.org gives builders the deeper material, with room for examples, detail, and ongoing improvement. Docs.kaspa.org starts with @IzioDev's work and has the broader goal of bringing important Kaspa L1 builder documentation into one place. Both repos are public. Pages will be added, wording will change, gaps will be filled, and the work can happen in the open. Big shoutout to @kasmediadotcom for their support in helping bring this refresh together. Have a look around. If you see something that can be better, please open an issue or PR.

Toccata consensus feature freeze is finally here after a heroic last-mile push by kas core devs. Aiming to reset TN12 tonight, or tomorrow at the latest. Genesis update: + 0x6b617370612d746573746e6574 // kaspa-testnet - 12, 2 // TN12, Launch 2 + 0x544f4343415441 // TOCCATA + 12, 3 // TN12, Launch 3

@brt2412 @OrangutanElder Congrats Bro👏

I wrote a PoC token contract in Silverscript, currently called DOG20 (better name ideas are welcome). It supports token ownership by 3 kinds of entities: 1. Public keys — like any regular Kaspa address. 2. P2SH addresses — which means ownership by a stateless contract, e.g. multisig. 3. Covenant IDs — which means ownership by a stateful contract. The third option is the interesting one, and it's a demonstration of a broader concept (that might be familiar to whoever watched the webinar by @IzioDev and @michaelsuttonil), called inter-covenant-communication (ICC). In this context, it means you can put arbitrary stateful rules around token control. For example: - “after the first 10 spends, wait a year before spending again” - zk-rollups can manage their L1 tokens using a stateful bridge. DOG20 also supports minters that are allowed to mint indefinitely — but that does not mean the supply must be unbounded. Let's say you want to publish a token and allow to issue only 100 new tokens each month. DOG20 doesn't support it natively, but you can achieve that by making the only minting entity a covenant. That covenant will store in its state `nextIssuance`, and will allow spends of 100 tokens only if `time > nextIssuance`, and will set `nextIssuance = nextIssuance + 30 days` each time it's used. I hope to explain about it a bit more in the future, but in the meantime, feel free to look at the examples linked in the next comment.

@Grayscale @realvijayk arigato gozaimasu! if Kaspa army showed up here, think how they'll show up when you provide a KAS digital asset.. by mid june Kaspa OP_CAT++ Bitcoin. worth the attention _/\_

Today there is a bigger update because there are 3 new PRs that are ready for review. The first one (github.com/kaspanet/vprog…) fixes some bugs and introduces the SchedulerState which unifies the way we expose shared state in our framework. The second one (github.com/kaspanet/vprog…) introduces the node-framework which builds on top of the first PR and introduces a generic platform for building L2 nodes that ingest data from the Kaspa L1 to produce state changes (and eventually proofs) of the L2-execution. The third one (github.com/kaspanet/vprog…) introduces the node-vprogs-cli - an actual binary that can be executed and that follows the L1 to execute transactions in a concrete VM. The binary is designed to support compile-time modularity, which means that by updating a single line in the backend.rs we can swap out both, the storage and the VM. A VM is defined by three functions: 1. A pre_process_block function which extracts the relevant L2 transactions from the L1 chainblock. 2. A process_transaction function which executes a single transaction (within its scope) and produces execution-results. 3. A post_process_block function which takes the execution results of the individual transactions and stitches them together into an aggegrated proof structure which can be settled on the L1. All steps are parallelized as much as the underlying causal structure permits. I still have a few chores on my todo-list and there are still a few missing parts (like syncing from state that we didn't actively witness) but this is pretty much as far as we get without re-integrating with the covenants on L1, so the next steps will be to actually design the concrete framework for settling state transitions on the L1 (and consequently syncing from it). I suspect that this will require a little bit of back and forth between the two development efforts but we are getting to the point where things start to get interesting.

wrote an outlook for the upcoming “Toccata” hard fork -- native L1 covenants, based zk apps, why the activation window moved, and what the road from feature freeze to mainnet looks like: @michaelsuttonil/kaspa-covenants-toccata-hard-fork-outlook-a4d81a40900c" target="_blank" rel="nofollow noopener">medium.com/@michaelsutton…

WarpCore now provides comprehensive support for: 1. **Fedwire** (US Federal Reserve wire transfers) - all tests passed 2. **SEPA** (Single Euro Payments Area) - all tests passed All tests verify end-to-end payment processing, compliance screening, Kaspa blockdag settlement, and regulatory adherence for both global payment systems. **Status: ✅ READY FOR INTEGRATION WITH FED/SEPA TEST ENVIRONMENTS** --- #kaspa #warpcore

Okay, it's time for a little update: I just finished the work on the zero knowledge part of the vprogs framework, which introduces the ability to prove arbitrary computation. It consists of the following 8 PRs that gradually introduce the necessary features: 1. ZK-framework preparations (github.com/kaspanet/vprog…): This PR cleans up the scheduler and storage layers, extends the build tooling with workspace-wide dependency checking, adds the ability to publish artifacts for transactions and batches (which will later hold the proofs), renames some core types for clarity, and introduces lifecycle events on the Processor trait that allow a VM to hook into key scheduler events like batch creation, commit, shutdown, and rollback. 2. Core Codec (github.com/kaspanet/vprog…): This PR introduces a lightweight encoding library for ZK wire formats. In a zkVM guest, every byte operation contributes to the proof cost, so the codec is designed to reinterpret data in-place rather than copying it. It includes zero-copy binary decoding (Reader, Bits) and sorted-unique encoding for deterministic key ordering. It is built for no_std so it runs inside zkVM guests. 3. Core SMT (github.com/kaspanet/vprog…): To prove state transitions, we need cryptographic state commitments. This PR adds a versioned Sparse Merkle Tree that produces a single root hash representing the entire state. It includes all state-of-the-art optimizations: shortcut leaves at higher tree levels to avoid full-depth paths for sparse regions, multi-proof compression that shares sibling hashes across multiple keys, and compact topology bit-packing to minimize proof size. It integrates into the existing storage and scheduler layers so that every batch commit updates the authenticated state root, while rollback and pruning maintain tree consistency. 4. ZK ABI (github.com/kaspanet/vprog…): Defines the wire format for communication between the host and zkVM guest programs, establishing a universal language for proof composition. It specifies how inputs, outputs, and journals are structured for two levels of proving: the transaction processor, which proves individual transaction execution against a set of resources, and the batch processor, which aggregates transaction proofs and proves the resulting state root transition. Because the ABI is backend-agnostic and no_std compatible, any zkVM backend can directly use it (non-Rust zkVMs would need to reimplement the ABI in their language). 5. ZK Transaction Prover (github.com/kaspanet/vprog…): Introduces the transaction proving worker, which receives serialized execution contexts via the ABI wire format and submits them to a backend-specific prover on a dedicated thread. The Backend trait abstracts the actual proof generation, so different zkVM backends can be swapped without changing the pipeline. 6. ZK Batch Prover (github.com/kaspanet/vprog…): Introduces the batch proving worker, which collects the individual transaction proof artifacts, pairs them with an SMT proof covering the batch's resources, and submits the combined input to a backend-specific batch prover. The result is a single proof attesting to the entire batch's state root transition. Like the transaction prover, the Backend trait abstracts proof generation so different zkVM backends can be swapped without changing the pipeline. 7. ZK VM (github.com/kaspanet/vprog…): Wires everything together by implementing the scheduler's Processor trait with ZK proving support. The VM hooks into the lifecycle events introduced in PR 1 to feed executed transactions into the transaction prover and batches into the batch prover. Proving is optional and configurable - it can be disabled entirely, run at the transaction level only, or run the full batch proving pipeline. 8. ZK Backend RISC0 (github.com/kaspanet/vprog…): Provides the first concrete zkVM backend using risc0. It implements the transaction and batch Backend traits, includes two pre-compiled guest programs (one for transaction processing, one for batch aggregation), and ships with an integration test suite that verifies the full pipeline end-to-end - from transaction execution through batch proof generation to state root verification. TL;DR: While the early version of the framework focused on maximizing the parallelizability of execution, this feature focuses on extending this capability to maximizing the parallelizability of proof production. If you're a builder: this is the first version of the framework that lets you write guest programs with a Solana-like API (resources, instructions, program contexts) and have them proven in a zkVM. The current milestone uses a single hardcoded guest program - composability across multiple programs and bridging assets in and out of the L1 are part of the upcoming milestones, but if you're eager to start tinkering, the execution and proving pipeline is fully functional and provides a minimal environment to build and test guest logic today. Once we add user-deployed guests, they will move one logical layer down: the current transaction processor will become a hardcoded-circuit that handles invocation and access delegation to user programs, similar to how SUI handles programmable transactions (including linear type safety at the program boundary). In practice, this means guest programs will be invoked with a very similar API but scoped to a subset of resources, so the basic programming model won't change. Note that guests currently handle their own access authentication (e.g. signature checks) - the framework will eventually manage this automatically. If you want to contribute, two areas where community involvement would be especially impactful: - An Anchor-like DSL for writing guest programs -- the ABI is stable enough to build on, and a good developer experience layer would make this accessible to a much wider audience. - A second zkVM backend (e.g. SP1) - the Backend traits are designed for this, and a second implementation would prove out the abstraction. One thing I find particularly interesting in the context of PoW: the block hash provides an unpredictable, unbiasable random input that is revealed after transaction sequencing. This gives guest programs native access to on-chain randomness without oracles or additional infrastructure - something traditionally hard to achieve in smart contract platforms. PS: I am also planning to start with the promised regular hangouts but since I will visit my family over easter and want to get a better understanding of the open questions next week (it's good to have some problems to wrestle during that slower time 😅), I decided to start with that once I am back (12th of April). Generally speaking, is there a day that people would prefer for these hangouts? I guess monday would be bad as there is already another community event (write your preferences in the comments if you have a strong opinion).

WarpCore on Kaspa TESTING UPDATE: The only and most comprehensive full stack banking / financial rails on an L1 PoW. We have completed the following tests: 286 transaction type tests to run using various scenarios: 1. ✅ CBDC Full Issuance Workflow Token registration → minting → reserve attestation → Islamic instruments 2. ✅ Multilateral Netting Cycle Multi-participant obligations → gross/net calculations → settlement 3. ✅ Credit Facility Lifecycle Draw → repay → exceed limits → full lifecycle management 4. ✅ Nostro/Vostro Account Operations Multi-currency positions → payments → funding → position reporting 5. ✅ Liquidity Pool Participation Contributions → withdrawals → returns → multi-participant pooling 6. ✅ FX Forward Trading Quote → forward rates → netting → PvP settlement → T+2 7. ✅ Multi-Currency Netting Parallel netting across EUR, USD, GBP currencies 8. ✅ Islamic Finance Instruments Murabaha (cost-plus) → Ijara (lease) → Musharaka (profit-share) → Sukuk (bonds) 9. ✅ Herstatt Risk Exposure Settlement risk monitoring → high/medium/low categorization 10. ✅ Concurrent Transactions Parallel settlement operations → fund conservation 11. ✅ T+2 Settlement Workflow Trade date → T+1 confirmation → T+2 execution 12. ✅ Batch Payment Processing 100-item batch → success rate tracking 13. ✅ Treasury Operations Multi-currency positions → USD equivalency → revaluation 14. ✅ Settlement Failure Recovery Failure → retry logic → recovery verification 15. ✅ End-to-End Cross-Layer Settlement CBDC mint → liquidity allocation → FX trading → netting → nostro settlement Transaction Scenarios Covered Payment Operations ✅ Single payments ✅ Batch payments (100+ items) ✅ Multi-currency payments ✅ Concurrent transactions ✅ Failed payments with recovery Netting Operations ✅ Bilateral netting ✅ Multilateral netting (3+ parties) ✅ Multi-currency netting ✅ Gross/net calculations ✅ Netting settlement Credit Operations ✅ Credit draw ✅ Credit repayment (partial, full) ✅ Exceeded limits ✅ Credit facility lifecycle ✅ Facility expiry FX Operations ✅ FX quotes (bid/ask spreads) ✅ Forward rates ✅ NDF fixing ✅ PvP settlement ✅ Settlement risk (Herstatt) ✅ T+2 workflows ✅ Multi-currency trading Liquidity Operations ✅ Pool contributions ✅ Pool withdrawals ✅ Share calculations ✅ Return distribution ✅ Multi-participant pooling CBDC Operations ✅ Token issuance ✅ Supply minting ✅ Supply burning ✅ Reserve attestation ✅ Murabaha financing ✅ Ijara leasing ✅ Musharaka partnerships ✅ Sukuk instruments Account Operations ✅ Nostro account management ✅ Vostro account tracking ✅ Multi-currency positions ✅ Balance updates ✅ Position reporting Risk Operations ✅ Herstatt settlement risk ✅ Risk categorization ✅ Exposure monitoring ✅ Risk recovery Cross-Layer Operations ✅ CBDC → Liquidity flow ✅ Liquidity → FX flow ✅ FX → Settlement flow ✅ End-to-end workflows All 286 tests executed sequentially Zero test failures 100% pass rate #kaspa #warpcore #xrp #kii #poweredbyKaspa

🇰🇼 🇮🇱 Rare moment of truth at the UN from brave Kuwaiti dissident @JJJuraid, invited by UN Watch: “Mr. Chair, I heard the term “colonizers.” But who are the real colonizers? A Jewish Kingdom ruled in Judea for a thousand years. We, the Arabs, took this land. Who Arabized Egyptians, Phoenicians, Persians and Amazighs? It was us, the Arabs. So why does the council enshrine a lie by keeping a permanent agenda item on Palestine, while ignoring the indigenous heart of Israel returning home? Let us be clear about who is actually defending our sovereignty. Today, Israel is a fighter for peaceful nations, freeing Gaza from Hamas terrorists and saving Iranians from the Islamic Republic. What Israel is doing to the IRGC — stopping a genocidal regime from acquiring nuclear weapons — is a gift to humanity. There are 57 Islamic countries and only one Jewish state, Israel. Despite the ongoing hateful desire to eliminate it, Israel has not only survived, it has thrived. I don’t believe in miracles, but this is one. So I ask the UN: when will you end the ritual of condemning Israel? Is it not time, instead, to learn from Israel? How to defeat terror, defend free societies, and pursue peace. Thank you.” What a refreshing act of integrity and truth. Stay connected, follow @MOSSADil.

Hello world. It is time. Igra Genesis and TGE are this Wednesday, February 26th. You're all invited. Our genesis block carries an inscription from Deuteronomy 22:8 in Aramaic: "When you build a new house, make a parapet around your roof so that you may not bring the guilt of bloodshed on your house if someone falls from the roof." We build with that in mind. Here's the sequence: - Code, configuration, and bootstrap scripts are frozen. Nothing changes from here. - New nodes launch with public RPC endpoints and block explorer. - Nodes begin mining blocks. - Once the network reaches DAA score threshold, core contracts deploy, including IGRA token contract, minting vaults and DAO governance. - IGRA is minted and distributed into the pools. - IGRA is allocated to all direct early round participants. Genesis parameters are cryptographically committed and locked. The entire bootstrap is trustless and deterministic. Every step is verifiable on-chain, in real time. On Wednesday we lay the foundation for the fair, scalable and permissionless economy. See you on-chain.

@moshikrl @kaspaunchained @michaelsuttonil aiming for two HFs in 2026, cov++ beginning of May, DK+increased BPS end of Q3 god willing. both are aggressive timelines, but realistic with the newly expanded devforce

@Max143672 @OriNewman @asaefstroem @IzioDev @manyfest_ @hashdag discord.com/channels/59915… t.me/kasparnd/10433…

Launching Today: WarpCore: ISO 20022 In. Kaspa Finality Out. Today we’re launching WarpCore (Phase 1) in a sandbox environment for financial institutions. WarpCore acts as a universal adapter: ISO 20022 ⇄ deterministic Kaspa logic. Banks keep their existing messaging, controls, and compliance pipelines - while settling verifiable, immutable financial events on Kaspa at incredible speed, without compromising decentralisation. Secured by Proof of Work. This is not a new rail. It’s a translation layer. Legacy systems in. Cryptographic finality out. More to come... #kaspa $kas #xrp #ada #xlm #iso20022

The $KAS Testnet 12 PR has been merged! 🚀 TN12 is the Kaspa test network running covenants, a feature introduced via KIP-17. Kaspa covenants let UTXOs enforce rules on how they’re spent in the future. Using new introspection opcodes, scripts can inspect the spending transaction and only allow it if specific conditions are met. This enables native tokens, smart vaults, congestion control, trustless L1↔L2 bridges, and more.