Proposal #9 - Governance Vault and Gas Upgrade

Proposal #9: Overview

Introduction

This proposal contains a governance upgrade part of which has been proposed in Proposal #8. The other part introduces new functionalities, all of which will be explained in this topic.

Please check below under Submitting the proposal for the recommended submission time!

Problem statement

These are the problems this proposal attempts to solve.
First the problem statement from Proposal #8:

The second problem is that Governance has is that due to the current state of the Ethereum mainnet, voting is expensive. This is for the reason that numerous operations have to be conducted with high basefees due to activity on the network. This discourages voters from voting and thus we receive a lower voter turnout.

The final problem is the voting period. A voting period of 3 days may be too short for voters to even notice that a proposal is going on, so again we do not receive a large enough voter turnout.

General information

The Vault and Gas Proposal, Proposal #9, includes two upgrades to the Governance contract plus a parameter change:

  1. The first upgrade is the vault upgrade, repeating it since Proposal #8 failed to reach quorum. This time around the vault contract is more optimized since I have decided to calculate (by use of scripts fetching data with rpcs and with dune analytics) the amount of TORN locked by users via governance proposal TORN outflows. This means users won’t have to migrate funds, and instead the upgrade will transfer the exact amount of user funds locked in governance into the vault contract (see below).

  2. The second upgrade to governance is the gas compensation upgrade. This upgrade enables Governance to compensate transactions for selected function calls directly in Ether.

  3. The third “upgrade” is changing the voting period for governance proposals.

Specifics to each point

These specifics should explain the parameters and concepts behind the aforementioned Governance upgrades better.

  • In regards to point 1 (from above) I have created a readme file, in which you can find the dune scripts/js scripts I used to find governance outflows and accidental transfers to governance. By the formula, mentioned in the readme, we calculate the amount of TORN to transfer to the vault.

  • In regards to point 2 of the proposal, I will cover this topic below.

  • In regards to point 3, the current voting period is at 259200 seconds (== 3 days). I would like to further extend this to allow participants more time to vote on the proposals, to 5 days. This value is retrievable from the public getter of the proposal contract.

Gas compensations

The governance upgrade comes with the functionality to compensate gas on castVote and castDelegatedVote operations. This means, that once you vote most of the amount (not all of it!) should be directly compensated to your account in ETH after you vote. You will not break even but you will pay much less gas.

In order to receive the ETH needed for the compensations, the proposal will initiate a Gnosis auction which will auction off some TORN in exchange for ETH.


Treasury considerations

Some may be concerned about the impact on the TORN price. With an amount of TORN that equals say 15 ether, this can have an impact of at most (based on the current market cap at evaluation) 0.05%. This means you would see a price change of -0.031$ per TORN approximately. TORN fluctuates by more than a dollar each day, so this is absolutely negligible.

Further, a question is also what percentage of TORN this is from the Governance budget (this is the exact reason why we need to separate the vault from governance, because it makes calculations like these harder). Thankfully, when considering the dune query script above then we know that Governance holds approximately 260444 non-user TORN.

The plan would be to auction off 787 TORN. This is approximately 0.3% of the funds available in governance. And equals a little more than 14.2 ETH.


Auction

In order to incentivize users to use the Gnosis Auction, the initial price of the auction has to be lower, so that users opt to bid on the auction in spite of the gas prices on Mainnet. Multiple parameters have to be in fact, set, please familiarize yourself with them by reading through the following readme.

In the case that the funding threshold is not reached, all changes revert and the TORN is sent back to Governance (over the auction handler).

Exactly these parameters can be seen here, and also in the deployed contract itself.

The tl;dr of it is, to incentivize users to engage with the auction, I advise a discount be set on the TORN of a little over 20%. I expect this discount to not last and the TORN to be bought for a larger sum, due to users bidding larger amounts of ETH for it.

Note, that once set an order cannot be canceled and the ETH will be transferred immediately to the Gnosis EasyAuction.

Gnosis EasyAuction is an audited auction contract that has been used for multiple token auctions of other projects.


Security considerations

Gas is compensated on castVote and castDelegatedVote actions. The tornado multisig can set the compensations to be available or not, and also which amount is available.

As discussed in this thread, it is not possible in any decentralized system with non-kyced (or using another identity system) customers to prevent multi-accounting attacks. It is to note that actions we would be compensating on can be used to burn the gas eth for compensations.

On the other hand, there is no possible permissionless system where such an attack is impossible given these functionalities, so in essence, we are attempting to allow permissionless gas compensations given that all actors cooperate.

If, say, governance would find that not all actors are cooperating, we may pause compensations, but opt to keep the compensations logic around for future uses, and simply use the logic in a next governance upgrade. In short, we can downgrade the logic back to non-compensations again if necessary.

It is in the best interest of actors to act in a profitable way, as such, if all actors act to maximize their own profit, then the system will work.

Given the amount of funds at risk is low (0.3%), I deem it acceptable that governance considers this option of voting incentivization.


Proposal specification

The proposal will implement the above upgrades by executing the following steps in the executeProposal() function:

Steps in executeProposal():

  1. A new Tornado Vault contract is deployed.
  2. A new Governance object and its address is directly fed into the upgradeTo(address) function of the LoopbackProxy.
  3. The new voting period is set.
  4. The total amount of TORN locked is calculated by the use of the total TORN outflows from governance due to proposals.
  5. The TORN is transferred to the vault.
  6. A new AuctionHandler contract, which obeys Governance, is created.
  7. TORN is transferred to the contract, and an auction is initialized.

This solves the locked / vested TORN dilemma from above. Funds falsely sent to either of the contracts are not accounted for to keep changes minimal.

General security considerations

Only the Governance contract may interact with the vault contract, which happens exclusively when a user unlocks TORN. The Vault contract does not influence governance contract bookkeeping, security stays the same in regards to this.

Gas is compensated using the send() function, forwarding 23000 gas making reentrancy impossible, and downgrades to the standard governance logic if send() fails.

These contracts have been audited. You may find the audit report here.

Since the audit the only changes made were:

  1. Setting the parameters for the auction.
  2. Updating readme files.

Github

Submitting the proposal

Somebody with TORN >= proposal_threshold should submit the proposal with the deployed contract address.

EDIT: For anybody proposing, don’t propose before Sunday due to low voter turnout on weekends.

Deployed proposal contract

The proposal contract:

Torn Vault which will hold user funds:

3 Likes