saefstroem

@ZealousSwap Reasonable reply. I see that you have considered this scenario. Good!

Appreciate it! and mainnet is the goal. There's no cheap way to do it, because a pool has no no-op entry. Every spend costs the attacker a Kaspa network fee, and for swaps: the 0.3% fee, slippage from moving the price, the storage-mass minimum on every output, and locked capital. So spamming interactions to hold the pool means paying our LPs to trade against you, every ~100ms, forever. It drains the attacker, not the pool. Even the cheapest griefing version, an add/remove ping-pong (no swap fee, no price move), still costs two network fees plus storage mass plus rounding dust to the pool every cycle, needs their capital locked, and still has to win a race every 100ms. It's not perfectly ideal, and yes, a determined attacker could ping-pong for a while and force some retries, but it gets expensive fast with nothing to show for it, so in practice nobody rational keeps it up. Kaspa also doesn't hand anyone a monopoly on the next spend. At 10 BPS honest txs compete for that outpoint every block, you can't guarantee winning every race, and pre-chaining your own spends breaks the moment you lose one conflict. Worst case for an honest user is a rebuild-and-retry, ~100ms. Price discovery isn't really stalled either: if the attacker holds the pool by trading, their trades are the price moving; if they ping-pong to avoid moving it, any honest trade that wins one race updates it. Acknowledging the possibility, we dont advise using the pool's price as an oracle and we purposely excluded any TWAP functionality from the pool (at least in its early stages) Sustained pressure on one hot pool is what the order-covenant batcher on our roadmap solves: signed intents get folded into one transition, so hogging the UTXO stops blocking anyone.

The ZealousSwap CoAMM whitepaper is out. A full constant-product AMM built in Kaspa L1 covenants, no smart-contract VM, documented end to end: swaps, liquidity, fees, and single-transaction token-to-token routing. Running on testnet-10 now. github.com/zealousswap/Co…

It can be offered in prod with warning notes. A protocol will never be production ready and guaranteed to be safe. I will of course continue to look for mistakes but I welcome anyone to help out. I myself might have trouble to launch the protocol due to lack of liquidity, but if anyone else can, that is great too

@asaefstroem I really want to use this in production from day 1 in order to give non-Kaspa holders a vessel to more easily participate in my app--highly important. Do you have an estimate of when it'll be production-ready? Alternatively, u think it can be offered in prod with warning notes?

Here is a contribution of mine. Stroemnet P2P atomic swap protocol is now fully open source: github.com/saefstroem/str…. Long live kaspa:native and $ETH.

@ZealousSwap Or another angle, where an attacker can attempt to perform arbitrage or frontrunning (MEV) by for a short burst of time making the pool UTXO unavailable

Re: 13.3 Ordering and Stale State What prevents an actor who wants to stall price discovery from repeatedly spamming the network with pool interactions to prevent others from interacting with it and thereby DoS-ing a pool? Great initiative though, I hope to see this on mainnet 🔥

crates.io/crates/dockerd… or simply cargo install dockerdump

I just pushed an update to Dockerdump and realized most devs don't know what it is. If you are like me and don't want to deal with Docker images but the software you are using only deals in Docker, get Dockerdump.

@shimadonia I don’t understand how you mean that Kaspa’s covenants, ICC on their own can do cross chain operations? Why would you want to do escrow over ZK or HTLC?

@asaefstroem HTLC/ZK are the standard primitives, but Kaspa’s covenant actors + ICC + escrow show clear feasibility for trustless cross‑chain coordination without hash‑locks.

@shimadonia The contracts utilize covenants from kip10 but the toccata covenants do not unlock much more utility when it comes to cross chain operations (except for the zk opcode)

@asaefstroem Interesting approach! Have you considered a more protocol native method using Kaspa’s covenant actors, ICC messaging and escrow primitives?

@shimadonia Well there is no way to perform trustless crosschain settlement without mechanisms like htlc or ZK.

@asaefstroem It could remove the HTLC overhead entirely and allow stateful, trustless cross chain settlement without LPs or relays. Curious if this direction was on your radar. 🙃

@JMehargII @KaspaBrasil I mean, the zk opcodes implementation have been all over crypto news. At least for $Kas. Im trying my best to spread it and its use cases. Have you seen my presentations in Berlin or London?

@asaefstroem @KaspaBrasil Is there anyway to Streamline this information to the community/world please?? zkSnark are the future of crypto, and with KAS as a major contender for the same category as BTC, this is imperative DEVs and potential institutions are aware of.............. right?

This is the power of the #Kaspa community and the brilliant minds of the developers.

@p4bpj @kaka_kaspa Yes, stroemnet can support these assets in the future.

@kaka_kaspa Maybe @asaefstroem ? I think he is building HTLC.

