Proposal #989 Community Pool Spending Proposal For StarShuffler

Related Posts • 2025-02-07 - Create first discussion post • 2025-02-10 - Create second discussion post Change log • 2025-02-11 Created initial post • 2025-02-12 Correct Forum post 1 link • 2025-02-18 - Add Alternative funding address since I have not been able to reach @Mag or Barry to proxy for milestone completion. • 2025-02-20 - Update funding addressing after discussing with Mag that they cannot proxy this effort due to the nature of the technology being developed. • 2025-02-25 - Proposal went live. Summary I am requesting 3300 $ATOM to build the smart-contract, relayer, and frontend for a ZK “mixer” for the Cosmos Hub. It will be called StarShuffler. If the community is open to this, I intend to put up the onchain proposal February 25th, 2025. Details This proposal would cover creating the smart contract, a minimal FE to interact with the contract, and a relayer, along with making the FE and relayer deployable as a docker container for self-hosting / Akash deployments for privacy. Ideally, the community pool funds would go to @Mag or another trusted third party who can disburse funds upon my milestone completions, assuaging community concerns…

Excerpt (1194 of 5276 characters). Read the whole post on the forum ↗

Could be nice to elaborate a bit more on what is it exactly for the ones who are not familiar with Juno Juicer or ETH TC

Never the less, I’m supportive because of the milestones approach and because I can feel you’re dedication. Would love more info though

Thanks Tagu! So while all implementations vary slightly in exactly the way their execution flow works, the basic implementation is the same. • A user generates a client side proof that returns special data to them (nullifier hash) which can later prove that they have the rightful ability to withdraw from the contract with, and creates a commitment message which they store on the blockchain along with sending the funds. Here’s an example of what that deposit message looks like on chain . • Users create a withdraw message (handled by FE) in which they include the nullifier hash, who they want the funds to go to, the relayer the transaction should go to, and previous builds include the fee: ``` msg.root.clone(), msg.nullifier_hash.clone(), msg.recipient.clone(), msg.relayer.clone(), msg.fee, ``` This message is designed this way so that even if the message was intercepted, it wouldn’t lead to loss of funds since the relayer and desired recipient are built-in as part of the ZKP. 3. The transaction is sent to the relayer which actually executes the message. There is sort of a debate about the criticality of relayers, but they are standard practice. The idea is if you…

Excerpt (1195 of 1728 characters). Read the whole post on the forum ↗

I am firmly in support of this proposal.

• affordable
• effective
• fun

The proposal is now live!

Feel free to ask me any further questions during the voting period.

Polkachu votes no:

image2043×223 47.9 KB

Just for a public response to their message, as I note above, I did try to broker the deal with Mag but he said they cannot publicly endorse a mixer. I’m not sure what constitutes in their mind suitability for community pool proposal, but the gist seems they don’t think the app is worthwhile since they refer to a nonexistent alternative. Appreciate their feedback regardless!

We will support this proposal, we think that this is a good example of the decentralized governance!

Hey @reasonant, Montagu from Citadel One here.

Imo the ask is reasonable and the idea is cool but can you explain how does this compare vs shielding $ATOM via other privacy protocols, such as Penumbra/ Secret? ie, why would anyone use StarShuffler instead of existing solutions?

why not use USDC from the hub treasury for this kind of financing?

Thank you for your support!

Hey Montagu, thanks for your question. So take this with a grain of salt because this is all up to personal interpretation. I really like Secret and Penumbra and particularly the latter I think Henry has done a great job. Penumbra 1. Deposits and withdrawals. So with Penumbra there are few things. First, depositing into penumbra and out of penumbra are public transactions, so it’s possible to correlate assets if this is done unskillfully. Penumbra’s DEX greatly improves this problem since it’s far easier now to move around assets shielded, making it more difficult to trace amounts. Now, StarShuffler’s deposits and withdrawals are also public transactions, but because the pools are all the same amount (i.e., every tx in one pool is 1000 $ATOM), you don’t have to worry about the issue of breaking value correlation. 2. Timing analysis. So both Penumbra’s intro-exit and Starshuffler’s intro-exit could face timing analysis attacks. No real difference here. 3. Privacy. What will really matter in my opinion of which option ends up more private is who has the bigger set of txs. Think if Penumbra had one deposit, then 50 withdraws after DEX swaps. It’s pretty easy to correlate the…

Excerpt (1199 of 2000 characters). Read the whole post on the forum ↗

Short answer is because I’d prefer $ATOM. I would’ve been open to doing USDC instead, but it wasn’t raised by anyone (unless I’m forgetting) prior to the prop going live.

Thanks for the detailed breakdown!
In my opinion there’s very little need for a mixer on the Hub at the moment as it offers no edge compared to incumbent solutions.
Therefore, Citadel One will be voting against the proposal.

I would , however, recommend resurfacing the idea once/ if the Hub adopts permissionless CosmWasm as it would make more sense with Hub-native DeFi.

Voted yes

Reasoning : it’s a small ask, it will probably not bring dozens of thousands of users from hype, but it could be practical to have. Hub has more daily users than most competitors mentioned. Many of them aren’t IBC global ecosystem users, chasing airdrop, buying NFT, bridging, using Dapps, they just buy ATOM on CEX, withdraw to keplr, stake, claim and vote sometimes… Many could randomly need this privacy service for some reasons and if you tell them to just go there and use your available atom to do this and it takes 3 minutes vs; swapping x or buy x on Osmosis and withdraw to secret, figuring out how to use it… etc

So to clarify in my proposal I discuss how this is in the context of permissionless cosmwasm, which Mag has assured me is coming soon. So this proposal lays out that this app would launch on the hub with permissionless cosmwasm. So if you’d be supportive of the app in permissionless cosmwasm, this is the proposal for that. Due to this, I won’t be surfacing this proposal a second time, as I will have considered the community to have voted against this app with permissionless cosmwasm since it’s integrated in the prop.

Appreciate it! Should take all but 30 seconds (:

On behalf of the PRO Delegators’ validator, we have decided to cast an abstain vote on this proposal, allowing our delegators to make their own informed decisions.

While we find the idea promising and relatively cost-effective, we recognize that the proposed product introduces potential challenges, particularly regarding the legal framework. Given the current lack of clarity on this front, we believe it is most appropriate to maintain neutrality at the validator level, ensuring that every option remains open for our delegators.

We appreciate the initiative and look forward to further discussions as the legal aspects become clearer.

Best regards,
Govmos

Hi Govmos,

Thanks for your thoughts. I do have to ask though:

1. What makes you afraid to be a validator for a ZKP? The government hasn’t taken any action against any penumbra validator, ETH pool, or Monero miner (as far as I know), so where is the risk coming from?
2. What is the point of a permissionless system if we’re too afraid to implement permissionless contracts? Seems like we’re just creating tradfi with a twist for number go up then.

Govmos:

maintain neutrality

While we support the initiative and strongly advocate for privacy within the ecosystem, we believe a neutral stance is the most appropriate course of action. Casting a vote on behalf of our delegators would imply making a decision for them, whereas our approach is to empower them to make informed choices independently. By abstaining, we ensure that our delegators retain full agency in determining their position on this matter.