[Proposal] Creation of the TrueFi DAO

Proposals
1

Creation of the TrueFi DAO

Authors: @hal @michael.bland

Overview of On-Chain Governance

On-chain governance of TrueFi is critical to putting the future of the protocol in the hands of its users, and is considered the 1st of 3 steps in TrueFi’s journey towards full decentralization. Currently, TrueFi smart contracts are owned by a series of multisigs, and upgrades are decided on via forum discussion and Snapshot voting. stkTRU was chosen as the governance token in order to ensure voters are committed to the longevity of the protocol by locking TRU.

On-chain governance will decide when to adjust protocol parameters or make smart contract upgrades. Important aspects of governance are as follows:

  • Ownership of smart contracts
  • Creating & voting on proposals
  • Executing code on-chain
  • Allowing for delegation and voting using stkTRU

Formal Proposal Process

  1. Forum Post & Poll
  2. Snapshot Signal
  3. On-chain vote
  4. On-chain execution

Anyone can create a forum proposal to encourage discussion and gauge community opinion. Once a proposal appears to gain favor with those interacting with the proposal, anyone can publish a snapshot poll. Forum polling can be voted on by anyone with a forum account while snapshot polling counts votes based on the stkTRU balance of a holder’s wallet. If a snapshot poll signals a positive result, anyone can create an on-chain proposal that contains transaction details for the desired outcome. Of course, anyone can skip these steps and go directly to an on-chain proposal, but it is highly likely that these proposals will be disfavored by the community as they have not been thoroughly vetted.

Forum and snapshot polls are non-binding, while on-chain proposals are fully executed if approved. After creating an on-chain proposal, all stkTRU holders are allowed to vote to execute the transaction payload. If passed, the transaction is queued and can be executed after 2 days.

Parameters

TrueFi DAO governance will use the OpenZeppelin standard Governor smart contracts and Tally front end. Both are industry standards with strong security features. Proposals are created with a set of desired transactions. If a user has enough TRU to meet the proposal threshold of 100,000 stkTRU, the proposal description and transactions are submitted to the Governor. In order for a proposal to pass it needs to meet a minimum quorum vote of 15% of all stkTRU tokens and final approval threshold of 50% of votes cast. If a proposal passes, the transaction is queued in a Timelock smart contract which allows execution after 2 days.

The three threshold amounts will be initially set by the TrueFi core team upon launch of on-chain governance. These thresholds may be changed later if a proposal is created and it gets passed by stkTRU holders through the governance process outlined above.

Parameter Value
Proposal Threshold 100,000 stkTRU
Quorum Threshold 15%
Approval Threshold 50%

Example DAO Actions

  1. Claim proxy ownership of TrueFi LP pools
  2. Establish developer council as owner of tfLP pools (for pause power)
  3. Establish Treasury smart contract
  4. Take control over Incentive Distributors and Farm smart contracts
  5. Give power to DAO to whitelist new portfolio managers
  6. Give DAO portfolio borrower whitelist power to DAO

Proposal: Establish TrueFi on-chain DAO with stkTRU as the governance token.

  • Yes - I support launching on-chain governance controlled by stkTRU holders.
  • No - This proposal needs to be re-worked

0 voters

4 Likes
2

This plan has been very well thought out and is well-defined which is great. I’ve read OpenZeppelin’s Governor contracts and they’re well put together. I’m generally supportive of this proposal, but I think some adjustments would be beneficial.

Proposal threshold

Using a proposal threshold of 100,000 stkTRU - only $7k worth - is rather low and could result in many low-quality proposals. While this may be good to promote innovation and entrepreneurship, decision fatigue is real and we don’t have to overwhelm voters.

Let’s raise this to 1M stkTRU to start off.

Proposal vote delay

I think there should be a voting delay of at least 2 days before voting commences to give time for [additional] discussion. Having experience with on-chain voting and DAO governance, I know it can be quite tricky to get voters to participate in forums discussion, snapshot polling, and even in on-chain voting. This delay allows time for the word to get out that there’s going to be an official vote, and allows time to prepare keys for voting.

