Optional onchain governance module

[PaulRBerg]

It would be helpful to give users the ability to optionally attach a governance module to a stream at the time of creation.

The use case is to give users the ability to use the streamed assets for voting.

Ideally, this governance module would connect seamlessly with Tally.

[PaulRBerg]

Had a chat with Matt Solomon from ScopeLift, who are working on a framework for flexible voting in DeFi.

we're in the process of writing real docs so in the meantime we have a patchwork of blog posts and code, but let me know if you have any questions

• Intro blog post: https://www.scopelift.co/blog/introducing-flexible-voting
• Repo: https://github.com/ScopeLift/flexible-voting
• Governor Implementation: https://github.com/ScopeLift/flexible-voting/blob/master/src/GovernorCountingFractional.sol
• Voting Client abstract contract, which you can inherit from when building an integration (e.g. sablier would inherit from this), at a minimum a good resource: https://github.com/ScopeLift/flexible-voting/blob/master/src/FlexVotingClient.sol
• More blog posts under this tag: https://www.scopelift.co/blog/tag/flexible-voting

and of course it might change based on feedback from users and devs between now and the time you start work on a sablier v3, so any feedback you have (e.g. changes to help you integrate, etc) is appreciated!

[PaulRBerg]

Implementing this will be difficult. Broadly speaking, there are two approaches:

1. Flexible voting by inheriting from FlexVotingClient
2. Deploy a bespoke "vault voting" contract, withdraw the stream deposit there, and reclaim the assets from the vaults when the user wishes to exit the stream. This is what Hedgey does: see this and this.

The problem with the 1st approach is that it only works with those governance systems that have integrated flexible voting, which AFAIK mean only. Aave, Uniswap, and Gitcoin at the moment.

Whereas the problem with the 2nd approach is .. well, there are multiple problems:

• Significant development cost
• Complicates accounting by moving the funds in a different bespoke contract per user
• Gas overhead
  • 410k gas to create a governance stream on Hedgey
  • 677k gas to delegate and deploy a vault contract

---

Can you think of any other approaches?

[PaulRBerg]

It looks like it might be possible to use Risc0's Bonsai for voting.

Using SNARKs to enable fully verifiable governance while lowering associated costs.

[PaulRBerg]

We should look into potentially supporting OZ's onchain voting mechanism (used by $COMP and $FLUID) since it's the closest to a universal standard in Ethereum.

[smol-ninja]

This is the OZ implementation:

/**
 * @notice Delegate votes from `msg.sender` to `delegatee`
 * @param delegatee The address to delegate votes to
 */
function delegate(address delegatee) public virtual {
    address account = _msgSender();
    _delegate(account, delegatee);
}

/**
 * @dev Delegate all of `account`'s voting units to `delegatee`.
 */
function _delegate(address account, address delegatee) internal virtual {
    address oldDelegate = delegates(account);
    _delegatee[account] = delegatee;

    emit DelegateChanged(account, oldDelegate, delegatee);
    _moveDelegateVotes(oldDelegate, delegatee, _getVotingUnits(account));
}

It delegates the entire balance of msg.sender to one address. Ideally, for a protocol holding users' tokens, the solution would be to allow partial delegation by choosing an amount in the delegate function.

There have been a few discussions on it where people have requested similar features. So far, the idea has been rejected as an infeasible solution. Let's say a protocol delegates balance to multiple addresses, then transfers some of the balance. How would the voting contract decide from which delegatee the amount shall be reduced?

---

I found a contract in ENS repo with a function to support partial delegations but it seems to be transferring tokens to the contract as a fix to the above problem.

My take is that with the current design of the delegation, we cannot support it until we want to delegate the full balance.

[PaulRBerg]

You're right. The OZ model doesn't work when tokens are pooled (like with Sablier).

I guess this is why Scopelift introduced flexible voting.