Multicall Installation: Proposing Governance & Configuration Parameters

nico · December 29, 2020, 2:56pm

While the Multicall Scheme has already been installed and successfully tested on xDAI, we’re now in preparation of installing Multicall also on Mainnet. The Multicall is kind of an universal adapter that allows the DXdao to connect to multiple contracts, instead a specific adapter that only connects to a single contract as Generic Schemes, we’ve been using in the past. With Multicall the DXdao will be able to create new connections to external contracts & protocols much faster.

To shortly give an overview of the differences between Generic Schemes and Muticall Schemes:

Generic Schemes

Connects to one specific Smart Contract
Can execute any function call on specified Smart Contract
Limited to execute one action in each proposal
Governance parameters define the proposal voting process
Custom UI that needs to be setup
Can spend funds & transfer ERC20

Example: https://alchemy.daostack.io/dao/0x519b70055af55a007110b4ff99b0ea33071c720a/scheme/0x252d4c96bc18c6e0670f5cebeda40d6997688223d9498c8a61e0cb45c2c0a3ff/proposals/create/

Multicall Schemes

Connection to one or multiple whitelisted Smart Contracts
Can execute any function call on whitelisted Smart Contracts
Can execute multiple actions on multiple Smart Contracts in a defined order within one proposal
Governance parameters define the proposal voting process for multiple whitelisted contracts
Generalized Proposal UI

Even though it’s technically possible, as of now we should not use the Multicall for proposals that involve any kind of funds. This is an additional organizational, security measure we should go until we have general experience with Multicall and better tools to analyze proposals. For now we can simply use the Funding Scheme to transfer funds if needed.

Example (xDAI):

To install the plugin on Mainnet we need to come to a consensus about some installation parameters. Going to share some parameters that we can discuss in this thread:

Multicall Contract Whitelist

The Multicall has a hardcoded (at least of now – we’ll be working on an upgradeable version) list of contracts it can speak to. Updates can only be done by deploying a new Multicall Scheme & Plugin-Manager proposal which is about 2 weeks – that’s why we should make sure we actually have whitelisted all the contracts needed.

TokenRegistry: 0x93db90445b76329e9ed96ecd74e76d8fbf2590d8
ENSRegistrywithFallback: 0x00000000000c2e074ec69a0dfb2997ba6c7d2e1e
ENSETHRegistry: 0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85
ENSPublicResolver: 0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41
ENSPublicProvider: 0x226159d592e2b063810a10ebf6dcbada94ed68b8
DutchX: 0xb9812e2fa995ec53b5b6df34d21f9304762c5497
GnosisProtocolRelayer: 0x0846Ff449b107A727958264Ad8f29f16B0040327
OracleCreator: 0x2aE76E736f5e4DdA4996b70AE2765Aa621482357
SwaprLiquidityRelayer: To be deployed
Bonding Curve: Addresses to be confirmed (@AugustoL @JohnKelleher )

Governance Parameters

My suggestion is to use the same, proven, governance parameters as the Funds & Voting Power Scheme.

QueuedVoteRequiredPercentage: 50%
QueuedVotePeriodLimit: 3888000 (45 days)
BoostedVotePeriodLimit: 604800 (7 days)
PreBoostedVotePeriodLimit: 86400 (1 day)
ThresholdConst: 1200 (1.2)
QuietEndingPeriod: 172800 (2 days)
ProposingRepReward: 500 REP
VotersReputationLossRatio: 4%
MinimumDaoBounty: 250 GEN
DaoBountyConst: 10

An explanation of each parameter can be found here:

Permissions

[x] Mint and burn reputation, send ETH and external & native tokens. Note: Cannot turned off (Activated by default, cannot be deactivated)

[ ] Register other plugins

[ ] Add/remove global constraints

[ ] Upgrade the controller

[ ] Call genericCall on behalf of

Future Multicall Scheme Features:

While the first Multicall Scheme version is already a big improvement and will help us to connect to external contracts & ecosystems faster, I believe there’s still big potential for improvements & additional features. We’re going to continue to collaborate with DAOstack to work on:

Updateable Whitelist: Instead of using a hardcoded whitelist, the whitelist can be governed & updated with prosoals.

Enable ETH transfers & ERC20 approvals: ETH transfer & ERC20 approvals with Multicall proposals, currently deactivated as of missing design pattern that ensures sufficient security.

Proposal Simulation: Allow users to simulate transactions & understand the state changes of calls before submitting proposals.

Simplified Proposal Creation UI: Further UI simplification so that allows non-technical users to easily create proposals.

corkus · December 30, 2020, 11:00am

This is an old public resolver from the ethereum name system which we should remove from the DXdao asap. All our ens domains are using the newest public resolver version 0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41

DutchX: 0xb9812e2fa995ec53b5b6df34d21f9304762c5497

I would propose to cut ties completely from the DutchX contracts.

OracleCreator: 0x2aE76E736f5e4DdA4996b70AE2765Aa621482357

Why does the DXdao need the connection to this contract?

nico · December 29, 2020, 9:12pm

@corkus great, thanks for your feedback! Definetly a good chance to get rid off the plugins we don’t need anymore. Let’s uninstall:

