Proposing a new Multicall Installation

nico · March 26, 2021, 8:19pm

Proposing a new Multicall Installation

It’s been 3 months since we installed the initial MultiCall Plugin on Mainnet and it’s a good time to discuss some new requirements for additional protocols to be whitelisted & general ideas for improvements – Let’s use this thread to define a new Multicall installation.

Specific MultiCalls

We currently do use one MultiCall plugin that allows us to connect to a defined list of protocols. While this keeps us secure and makes a lot of things simple, there are some downsides of using the same governance parameters for different use cases – Just one example: Having a 7 days voting period to provide some big chunks of liquidity on Swapr from the DXdao treasury seems reasonable, 7 days to update an ENS domains on the other side? Mhhhh, could go faster!

Why not using different Multicalls that give us some more flexibility and allows us to move faster where needed (@AugustoL was speaking about this idea already months back). Let’s use three specific Multicalls:

Quick Multicall (3 days execution time)
Used to execute technical / product-specific proposals
Safe Multicall (8 days execution time)
Used to execute mature / critical governance proposals
Open Multicall (14 days execution time)
Allows to interact with any protocol (no whitelist)

Multicall Governance Params:

1.Quick Multicall

Protocol whitelist:

TokenRegistry: 0x93db90445b76329e9ed96ecd74e76d8fbf2590d8
ENSRegistrywithFallback: 0x00000000000c2e074ec69a0dfb2997ba6c7d2e1e
ENSETHRegistry: 0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85
ENSPublicResolver: 0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41
ENSPublicProvider: 0x226159d592e2b063810a10ebf6dcbada94ed68b8
Radicle Registry (New): 0x37723287Ae6F34866d82EE623401f92Ec9013154

Governance params:

Boosted Vote Period Limit: 2 days (172800 seconds)
DAO Bounty Constant: 10
Proposal Reputation Reward:0 REP
Minimum DAO Bounty: 250 GEN
Pre-Boosted Vote Period Limit: 1 day (86400 seconds)
Queued Vote Period Limit: 7 days (604800 seconds)
Queued Vote Required: 50%
Quiet Ending Period: 2 days (172800 seconds)
Threshold Constant: 1.2
Voters Reputation Loss:0%

2. Safe Multicall

Protocol Whitelist:

Bonding Curve: 0xa1d65E8fB6e87b60FECCBc582F7f97804B725521
DXswapFeeReceiver: 0xc6130400c1e3cd7b352db75055db9dd554e00ef0
DXswapFeeSetter: 0x288879b3cafa044db6ba18ee638bbc1a233f8548
GnosisProtocolRelayer: (Waiting for deployment)
SwaprLiquidityRelayer: (Waiting for deployment)

Governance params:

Boosted Vote Period Limit: 7 days (604800 seconds)
DAO Bounty Constant: 10
Proposal Reputation Reward:0 REP
Minimum DAO Bounty: 250 GEN
Pre-Boosted Vote Period Limit: 1 day (86400 seconds)
Queued Vote Period Limit: 21 days (1814400 seconds)
Queued Vote Required: 50%
Quiet Ending Period: 2 days (172800 seconds)
Threshold Constant: 1.2
Voters Reputation Loss:0%

3. Open Multicall

Protocol Whitelist:

No whitelist

Governance params:

Boosted Vote Period Limit: 13 days (1123200 seconds)
DAO Bounty Constant: 10
Proposal Reputation Reward:0 REP
Minimum DAO Bounty: 250 GEN
Pre-Boosted Vote Period Limit: 1 day (86400 seconds)
Queued Vote Period Limit: 21 days (1814400 seconds)
Queued Vote Required: 50%
Quiet Ending Period: 2 days (172800 seconds)
Threshold Constant: 1.2
Voters Reputation Loss:0%

Uninstallation of old Plugins

There are some plugins that are either not used at all or duplicates with the upcoming, new Multicall installation. Let’s uninstall those plugins:

