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.

$KAS "We will have one of your own on this show next week." @MorningMotionTV @austinoakes

Kaspa addresses just got names and faces 👀 Kascov now shows KNS .kas names on address pages, top holders, trades and transfers, paired with deterministic Kaspicon pixel identities. Shoutout @knsdomain + @weirdtualguy 🫡 Try it → kascov.io #Kaspa #KCC20

Your .kas name now shows up in 🗡️Dagger. ▸ KNS domains on your Wallet, Balance, Portfolio & Deposit screens ▸ Read straight off Kaspa L1 — inscribed, permanent, already yours ▸ Zero setup, zero cost Big respect to @knsdomain for building real on-chain identity on Kaspa. Trade Kaspa L1 in Telegram 👇 t.me/Daggerkcc20bot?start=DA…

As far as I understand this post, I strongly disagree with it (but maybe I’m reading it wrong) Kaspa covenants can support onchain composability in ways which are conceptually eqv to eth/vm style interfaces. Ie two completely different bytecode contracts can share the same onchain verification api such that eg a dex can interact with two types of asset contracts in the same manner. I currently know of 2 ways to do this (but I can imagine there are more). Composability method #1: Define/ spec/ conventionize the state layout of a contract. By making sure that all contracts following a specific spec/ convention share the same state layout, you allow an independent third program to inspect and observe their state transition without being tied to a specific bytecode implementation. That is, the observer can look at all inputs and outputs involved in the observed contract state transition and deduce from that the logical operation that occurred. All the observer needs is 2 things: (i) A stable hash of the non-state parts of each such covenant (ii) A covenant id Composability method #2: This one is a bit more involved but also more efficient. The specification not only defines an agreed state layout but it also defines an additional component: the state of each output must have a designated field which must describe the operation that just happened in concise terms. I.e., descriptors of the form: <note: x tokens were transferred from A to B>. This designated note / receipt field can be plaintext or a hash of several statements, and its exact format must be part of the said standard. Think of this as the verification eqv of an interface call. Instead of calling an opaque interface entry and relying on the specific runtime contract to execute the logical meaning of that op (as in classic vms), you have that specific contract declare the statement of what it did, and as an observer, you only need to inspect and read that note and make sure it matches the operation you expected. --- I wrote about method #1 here kas-smiths.org/t/fungible-to… and full support for it is already implemented in argent. Method #2 is somewhat more powerful/minimal but requires more effort from each contract following the std. I appreciate you taking the time to analyze and write about this topic and raise awareness of the std challenges. I’d be happy to explain more, brainstorm initial ideas etc etc cc @DailyKaspa

Who remembers when I had to spend time educating people why forks on $KAS or in general are not always bad? @Davincij15 forks are beautiful when you have consensus. :) It becomes bad when you do not have consensus. Which unfortunately Bitcoin sees many of those. In $KAS all forks have been with overwhelmingly good consensus and this is simply because $KAS is here to set the new standard for proof of work. Start studying!

Hello, welcome to todays NAT 101 class (yes this is Kaspa related - bare with me). Most ppl are familiar with the fact that every device connected to the “internet” has an IP.. What most don’t realise is that in most cases this IP is not a real, globally reachable address. It’s just a local one. Analogy time: someone asks where you live and instead of giving your street address, you say “yeah i’m in the spare bedroom, second door on the left past the laundry”. Completely correct inside your own house, totally useless for anyone trying to navigate to you. That’s basically how home networks work. Your devices have private IPs that only make sense inside your house. The router (the box with flashing lights on it) is the only thing with a real, public address. The reason this exists is simple: 1. We ran out of usable IP addresses (ipv4) ages ago (don’t @ me about ipv6, adoption has been ' coming soon' since 98 lol) 2. Routers act as a basic firewall, so random traffic from the public internet wasteland doesn’t hit your internet connected fridge This process is called NAT (network address translation). It lets all your devices share one public IP, but the tradeoff is: nothing on the outside can start a conversation with you unless you open a port manually (which 99% of ppl never do). (This is where $kas relevancy comes in) so you end up with nodes that can dial out to the network, but the network can’t dial in to them. Lots of home nodes sit in this half connected state. Now, there are ways around this. UPnP is a method that involves the node begging “router pls can i has some open ports?” method, but it’s hit or miss depending on your hardware/security settings (mostly a miss due to poor implementation on home routers or outright blocked as most see it as a security risk). The more interesting method (and the point of this whole ramble) is TCP hole punching. The concept is: two devices behind two different routers want to talk directly, but both routers are blocking inbound traffic (remember, no random traffic to your fridge). So they coordinate through a public “rendezvous server” to make both routers open the right outbound paths. Once both routers see outbound traffic going to the same ip:port, they allow the return traffic too (that’s the hole in the punch). Here’s the flow, simplified: 1. Private node a contacts the rendezvous server (in our case a public node) -> the server learns private node a’s public ip:port 2. Private node b does the same 3. The server gives a the public address of b, and gives b the public address of a 4. A + b both try to open a connection to each other at the same time 5. Those simultaneous outbound attempts cause each routers NAT to create a temporary mapping (ok pass go, collect 200 - NAT is now mildly confused and lets it through) 6. Once those mappings exist on both sides, a handshake can succeed through the two NAT’s and voilla you have connection It doesn’t work for every router or isp setup, but when it does, two private nodes can talk directly without anyone touching router settings. For kaspa, this is huge. if even 50% of private nodes suddenly become fully reachable, the network becomes stronger, more connected, and far more decentralised. There are of course considerations around how we route these connections and how we manage inbound limits. All of that is part of the design work ahead though. Michael started this initiative, and I’m just trying to contribute in whatever ways I can. I’ve put together a PoC that works in a controlled setup, but there’s plenty left to learn and a fair bit to build before it’s ready.