With Reflexer progressively moving to a DAO, we need to setup the processes by which the community makes decisions on token allocations, system parameters, etc…
This post is an overview of the potential Reflexer DAO governance process. This post will be updated when the formal on-chain governance of the remaining system parameters is in place.
Phase 1: Signaling
Conditions: none, anyone can start a discussion for a new proposal.
Goal: Start the discussion, evaluate the potential of an idea, temperature check, non binding polls.
Duration: at least one week before moving to the next stage to ensure that people had enough time to give their opinion.
Content: new forum thread with
Abstract
Motivations
Initial Implementation details/specs
Poll (Show who voted to minimize sybil attacks on the polls)
Phase 2: Formal proposal
Condition: successfully demonstrated the interest of the community in the signaling phase
Goal: after the discussion and adjustments from in the signaling phase, write the final proposal specifications post and ensure that enough token voting power supports the idea.
Wanted to give some nuance for the on-chain governance process.
The idea right now would be to use a battle-tested contract like Compound’s Governor Bravo. There are some changes that need to be done to the contract though in order for it to be compatible with ds-pause, which is another contract inherited from Maker.
ds-pause allows governance to schedule a proposal that then needs to wait for a set period of time before it can be executed. While the proposal is under timelock (waiting), it can also be cancelled by governance.
Similar functionality to ds-pause can be found in the vanilla Governor Bravo setup. Once tokenholders vote on a proposal, it has to wait before it can be executed. In order to make ds-pause and Governor Bravo compatible and not have one timelock in Governor Bravo and a second timelock in ds-pause, the Reflexer Governor Bravo will not have any timelock logic and it will instead delegate the timelock responsability to ds-pause.
The second difference compared to the vanilla Governor Bravo is a customizable quorum. 15K FLX might be a fine quorum to start with but as RAI continues to mature, governance might want to increase the quorum. So, the idea is to have a lower and an upper bound within which governance can change the current quorum. This prevents setting the quorum to 0 or to an extremely high number which can prevent any proposal from passing.
Now onto the actual governance process:
When a proposal is created on-chain, it enters a review period (during which the proposer may change their mind and cancel it or at least, the community has time to analyze the proposal)
After the review period, voting begins. As suggested by @AlexPVT, the voting period can last 5 days so there’s plenty of time for voters to decide on how they cast their votes
After the voting period, assuming the proposal is successful (had enough votes to go above the quorum and the majority of votes, meaning 50% + 1, are for), it can be scheduled in ds-pause to be executed after the timelock
As for potential governance parameters, one way it could be set up is as follows:
Minimum quorum: 15K FLX
Initial quorum: 15K FLX
Max quorum: 50K FLX (5% of initial supply)
Vote threshold in order to pass: 50% + 1
Proposal review period: 2 days
Proposal voting period: 5 days
ds-pause timelock: 2 days
Note that even if the minimum or maximum quorum values are immutable, governance may choose to migrate to a completely separate Governor contract. You might ask “but why have the quorum bounds when we can just redeploy the Governor and switch to the new version?” and the answer is that deploying a new governance contract just to slightly change an immutable quorum value isn’t optimal.
The DAO will also have a treasury smart contract holding FLX which can then be spent by tokenholder vote. The code for the treasury contract can be found here.
Note that the treasury contract has a special role called treasuryDelegate. The purpose of the treasury delegate is to perform FLX transfers that may be repetitive and that would not necessarily make sense to have a vote for every single time. An example of a periodic transfer is for RAI incentives which are released on a monthly basis. The treasuryDelegate could be another smart contract that can be called by anyone in order to transfer a fixed amount of FLX to the incentives contract. That fixed amount of FLX can be customized by the DAO, but these changes are expected to be less frequent compared to having a proposal every month for this purpose.
Note though that the incentives contract will need a monthly vote in order to create a new FLX distribution and allow eligible claimers to receive their incentives.
There are a couple questions to answer regarding the treasuryDelegate:
How would the DAO handle bounty payments or periodic payments for DAO members? Allow the delegate to transfer a set amount of tokens every month for this purpose?
What amount of FLX should be transferrable every month by the delegate?
Is a smart contract that automatically transfers some amount of FLX the best idea for a delegate?
The delegate could set up and maintain a monthly budget request based on the prevised costs with monthly operations plus committed bounties for the epoch. This amount can be approved or revoked at governance’s discretion, fixed amount per epoch.
The delegate could be allowed to transfer a set amount of tokens for payment purposes with a set max. value per payment equal to e.g. the biggest bounty/salary for the epoch + a margin, or a function of delegateLeftoverToSpend, to avoid payment of big(er) amounts in case the delegate has made a mistake or has less noble intentions. This combined with the fact that increases in allowance take effect only in next epoch and decreases take effect immediately, the risk would be pretty well mitigated.
The process could be automated, if delegateAllowance would read from bounty list + payment for DAO members list for the current epoch.
Is it possible to set the minimum and max quorum bounds as a percentage or factor of the current quorum? That way they create a sliding scale that moves with the quorum?
I think I’m +1 here for the automated approach, with the DAO able to remove/change the automation.
Another option would be to have major and minor votes. And these operations could be handled by minor votes that might have lower quorum, less lock-up time, or similar.
The gov process looks solid, I’m in favor. Would like to echo the question on voting with stkFLX.
Agree with @goron_dan on setting a max amount of tokens for the treasuryDelegate.
We should also have a process in place to skip snapshot votes and go directly onchain in emergencies(timelock would still be in place of course)
If it’s a popular request, stkFLX is not transferrable but has snapshotting logic like FLX. The easiest way to integrate is to calculate total voting power as your FLX balance + your stFLX balance.
Potentially allow a boost for your stFLX balance because it represents a LP token.
also, i imagine we need a solution to be able to vote using stFLX too, not only FLX
Would like to echo the question on voting with stkFLX.
I would like to propose making stFLX the sole governance voting token for Reflexer.
Here’s what I propose:
update staking to use 80/20 FLX/ETH Balancer v2 instead of 50/50 FLX/ETH Uni v2
Use stFLX as the governance voting token for the Reflexer protocol
stFLX holders have voting power = tokens in their possession at the voting start time (not at the start of the review period) → accounting managed by internal token transfer tracking onchain
Rationale:
it’s annoying as an FLX holder to choose between staking FLX and participating in governance, stakers trying to protect the system are forced to give up governance rights to do so
when FLX is the governance token, it can be borrowed to be used in governance, then immediately sold
given how the compound bravo snapshot works, your voting power is based on your FLX balance at the beginning of the proposal voting period, so you could sell 100% of your FLX immediately after the voting starts and retain full voting power
with stFLX, you would still have the 21 day unstaking thawing period, during which you are still providing FLX/ETH liquidity
personally I’ve always felt the openness of MKR governance was one of the worse design decisions, and would be more comfortable if those participating in governance have more skin in the game
to attack governance with stFLX, an attacker has to lock up their FLX/ETH for at least 21 days, and if they successfully damage the system in some way, other FLX holders can dump on them (since they are locking LP shares, not just FLX)
re 80/20 FLX/ETH - it doesn’t make sense to use 50/50 FLX/ETH to secure reflexer governance, that’s too much ETH IMO, and the 80/20 Balancer pools are governance minimized (same as uniswap) and battle tested
Downside risks:
It is possible for all existing stFLX holders to be slashed in the case of bad liquidations (e.g. maker’s black thursday). If that were to happen, the threshold for passing a proposal would decrease (though it would still have to pass quorum).
note - slashing in reflexer keeps stFLX token balances the same, but reduces each staker’s claim to the underlying LP tokens
also, only up to 30% (docs) of the stFLX is actually slashed, the other 70% stays put
the attack vector here is to submit a proposal right after a major slashing event, and try and add more stFLX yourself to push it through, but given that slashing is only 30% the opportunity isn’t massive
Fewer people will want to participate in governance because thy don’t want to lock up FLX/ETH LP
this can be a good thing for ungovernance, but also not great if it means the protocol is defended by less capital total
Possible Solutions:
simplest solution to the post-slash attack would be to extend the review process to up to several days, or even a week, as RAI matures (this gives FLX holders more time to react to slashing and add more stFLX)
Work Required
update stFLX to use 80/20 FLX/ETH Balancer V2 instead of 50/50 FLX/ETH Uni v2
add onchain transaction history tracking to the stFLX token (for compatibility with compound bravo)
redeploy staking contract to use new stFLX token
manage comms around the staking migration to the community
Next Steps
discuss proposal in this forum
snapshot vote at the end of April
if it passes, discuss implementation in more detail (might have to delay some ungovernance that touches this specifically)
Both FLX and stFLX can be used, just add a governance multiplier for stFLX because it represents a LP token e.g 1 stFLX = 2 FLX in terms of gov power. Or just make it 1 stFLX = 1 FLX, whichever option the community prefers.
Feels like Balancer stuff needs one snapshot and stFLX another snapshot because they can be developed independently.
Both FLX and stFLX can be used, just add a governance multiplier for stFLX because it represents a LP token e.g 1 stFLX = 2 FLX in terms of gov power. Or just make it 1 stFLX = 1 FLX, whichever option the community prefers.
Interesting idea. How would it account for slashing? If stFLX stakers get slashed they still have the same quantity of stFLX but can claim less of the underlying FLX/ETH LP tokens. Would it be able to introspect into the stFLX and award voting power based on the underlying LP? If so, then I think doing 1.5-2 “votes” per FLX equivalent in the FLX/ETH LP might be OK.
So if Alice has 80 FLX in a 80/20 FLX/ETH pool, they would get 120-160 votes. If Bob has 80 FLX, they get 80 votes.
Note - Another way of doing this accounting would take into account the value staked, and we know that the value of an 80/20 FLX/ETH pool is 100 FLX, so the 1.5-2x multiplier would be applied to that number, and so if Alice had 80 FLX in an 80/20 FLX/ETH pool she would receive 150-200 votes.
If we did it this way I think it’s also less important to use 80/20 FLX/ETH over 50/50 FLX/ETH. The rationale for 80/20 FLX/ETH was also assuming it would be the sole governance token. If we did 50/50 FLX/ETH it would be more important IMO to use the FLX value based accounting over pure FLX. So if Alice had 50 FLX in a 50/50 FLX/ETH, she would get 100 * 1.5-2x = 150-200 votes.
Use both tokens if you want more governance participation. It looks like we agree it’s the best method especially with gov boostie for stFLX.
Governance is hard so I advocate for simple logic to determine voter power so there’s little room for confusion. Is value staked worth it instead of just applying a boost?
I wasn’t suggesting we actually check prices and determine market value, more that we just apply a higher “boost” per FLX for the 50/50 LP than for the 80/20 LP.
