Flow Governance


There’s been some talk about our governance model. We’ve briefly discussed:

  • Turning governance into a sort of RPG-like thing. I threw some ideas into that thread, but it also led to my post later that day in which I explained why I think something’s “paint job” is important. Yeah, the post was a little nutty, but I stick to it.
  • Rewarding voters via reward “streams”; basically, a vote is placed, and the voter receives a month-duration stream rewarding them for their participation. This encourages consistent participation, as more votes = more streams = more income, but if the voter abstains for too long all of their streams will run out, tapering off their income until it eventually ceases.
  • Conviction voting, and voter decay. The former is a mechanism by which the voter expresses their preference, and the longer they keep that preference the more weight it holds; changing your preference takes the weight out and you start from 1x again. The latter is a mechanism by which the voter is encouraged to vote consistently, else the weight of their vote is reduced (until after they vote again); our interest in this concept was to use it in our quorum, such that “decayed” voters would count less towards quorum requirements.
  • Augmenting rewards with NFTs that amplify earnings (it’s towards the bottom of the OP). The idea is that (in the case of the linked proposal) voters, no matter which way they vote so long as they do so, are rewarded with an NFT that, when staked, amplifies LP rewards on Bancor.

Now that you’ve a little background, let’s delve a bit more into the specifics that I’ll use to build this new governance model.



I explain the technical aspects in a later post. I still love this idea. I think it has a great potential for helping us passively regulate and maintain the governance process.

Sure, it’s kinda-sorta meant for payroll, but it has so many applications beyond that; it’s a generic money pipe through which value flows at an arbitrary constant rate for a specified duration, and we can use it to time-delay the flow of value on arbitrary processes, and with compounding streams, it’s a money pipe that emits more money towards an arbitrary destination as its transiting the money you originally sent.

Decay, Conviction

I haven’t been able to get this entirely out of my head; it’s sticky–leaves residue. Basically, what I’m proposing here is that we use an APY-type mechanism to provide us with a live feed of voter engagement. Decay and Conviction are two substances that are used to measure activity from an individual voter; you may think of them as auras or fluids, but if that offends your defi sensibilities, they’re internal tokens/values of some description that you don’t start accruing until your governance stake is first established; new voters are not subject to decay from previous proposals, but also can’t vote on them (much like the current system).

When you stake vBNT, Decay will start accruing from proposals presented thereafter. If your Decay income is higher than your Conviction income, eventually you will slip into a condition known as Rot, which is where your Conviction is no longer counted until you pull yourself out of Rot. The gap between your Decay and Conviction levels implies the level of your voting activity, which falls roughly into one of four categories:

  • High Decay, High Conviction: These are older voters that may not be very active and may have recently slipped into Rot, but are active enough such that we can consider their return reasonably likely.
  • High Decay, Low Conviction: These are old voters that are not active, and their Conviction isn’t counted on any proposals they previously voted on until they vote on enough proposals that are giving them Decay to reverse the polarity of the neutron flow; the wider the gap, the more proposals they’ll need to vote on.
  • Low Decay, High Conviction: These are older voters that are very active and do not let proposals sit for long. The wider this gap is, the longer they can “vacation” from voting before their Decay gets too high.
  • Low Decay, Low Conviction: These are new voters. They’ve only recently entered a stake in governance, and we don’t know how active they are yet.

This model:

  • Inherently gives us pseudonymous (not totally anonymous because there’s people like me that put their name on it) historical voting data about each voter.
  • Automatically greatens the penalty for greater periods of inactivity in real time.
  • Automatically grants consistent voters “vacation days”
  • Cleanly measures voting activity from each voter, meaning rewards are easier to calculate.

Speaking of rewards…


There’s a good bit to take in there. We can take this idea and adapt it to the Flow Governance system laid out above. Voters never hold Decay or Conviction, they are entirely internal value/tokens, but we can use the gap between Conviction and Decay to calculate the rate of a third flow which the voters will receive, the reward stream, which I’ll call “Sap” for now. You can essentially take most of the talk about “steeping” and apply it to Sap instead of vBNT.

The “powerups” take the form of the aforementioned yield-augmenting NFTs, but we can do other things with them too, like reducing decay flow, or augmenting the effective voting weight used in calculating Conviction/Decay (and by extension, Sap).

Voters realize their Sap rewards by “tapping” their Sap reserve (an internal “tank” where the Sap flow from good voting health collects). They can then trade the Sap, or “steep” crates in Sap to receive augment NFTs, which they can use or trade. How they get the crates in the first place is matter for discussion; perhaps some kind of raffle where your Sap flow determines your chances of getting a crate?

The Governance Model, From The Perspective Of The User, Start To Finish

  • A user stakes vBNT.
  • A proposal is presented, and the user begins accruing Decay.
    • The user votes, and the Decay flow is stopped while a Conviction flow is started. The Conviction is “stored” in the proposal it comes from so it can continue to lend weight to the user’s vote.
    • The user doesn’t vote, and their Decay flow continues. If their total Conviction income is insufficient, they will eventually slip into Rot.
  • As time goes on, the user accrues a Sap balance according to their Decay and Conviction flows.
  • The user can “tap” this balance, which initiates a stream of Sap (via Sablier) from the protocol to the user.
    • Eventually, the user gets an augment crate (somehow) and steeps it in their Sap. When the crate is “cracked”, they receive an augment NFT which affects their position in governance somehow.
    • Eventually, the user accrues a significant pile of Sap and sells it for a sum which they can then deposit into an LP, or buy more voting power, or go buy an NFT that they want, or whatever they decide to do with it.

Share thoughts!

EDIT: That’s what I was forgetting!

Consequences For Delegates

Under delegation, the system works almost the same; delegates have larger flows because they have more voting weight, but they split rewards with their delegators. The portion could be determined by the delegate’s own flow (that is, what they would have without any delegates); active delegates get a fatter cut of the Sap resulting from their votes.

Extra Notes

  • Flows must never be capped, as it would effectively put an expiration date on voters; the continual and unlimited accrual of balances is our live data feed from a given voter, and capping the rate at which those balances can accrue means that after a certain point, we’ll have a much harder time judging that voter’s activity and deciding whether or not they should be included in the governance calculations. It also means we’ll have to force a final state for the voter–either active, rotted, or neutral (Conviction = Decay)–and we should not do that to voters who have been participating for a certain length of time.

Since this was posted, I have begun building a Haskell program to serve as a proof-of-concept. I initially posted a functional code snippet; I later retracted it as I thought it was sub-par. (I’m a bit of a perfectionist when it comes to my code.)

Progress has been consistent but slow; I have very limited free time to work on this right now. Code is coming, but I want to make sure it’s good code so it’s (hopefully) easier to implement.