About secondary proposals 10, 12, 13 not executing

TL;DR These proposals are virtually guaranteed to never execute because their specified target function signature was invalid. I advise them to be re-processed.

If you look at the DAOv1 proposals created to execute through the Agent app, you’ll see that you can’t tell what the proposals are for. This is because the Aragon client doesn’t necessarily know what the target function signature is, so can’t make an attempt to decode the parameters and display them. For DAOv1 proposals, we use a separate application that we developed to decode and display proposal details. This functionality is built into the new DAO dashboard, where the proposal metadata (which would normally only be a description in plain English) includes the target function signature that the dashboard uses to decode the proposal parameters.

The function signature format used to calculate the function selector is very widely-recognized, which is why it wasn’t explicitly documented in the interface. From Contract ABI Specification — Solidity 0.8.10 documentation :

The first four bytes of the call data for a function call specifies the function to be called. It is the first (left, high-order in big-endian) four bytes of the Keccak-256 hash of the signature of the function. The signature is defined as the canonical expression of the basic prototype without data location specifier, i.e. the function name with the parenthesised list of parameter types. Parameter types are split by a single comma - no spaces are used.

The problem here was that the example in the DAO members docs used a wrong format (transfer(address, uint256) instead of the correct transfer(address,uint256)), which was followed while creating the invalid proposals. The docs are updated since then.


Note the whitespace in the signature

The function selector calculated from transfer(address, uint256) does not correspond to an existing function defined in the USDC contract (the chance of this happening accidentally would be 1 in 2^32), which is why attempts at executing these now passed proposals will revert. The only risk to consider here is if these proposals will become executable in the future. For this to happen, the USDC token contract will have to be updated with a new visible function whose signature is the same as the one calculated from transfer(address, uint256) (a similar thing was done in the recent Poly Network bridge hack). Since the DAO is already susceptible to lose its USDC due to a malicious update of the USDC contract, this is not a risk worth considering.

The DAO and its dashboard are designed to allow the creation and display of any arbitrary proposal. This means they are powerful, and like all powerful things allow the user to shoot themselves in the foot. Due to the restrictive development conditions (which still persist because we have even more things to build) we built an MVP that expects exact input from the user and depends on the voters to verify the correctness of this input. We want to improve the interface to streamline the proposal creation and avoid these simple mistakes, but this will not reduce the voter responsibility for verifying proposals because you can’t know if the proposal creator used the standardized flow that we provide or have created a malicious proposal that seems innocent. Therefore, no matter how we improve the dashboard UX, a high level of blockchain literacy and sense of responsibility from all parties is required for successful governance.

2 Likes

Makes sense.
Thanks for the elucidation burak, appreciate the effort to explain all the moving pieces at the end there.

DAO Tracker was adjusted to check this signature
It displays a warning badge, and groups such proposals separately to prevent similar things from happening in future.

5 Likes