A Meta-Protocol for Adding New Token Pools

Proposals
#1

Problem:

There are too many “We should add a tornado pool for X token” posts [1, 2, 3, 4]. To approve each one requires a lot of governance overhead (not to mention the shills will never cease to bombard this forum with new tokens)

Solution:

Create a meta-protocol to autonomously create mixer pools when provable market demand is reached

Meta-protocol:

  • Pre-commitment pools can be created with any fixed deposit_amount for any asset
  • Governance decide upon a deposit_count threashold that must be met for any pre-commitment pool
  • Before the deposit_count is met for any pool, committers can withdraw their deposit
  • If/when deposit_count is reached, the pool is locked from withdraws and a tornado pool is then deployed trustlessly and permissionlessly (no need for governance)
  • Once the tornado pool is created, then committers can only make a one way tx which deposits their commitment into the torndao pool for mixing

Example:

  • TORN governance decides any pool can be opened at any deposit_count of 1,000
  • A UNI community member decides to open a 100 UNI deposit_amount pre-commitment pool and make the first deposit
  • The UNI community member spreads the word in the rest of the UNI community
  • Eventually, 999 other UNI holders all deposit exactly 100 UNI into the pre-commitment pool
  • At the 1,000th 100 UNI commitment, the contract can be called by anyone to lock funds and deploy the tornado pool
  • Once locked, committed UNI community members can begin depositing their committed UNI into the tornado pool
  • From here on out, anyone can begin mixing their UNI in batches of 100 UNI

Requirements:

  • A pre-commitment pool contract
  • A pre-commitment pool factory contract
  • A tornado pool factory contract that’s admin-ed by pre-commitment pool contracts
  • An official proposal to codify this
11 Likes
Proposal to Add FRAX as Deposit Asset
Proposal to Add FRAX as Deposit Asset
#2

Here’s a quick prototype of the commitment pool contract

1 Like
#3

This is by far the best proposal I’ve seen on this forum (other than mine of course :stuck_out_tongue:).

You have a great brain ethdev, you haven’t failed to surprise me and the community with knowledge in the last couple days.

1 Like
#4

Ha, thank you kindly @gewitet. High praise indeed :slight_smile:

Grateful to be part of such an awesome community

If this governance-minimized, market-based model gets enough support to become an official proposal, I’d be more than happy to continue working on the contracts

#5

Very good idea. Approval from the community and from the market shall both be necessary parameters for new assets additions.
Overall, less different assets to chose from determines less dilution, thus less is better.

1 Like
#6

Indicatively, which numbers were you thinking of in terms of minimum amounts of

  • … total USD worth deposited
  • … days it stays in the commitment pool
  • … different addresses depositing in the commitment pool
    ?
#7
  • … total USD worth deposited

Total USD is not really the key metric. More like number of deposits. Because anonymity is achieved when enough deposits are made to safely mix without meaningful detection. So for example 1,000 deposits of $10 amounts is just as anonymous as 1,000 deposits of $1,000,000 amounts

  • … days it stays in the commitment pool

Doesn’t need to stay in the commitment pool for any min period of time. The goal of the pool is just to reach the min number of deposits required to create a safe, new Tornado pool. Keeping funds in the commitment pool longer doesn’t further optimize anything

  • … different addresses depositing in the commitment pool

This is actually a good metric to consider because in theory one whale could fulfill all the commitments required to meet the min threshold. Although it wouldn’t be in their best interest to do so, this is still a way for this design to be gamed. But setting a threshold for the min number of different addresses doesn’t solve it either as a malicious whale could just sybil attack it and move funds to various wallet addresses prior to commitment

I did just add a deactivatePool() function that can be called by governance, though, in the event we catch this kind of attack playing out. But it would still be possible for a malicious actor to act quicker than governance would have time to react. Still some other similar failsafe to this could be implemented. Just a matter of figuring out what it is

4 Likes
#8

It’s not necessarily a bad thing if we are looking for a higher TVL in tornado.cash

That whale who gamed the system is the same one who will lose the most in terms of fees and anonimity, it’s just not worth it for them. I will also add that if a project does this to advertise their product it will just be seen by the entire community as a scam, just like every other crypto project that does heavy advertising.

