Lottery and Vault Proposal Discussion

Hello to the community!

I am in the final stages of review for the new governance proposal. As such I wanted to get the discussion kickstarted with the community about this proposal due to the fact that there are several parameters the community should decide and give feedback on.

EDIT: I updated the repository influenced by discussion, please check the following post and keep it in mind while reading.

General information

The Vault and Lottery Proposal, which is looking to be 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.

  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 the lottery upgrade. Users will be automatically signed up for a lottery when voting on a proposal. Lottery rewards will be in TORN.

  4. The voting period for governance proposals should be extended due to governance problems with reaching quorum.

A documentation on the most important parts for you as a community member of changes 2. and 3. can be found in this readme.

Specifics to each point

These specifics are necessary for you to understand what feedback I will need from the community.

  • In regards to point 1 (from above) I have created a readme file, in which you can find the dune scripts/js scripts we 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 and 3 of the proposal, there are several parameters to cover. I will discuss them in the section below.

  • In regards to point 4, 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.

Lottery and gas compensations

This is the main part of the part proposal. There are several parameters associated with this upgrade I would like your input on:

  1. I would like your feedback on the per-proposal TORN rewards for at least a few upcoming proposals. I have thought about the rewards being in the dollar range of 1000$ and then towards 5000$ approximately. Note, that there will be multiple winners per proposal which will be decided with random numbers provided by Chainlink VRF.

  2. In order to compensate gas for voters, Governance will have to acquire Ethereum by auctioning off some TORN. This is to be seen as Governance deciding on some number to auction off in order to help itself pass proposals through incentivizing voting. This will be done through a Gnosis Auction. You can familiarize yourself with the parameters involved with this readme file. For us of interest are the 6 parameters which the initializeAuction function of the auction handler takes.

  • Most importantly, I would like to know how much TORN the community would be comfortable with auctioning off, what minimum price the community would like to set for the TORN, how long the auction should last and what the minimum amount of Ether is we would like to receive in order to have gas compensations at all. I would also like your opinion on the amount of winners a lottery should have.
  1. I would like your input on the per-proposal gas compensations, since above we auction off a total amount of TORN for a total amount of ETH, I would like to know how much you would like governance to compensate per proposal.

Suggestions and template

These are a few suggestions for what I think are acceptable sample numbers for this proposal. Below you will find a pseudocode-like table which should bring you closer to the actual values being used.

Starting with the voting period.

votingPeriod = 6 days (any time unit goes)

Continuing with lottery and gas compensations

numberOfWinners = 5

perProposalRewardInTorn = 5000$

amountOfTornToSell = minimumAmountOfETHFromAuction/minimumTornPriceInEth

timeAuctionLasts (any time unit goes) = 5 days 

minimumTornPriceInEth = currentPriceInEth*0.5

perProposalETHAmountForCompensations = 0.95*1.4 eth

minimumAmountOfETHFromAuction = 10*perProposalETHAmountForCompensations (== 12.6 eth)

The above parameters are not final, represent my model ideas, and will primarily be influenced by your opinions.

When it comes to the amount of ETH I think will be necessary to compensate each user, I have used this dune query to determine how much in average ETH has been used on a proposal for voting.

Note, that due to the registration function the average gas cost will increase. Thus, I have multiplied the average amount of ETH used for gas on a proposal (0.95 ether) with a coefficient to bring us closer to the real value. I have found that a coefficient of 1.4-1.5 should be sufficient to compensate the increase in gas usage plus the increase from more voters alone, since when looked at closely, most passing proposals have a total ETH gas usage below 1 ether (dune script).

Feel free to copy this template and enter your suggestions below. I will then collect the suggestions, calculate mean values, see what can work (since some of the parameters interact) and present this data to you further.

Repository and test deployment

The entire upgrade repository:

You can find a verified proposal deployment as an example here:

These values are obviously not final and I will deploy the proposal on mainnet once we have agreed as a community on the parameters involved.


Thanks @CommunityDev1337 for the Hard work!

First, I love the new approach of the vault migration. It’s strictly superior and more gas efficient than the previous one. The calculation of the amount to transfer is tricky and we should not get it wrong. Maybe it would be good to run a similar SQL query on Google BigQuery to cross check the results from Dune (They might be missing events, you never know).

Regarding the lottery and gas compensation, I was concerned about the possibility of gaming it by starting many empty proposal just to get some lottery tickets. I guess that’s why you’ve added an admin function for the community multisig to shut down the rewards ? Could I start 10 proposals, be gas compensated + get lottery tickets before the multisig have time to remove rewards ?

Also, you haven’t mentioned the admin functions, could you expand on it ?

What are the security implication of the proposal ? What are the risks ? I guess we’re not getting an audit that one ? I just want to make sure that enough skilled eyeballs have looked at the code :slight_smile:

Last, I am curious why you haven’t considered a simpler approach for voting incentive. We could have done it completely separately from gov by coordinating with the community multisig, committing to reward voters and doing Merkel drops.


Hey, to address your questions.

Results have been cross-checked with js scripts which directly fetch data from mainnet, so from my point of view the data is precise. I will look into BigQuery though and attempt to also cross-check it with that data.

