This proposal executes funding requests for the Meta-Governance and Public Goods Working Groups for the April 2025 funding window as passed in EP 6.6.1 and EP 6.6.2. This bundled executable proposal follows the requirements set out in Rule 10.1 of the Working Group Rules (EP 1.8).
This amount will cover all expected expenses outlined in the social proposal while leaving a prudent reserve to ensure continuity if future funding is delayed.
This amount represents the adjusted funding request after discussions in the forum, reducing the original request from 521k to 356k by adjusting the Strategic Grants and discretionary funding categories.
Specification
The following transfers are to be made from the DAO treasury:
Transfer 589,000 USDC to the Meta-governance safe:
The simulation and tests of EP 6.11 can be found here. The proposal was simulated by proposing, passing, executing, and asserting the difference between states after the ENS and USDC transfer operations. An extra validation will be required when the proposal gets onchain so the calldata can be verified against the description.
This can be checked by cloning the repo and running: forge test --match-path src/ens/proposals/ep-6-11/* -vvvv
The onchain proposal validation has been made and sucessfully passed the verifcation againts its description. The test file can be found here, and it can be run using the same command:
forge test --match-path src/ens/proposals/ep-6-11/* -vvvv
These proposal validations are interesting. I’m curious if you could clarify on the intention behind them? I am concerned that a lot of the potential value is lost due to a lack of a consistent source of truth.
The updated simulation validates that the calldata posted on chain matches the calldata generated by the test script. This is interesting, but it assumes (incorrectly in my opinion) two things:
The calldata that you’ve added to the script is the actual calldata that was posted on chain.
That the calldata you are generating with abi.encodeWithSelector is what is intended.
The context to me looking at this was that in advance of submitting the proposal, @5pence.eth asked me to double check his calldata. He had noted that his encoded numbers looked to be incorrect and didn’t match the intention as described
The original blockful validation essentially demonstrates that if the calldata that blockful have generated is submitted and executed then it will result in a particular chain state but what if the calldata that blockful generates is not what actually gets posted on chain?
This submission flow and validation in my opinion should be a single flow - any submission interface should generate a single Tenderly trace of potential execution. That is the validation.
When I tested with Agora, the flow was buggy. I’ve seen it working before, but when I tried it was erroring.
With Tally independent Tenderly traces were generated for each transaction rather than a single transaction that considers how all the elements of a proposal interplay and their net effects.
In the end the proposal was posted using Tally. Spence opted to not include the calldata in the description noting that doing so adds no value and presents an opportunity for what is posted in the description to diverge from what is actually submitted on chain.
The reality is that an optimal proposal draft submission process should allow intuitive generation of calldata, and create a Tenderly trace of execution. The complementary forum post associated with a potential executable should link to the draft on the governance platform such that when discussion has concluded and social consensus has been reached Metagov can simply click ‘Submit’.
I’m not sure why they do this, but if you look closely, the traces after the first have state overrides that mirror the changes made by previous transactions.