A philosopher
Metaphysics
Joined February 2018
- Tweets1.1K
- Following879
- Followers289
- Likes1.5K
tree(3) retweeted
I like! This is a really simple and inexpensive way to significantly reduce the quantum threat to Kaspa users.
Traditional addresses expose the public key controlling the funds. A sufficiently powerful quantum computer could derive the private key from that public key and steal the funds.
KIP-22 proposes a simple change: instead of exposing the public key, an address commits to a cryptographic hash (a fingerprint) of the spending conditions. The public key stays hidden, and unlike elliptic-curve cryptography, strong cryptographic hashes remain highly resistant to quantum attacks.
Only when we spend the funds do we reveal the necessary information for the network to verify the transaction.
There is still a theoretical attack vector where an attacker could intercept a spending transaction, derive the private key, and attempt to front-run the original transaction. But since PoW relies on hashing, which is far more resistant to quantum attacks, the network should remain operational and continue confirming transactions, leaving an attacker with only a very narrow window to act.
Exploiting this would require not just a quantum computer capable of breaking public-key cryptography, but one powerful enough to do this faster than the network converges. On Kaspa, that means just a few seconds. That's a much stronger "theoretical adversary," and it's unclear whether such a machine will ever exist.
Personally, I doubt quantum computers will ever be able to break public-key cryptography at realistic key sizes (I suspect that Hilbert space itself is discrete and has a much coarser resolution than commonly assumed, but that's a different topic).
So TL;DR: KIP-22 isn't a "complete" post-quantum solution, but it's an elegant, relatively low-cost way to significantly reduce the attack surface for quantum adversaries.
Published KIP 22 to help Kaspa users better protect their funds from future quantum attackers by keeping public keys hidden until spending
github.com/kaspanet/kips/blo…
tree(3) retweeted
composability between native covenants is ready (and is the key for eg all the dexs you’ll see over kcc20 tokens soon). sync composability between vprogs isn’t
AI generated code is taking too much ram! Can we imagine World of Warcraft used to run with 256MB ram machine. It’s not enough to render a text webpage nowadays
tree(3) retweeted
did you know that miners sometimes see their submitted block become a "chain block" on Kaspa?
when this happens, the block merges other blocks, called "merged blocks", and together they form a "merge set".
if it happens to merge red blocks, guess who wins the red pots? (reward that should have been allocated to the red merged block if it was blue instead of red)
tree(3) retweeted
everything you mentioned is possible. burn and mint are easy; freeze can be implemented in various ways, with different tradeoffs. dexs and lending platforms are possible as well, though good designs require real effort and expertise.
the main ingredient enabling the more compositional apps like dexs and lending is single-transaction atomicity, which allows onchain composability. these are exactly the kinds of design patterns Argent is trying to establish, and that the various KCCs are being designed with in mind
tree(3) retweeted
Tic-tac-toe is live on Kaspa testnet: the first vprog, a verifiable program with real execution and real settlement, running since yesterday.
You can play it here: vprogs-tt.izio.fr/
(Requires private key and some testnet funds)
We still need to review and merge a stack of PRs, however this is already a working POC. UI/UX was never a priority; the frontend can be enhanced or built separately
I'm gonna work on mdBook covering the parts of the system I consider meaningful and a workshop on vprogs and building apps on top
For Devs: this is the invitation. Play the game, read the code, build your own vprog.
Game code: github.com/biryukovmaxim/vpr…
vprogs framework: github.com/kaspanet/vprogs/t…
tree(3) retweeted
just a gentle reminder that krc20 is not kaspa L1, it only travels over L1 txs as data carriers, but the interpretation of krc20 state is done purely offchain just like any other non-zk based solution. this is why covenants were developed for kaspa L1 with kcc20 built on top of them for native assets (note: kcc20 spec is still in draft)
tree(3) retweeted
install Git and Rust on your computer, these two software are the only requirements as of today. open a terminal / powershell:
1. git clone github.com/argent-lang/argen…
2. ./setup
3. follow this video: youtube.com/watch?v=xZsuvcc9…
Additionally, you can observe different working examples here: github.com/argent-lang/argen… and here: github.com/argent-lang/argen…
And finally, don't forget to PR your own crafted apps to argent-lang/argent-playground
Community-based support in 'development' on Kaspa's Discord: discord.gg/48enF9xBy8
tree(3) retweeted
Dear CoinEx Community,
Today, I am announcing that CoinEx will cease operations and begin an orderly wind-down.
First, what matters most: your assets are safe. CoinEx’s reserve ratio exceeds 100%, and every user asset is fully backed and available for withdrawal. Withdrawals are open starting today and will remain open until December 22, 2026. Certain tokens may take slightly longer to process while funds are moved between cold and hot wallets, but every withdrawal request within the withdrawal period will be honored and processed.
CoinEx officially went live on December 22, 2017. Exactly nine years later, on December 22, 2026, the platform will be formally closed. Nine years is a long time in crypto. Together, we lived through multiple bull and bear cycles, witnessed the rise and fall of countless projects, and watched many of our peers leave the market in one form or another.
After much reflection, I have come to accept a hard truth. CoinEx did not become one of the industry’s leading exchanges, and the security and compliance risks of running a crypto exchange have become increasingly difficult to contain. Revenues can decline, responsibility does not. Carrying unlimited risk for limited revenue is no longer a rational choice. That said, CoinEx has survived nine years in one of the most volatile and unforgiving industries, weathered every storm, and is leaving intact, and with dignity. We may not have won the race, but we are finishing with honor.
On CET: CoinEx will buy back CET at its initial listing price of 0.005 USDT per token, with no cap on quantity. To every CET holder who has supported us over the years, thank you. CET represents your belief in CoinEx and, for many of you, your belief in me personally. I am sorry that we were not able to create the long-term value we once hoped CET would deliver. The least we can do now is bring that chapter to a responsible conclusion.
I did seriously consider selling CoinEx. Ultimately, I decided against it. Users entrusted their assets to CoinEx because they trusted the platform and, in many cases, trusted me personally. I did not feel that handing the platform and that trust to a new owner was the right way to end this journey. A clean ending is the right ending.
Nine years, millions of users. I did not turn CoinEx into the “great” exchange I once hoped it would become. But I can give it a decent ending: making sure users can withdraw their assets in full, giving my employees a dignified farewell, and providing CET holders with a clear and responsible conclusion. This is the best ending I can give CoinEx.
To everyone who traded with us, built with us, and stood by us through the hardest days of this market, thank you. It has been a privilege to walk this road with you.
To the CoinEx team, thank you for building this platform with me, for carrying it across every cycle, and now for seeing it through to the very last day.
For detailed arrangements, please refer to the official announcement: coinex.com/en/announcements/…
Thank you all for nine years of trust.
Haipo Yang
Sept 15, 2026
tree(3) retweeted
i’ve spent the last few months bringing native Kaspa payments to x402.
tldr: x402 is an open, chain agnostic payment protocol built around the long existing HTTP 402 code. kaspa-x402 intends to bring native KAS into that shared standard.
i keep seeing people use “x402” to mean anything built around the HTTP 402 response code. HTTP 402 has existed for decades, and anyone can hang their own payment flow off it.
x402 refers to a specific open protocol built on top of that code. it standardises how a server requests payment, how a client authorises it, and how the payment is verified and settled.
it can be used for paid APIs, AI agents buying data or tools, and MCP servers charging per call. kaspa-x402 adds native KAS to the existing x402 v2 flow.
there are two payment paths:
- exact for a normal one off KAS payment, with an optional KIP10 additive mode
- batch-settlement for small or repeated payments, where the client funds a SilverScript covenant once and signs a fixed charge voucher for each request
the longer term goal is to contribute the Kaspa support upstream into the wider x402 project, so Kaspa works within the same standard being adopted elsewhere.
i’m looking for humans and agents to go through it deeply before the final v1 release. read the code, build against it, test the assumptions and try to break it. if you find something, pls let me know.
code: github.com/elldeeone/kaspa-x…
upstream x402: github.com/x402-foundation/x…
docs: kaspa-x402.org
TN gateway: demo.kaspa-x402.org
discussion: kas-smiths.org/t/kaspa-x402-…
tree(3) retweeted
A lot of people think what makes Kaspa unique is the technology.
But the technology is really the consequence of a deeper philosophical difference.
Most crypto projects ask: How can we maximize performance without sacrificing decentralization?
Kaspa asks: How can we maximize decentralization without sacrificing performance?
That slight inversion of priorities changes everything.
It changes what the system optimizes for, which tradeoffs are acceptable, and ultimately what kind of threat model matters.
Kaspa and in particular the upcoming DAGKnight fork are built around the idea that a decentralized monetary network should remain resilient even under extreme failure scenarios like global infrastructure disruption, war, or other large-scale breakdowns.
Because fast digital coordination should not force people to choose between trusting a small group of node operators over a small group of banks.
For many applications, that distinction may not matter.
But for the applications where credible neutrality, censorship resistance, and resilience matter most, that ideological edge is the product.
Kaspa does not merely compete at the technological level.
It competes at the philosophical level and the technology is just the downstream consequence of following that philosophy to the end.
tree(3) retweeted
Built a payment protocol for metering LLM output on Kaspa with chunked reservation plus two-sided measurement, settled by a 504-byte covenant. There's an Argent port alongside the hand-written SilverScript, and both are chain-proven on testnet-10.
github.com/kaspahttp402/mete…
tree(3) retweeted
Turns out the full node can travel light: same full verification and 97% less storage.
We previously said substantially lower storage would require a separate light node with different security assumptions.
Well, we got one thing wrong.
Our upcoming upgrade delivers that reduction to the full nodes, with full transaction verification stays intact.
Igra node storage: 1TB -> 30GB.
Storage growth: 150GB -> 4GB per month at current activity.
Running a node and verifying Igra yourself is now practical for far more people.
Node operators and attesters: details and documentation coming shortly.
Decentralize the world!
tree(3) retweeted
Finally, Silverscript v1 is out [Link in the reply]. This completes the journey we started eight months ago with Toccata — it's finally possible to write human- (and AI-) readable smart contracts on Kaspa.
This language started simply as "CashScript with loops", but eventually grew into a full-fledged smart contract language capable of expressing complex, stateful contracts. It's always fun to look back at the first token mechanism @IzioDev and I worked on using raw opcodes, which took thousands of lines of code, and see the same thing implemented in just 60 easy-to-read lines of Silverscript.
I'm excited to explore the possibilities of UTXO programmability together with the Kaspa community, and this is only the beginning - Silverscript will evolve, Argent will add higher layers of abstractions, and I'm sure more people will find their own way of extending this new ecosystem.
tree(3) retweeted
Link for the release github.com/kaspanet/silversc…