Did you think about a possible limit to keep up the pool itself? If there is no new deposit for 10-20-30 days the pool is automatically deactivated.

It’s safe to say that if there is no new deposit in 20-30 days the anonimity set is likely very poor and there is no organic demand for that asset to be on tornado.

I would start using governance only if there is clear manipulation (ex. 1 deposit every 20 days just to keep the pool up).

#9

Great idea, I would indeed link it to nº of deposits rather than total value.
Thanks @ethdev

1 Like
#10

I came to the forum today to shill my coin for official support. But I like this idea so much that I’ll hold off until this is implemented and there is a better path to support.

1 Like
#11

That whale who gamed the system is the same one who will lose the most in terms of fees and anonimity, it’s just not worth it for them.

Exactly

Did you think about a possible limit to keep up the pool itself? If there is no new deposit for 10-20-30 days the pool is automatically deactivated.

It’s safe to say that if there is no new deposit in 20-30 days the anonimity set is likely very poor and there is no organic demand for that asset to be on tornado.

I would start using governance only if there is clear manipulation (ex. 1 deposit every 20 days just to keep the pool up).

I did not. It’s interesting. However, I’d say that it’d actually be useful to keep a commitment pool open indefinitely as a token might not be popular enough now to create a tornado pool, but it could become popular enough in another two months. Regulating the speed of adoption doesn’t really optimize for anything.

2 Likes
#12

Interesting thoughts @ethdev

Another alternative, still within your idea of a meta-protocol: why not leaving the risk and responsibility back to the proposer?
In a nutshell, imagine something along the line of this:

  1. Tom wants to add his coin CRACKS to the assets listed on tornado.cash;
  2. In order to do so, he needs to buy and burn a specified amount of TORN (e.g. 100 TORN) via a third smart contract;
  3. Once this fee is paid, a commitment pool is seemlessly created by this third smart contract and added to tornado cash dapp UI one row below existing pools;
  4. whenever this pool does not contain a specific minimum amount of deposits from different addresses* (e.g. at least 100 deposits), a red warning message will appear underneath it for users to be aware to use the pool at their own risk.
  5. OTOH whenever this pool does contain the above mentioned, not only the red warning message is removed and users are able to access it as any other pool
  6. additionally, pools can be deactivated manually following standard ad hoc governance consensus protocol

Would love to hear your thoughts.

*: wondering if there’s an easy way to have the dapp not count as unique those deposits coming from addresses which have had transactions with each other

#13

Basically the advantages would be:
a. making the process more seamless would decrease the grunt dev work / attention required once the system has been set up, and also the community could focus on more important things than “let’s list this or this”;
b. creating a first use case for $TORN and making it a deflationary asset.

#14

Thanks @franzhine

  1. In order to do so, he needs to buy and burn a specified amount of TORN (e.g. 100 TORN) via a third smart contract;

I’m not personally a fan of arbitrary, serviceless fees, but if the community wants to introduce fees, it’s always up for a vote. I would just advocate that this proposal starts without a fee included and then if it justifies a fee later, it can be added in a subsequent proposal

  1. Once this fee is paid, a commitment pool is seemlessly created by this third smart contract and added to tornado cash dapp UI one row below existing pools;
  2. whenever this pool does not contain a specific minimum amount of deposits from different addresses* (e.g. at least 100 deposits), a red warning message will appear underneath it for users to be aware to use the pool at their own risk.
  3. OTOH whenever this pool does contain the above mentioned, not only the red warning message is removed and users are able to access it as any other pool

It’s probably best not to have the UI for commitment pools at the tornado.cash domain since people go there with the intent to mix. Commitment pools won’t actually mix, themselves. It would be better to host at another domain

  1. additionally, pools can be deactivated manually following standard ad hoc governance consensus protocol

Just to add some clarity, the deactivate() function should really only be used for technical reasons rather than political reasons. For example, it would need to be used in the event that a commitment asset carried with it an unaccounted for externality. One such asset might be cDAI, which liquidity mines COMP tokens. If a commitment pool triggered an off-the-shelf cDAI Tornado pool, it is possible that a bunch of COMP could go to complete waste because the Tornado pool wouldn’t have the proper functionality to manage the COMP. In that scenario, governance could deactivate() the cDAI commitment pool to custom code a cDAI Tornado pool that is capable of handling COMP distributions

