Kusama Shield v2 — some questions

Governance
1

This proposal stands out for a few reasons. The team delivered a working v1 on a modest budget and shipped features beyond scope. The PolkaVM work on Poseidon hashing could give Kusama Asset Hub a real edge for ZK applications. And the permissionless approach — no prescreening, one-block finality — is a clear alternative to projects like Privacy Pools.

That said, a few areas could use more detail:

On the swap mechanism: Where does liquidity come from when users exchange tokens? Is this purely routing through the Asset Hub DEX and Snowbridge, or is there another component?

On privacy guarantees:

  • Are deposits fixed denominations or variable amounts?

  • What protections exist against timing correlation between deposits and withdrawals?

  • Do users interact directly with the contract on withdrawal, or is there a relayer model?

  • How does bridging via Snowbridge affect the overall privacy model?

On PolkaVM performance: Do you have preliminary benchmarks comparing gas costs for Poseidon hashing on PolkaVM vs standard EVM?

On Zcash integration: The proposal mentions ZEC → DOT support. What bridging mechanism would enable this, and is there a timeline?

On network clarity: The proposal requests Kusama Treasury funding for Kusama Asset Hub, but Milestone 3 lists swap pairs as “→ DOT” rather than “→ KSM.” Can you clarify which network this targets and correct if needed?

PixelProof, and the Cost of a Careless Aye
2

Hey @hantoniu-codeberg ,

Thanks for the comment, its easier if you use any of the following platforms to comment directly under the ref(so that all comments can be found in one place and responded to in a fast pace):

https://kusama.subsquare.io/

On the swap mechanism: Where does liquidity come from when users exchange tokens? Is this purely routing through the Asset Hub DEX and Snowbridge, or is there another component?

I think you are misinterpreting this a little bit.

1 - Assethub DEx aka pallet conversion on the Hub only support a certain amount of tokens(you can look up which LP pools are currently deployed on the hub here: Kheopswap) This is only use to swap DOT > KSM. (This means only assets that are registered on the Hub and have a LP pool can be swapped on assethub’s dex, this is a very small list of lp pools here)

2 - yes there is another component, mentioned several times which is opt’ing into a Portugese trading firm, allowing users to bring other assets into dotsama without KYC/annoying sign ups: Swap 60 different tokens straight into Dot on the Hub

please note: these are different ways of swapping tokens

  • Are deposits fixed denominations or variable amounts? They are fixed amounts as you can see in v1 proposal but also in the interface

  • What protections exist against timing correlation between deposits and withdrawals? It’s the same model for all ZK shielded pools, malicious actors could potentially utilize correlation attacks but with shielded pools it all depends on usage, there is no delay functionality built in. As long as there is semi-high usage correlation attacks should not be the biggest threat to users(But In order to get it black and white we have to wait and hear what the audit guy says)

  • Do users interact directly with the contract on withdrawal, or is there a relayer model? The user interacts directly with the contract. a relayer model with shielded pools often refeers to withdrawing via extra steps which is not the case for the first PoC version

  • How does bridging via Snowbridge affect the overall privacy model? Snowbridge has nothing to do with the main functionality which is a shielded pool in the form of a smart contract. Snowbridge is the bridge protocol that Kusama and Polkadot use to talk to eachother it has Nothing to do really with the smart contract on Kusama AH. Snowbridge is used by the dapp to allow users to send DOT to KSM on Kusama AH. Think of bridging and swaps as extra features to make it easy for user to convert into KSM.

On PolkaVM performance: Do you have preliminary benchmarks comparing gas costs for Poseidon hashing on PolkaVM vs standard EVM?
There is a benchmark on the frontier EVM I could find and send you, please also note that the solidity Poseidon implementations where very hard to test since the contract size has been cap’d, they are suppose to 10x the allowed contract size so things might have changed, will look this up and attach as a comment

On Zcash integration: The proposal mentions ZEC → DOT support. What bridging mechanism would enable this, and is there a timeline? Please read above comment, this was shipped already(Free of charge to the treasury as it was not covered by the v1 proposal and no retro active funding has been requested) and users has been able to swap ZEC > DOT for over a month now. On another note on Zcash, we have actually had several Zcash developers/community members look at Kusama Shield and they are very positive towards Kusama doing more privacy stuff

On network clarity: The proposal requests Kusama Treasury funding for Kusama Asset Hub, but Milestone 3 lists swap pairs as “→ DOT” rather than “→ KSM.” Can you clarify which network this targets and correct if needed?

