Infrastructure upgrade proposal discussion (pre-proposal, not going live yet)

Soon (this is a relative term), I would like to propose an infrastructure upgrade which will seek to clean and upgrade our infrastructure to achieve the following goals.

  • Multiple oracles: the system will be upgraded to support multiple oracles such that we can react to liquidity conditions and deploy and exchange oracles easily, instead of having to upgrade the FeeManager contract each time. The FeeManager contract would be turned into the FeeOracleManager contract which would support this functionality.

    • In the future, it will be intelligent to transition to Curve’s pools. These offer an inbuilt EMA oracle, and since these are similar to UNIv2 pools, will not cause liquidity fragmentation like UNIv3. Logic is already written for fetching prices from Curve, but this proposal does not contain these parts because we need to make proposals atomic. To be specific, we can currently actually even rely on non-TORN price from Curve, because the logic is ready, but we are not going to be using something like this until the next infrastructure related proposal.
    • This would include the addition of the UniswapFeeOracle which is based on the Uniswap V2 TWAP.
    • Note that one of the goals of this is obviously, to start deploying new instances, for example, LSDs, stuff like crvUSD, LUSD and so on.
  • Better withdrawal mechanics: after the upgrade, withdrawals will have the guarantee that manual withdrawers and third-party (not staking) relayers will always be able to withdraw funds. At the same time, for new instances (these are not going to be added in this proposal, but the code is already done), we use this to enforce withdrawals to be routed through the router, which supports this permissionless functionality. Why? Because, if we can guarantee that withdrawals will never break, which we can with the below, then we can safely enforce instances to demand withdrawals go through the router.

    • This would include the deployment of a new TornadoRouter.
    • Withdrawals on the router have been tested in forked mode, by using precomputed commitment and proof values, from a certain Ethereum block height to guarantee these precomputed values are always valid for them.
  • Registry will be made immutable: the registry is an important source of truth which, if it is not deployed immutably, can not give the above security guarantee. For this reason, a properly written, clean implementation of the registry, will replace the current one, and then the admin slot of the proxy will be set to 0. This is possible by simply taking the computed slot of the admin variable in the proxy.

    • This would include an upgrade of the RelayerRegistry and setting the admin field to address(0). The code is and will be heavily reviewed further to guarantee code correctness.
  • Proper segmentation of duties: the current infrastructure contracts are functional, but are not written as good as they could be written. Numerous functionalities which shouldn’t be intertwined, are. For example, the instance registry should not be storing fee data. The relayer registry should not be calling burn, the router should. Basically, we are cleaning up the logic, making it readable, and better to interact with.

    • This would include an InstanceRegistry upgrade to make it simpler and only store instance related data, as mentioned above.
    • This would include a miniminal TornadoStakingRewards upgrade just to switch the address which may call the addBurnRewards function.

As you can imagine, this is a quite large proposal, but it is connected because the infrastructure itself is connected, for this reason, I am making this thread to introduce to you, and talk with you about the changes of this proposal, it is obviously not going live immediately, since we need to reach consensus.

In any case, for those of you who want to check out code, please check out the following file:

Also the proposal.

Note two things: 1. Deployment scripts haven’t been created yet but this only comes down to simple deployments. Only the router is there. 2. Coverage has to be viewed from browser, by accessing the index.html file. Coverage is not a full representation of test state. This repository is a sub-repository, and some tests have been moved due to other functionality which is not needed for this proposal. In any case, all functions have been examined thoroughly.

In terms of security, I will most likely do another writeup in this same thread, but in essence, I have examined absolutely all security risks, especially in regards to TWAPs (single-block attacks, multi-block attacks (MMEV), flash-loans), and modification of parameters, and I can say confidently that once everything is finalized (soon), that there will be no issues.

So yes, essentially, please feel free to ask questions, check stuff out for now. I mean in my opinion, if we can reach consensus quickly, I know what last checks I need to make and we can go live with this, honestly. So basically, this is a kind of large temperature / vibe check.

Tracking commits after posting thread.

Commit 1 (22/06): Modularize external registry calls and code quality recommendations from Theo
All commits after 1: some code quality upgrades and more registry coverage


excellent improvement. The link to git does not open, 404

Thx, there you should be seeing it now.

Can we get some more input on this from anyone, maybe you again @Promax ? Anyone would like to add anything else?

In any case I’ve pushed some code quality commits and added some more tests, and deploy scripts, and checked stuff out, I can deploy this soon. Happy to hear everyone’s thoughts.

Appreciate all your work.

But I have no ability to fully understand the proposal logic, not to mention review and input idea.

Just hope that more people who could understand those, could review and give comment on that.

I will verify then finally that the logic is finalized and probably have to write more update thread when it comes to inform on necessary code changes if the proposal passes for relayers. It should be one address switch I believe. Also I’ll see if I can make a simpler summary or something for voters.

Sorry for the downtime. There were some issues regarding deployment but that is now gone. Deployment will be going live soon, we only need to handle some few final things. We also had to settle on a design. If you ever doubt whether there is activity, you can always check the Git.


Currently I with T-Hax working on other issues, such as migration to WalletConnect V2 (since V1 was disabled on June 28 and some users encountered a problem on the Tornado website) and a large update to the UI, CLI and relayer software at the same time, related to the correct calculation of gas on the relayer transaction, which will allow output through relayers on the site on sidechains like Arbitrum or Optimism.

Since this proposal requires updating the site (including on IPFS), because the router contract will be updated and it needs to be changed so that user interaction with tornado contracts (deposits / withdrawals) takes place correctly.


Thank you for working very hard

1 Like