DutchX (0xb9812e2fa995ec53b5b6df34d21f9304762c5497)
GenericSchemeENSETHRegistry (0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85)
GenericSchemeENSRegistryWithFallback (0x00000000000c2e074ec69a0dfb2997ba6c7d2e1e)
GenericSchemeENSPublicProvider (0x226159d592e2b063810a10ebf6dcbada94ed68b8)
GenericSchemeENSPublicResolver (0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41)
GenericSchemeDXTokenRegistry (0x93db90445b76329e9ed96ecd74e76d8fbf2590d8)
MultiCall v1 (0xef9dc3c39ca40a2a3000acc5ca0467ce1c250808)

If we need to interact for some reason in the feature with either of those protocols we could still use the open multicall even though we uninstalled the plugins.

Further research

One essential feature that is currently missing on MultiCall is to approve & transfer tokens and ETH. While nobody is researching or implementing it, we should think on how to move forward there. Having those features in place would allows us for example to bridge tokens to other networks, interact with other DeFi protocols and many more.

AugustoL · March 29, 2021, 2:12pm

@nico this looks awesome, something that will make a huge change for us is the Open Multicall, we have been talking about having something like that since august last year.
I think the parameters are very well thought but one thing can use a change, the Threshold Constant in the Open multicall, since we will likely have a lot of active proposals here I would set the Threshold Constant to 1.1 (this will increase the amount of GEN needed per boosting less per active proposal)

The open multicall will make the ContributionReward useless, since we will be able to use OpenMulticall instead of the ContributionReward and even do “multiple contributions” in one proposal, so I would propose to uninstall it too BUT after we see that the multicall works as expected on mainnet.

And at last, what about permissions? There are four permissions that can be set for schemes:

canGenericCall: Used to make generic calls from avatar.
canUpgrade: Used to upgrade the controller. (not used)
canChangeConstraints: Used to change constraits. (not used)
canRegisterSchemes: Used to register and unregister schemes.

The multicall schemes all need to have the canGenericCall allowed to work, the canUpgrade and canChangeConstraints can be set to false since are not used and the canUpgrade allows to upgrade the controller (something we dont want!, yet). And the canRegsiterSchemes as far as I know is only enabled in one scheme that is the scheme registrar, It would be good to have the open multicall being able to register schemes so we can later remove schemeRegistrar.

So by allowing the open multicall to register schemes we can have the scheme registrar contract in the “second round” of schemes removals next to contribution rewards scheme.

nico · March 30, 2021, 2:55pm

Hey @AugustoL, thanks for your thoughts!

one thing can use a change, the Threshold Constant in the Open multicall, since we will likely have a lot of active proposals here I would set the Threshold Constant to 1.1 (this will increase the amount of GEN needed per boosting less per active proposal)

I’m personally not too afraid that are too many active proposals on mainnet, and the higher threshold constant could be a nice filter-feature to let the DAO decide on more/less valuable proposals. Let’s use this poll to make a decision:

What should be the threshold constant for Open MultiCall?

1.1
1.2

0 voters

The open multicall will make the ContributionReward useless, since we will be able to use OpenMulticall instead of the ContributionReward and even do “multiple contributions” in one proposal, so I would propose to uninstall it too BUT after we see that the multicall works as expected on mainnet.

ETH & token transfers are disabled in the current MultiCall through the Scheme Constraints, that’s mostly of security concerns (Don’t get confused by the scheme permissions below, that tell the opposite, we’re overwriting them on scheme constraint level, as they currently cannot be disabled through the security permissions). Having a new MultiCall iteration that supports transfers & approvals makes total sense to me and we should work on it – it would indeed make the Contribution Scheme redundant.

And at last, what about permissions? There are four permissions that can be set for schemes`

I think we should go with the same one as the current MultiCall for now:

[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

[x] Call genericCall on behalf of

And the canRegsiterSchemes as far as I know is only enabled in one scheme that is the scheme registrar, It would be good to have the open multicall being able to register schemes so we can later remove schemeRegistrar.

I’m not 100% sure but wouldn’t the MultiCall need some modifications on the contract itself to expose the functions to actually register the scheme on the controller?