Proposal #8: Governance upgrade: Lock user funds in separate vault

Proposal #8: Overview

Problem statement

The governance contract holds at the point of writing around 274,000 TORN tokens.

These TORN tokens may come from multiple sources:

  • TORN locked by users.
  • TORN released from the vesting contract.
  • TORN accidentally sent into the contract by outside users.

Mixing TORN locked by users with the last two leads to inconveniences and issues:

  • Governance can vote to use locked TORN.
  • Amount of vested / locked TORN has to be calculated by looking into transaction history.

For this reason, a governance contract upgrade is required.

Proposal specification

The proposal will solve the above problem by separating user-locked funds into a dedicated vault contract.

Steps in executeProposal():

  1. An implementation of the new GovernanceV2 contract is deployed.
  2. The LoopbackProxy logic is upgraded to the GovernanceV2 logic. Governance is its own proxy admin so it calls this function on itself.
  3. Governance now deploys the new vault, which can only be deployed once.

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.


Migration happens only once per account, automatically, upon TORN lock or unlock.
This means that funds will be migrated at any point in time after the upgrade, once you lock or unlock some or all of your tokens.

Security considerations

Only the Governance contract may interact with the vault contract, which happens exclusively when a user locks / unlocks TORN.
The Vault contract does not influence governance contract bookkeeping, security stays the same in regards to this.
Migration is ensured to only happen once and cannot be called explicitly by actors.

These contract have not been “officially” audited. The team will examine / has examined these contracts for possible points of failure.
None such points have been confirmed yet.

Submitting the proposal

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

Deployed proposal contract

My credentials

Learning smart contract dev, came into the scene in January (first time I was exposed to crypto), immediately clicked with the idea of programmable chains and started exploring. Interested in computer science in general (studying in another field of engineering), have a very strong C++ understanding.
My intention is to contribute regularly to tornado because I am interested in the technology and speaking to everyone involved with it has been a pleasant experience.
Will post Github below because I can only post 2 links as a new user.


Awesome work from @CommunityDev1337!

This issue was pointed out by the Tornado team before:

This proposal fix a technically in the Tornado governance contract itself. It will minimize making errors with future proposals and allow for more flexibility. Codes looks good and well tested and it was review by the Tornado team.

Strong support from my side!

We still need someone with 1000 TORN to submit the proposal. The address to be used is 0x8d1F583d31a9634C436d2d9E950E0D32ceE1977A as specified above. Reach out on Discord or Telegram if you have questions.

Otherwise, great work from community member @CommunityDev1337. He intents to regularly contribute ecosystem and will be pushing some more Tornado proposals. I would support remunerating his highly valuable work. I will put up a remuneration proposal on snapshot.


Its up, go vote:


Awesome work!
We definitely need more community members like you !

1 Like

I could vote with the TORN already locked in the governance contract but I can’t lock any extra TORN.

MetaMask - RPC Error: MetaMask Message Signature: Error: Ledger: Only version 4 of typed data signing is supported
1 Like

Should be fixed now. Try on f8c15d1 version. Thank you for reporting!


Hello Pertsev, could you let me know what you had to do to fix this issue. We are dealing with this same error from Ledger users.