Basically the advantages would be:
b. creating a first use case for $TORN and making it a deflationary asset.

As an alternative to just a straight user fee to create deflationary pressure - and returning to the cDAI example above - if governance custom coded a cDAI pool, then COMP rewards could be split with users and a % could be used by governance to buy and burn TORN. This would be a nice justified, service-based fee that is a win-win for users and governance. Users get additional yield. And governance get paid for putting in the work to make this possible

wondering if there’s an easy way to have the dapp not count as unique those deposits coming from addresses which have had transactions with each other

Unfortunately, not in real time at the contract layer

There could be a meta-data layer that would need to be submitted and checked between hitting the deposit_count threshold and locking the commitment pool. But keep in mind this could accidentally target two genuine tornado users who just so happen to have sent coins to each other.

2 Likes
#15

Fair enough.

I see - so the only participants to these pre-commitment pools would be those pushing the proposal but access to standard users would be granted only on a second stage. Sounds right.

Thanks for clarifying, makes perfect sense.

Excellent idea.

Hmm I see, not possible at the contract layer. Great idea about the possibility of doing it via a meta-data layer between deposit_count threshold and commitment pool locking; wouldn’t be too fuzzed about false positives as in the big pictures those wouldn’t account for more than 1-2%; what we don’t want is several deposits from different wallets all coordinated by a single bad actor.

#16

Why would you need a commitment pool ? To show sufficient interest in the token ? It’s gameable by anyone, just sybil attack.

After all, the contracts are open source. It’s pretty easy for anyone to deploy a new pool for any token. Then it’s just a matter being listed in the front-end.

#17

Well - I would say something is better than nothing though, and some anti sybil attack measures such as the one discussed in the latest posts (i.e. screening out from deposit_count concentrations of addresses overtly interacting with each other via pre-screening on a meta-data layer) could make it perhaps not impossible, but at least highly uneconomical for a bad actor to orchestrate one.

#18

Why would you need a commitment pool ? To show sufficient interest in the token ?

So that if a new tornado pool is opened, it is generated with a sufficient amount of initial deposits to ensure a minimal amount of anonymity. Commitment pools solve the cold start problem for any new tornado pool, regardless of if it’s hosted at tornado.cash or not

It also alleviates the burden on governance of having to debate “should we add X token?” repeatedly on the forums. The only thing governance should be concerned about with respect to new pools is if they are anonymous enough to uphold the integrity of the protocol

Lastly, it gives new tornado pools a trustless, streamlined way to get whitelisted to work with our community-curated list of relayers

It’s gameable by anyone, just sybil attack.

Again, the goal is just to create a new tornado pool with enough entropy to ensure sufficient anonymity for real users. If entropy is achieved by a whale introducing a majority of the initial liquidity, that’s okay

Only time it wouldn’t be okay is if a whale made all the deposits (from one address or many connected addresses) and then withdrew them all to the same address. This would leave real users immediately stranded (granted they could just withdraw funds to their original address and be back to where they started, but the UX would be terribly frustrating and expensive)

This is why it’s worth discussing a proper failsafe, which could potentially be resolved with meta-data + TORN staking

After all, the contracts are open source. It’s pretty easy for anyone to deploy a new pool for any token. Then it’s just a matter being listed in the front-end.

Then why do we need to do any governance at all around new tokens if people can just make their own tornado pools? If we’re only voting on what gets added to the front-end without any actual coordination contracts, then isn’t this all just costly governance theatre?

3 Likes
#19

One thing to keep in mind is how it would work with relayers. Relayers take fee in pool asset and also have functionality to exchange a fraction of deposit to eth. If arbitrary coins can be added we need to ensure that relayers are not exposed to the coin price volatility.

1 Like
#20

This is actually a really good point

What are the options here?

  • Relayers must opt in to each asset pool manually
  • Relayers add a uniswap interface to receiving their fees in their preferred asset
  • There is not one list of approved relayers for all asset pools but a list of relayers of each set of asset pools