'The "Doherty Threshold" was defined as ~400 milliseconds; the maximum amount of tolerable UX latency'
kaspa blocktime is 100ms, add a RTT and you're still below the threshold.
kaspa blocktime is 100ms, add a RTT and you're still below the threshold.
UX latency is the most frustrating (lack of) advancement in computing over the last ~50 years.
IBM, way back in the 80s, found that user productivity shot up *exponentially* as system response time dropped. The "Doherty Threshold" was defined as ~400 milliseconds; the maximum latency before interrupting user flow state.
It's unbelievable how many modern operating systems (*cough* win11) violate this threshold constantly.
Literally all you need to do as a Dev is pay attention. Add a "Doherty Threshold" to your test suite. There's so many different profiling tools, and especially with how good models are, really no excuse. Sure, some stalls are unavoidable, but that's when you pull out other UX tricks to at least give the illusion of responsiveness.
Crazy how much vintage computing hardware feels immeasurably more responsive despite having thousands of times less overall performance.
1
14
41
606
a community funding wallet has been opened to reward security reporters who contributed in the software hardening, something that should be encouraged further.
here are all the details: discord.com/channels/59915…
here are all the details: discord.com/channels/59915…
2
36
153
9,467
get utxos by covenant id, which was a long awaited node feature is now approved.
you can build the node from source code and try this feature out now, or wait for upcoming release.
WASM support and JS example provided, should be easy to use.
just add "--covenant-index" to the arguments list.
thanks to @Max143672 for the feature :)
cc @kascovio
you can build the node from source code and try this feature out now, or wait for upcoming release.
WASM support and JS example provided, should be easy to use.
just add "--covenant-index" to the arguments list.
thanks to @Max143672 for the feature :)
cc @kascovio
9
40
186
3,894
Kas the coin can also be 'tokenized' as a kcc-20.
the need may not be very clear to everyone, but basically: my L1 app may want to uniformly manage kcc-20 and Kas the coin, without extra 'custom code'.
@manyfest_ details one of the direct use-case.
i have been convinced that designing kas-20 correctly only gives benefit with no tradeoff.
is it possible to have such an atomic covenant transaction that:
1. convert Kas to kas-20
2. trade it for the Many kcc-20 token
(=without adding one extra conversion step)
the need may not be very clear to everyone, but basically: my L1 app may want to uniformly manage kcc-20 and Kas the coin, without extra 'custom code'.
@manyfest_ details one of the direct use-case.
i have been convinced that designing kas-20 correctly only gives benefit with no tradeoff.
is it possible to have such an atomic covenant transaction that:
1. convert Kas to kas-20
2. trade it for the Many kcc-20 token
(=without adding one extra conversion step)
Onwards!
KCC-20 lets us create tokens that work together through a shared interface. Native KAS is a fungible token as well, but it isn’t a KCC-20 token.
Imagine a DEX, for example. KCC-20 lets us write a generic pool covenant that supports any pair of KCC-20 tokens. But if one side of the pair is KAS, we’d need special logic to handle it.
Representing KAS as a KCC-20 token would let covenants handle KAS the same way they handle other KCC-20 tokens. There could be different implementations and deployments of a KAS-backed KCC-20 token, but it would be beneficial to agree on a single one to avoid fragmentation.
I'm proposing a simple implementation, KAS20. Join the discussion on Kas-Smiths:
kas-smiths.org/t/a-kas-backed…
5
48
213
2,795
Status final = beginning of a new era
Greetings $KAS. KCC-1, KCC-2 and KCC-20 are now Final, meaning they are ready for full adoption across the ecosystem.
We invite Kaspa builders to join the public KCC channel to ask questions, get support, discuss implementations and share what you build.
Come build with us.
13
79
345
3,525
IzioDev retweeted
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/…
github.com/kaspanet/kips/…
39
194
540
27,654
IzioDev retweeted
yes it's the era of a custom software
but you likely overestimate amount of people who have ever thought about making or fixing some software. Last 10 years people asking me how to become SWE (frankly very rarely they ask this nowadays 😭) - I always responded very simple:
"Just start making something. Take some problem that you want to implement, some software that you hate, or automation that is missing - and do it in any way"
you know what I have heard 98% of times? Something like "I don't know I don't need anything".
It takes time, experience, and taste to know that you can build something and you have to be brave enough to believe you can actually handle it
but you likely overestimate amount of people who have ever thought about making or fixing some software. Last 10 years people asking me how to become SWE (frankly very rarely they ask this nowadays 😭) - I always responded very simple:
"Just start making something. Take some problem that you want to implement, some software that you hate, or automation that is missing - and do it in any way"
you know what I have heard 98% of times? Something like "I don't know I don't need anything".
It takes time, experience, and taste to know that you can build something and you have to be brave enough to believe you can actually handle it
13
6
227
6,074
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)
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)
5
25
129
2,886
IzioDev retweeted
not easily, no. a solana program has more capabilities and can be longer and more expressive. sophisticated designs can create a multi-contract argent app that executes complex behavior across partitioned state and over multiple transactions (that’s why i called these “mini programs”), like i did with chess, but then composition with other covenants/apps needs to be carefully designed, as does contention over shared variables/state.
in short, i cannot promise you yet that things will run smoothly and compose cleanly. we are not a solana vm by design, and hence i expect the created apps/systems to be shaped differently to match the inherent constraints. so i can’t promise how exactly this will evolve, but my strong hypothesis is that it enables significantly complicated systems.
(the answer above is all within pure covenants and does not talk about based zk apps, which are as fully expressive as a solana program but currently have limited L1 composability that depends on zk proof submission)
in short, i cannot promise you yet that things will run smoothly and compose cleanly. we are not a solana vm by design, and hence i expect the created apps/systems to be shaped differently to match the inherent constraints. so i can’t promise how exactly this will evolve, but my strong hypothesis is that it enables significantly complicated systems.
(the answer above is all within pure covenants and does not talk about based zk apps, which are as fully expressive as a solana program but currently have limited L1 composability that depends on zk proof submission)
4
34
145
3,053
IzioDev retweeted
KCC-20 has advanced to Last Call:
github.com/kaspanet/kccs/…
A companion reference implementation by @manyfest_, written in Argent together with its pinned generated Silverscript, underwent an extensive manual review and AI-assisted audit by Michael Sutton, covering KCC-20 conformance, implementation correctness, and edge cases.
It is now open for final public battle testing. We encourage developers and security-minded reviewers to try to break it, probe edge cases, and report any implementation bugs or discrepancies with the spec.
Argent contracts:
github.com/argent-lang/kc…
Generated Silverscript:
github.com/argent-lang/kc…
github.com/kaspanet/kccs/…
A companion reference implementation by @manyfest_, written in Argent together with its pinned generated Silverscript, underwent an extensive manual review and AI-assisted audit by Michael Sutton, covering KCC-20 conformance, implementation correctness, and edge cases.
It is now open for final public battle testing. We encourage developers and security-minded reviewers to try to break it, probe edge cases, and report any implementation bugs or discrepancies with the spec.
Argent contracts:
github.com/argent-lang/kc…
Generated Silverscript:
github.com/argent-lang/kc…
5
63
170
22,625
IzioDev retweeted
The KCC Coordination Forum has reached an important milestone in the standardization process. The foundational KCC-1 and KCC-2 standards have now entered Last Call.
This opens a final 14-day review period. If no major issues are identified, both standards will be finalized and considered ready for ecosystem adoption.
We encourage anyone working with these standards to review them carefully and raise any remaining concerns during this period.
This opens a final 14-day review period. If no major issues are identified, both standards will be finalized and considered ready for ecosystem adoption.
We encourage anyone working with these standards to review them carefully and raise any remaining concerns during this period.
2
41
134
13,912
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.
i assume it will also help to identify bottlenecks, so let's congest there.
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/…
vprogs framework: github.com/kaspanet/vprog…
7
68
232
9,068
IzioDev retweeted
d'autres chercheurs veulent aussi apporter d'avantage de réactivité aux transactions, sans modifier le protocol.
x.com/michaelsuttoni…
x.com/michaelsuttoni…
i used to think real-time execution was the one thing that couldn’t be faked on bitcoin L1.
i stand corrected.
1
4
42
834
IzioDev retweeted
i used to think real-time execution was the one thing that couldn’t be faked on bitcoin L1.
i stand corrected.
i stand corrected.
52
129
625
26,617
covenant: deployment-time static metadata such as symbol name, image/logo, decimals and all.
While prototyping KCC-20 I got asked how should token symbols, descriptions, images, and other kind of metadata be defined.
On EVM systems, there is a single SC which represents a token, and holds both its balance state and global state.
On the UTXO model there is no global state, the token is split and held across holders, each one holds his specific token (UTXO/covenant).
This means that adding state fields for metadata would duplicate them across each UTXO, which is wasteful. Things such as representation, name, symbol or image are also not part of the SC logic, and should not be part of it.
A naive approach is to declare such metadata in the payload field of a tx, which is an "empty space" that can be used to write whatever information.
The issue is that Kaspa is prunable. Eventually, the block containing this tx would no longer be available for verification, so at some point the data would need to be trusted by off chain entity.
After drafting a few solutions, we came up with KCC-23, a convention for binding the metadata to the covenant ID itself.
Read more on Kas-Smiths:
kas-smiths.org/t/kcc-23-conve…
Or read the KCC draft:
github.com/kaspanet/kccs/…
3
30
142
3,625
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.
taken from a UX perspective, and we have a lot to learn from, lot of challenges to crack produce-wise.
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.
taken from a UX perspective, and we have a lot to learn from, lot of challenges to crack produce-wise.
1
36
155
2,422
