[EP 5.24] [Executable] Term 5 Q4, Collective Working Group Funding Proposal

5pence.eth · October 31, 2024, 1:06am

Status	Draft
Voting	Disputed and Linked Incorrectly to linked from this Tally Proposal
Next Steps	Will Be Re-Posted w/ new EP# by Nov 2nd
Author	5pence.eth

This proposal executes all three Working Group funding requests for the October 2024 funding window as passed in EP 5.17.1, EP 5.17.2, and EP 5.17.3. For more detail, view the ENS Governance docs at Funding Requests

Proposal Components

1) Meta-governance Funding Request [EP 5.17.1]

The Meta-governance Working Group requests funding to fulfill anticipated budgetary needs through the next formal funding window in April 2025.

Destination	USDC	ETH	$ENS
ENS Meta-Gov Main Multisig	254,000	0	0

This amount will cover all expected expenses while maintaining a 100,000 USDC prudent reserve to ensure continuity if future funding is delayed.

2) Ecosystem Funding Request [EP 5.17.2]

The ENS Ecosystem Working Group requests funding to support operations through April 2025. This is the only funding request of Term 5. The working group is responsible for growing and improving the ENS Ecosystem by funding builders and projects that are ENS-specific or ENS-centric.

Destination	USDC	ETH	$ENS
ENS Ecosystem Main Multisig	836,000	0	0

3) Public Goods Funding Request [EP 5.17.3]

The ENS Public Goods Working Group requests funding to support operations through the next funding window in April 2025. The funds requested extend current needs through to next term to ensure that next season’s stewards have available funding before the next funding window.

Destination	USDC	ETH	$ENS
Public Goods Main Multisig	226,000	0	0

Specification

The following transfers are to be made from the DAO treasury:

Transfer 254,000 USDC to the Meta-governance safe:
- Address: 0x91c32893216dE3eA0a55ABb9851f581d4503d39b
Transfer 836,000 USDC to the Ecosystem safe:
- Address: 0x2686A8919Df194aA7673244549E68D42C1685d03
Transfer 226,000 USDC to the Public Goods safe:
- Address: 0xcD42b4c4D102cc22864e3A1341Bb0529c17fD87d

Total transfer amount: 1,316,000 USDC

Calldata:

5.17.1 Tx to Metagov

{
    "target": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
    "value": 0,
    "calldata": "0xa9059cbb00000000000000000000000091c32893216de3ea0a55abb9851f581d4503d39b0000000000000000000000000000000000000000000000000000003b23946c00"
}

5.17.2 Tx to Ecosystem

{
    "target": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
    "value": 0,
    "calldata": "0xa9059cbb0000000000000000000000002686a8919df194aa7673244549e68d42c1685d03000000000000000000000000000000000000000000000000000000c2a57ba800"
}

5.17.3 Tx to Public Goods

{
    "target": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
    "value": 0,
    "calldata": "0xa9059cbb000000000000000000000000cd42b4c4d102cc22864e3a1341bb0529c17fd87d000000000000000000000000000000000000000000000000000000349ea65400"
}

AvsA · October 31, 2024, 6:14pm

Addendum

There are some differences in the text above and the one posted on tally. The main discrepancy is that the actual vote also includes the required funds for EP 5.19 (Blockful Security Bounty) and EP 5.21 (Governance Distribution Pilot).

Destination	USDC	$ENS	Social Proposal
ENS Meta-Gov Main Multisig	254,000	0	5.17.1
ENS Meta-Gov Main Multisig	100,000	15,000	5.19
ENS Meta-Gov Main Multisig	0	30,000	5.21
Total	354,000	45,000

The reasoning behind merging all these 3 working group funding proposals and 2 social proposals as a single executable is to reduce the effort required by delegates. These proposals have already all been voted and approved, and the executable transaction is where there is a higher danger of something going wrong, so it’s very important to make sure every executable proposal is carefully scrutinized. I believe that having them as 5 separate proposals (or even 2) increases that risk.

nick.eth · October 31, 2024, 9:10pm

I am voting against this on procedural grounds. Bundling the funding proposals for the working groups is allowed by the WG rules, but bundling unrelated proposals is contrary to the documented governance process. Furthermore, the text of the vote does not clearly specify the individual proposals the voter is agreeing to by voting in favor, or provide a breakdown of how the funds are being allocated.

The governance process is frequently adhered to more loosely than it should be - often proposals have been put forward for vote even before being committed as EPs in the governance docs, and in some cases without correct numbering - but thus far we have at least followed the process that proposals are put forward and voted on individually.

I’d also note that:

