-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Give GenericSchemes a name, default proposal params #621
Comments
|
[Note: this response to Oren's comments above is obsoleted by the addition of the request for replaceable param values in the ABI] The advantage of default params (over subclassing GenericScheme) is that people won't have to write any code. Rather, they would be able to register a GenericScheme with the desired params using SchemeRegistrar. No coding required.
Indeed, but combine this feature request with this one, and you have a lot of flexibiity. |
If a DAO wants to have multiple sets of default values, then it would need to deploy an additional GenericScheme instance for each default set. That seems less than ideal. |
To address my comment just above, see this PR: #623 |
Feature request: Let GenericScheme instances be configured with a name, default ABI and contract address. dApps such as Alchemy could display the name to automatically identify each GenericScheme, and supply
null
s for the ABI and contract address when creating a proposal, to causeexecute
to use the defaults.These configurations would be part of the scheme parameters, settable by SchemeRegistrar.
dApps would obtain the default ABI from the GenericScheme params and parse it to identify any contract.function params that do not have values. For those params that do not have values, the dApp would generate a form enabling the user to enter the values. The dApp would poke these values into the ABI and submit that completed ABI to
proposeCall
(when proposals are created).These features would enable dApps like Alchemy to use GenesisScheme instances without requiring any custom code to support the GenericScheme.
The text was updated successfully, but these errors were encountered: