Add MetadataRegistry contract#586
Conversation
thomas-waite
changed the base branch from
feat-governance-upgrade
to
feat-deploy-pods
contracts/pods/MetadataRegistry.sol
Outdated
| uint256 podId, | ||
| uint256 proposalId, | ||
| string memory metadata | ||
| ) external { |
There was a problem hiding this comment.
Agree that this function needs to be permissioned, otherwise we are going to get spammed with garbage data.
There was a problem hiding this comment.
I'd take it a step further and possibly enforce that this is done atomically with pod creation. What are the pros and cons of this?
There was a problem hiding this comment.
Not sure I follow? My plan is to grant a new role POD_METADATA_REGISTER_ROLE, who's admin is the ROLE_ADMIN, when the pod is deployed.
I will then permission this registerProposal() function to that POD_METADATA_REGISTER_ROLE
|
@thomas-waite can you change the naming here to be more specific? Ie it would be really easy to confuse this, governance-proposal specific contract with the other, generalized metadata push that we're thinking about. Something like "GovernanceMetadataRegistry" would suffice imo |
Totally, have changed |
thomas-waite
changed the title
thomas-waite
changed the title
4 participants
Summary
Adds a
MetadataRegistrycontract with a single non-permissioned state changing function:registerProposal(uint256 podId,uint256 proposalId,string memory metadata.Used in order to emit
metadatafor pod proposals, which the frontend can listen to and display. This is required as Gnosis Safe's do not support adding arbitrary metadata. A spec is available if useful.It is intended that the first function call in a pod transaction - before the transaction goes to the appropriate timelock - is sent to this contract. The contract can emit the metadata and allow the frontend to show the proposal as it is in the timelock, where it can the be vetoed if appropriate.
TODO
Once permissions PR is in, make the
registerProposal()method permissioned to pods only. Will prevent an unlikely DDOS weakness