Skip to content
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

WIP 🚧 feat: token voting target improvements #30

Conversation

clauBv23
Copy link

@clauBv23 clauBv23 commented Sep 4, 2024

No description provided.

Comment on lines 310 to 316
permissions[1] = PermissionLib.MultiTargetPermission(
PermissionLib.Operation.Revoke,
_payload.plugin,
_dao,
PermissionLib.NO_CONDITION,
UPGRADE_PLUGIN_PERMISSION_ID
);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from v1.3 the UPGRADE_PLUGIN_PERMISSION_ID is not being granted to the DAO, so it doesn’t need to be revoked when uninstalling.
It is already being revoked when upgrading from a previous version

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in 6b02e12

Comment on lines 334 to 340
permissions[4] = PermissionLib.MultiTargetPermission(
PermissionLib.Operation.Revoke,
_payload.plugin,
address(type(uint160).max), // ANY_ADDR
PermissionLib.NO_CONDITION,
TokenVoting(IMPLEMENTATION).CREATE_PROPOSAL_PERMISSION_ID()
);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the previous version, after uninstalling a plugin, the proposal creation and voting process were still allowed, even though proposal actions would fail due to the plugin losing execute permission, but, revoking CREATE_PROPOSAL_PERMISSION now changes this behavior.

I'm not sure if this would create any significant issues in practice, but one potential scenario that comes to mind is users using an uninstalled token voting plugin for off-chain decisions. In such cases, they might still create proposals without actions, using the proposal description as metadata. While this might not be a very common use case, it seems worth considering. wdyt?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We agreed on not allowing the proposal creation once the plugin is uninstalled. In the end, the functionality of a plugin is to create proposals on the Dao it is installed on, so when it is uninstalled it should not allow proposal creation.

However, users can always grant the create proposal permission after uninstallation if they need it

@@ -259,6 +271,10 @@ abstract contract MajorityVotingBase is
/// @param proposalId The ID of the proposal.
error ProposalExecutionForbidden(uint256 proposalId);

/// @notice Thrown if the proposal with same actions and metadata already exists.
/// @param proposalId The id of the proposal.
error ProposalAlreadyExists(uint256 proposalId);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as with multisig

aragon#19 (comment)

);

emit ProposalExecuted(_proposalId);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't see it being removed from the plugin side. Just to confirm

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the event is defined in IProposal and emitted on each plugin implementation of IProposal

TargetConfig calldata _targetConfig,
uint256 _minApprovals,
bytes calldata _pluginMetadata
) external onlyCallAtInitialization reinitializer(2) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm, aren't we initializing build 3 at this point?

Suggested change
) external onlyCallAtInitialization reinitializer(2) {
) external onlyCallAtInitialization reinitializer(3) {

/// @dev WARNING: The contract should only be upgradeable through PSP to ensure that _fromBuild is not incorrectly passed, and that the appropriate permissions for the upgrade are properly configured.
/// @param _fromBuild The build version number of the previous implementation contract this upgrade is transitioning from.
/// @param _initData The initialization data to be passed to via `upgradeToAndCall` (see [ERC-1967](https://docs.openzeppelin.com/contracts/4.x/api/proxy#ERC1967Upgrade)).
function initializeFrom(uint16 _fromBuild, bytes calldata _initData) external reinitializer(2) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question

Action[] calldata _actions,
bytes memory _metadata
) public pure override returns (uint256) {
return uint256(keccak256(abi.encode(_actions, _metadata)));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as with multisig

Comment on lines 109 to 121
PluginUUPSUpgradeable.TargetConfig memory targetConfig,
uint256 minApprovals,
bytes memory pluginMetadata
) = abi.decode(
_data,
(
MajorityVotingBase.VotingSettings,
TokenSettings,
GovernanceERC20.MintSettings,
uint256
PluginUUPSUpgradeable.TargetConfig,
uint256,
bytes
)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

permissions[2] = PermissionLib.MultiTargetPermission(
PermissionLib.Operation.GrantWithCondition,
plugin,
address(type(uint160).max), // ANY_ADDR
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as with multisig, if feasible

Comment on lines +352 to +365
);
(bool success2, bytes memory data2) = token.staticcall(
abi.encodeWithSelector(IVotesUpgradeable.getVotes.selector, address(this))
);
(bool success3, bytes memory data3) = token.staticcall(
abi.encodeWithSelector(IVotesUpgradeable.getPastVotes.selector, address(this), 0)
);

return (success1 &&
data1.length == 0x20 &&
success2 &&
data2.length == 0x20 &&
success3 &&
data3.length == 0x20);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to compute everything upfront. Lazy evaluation:

if (no) return false;
else if(no) return false;
else if(no) return false
return true;

* fix tests and contract

* change

* add actions in proposal id generation

* rename'
uint256 allowFailureMap;
uint256 minApprovalPower;
TargetConfig targetConfig; // added in v1.3
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean added in v1.4 ?

@novaknole novaknole deleted the branch feat/add-minimal-approval-configuration October 18, 2024 06:49
@novaknole novaknole closed this Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants