Proposal #989 Community Pool Spending Proposal For StarShuffler

Hub Proposals Community Spend
1

Related Posts

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 about me stealing funds without delivering a product. I haven’t gotten a response from @Mag yet as to whether he would support this. Him and I have had a call regarding another project so we have had prior communications.

I would be asking for 3300 $ATOM to develop the contract, relayer, and FE. The milestone completion time will vary depending on permissionless CosmWasm Hub integration time, and this timeline will assume that that occurs sometime mid-year.

Update 02/20: This will not be proxied due to the nature of the technology being developed.

Milestones

  1. Create working MVP on Juno mainnet (or testnet) which includes a working frontend, relayer, and smart contract. This milestone is contingent upon demonstrating a successful deposit and withdrawal, along with the code being open-source. Disbursement is 2000 $ATOM. Estimated timeline - 2 months from proposal approval.

  2. The smart-contract is ported over to $ATOM and instantiated. Disbursement is 650 $ATOM. Estimated timeline - 2 weeks post permissionless CosmWasm integration onto the Hub.

  3. Integrate multi-amount pools (e.g., 100 & 1000 ATOM). Estimated timeline - 2 weeks post milestone #2.

This effort will produce a usable app for the Hub and is relatively low-cost. It is also low-risk as I am proposing a trusted third-party disburse funds based upon milestone completion. Consequently, if I fail, the funds can simply be returned.

I am currently designing the contract as feeless. Relayer deployment will have the option for fees for sustainability if community members want to run relayers. Why not build the fees into the contract? Principally liability, but also some personal ethics.

Audits are where the serious money comes into play; I have been quoted upwards of 20k for simple audits. Therefore I have no current plans to contract an audit, and an audit would only be conducted with community support at a later time. Please let me know if the community is amenable to the idea.

Recipient

Ideally an Interchain labs wallet. Ultimate recipient is reasonant

Update 02/18: I have not been able to reach @Mag or another Barry either here or on X (Twitter). If I don’t receive any contact from them, the proposal obviously cannot proceed with their proxy, so the proposal will use the recipient address of cosmos145q97pk7hsu6zzsqtkjttlnpk90h9g6y3wzhn3.

Update 02/20: After discussing with Mag, he/they will not proxy funds due to the sensitive nature of the technology being developed. Therefore the funding address will be cosmos145q97pk7hsu6zzsqtkjttlnpk90h9g6y3wzhn3.

Amount

3300 $ATOM

Forum post link

IPFS link

To be created.

Governance votes

The following items summarize the voting options and what it means for this proposal:

YES - You support the community pool funding this dApp and the manner in which it is proposed.
NO - You do not support the community pool funding this dApp or the manner in which it is proposed.
NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.
ABSTAIN - You wish to contribute to quorum but you formally decline to vote either for or against the proposal.

5 Likes
2

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

2 Likes
3

Thanks Tagu! So while all implementations vary slightly in exactly the way their execution flow works, the basic implementation is the same.

  1. 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.

  2. 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 execute the withdraw message yourself it links the interacting wallet with the recipient address, which is undesirable. So the relayer conducting the execution protects this.

With this system, the withdraw process proves that the withdrawer has a right to withdraw, but it does not link the withdraw from the specific deposit. The whole thing is obviously a bit complicated, and cryptography research is quite different from implementation. So let me know if you need me to drill down on any point further if it didn’t make sense.

4 Likes
4

I am firmly in support of this proposal.

  • affordable
  • effective
  • fun
2 Likes
5

The proposal is now live!

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

1 Like
6

Polkachu votes no:

image
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!

7

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

2 Likes
8

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?

2 Likes
9

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

10

Thank you for your support!

11

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 one depositor to that. Now, those tx’s are “tainted” in the set since they’ve been figured out. Same thing applies to StarShuffler. One depositor and one withdrawer is obvious. Bigger set = more privacy.

So the main benefit of StarShuffler is marginal gains in privacy related to value correlation attacks. However, it is also cheaper since there would be no fees (vs Penumbra’s DEX fees) and you don’t have to deal with IBC. Therefore I think StarShuffler is simpler to use.

As far as Secret goes, I don’t really know how to assess their privacy guarantees going from the abstract to reality. There was the infamous consensus seed issue, but that’s been resolved. Not much more to say on it, SGX ya know. But again, native ATOM vs moving into sATOM is an ease of use advantage for StarShuffler.

2 Likes
12

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.

13

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.

14

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

2 Likes
15

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.

1 Like
16

Appreciate it! Should take all but 30 seconds (:

17

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
pro-delegators-sign

3 Likes
18

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.
1 Like
19

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.

3 Likes