Old ENSPublicResolver (0x226159d592e2b063810a10ebf6dcbada94ed68b8)
DutchX: 0xb9812e2fa995ec53b5b6df34d21f9304762c5497

The OracleCreator is part of the Gnosis Protocol Relayer & Swapr Liquidity Relayer contracts, but you’re right we don’t really need to interact with it.

JohnKelleher · December 29, 2020, 10:14pm

I have a few thoughts on the configuration parameters:

Should we reduce the QueuedVotePeriodLimit? I think 45 days is longer than necessary to let a proposal expire and if we shorten it then it will help keep Alchemy from being cluttered.
Should we reduced the ProposingRepReward? I am not sure it makes sense to give out 500 REP per proposal. This could result in workers that already have greater than the max REP accumulating more REP because they frequently make proposals via the multi-call scheme.
Should we remove the VotersReputationLossRatio completely? That is, reduce it to zero. I feel like it mainly acts to discourage voting. And since it only affects non-boosted proposals, it specifically discourages voters from voting before a proposal becomes boosted.

JohnKelleher · December 29, 2020, 10:19pm

@nico The bonding curve address is https://etherscan.io/address/0xa1d65E8fB6e87b60FECCBc582F7f97804B725521

It is actually one and the same as the DXD token contract. And you can see that it contains nearly 2500 ETH that represent the buyback reserve. The contract provided in the response by @corkus is actually the “implementation” contract, that is the contract which has the business logic. The bonding curve contract 0xa1d65E8fB6e87b60FECCBc582F7f97804B725521 is the permanent contract with the data storage. It is a proxy to the implementation contract where the business logic lives. If DXdao ever wanted to update the bonding curve, it would do so be deploying a new implementation contract with new business logic and pointing the permanent proxy contract with the storage to the new implementation.

nico · December 30, 2020, 9:12am

@JohnKelleher great, thanks! All sounds reasonable for me:

Should we reduce the QueuedVotePeriodLimit ? I think 45 days is longer than necessary to let a proposal expire and if we shorten it then it will help keep Alchemy from being cluttered.

What about 21days?

Should we reduced the ProposingRepReward ? I am not sure it makes sense to give out 500 REP per proposal. This could result in workers that already have greater than the max REP accumulating more REP because they frequently make proposals via the multi-call scheme.

Maybe 100 or even zero?

Should we remove the VotersReputationLossRatio completely? That is, reduce it to zero. I feel like it mainly acts to discourage voting. And since it only affects non-boosted proposals, it specifically discourages voters from voting before a proposal becomes boosted.

Agree, we should remove it.

corkus · December 30, 2020, 11:07am

lets make a poll!

What should the QueuedVotePeriodLimit be for the multicall scheme?

7
14
21
28
35
42

0 voters

What should the ProposingRepReward be for the multicall scheme?

0
100
200
300
400
500

0 voters

Should we disable VotersReputationLossRatio so no one is losing any Reputation by voting on proposals?

Yes
No

0 voters

pulpmachina · December 30, 2020, 1:37pm

A question on the ProposingRepReward parameter:

I agree with @JohnKelleher 's point that if our policy is to not give workers more than 4% REP for work performed, then it is a bit of a workaround to provide REP for passed proposals. Especially since workers predominantly make proposals on Alchemy.

However, I like that REP rewards are given to incentivize positive participation in DXdao, and I like that it’s automatic (no need for a separate proposal). Correct me if I’m wrong here.

So, I see two separate, yet somewhat opposing interests: (1) limit centralization of voting power by capping REP accumulation to 4%; and (2) incentivize positive participation in DXdao to those that make passing proposals by rewarding REP.

Could both of these interests be met by modifying this parameter to allow a REP reward (even 500 REP) to any ETH address that makes a passing proposal, so long as that ETH address has less than 4% REP? Is this possible?

I understand that someone could game the system by using different ETH addresses to make proposals, but that is something we are dealing with regardless when limiting REP accumulation generally. We should also discuss disincentivizing such behavior, if and when it can be determined that someone is gaming the system in this manner.

nico · December 30, 2020, 8:49pm

Updated Contract Whitelist:

TokenRegistry: 0x93db90445b76329e9ed96ecd74e76d8fbf2590d8
ENSRegistrywithFallback: 0x00000000000c2e074ec69a0dfb2997ba6c7d2e1e
ENSETHRegistry: 0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85
ENSPublicResolver: 0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41
GnosisProtocolRelayer: 0x2aE76E736f5e4DdA4996b70AE2765Aa621482357
SwaprLiquidityRelayer: 0x03b60c1FbCCb200CB2Da7936184C512E845b8907
Bonding Curve: 0xa1d65E8fB6e87b60FECCBc582F7f97804B725521
DXswapFeeReceiver: 0xc6130400c1e3cd7b352db75055db9dd554e00ef0
DXswapFeeSetter: 0x288879b3cafa044db6ba18ee638bbc1a233f8548

AugustoL · December 31, 2020, 1:53pm