Having a delay also limits governance attacks and provides a heads up - we don’t want any malicious or poor quality proposals going to vote, say, at a time when it’s known that key voters may be unreachable.

Proposal voting duration

This is something important to discuss. I think it’s important to move slowly when it comes to smart contracts holding hundreds or billions of dollars. I’m in favor of the voting period being 5 days long to ensure that everyone is able to get their votes in.

Other than that, I’m excited for what’s to come!

6 Likes
3

Thanks for your feedback Tyler!

  1. Threshold: I asked our security team what they think of raising the threshold. I don’t personally feel like there’s a huge risk of spamming, especially considering the gas costs of creating a proposal. Also, when TRU price recovers this shouldn’t be an issue anymore.

  2. Vote Delay: As far as I know, vote delay isn’t a parameter we can control with these smart contracts. The votingThe reason we have a formal process which includes forum discussion and snapshot signal is to ensure that there is time to talk about a proposal before it’s put on-chain. It’s unlikely any proposal will pass unless it has been fleshed out in discussion.

  3. Voting Duration: Similar thoughts as the previous question, I think going with the standard is fine, 5 days might be too long. Having a longer delay slows down the ability to act semi quickly in case there needs to be an upgrade or fix (luckily we have implemented emergency pause functionality for our developer multisig).

Let me know what you think! Parameters can always be adjusted after launch.

2 Likes
4

Thanks for the response Hal!

With the proposal threshold, I think it’s better to be safe than sorry. It can be gradually lowered as the DAO evolves and the cost of reaching the threshold increases.

I still think a vote delay would be beneficial. It’s more concrete and it allows time for voters to get ready if they haven’t been following discussions on the forums or Discord. The more people involved, the harder consensus is to achieve, and not all voters will be able to stay up to date on the discussions, especially as TrueFi becomes more decentralized. This can be set by overriding IGovernor#votingDelay.

You have a fair point on the voting duration. It can both work for us and against us. Disaster recovery is important and having a shorter voting duration will speed this up. Having additional control mechanisms is also essential.

One suggestion I have is to deploy two instances of the Governor contract - one as described in this thread, and another with much shorter durations and higher requirements such as a 2/3 majority, a higher quorum, and a higher proposal threshold. Doing so would allow us to recover from disasters quicker while still keeping things secure.

Correct me if I’m wrong, but I don’t think anyone has mentioned the voting duration. I’m assuming the standard period is 3 days.

1 Like
5

Hi.

I agree with TylerEther and think the staggered Governor contracts are a neat way to solve for disciplined roll out vs agility for disaster recovery.

I believe erring on the side of caution is the right thing to do which will also give more time for the community to reflect, discuss and contribute to higher quality decisions.

I appreciate the path to decentralisation and desire to keep kicking goals and reach milestones but recent events are also a reminder to me of the great Buffet quote “in order to succeed you must first survive”.

We can always dial up the settings once there is a good operating rhythm.

6

if truefi dao approved , it should reduce tru emissions , otherwise the truefi has no future

7

Thanks for pointing this out!

Based on your feedback, we are going to add a 2 day voting delay to the governance contract. This will increase the total time to execute a transaction to 7 days.

As for having 2 governor contracts, we are open to this idea! For now I think it makes sense to deploy one contract. For security purposes, we have a developer multisig setup which has the power to emergency pause certain smart contracts. This gives us the ability to pause contracts immediately, but restrict the power granted to the multisig (e.g. it can only pause/unpause but can’t upgrade)

The final proposed parameters will go up on snapshot today as:

Voting delay: 2 days
Voting period: 3 days
Timelock delay: 2 days

4 Likes
8

Smart contracts are deployed!

Governor 0x585CcA060422ef1779Fb0Dd710A49e7C49A823C9
Timelock 0x4f4AC7a7032A14243aEbDa98Ee04a5D7Fe293d07
2 Likes
9

Snapshot vote is live to establish the DAO:

https://snapshot.org/#/truefigov.eth/proposal/0x129d7c6dfd0cbb36223ff276099b8f54b7e42252000d231935fd808e2f152939

4 Likes