When it comes to this point I made several tradeoffs and also thought about the implications of gas compensation. I should have mentioned it immediately (although it is visible in the governance changes readme): the tornado multisig essentially whitelists (“prepares”) proposals for reward distribution, but only after the proposal has finished. This means that any proposal can retroactively be whitelisted for reward distribution, and that you DO NOT have to necessarily know if a proposal will be compensated or not, and also that invalid proposals will never be whitelisted unless multisig is malicious. This is specifically done this way to avoid the above problem. You can find the function in question here.

An option would have been to allow governance to do the same, but in this case, this would have implied such an overhead on reward distributions, that it would not have made sense to implement them at all (governance would have to vote on each reward distribution for retroactive proposals, or wait for another proposal to include it with these ones, which would also imply using twice the gas).

When it comes to gas compensations and using them, first of all multisig can add and withdraw the amount to compensate. Yes, actors may elect to multiaccount for various reasons (this is the tradeoff of having a trustless system, a fair lottery is mathematically not possible). These parameters above are important exactly due to this fact. If we spot malicious behaviour, we can decide to punish it by not rewarding for a proposal.

E.g., we can say, for this proposal, we are compensating gas, and we are maybe doing a lottery. Let multiaccounters bet on the outcome. We can also say we are doing a lottery, but not compensating gas. Let them then pay their gas fees. We also don’t have to compensate all of the gas at once, we can set some number and if someone reports it isn’t enough, or we just see it, just add more later. We also mostly don’t care about small scale multiaccounting, mostly just large-scale.

Do keep in mind that we can elect to compensate less gas. There is an extra parameter for the compensateGas modifier which takes into account function call gas (still doesn’t add up to 100%).

Do keep in mind that I work with a “relatively” low amount of funds for a reason.

Essentially, if we all cooperate we can get the best outcomes, and we most importantly definitely draw attention to governance voting.

Because this is not really the idea of what I am working on. I have worked on a governance upgrade that can as trustlessly as possible incentivize voting on-chain, while specifically also trying to reward smaller voters. If the community wants to incentivize voting in a different manner, then we will find out in this discussion, but the point is that merkle drops, rewards by multisig and voting rewards (as in repeated voting you mean?) can also be compensated, but it either does not cover all our voters (those that vote but do not engage) or is gameable.

Lastly, the governance contract is undergoing an audit and the results will be published.


The proposal requires the multisig to be quite involved (Monitor for malicious behavior, decide when to take action against malicious actors) It’s also in full control of when to allocate the lottery rewards and how much. That’s why I was thinking of doing it fully off-chain. Pick random voters and send rewards (Since it’s anyway almost in full control).

But the gas compensation mechanism is very useful. We couldn’t have done that off-chain since Merkle dropping small amounts does not work because of the cost of claim.

Regarding the parameters you are proposing they seems reasonable to me. Only the 6 days voting period seems a bit long to me. I actaully think that the current 3 days is fine. It’s in line with what most other Defi protocols are doing.


In regards to this, simply for the reason that we have had governance proposals not reach quorum I see no large negative tradeoff with making the voting period longer. If at any point we would need to pass multiple proposals quickly, it would be possible to do this by proposing it from another account.

I agree.I suggest that each time the group votes, the group should promote the benefits of voting for TORN token holders.
l look forward to an update in the upcoming versions of the interface and user guide. Along with that is the effective use of the TORN token.

I’m not a fan of lottery in general. I already do vote but I wouldn’t be incentivized to vote more especially if gas is expensive if I’m not guaranteed to be compensated for it.


Noob here, but it seems to me “lottery” and “governance” shouldn’t be mixed.

Multisig decides if compensations happen or not. The first few proposals would most definitely have compensations.

Most logic when it comes to lottery is delegated to specific contract. Registration function is only necessary part of lottery logic which governance has to call.

Thanks for this @CommunityDev1337

I’m not technical and I’m sure there’s more peeps like me so for our sakes can you just break down the following:

  1. in the linked proposal #8 you said

why is this an issue?

  1. is this a full compensation for every vote? I got a 404 when clicking the readme file and am still getting my head around the template.

  2. maybe we should extend the voting period once we see that loads of proposals have low activity. Not passing might be a signal from the community to keep things as is. FWIW I prefer members improving their proposals (like you’ve done) rather than extending the time.


Right, I am going to paste an update shortly since I’ve opted to:

  1. Change repository structure a little bit.

  2. Separate out gas compensations + vault from the lottery, based on feedback.


Alright so a couple of updated, the default branch of the repo is now only-vault-and-gas:

The naming of the repository is off right now but let’s keep it this way for the moment at least. I can seperate this out into a completely new repository later.

The lottery functionality is NOT present right now and also there is a modification to how compensations work, basically, it only compensates up to quorum votes and not further. Please give me your input on this change and what you think about it. Most of the other logic stays the same.

So basically, now, we only compensate gas and have no lottery and furthermore, this will also be used for other use-cases of functions governance could have in the future for upgrades to the protocol.

The vault upgrade is also still in effect.

Once we have some discussions going about this the Proposal contract will be deployed on mainnet and viewable.


It would still be nice to receive more input on the parameters. I will post tomorrow and more thorough explanation on them. But for starters, let me refer to this file again:

And let me also post the related files for this branch:ž