To clarify the goal of the swaps is to provide an easy to use on-ramp into Kusama ecosystem. Practically there is a lot more liquidity and support for the DOT token so in practice users go from > DOT > KSM. This can be abstracted more in the future to say “Convert/Swap directly into KSM“ in the future. To be super clear: what we mean by Milestone 3 is provide extensive documentation for the swapping feature for example to cover Bitcoin cash guide on the docs pages(https://kusamashield.codeberg.page/) we would write a how-to guide displaying a user using a bitcoin cash wallet and swapping using the main UI into DOT and then into KSM. The goal of all swaps is to onboard people into KSM. It might be confusing as we write into DOT and then KSM.

ps.

There is a 30minute explainer video posted in the comment for the ref that tries to straighten out and paint a more clear view on features

Thanks for your comments

3

Thanks for the quick and transparent response — really appreciated.

I posted here rather than Polkassembly/Subsquare because the Forum is a moderated space with clear guidelines, and threads are easier to follow. The proposal is aimed at stakeholders deciding on funding — I’m not here in that capacity. I hold some tokens, but mostly I’m trying to understand the project and its vision. And I like what I’m seeing — there’s real potential here if it’s designed right.

A few things I’m still curious about:

On relayers — Is this on the roadmap? Without it, withdrawal addresses interact directly with the contract, which limits privacy. Curious what the reasoning is for not including this in v2.

On decentralized swaps — The external token swaps currently run through a centralized partner, which exposes metadata on entry. This matters for any token, but especially for someone choosing to swap ZEC — if they’re reaching for a privacy coin, they probably care more about that aspect. Are there plans to integrate decentralized cross-chain protocols (NEAR Intents, THORChain, etc.)? Beyond the privacy benefit, this could also put Kusama Shield on the radar of users in those ecosystems.

On communicating privacy levels — The planned k-anonymity score is a good start. But it might be worth expanding it to flag structural limitations too — centralized on-ramp, no relayer, visible bridge transactions. Users with critical privacy needs should know where things stand before transacting.

On the audit — I understand it was moved out of this proposal pending possible ZK bounty funding. Is there a rough timeline or fallback plan? For a tool handling real assets, this feels important for user trust.

Also looking forward to seeing the PolkaVM benchmarks when you have them — the gas efficiency claim is one of the more compelling parts of the proposal.

4

On relayers — Is this on the roadmap? Without it, withdrawal addresses interact directly with the contract, which limits privacy. Curious what the reasoning is for not including this in v2.

Yeah there is even a proof of concept of this having the shielded pool deploy a contract which gets a new address every time and then going to the user.

On decentralized swaps — The external token swaps currently run through a centralized partner, which exposes metadata on entry. This matters for any token, but especially for someone choosing to swap ZEC — if they’re reaching for a privacy coin, they probably care more about that aspect. Are there plans to integrate decentralized cross-chain protocols (NEAR Intents, THORChain, etc.)? Beyond the privacy benefit, this could also put Kusama Shield on the radar of users in those ecosystems.

The assethub dex is currently a decentralized alternative, I understand that more swap pairs should me migrated, atm there is very little metadata that gets taken from the user(for example IP address, user agent, session/cookie data is NOT STORED). Thorchain does not offer as many swaps but this is something we are actively looking into, we want to make it really useful and have therefor semi centralized some of the swaping features for now, if there is better alternatives we will absolutely switch. NEAR Intents(https://near-intents.org/) does not support DOT, which kind of a blocker. Ideally we want to integrate with zkp2p for offramps and after talking with zkp2p, we are waiting for DOT to be integrated with near intents.

On communicating privacy levels — The planned k-anonymity score is a good start. But it might be worth expanding it to flag structural limitations too — centralized on-ramp, no relayer, visible bridge transactions. Users with critical privacy needs should know where things stand before transacting

One could go really far and say that your connecting to nodes via your regular socket/connect and therefor all websites in the world should be marked as not private. It’s something we can add a page on the documentation page about.

On the audit — I understand it was moved out of this proposal pending possible ZK bounty funding. Is there a rough timeline or fallback plan? For a tool handling real assets, this feels important for user trust.

Yes! The audit has been planned since November and now we get some type of clarity. If the ZK bounty does not approve the audit cost(which we’re asked to take out of the proposal) the backup plan is to have a top up ref. the estimated timeline on the audit is Q2-Q3 this year

5

Thanks for all the detailed answers — this has been a really helpful exchange.

Good to hear the relayer PoC exists, and that NEAR Intents / zkp2p are on the radar once DOT support lands. The minimal metadata approach with the swap partner is also reassuring.

One gentle pushback on the privacy meter point: I understand you can’t solve every layer of internet privacy, but I’d frame it differently. The Zcash engineers take the approach that privacy fails if any link in the chain is weak — it’s not about perfection, it’s about being honest with users at decision time. A documentation page is helpful, but an in-UI warning at the moment of transaction (“your entry used a centralized on-ramp” or “no relayer on withdrawal”) would help users with critical privacy needs make informed choices. Just a thought.

Looking forward to using Kusama Shield and seeing it succeed. There’s real potential here.

1 Like