$Kaspa Is anyone currently developing a truly native stablecoin or wrapped BTC protocol on Kaspa based directly on L1 Covenants? My idea is to combine the KRC-20 token standard with Kaspa Covenants and SilverScript to redesign a native, programmable fungible-asset protocol. The core objective would be to ensure that token issuance and redemption are enforced by on-chain rules, rather than interpreted by an indexer or controlled by a project team with discretionary minting authority. Under this design, the actual circulating supply would be dynamically constrained by a predefined mint-and-burn policy. For example, when a user locks 1 USDC through a cross-chain bridge, and the bridge verification mechanism confirms the deposit, the protocol would mint the corresponding asset on Kaspa L1 at a 1:1 ratio. During redemption, the corresponding token on Kaspa would first be burned, after which the original asset would be unlocked on its source chain at the same 1:1 ratio. If this mechanism can be implemented successfully, Kaspa could establish a native asset issuance and management framework capable of supporting assets such as KUSD, KBTC, and KETH under a unified protocol standard. The critical infrastructure that needs to be built consists of two main components. First, Kaspa needs a native fungible-token standard built with Covenants and SilverScript, supporting conditional minting, burning, transfers, and supply control. Second, it requires a mature, reliable, and as trust-minimized as possible cross-chain verification and asset-custody mechanism. Fundamentally, this is not simply about issuing a stablecoin on Kaspa. It is about building a native programmable asset-issuance layer for the Kaspa network. Once native issuance controls and burn functionality are available, Kaspa would have the technical foundation needed to support native stable-value assets. Before USDT or USDC are issued directly on Kaspa, bridged assets such as KBTC and KUSD could serve as practical alternatives. The key objective is to establish stable-value assets directly on Kaspa L1, which would significantly improve the network’s suitability for payments and settlement. @michaelsuttonil @IzioDev

@kaka_kaspa The idea is good, the only thing we need now is a standard for wallets to adopt.

@JMehargII @KaspaBrasil Both. Search for zk opcodes on kaspa.

@asaefstroem @KaspaBrasil zkSnark or stark?

@JMehargII @KaspaBrasil Its already live on mainnet :)

@KaspaBrasil Tommy $KAS needs to figure out a zkSnark upgrade ASAP to be relevant for institutions to start taking a serious look at it after BTC paves the way theough the clarity act......... you know what I mean?.......

@FireCashX @aglovale0x Example: you can make a privacy wallet where private transfers are enabled by default. If you are a serious builder and are not just looking for a quick in and out, we need strong developers in the $KAS ecosystem. Forking and splitting the ecosystem makes no sense at all.

@aglovale0x @asaefstroem The chain must have mandatory privacy. Otherwise it will be a ghost transparency chain like Zcash.

Privacy of zcash:native speeed of kaspa:native #PoW launch 12 of the July.

@Cryptopumpzzzz So nice meeting you man, thank you for the kind words. Without you we wouldn’t be able to share it! You are the guy for when Kaspa needs to be seen live 🔥

What a weekend! 👏 First of all, a huge thank you to everyone in the Kaspa community who chipped in the extra $500 to get me over to the UK AI Agent Hackathon at Imperial College London. I was genuinely honoured to represent the community and livestream the event for those who couldn't make it. It was great meeting @LevendiPro again. The first time was brilliant, but this time we got to spend a lot more time together. His brain genuinely never switches off—he's constantly thinking of new ideas to promote Kaspa, @WolfysBar @Crumpet_Media , and the ecosystem as a whole. I also got to spend time with @asaefstroem and @IzioDev . Two of the nicest, most down-to-earth guys you'll ever meet. I felt smarter just listening to them talk code... even if I only understood about 1% of the conversation. 😂 It was also great finally meeting @qu1ck_crypt0 (J), my Blockchain Banter co-host. Top bloke, and it was nice to finally chat properly in person. A massive thank you as well to @Seb28_7 and @Elliott_Blast for making the event possible. One thing that really stood out to me is this: Kaspa has some of the smartest people I've ever met working on it, but they're also some of the most humble and approachable people you'll come across. That's a special combination, and it gives me even more confidence about where this project is heading. And because it's me the trip home couldn't be straightforward. 😅 I left Imperial at 5:15pm for Stansted and got there around 7:15pm, but security took so long that by the time I reached the gate it had already closed. 🙄 Ended up waiting for the 11:30pm flight home after surviving on very little sleep on my brother's couch. Never a dull moment! 😂 Every minute was worth it though. The future for kaspa:native is incredibly exciting. 💚

Kaspa devs with some of our workshops attendees. The next generation of blockchain technology meets the next generation of builders. 🤝💚

Follow @kaspagrowth for more updates on KEG-led growth initiatives for Kaspa