Regarding the parameter quietEndingPeriod which has a very weird functionality IMO. Im using it as value 0 in the dxvote dapp, it basically check that no vote happened during that period of time in the proposal, which I think it delays the proposal execution and makes the process more bureaucratic.

I think the proposals should start and end at a certain time, thats it. Having the the proposal time being increased constantly with the right coordination can delay the proposal a lot.

As I say Im using a 0 value for quietEndingPeriod on all schemes in dxvote dapp and besides making the voting a bit more gas efficient it removes bureaucracy of the process, making a proposal finish at an immutable time.

AugustoL · December 31, 2020, 1:56pm

DXvote deploy contracts script, https://github.com/AugustoL/dxvote/blob/master/scripts/deployContracts.js

The important section(take a look that when I deployed on rinkeby I used a different config, focusing on safe and slow master scheme conf and a fastconf for quick scheme):

const schemesConfiguration = (network == 'rinkeby') ? {
    master: {
      queuedVoteRequiredPercentage: 50,
      queuedVotePeriodLimit: moment.duration(6, 'days').asSeconds(),
      boostedVotePeriodLimit: moment.duration(2, 'days').asSeconds(),
      preBoostedVotePeriodLimit: moment.duration(0.5, 'days').asSeconds(),
      thresholdConst: 1500,
      proposingRepReward: web3.utils.toWei("0.02"),
      votersReputationLossRatio: 2,
      minimumDaoBounty: web3.utils.toWei("1"),
      daoBountyConst: 20,
    },
    quick: {
      queuedVoteRequiredPercentage: 60,
      queuedVotePeriodLimit: moment.duration(3, 'days').asSeconds(),
      boostedVotePeriodLimit: moment.duration(1, 'days').asSeconds(),
      preBoostedVotePeriodLimit: moment.duration(0.5, 'days').asSeconds(),
      thresholdConst: 1050,
      proposingRepReward: web3.utils.toWei("0.002"),
      votersReputationLossRatio: 4,
      minimumDaoBounty: web3.utils.toWei("0.25"),
      daoBountyConst: 10,
    }
  } : {
    master: {
      queuedVoteRequiredPercentage: 50,
      queuedVotePeriodLimit: moment.duration(60, 'minutes').asSeconds(),
      boostedVotePeriodLimit: moment.duration(20, 'minutes').asSeconds(),
      preBoostedVotePeriodLimit: moment.duration(5, 'minutes').asSeconds(),
      thresholdConst: 1500,
      proposingRepReward: web3.utils.toWei("0.02"),
      votersReputationLossRatio: 2,
      minimumDaoBounty: web3.utils.toWei("1"),
      daoBountyConst: 20,
    },
    quick: {
      queuedVoteRequiredPercentage: 60,
      queuedVotePeriodLimit: moment.duration(30, 'minutes').asSeconds(),
      boostedVotePeriodLimit: moment.duration(10, 'minutes').asSeconds(),
      preBoostedVotePeriodLimit: moment.duration(5, 'minutes').asSeconds(),
      thresholdConst: 1050,
      proposingRepReward: web3.utils.toWei("0.002"),
      votersReputationLossRatio: 4,
      minimumDaoBounty: web3.utils.toWei("0.25"),
      daoBountyConst: 10,
    }
  };

Powers · December 31, 2020, 3:18pm

Hmm, is this the overtime feature that is meant to prevent any last second voting attacks?We saw this last week with the bonding curve proposal. It seemed like it worked pretty well then.

I agree that proposals should start and end at the same time but I’m not sure why that should apply to the boosted phase, since that’s already an accelerated proposal timeline.

The one thing I’ve noticed that has happened is that it goes into the quietEndingPeriod when a proposal gets its first vote within the last 2 days. I think this happened to Ezra’s REP boost and the DXD.eth snapshot proposal. No one had voted (bc of gas) and then when it got a single vote in the FOR, it extended the voting period for another day.

I would be okay with keeping the time extension for when a vote switches from one side to another (like the bonding curve proposal), but getting rid of it for when it’s just the first vote, so it’s going from neutral to for/against.

JohnKelleher · January 4, 2021, 9:24pm

Following up on the quietEndingPeriod and what @Powers said above. I think it is an important parameter to have because of how voting tends to work in DAOstack/DXdao. It seems to me that people will often choose not to vote if the vote is going the way they want it to, probably partly to save gas by not voting. This is fine as long as they have enough time to react to a change in the winning side. So having the quietEngingPeriod leaves enough time for people to react to some voter or voters swinging the balance at the last minute.

AugustoL · January 5, 2021, 12:29am

@Powers @JohnKelleher In my opinion voters should vote on time, if they want to wait till last minute to vote because their decision depends on what the majority wants it is fine, but it I think it should not affect the time a proposal finishes. Regarding how boosted proposals change a proposal duration that happens because there is money staked on that proposal to pass, is not that it gets boosted without any reason, and that is what makes a proposal being processed faster.

This being said Im would still be ok with a very short time in quiet ending period, maybe an hour ? but I think is not necessary at all, simple voting, on time with few rules. And well…enough time to vote… I guess the quiet ending period can be used in a quick scheme where the voting time of a proposal is way lower, that would be a good use case for it.