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
FeeManagercontract would be turned into theFeeOracleManagercontract 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
UniswapFeeOraclewhich 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.
- This would include the deployment of a new
-
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
RelayerRegistryand setting theadminfield toaddress(0). The code is and will be heavily reviewed further to guarantee code correctness.
- This would include an upgrade of the
-
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
InstanceRegistryupgrade to make it simpler and only store instance related data, as mentioned above. - This would include a miniminal
TornadoStakingRewardsupgrade just to switch the address which may call theaddBurnRewardsfunction.
- This would include an
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