you too want to build a Kaspa L1 app and are unsure where to start?

Max inviting devs to try a testnet vProg app in their browsers and then be curious on how it works, maybe even write their own prog? i assume it will also help to identify bottlenecks, so let's congest there.

d'autres chercheurs veulent aussi apporter d'avantage de réactivité aux transactions, sans modifier le protocol.

i used to think real-time execution was the one thing that couldn’t be faked on bitcoin L1. i stand corrected.

covenant: deployment-time static metadata such as symbol name, image/logo, decimals and all.

here is how i evaluate the kcc-12 proposal in a second pass. i sketch a user journey, observe flaws on existing web3 platform, see if my user journey fixes it, iterate. once i have a viable sketch, i take kcc-12, see if it **enforce** this flow. if not, it needs changes. kcc-12 should also be taken from a UX perspective, and we have a lot to learn from, lot of challenges to crack produce-wise.

A bank in Tel Aviv was told twenty months ago to take a quantum plan to its board. A utility in Ohio has never been asked. Same threat. (Almost) same NIST algorithms. Four very different PQC migration approaches globally. I tried to compare these PQC migration approaches, fresh from GISEC in Dubai and ahead of my related closing keynote at the PQC Summit in College Park on Tuesday. Some of what I found: Hong Kong's regulator scored its banks 2.3 out of 10 in July and set a target of 10 by 2030. FINMA surveyed 60 Swiss institutions, found 72% had taken no quantum-safe measures, and demanded board-backed roadmaps by mid-2027. The three NERC CIP standards shaping a US utility's 2026 compliance year say nothing about post-quantum cryptography. Not one. Canada put PQC clauses into every new federal contract in April. The US equivalent is still a rulemaking. Germany has recommended FrodoKEM and Classic McEliece alongside the NIST picks since 2020, and Europe got them into ISO in June. Chrome will accept only Merkle Tree Certificates in its quantum-resistant root store, while Europe's eIDAS trust lists are built on X.509. The post-quantum PKI can fork along a line that already exists in law. And nobody, anywhere, has enforced a PQC requirement yet. The full comparison, with a one-page table by jurisdiction and five things I think each migration could borrow from the others: postquantum.com/post-quantum… #PQC #PostQuantum #QuantumComputing #CyberSecurity #CISO #InfoSec #Regulation #CryptoAgility

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)

Do you think high liquidity is a cause or a consequence of a thriving ecosystem? Lot of places to claim atm.

"you know whats missing in kaspa developer team? clear and understandable communication with the plebs" Waiting for you there.

it's not an ideal representation, but it may help to grasp the leader/delegator concept. note that a transaction may contains multiple covenant groups, here we're specifically looking at a single group interaction. this model essentially allow delegator to run less computation that would have been required otherwise

this is a good opportunity for me to expand on storage. no meta-data really is "stored on-DAG", when we say that, we likely refer to "witnessed": a revealing event to feed the execution engine with full data. Kaspa decouples the DA (data availability) layer with the execution layer, for example through the pruning strategy: only the last ~30hrs of "non-consensus important" data are kept. or for example the program model: builders deploy a hash to the covenant and its state, and only these 32-bytes represents the covenant at the UTXO-level. without this decoupling property, i likely wouldn't be able to run a **full** node on my laptop. in this context, on-DAG image concept you're referring to would likely be projected as: "i store an integrity hash of the image, while the image still is served externally". essentially, we have to ask ourselves: who cares about the image integrity of an NFT (if there is an image attached to it at all)? the possible answers likely doesn't contain L1, meaning there will be no covenant program verifying image integrity. in this context, the end-users might be the interested party, and as such, they could take the integrity hash (from covenant state, or other), take the actual image that is being served externally and verify the image is the correct one