5.19 needs a new EP for the executable proposal. You can’t put the same proposal up for vote multiple times. The new EP can simply state that it’s requisitioning funds for the proposal approved in 5.19.
5.21 needn’t have been posted as a social proposal in the first place. We abandoned social proposals in advance of executable proposals in term 1 of the DAO, because it doubles the voting overhead for delegates, while only saving a little gas money in the event of a ‘no’ vote on the social proposal, which is rare. Current process doesn’t require executable proposals to go to a snapshot vote first.

I’d also note that this thread still hasn’t been updated with the voting period and a link to vote. I’m aware that the process is manual and error-prone, but proposers - and MG stewards - should be responsible for ensuring the state of votes is transparent, and that voting is as easy as possible.

5pence.eth · October 31, 2024, 10:25pm

I want to comment that the collective proposal at the top of this thread was prepared and intended to be posted “as-is” in accordance with the Working Group rules that were codified in [EP 1.8].

The choice to put this proposal onchain and include the assets needed to cover the Blockful Bounty Proposal and the Retroactive Governance Proposal into this single executable was not expected by the Meta-governance group, and isn’t standard practice historically in the ENS DAO.

Because of the discrepacies, I wasn’t willing to link this thread to the proposal Avsa put onchain as they’re clearly not the same.

I commend Avsa’s inetntions of streamlining and securing the governance process with fewer votes, but I think there could be bigger problems created by creating omnibus onchinan executables that don’t have clear lines of atribution or casusality.

I would prefer to see this original Working Group Funding request proposed onchain as it is in the top of this thread.

I support the other proposals included in this Executable, but because I believe they should be separate, I’ll be voting “No” on this proposal.

lefterisjp · October 31, 2024, 10:43pm

As others said here I also voted against this due to procedural grounds and multiple discrepancies seen in the comments of the proposal in Tally

alextnetto.eth · November 1, 2024, 12:30am

I was the one who suggested bundling the proposals in the metagov call 2 weeks ago, and this week, we also discussed it. There were some concerns, but there was a consensus that it was mostly beneficial. So, any misunderstanding around that, is on me.

Aggregating three social votes that had only token transfer in their scope into one EP together saves delegate time, gas fees, and operational resources on proposing and verification of proposals for security. The same benefits as pointed out by @AvsA.

It’s also not explicit in the docs, but that’s a more subjective interpretation. Mine is: For this to be against the governance process, it should say somewhere that each EP must be voted independently in all phases.

Still, I’m voting against it because I think the proposal’s title and description should expose this clearly, with the value related to each social vote being separated.

There were already past EPs that had combined social votes. Though it was some time ago, March of 2022 haha

nick.eth · November 1, 2024, 7:46am

Ah! Thanks for the clarification.

This seems like an odd take; the docs describe the process and make no allowance for bundling. If it’s not explicitly allowed, it’s prohibited.

Fair cop!

alextnetto.eth · November 1, 2024, 7:58am

That’s probably the best way to interpret it!

simona_pop · November 1, 2024, 10:10am

echoing all the concerns above re procedure and general misalignment with governance best practice - have voted against

estmcmxci · November 1, 2024, 6:40pm

Alex, I believe ENS delegates possess enough discernment to evaluate each proposal on its own merit. Each proposal deserves independent evaluation.

We should hold ourselves to a higher standard and trust that delegates are well-qualified, capable of swiftly understanding and judging each proposal individually.

Executable proposals should not be treated as perfunctory tasks or viewed as mere chores.

—

On the contrary, I believe consolidating multiple proposals in a single move harms the integrity of the DAO’s governance process.

This approach not only jeopardizes each individual proposal but also undermines the trust that each proposer placed in the proposal process itself.

—

100%—this was the intention from the start. Frankly, I was dismayed to see that the proposal, EP 5.24, did not align with the text authored by @5pence.eth, nor did it adhere to the Working Group ruleset, specifically rule 10. Instead, it included extraneous specifications, such as an additional 100k USDC and 45k ENS to the Meta-Governance Multisig.

These additions should have been presented in separate proposals, as we had discussed. Unfortunately, the proposer made a last-minute maneuver, which became my personal ‘October Surprise.’

—

I am corroborating @5pence.eth’s claim. This was completely unexpected.

—

@nick.eth, just in case, I wanted to bring the Voting Period Bulletin to your attention. This is a thread I’ve maintained since April, which aggregates proposals and provides essential information along with a link to each vote. I update it as proposals go live and plan to continue maintaining it.

—

I disagree. As someone present at each Meta-Governance call, I observed that no consensus was reached. It was, in fact, very confusing to me, and I had to reach out to @AvsA to confirm his intentions and whether they aligned with proper procedure.

—

Unfortunately, I will vote ‘Against’ this proposal in the hope that we can follow up with a well-structured proposal to ensure the continuity of the Working Groups.