ProposalsProposal 474
ProposalsProposal 474
In V3 we introduced a data contract where people post candidates onchain (using events). Accounts with zero votes need to pay a small spam-protection fee to create a candidate.
We use the create candidate function also as part of the flow of updating an onchain proposal that was created with signatures, as a means of collecting signatures again for the update.
The primary bug is that we charge the candidate creation fee in this proposal update flow, when in fact we don’t want to charge it. The fix is not charging the candidate creation fee when the candidate is explicitly created in order to update an existing proposal, and the proposal meets certain conditions: it’s in the Updatable state, the candidate creator and the proposal proposer are the same account, and the proposal has at least one signer.
The secondary issue is that candidates can be created with an invalid amount of transactions, leading to bad UX when people try to convert these candidates to proposals. The DAO’s rules for transactions are: (1) there must be at least one transaction, and (2) there must be at most ten transactions. With this fix the data contract enforces the same rules so users get pushback early on.
Exact changes can be seen in this pull request.
Because this change is for a side contract, which doesn’t have any access to the core nouns contracts,, we're not going through an official audit process. This change has been reviewed by solimander.
The transaction sets the data contract proxy implementation to be the fixed version deployed here.
Thanks,
the verbs ⌐◨-◨
In V3 we introduced a data contract where people post candidates onchain (using events). Accounts with zero votes need to pay a small spam-protection fee to create a candidate.
We use the create candidate function also as part of the flow of updating an onchain proposal that was created with signatures, as a means of collecting signatures again for the update.
The primary bug is that we charge the candidate creation fee in this proposal update flow, when in fact we don’t want to charge it. The fix is not charging the candidate creation fee when the candidate is explicitly created in order to update an existing proposal, and the proposal meets certain conditions: it’s in the Updatable state, the candidate creator and the proposal proposer are the same account, and the proposal has at least one signer.
The secondary issue is that candidates can be created with an invalid amount of transactions, leading to bad UX when people try to convert these candidates to proposals. The DAO’s rules for transactions are: (1) there must be at least one transaction, and (2) there must be at most ten transactions. With this fix the data contract enforces the same rules so users get pushback early on.
Exact changes can be seen in this pull request.
Because this change is for a side contract, which doesn’t have any access to the core nouns contracts,, we're not going through an official audit process. This change has been reviewed by solimander.
The transaction sets the data contract proxy implementation to be the fixed version deployed here.
Thanks,
the verbs ⌐◨-◨