(RFC) The role of delegates in Delegate Contribution Program (DCP)

[Curia]

The purpose of this proposal, to be separate from Co-Creation Sprint - Delegation Discussion Thread is to summary the discussion about the roles of delegates into a concrete proposal, therefore when the OC / AC committees form, they can use these key findings from delegates as a consideration.

Shout-out to @alexsotodigital for the feedback and for initiating the idea of Support Squad which now has become part of the Delegate Contribution Program (DCP).

After analyzing delegate feedback from the Miro board, we came up with 4 Strategic Pillars that align with the goals Scroll aims to achieve in this phase, which mainly focus on price performance and increasing volume.

The Strategic Pillars include:

1. Ecosystem Vitality (Onchain Growth & Liquidity)

2. Network Resilience & Security

3. Data Transparency & Open Analytics

4. SCR Token Utility & Economic Flywheel

There were originally 11 roles in total. However, from the meaningful feedback from delegates, there is broad agreement that the role of delegates needs to evolve in the DCP to be more than just voting or providing rationale and feedback, and that there should be clear delegate responsibility for each role, aligned with Scroll, to ensure the work actually moves Scroll forward.

Following the feedback “Fewer roles, but better defined,” adjustments were made by using a 2-system model as suggested by Alex, resulting in 8 roles in total. A poll was then created to answer:

Which specialized roles do delegates feel are most critical to launch first in the Delegate Contribution Program?

From the result of 4 people who voted, delegates ranked Program Coordinator as the highest priority role for Scroll.

Final Ranking (Highest → Lowest Priority)

Rank	Role	Avg priority score
1	Program Coordinator	2.0
2	Biz-Dev	4.0
3	Scribe	4.5
4	Content	4.75
5	Growth	4.75
6	Analyst	5.0
7	Weaver	5.0
8	Community	6.0

We do think the sample size is still too small to jump to a strong conclusion about which roles are the most critical. However, it does show that delegates generally agree on this set of roles.

We believe the next step is to run an experiment, where at least one delegate contributes to each role for two months, and explore the actual workload involved. This would help determine whether we should:

a) stop the role,

b) continue the role as is, or

c) add more people to that role.

Running this experiment would raise several open questions for the DAO:

• How can we measure the impact of contributions in a fair and consistent way?

• What are the expected time commitment, duration, and capacity requirements for each role (e.g., hours per week, commitment period, and number of delegates per role)?

• What eligibility and role-allocation rules should apply (e.g., verification requirements and whether a delegate can assume multiple roles)?

• What accountability mechanisms should exist if a delegate fails to fulfill the responsibilities of a role?

[Eureka]

From the 8 roles listed, there appears to be significant overlap with roles currently performed by both the Operations Committee and the Foundation.

Overlap Observations

Program Coordinator
This role already exists within the Operations Committee and is currently held by @EthereumTGU. Introducing a parallel role at the delegate level risks redundancy unless the scope is clearly differentiated.

Content, Growth, and Community
These responsibilities appear to overlap with Marketing Operations, currently covered by @gabriellamena. Unless there is a DAO-specific mandate that is not being met today, this may not justify a separate delegate role.

Business Development
Historically, meaningful BD work by DAO contributors has been challenging. We also assume the Foundation is already handling core business development. Introducing this as a delegate role may create unclear ownership and expectations.

Scribe & Weaver
Given the DAO’s current activity levels, these functions could reasonably be consolidated into a single role. Maintaining two distinct positions feels disproportionate to current needs.

Analyst
This is the role that would benefit most from further clarification. Specifically:

• What decisions are these analytics meant to inform?
• Are we talking about governance participation metrics, treasury analytics, protocol KPIs, ecosystem growth, or something else?

Clear deliverables and outputs would help determine whether this role is additive.

Answer to open questions:

@Curia

Running this experiment would raise several open questions for the DAO:

• How can we measure the impact of contributions in a fair and consistent way?
• What are the expected time commitment, duration, and capacity requirements for each role (e.g., hours per week, commitment period, and number of delegates per role)?
• What eligibility and role-allocation rules should apply (e.g., verification requirements and whether a delegate can assume multiple roles)?
• What accountability mechanisms should exist if a delegate fails to fulfill the responsibilities of a role?

• A monthly timesheet makes sense, where contributors list tasks performed, time spent per task, and the projects they contributed to. This creates a lightweight but consistent accountability mechanism.

• This should be role-dependent. However, given the overlaps highlighted above, some roles may not justify a standalone time commitment at this stage.

• The verified delegate framework should be sufficient for determining eligibility. Adding additional layers may introduce unnecessary friction.

• Since an Accountability Committee already exists, it would be appropriate for these operators to oversee delegate role performance and enforce standards, rather than creating parallel oversight structures.

[alexsotodigital]

Thanks @Curia for opening this thread.

I want to offer a brief recap and share a few reflections to clarify intent, address points of confusion, and refine our shared direction.

1. Let’s start from operational needs, not assumptions.

It’s been great to see delegates mapping out potential roles, although only four of us responded to the poll that yielded these results.

That said, if the DCP is meant to support execution, then the Foundation, Operations Committee (OC), and Accountability Committee (AC) should first articulate what support they actually need. Without that, we risk short-term bias, designing roles that prioritize visibility over systemic impact. Delegates can then step into those defined needs, rather than projecting assumed gaps.

2. The real question: where does Scroll’s work happen?
We know centralizing all execution within the Foundation is neither scalable nor aligned with Scroll’s goals (whether for regulatory or resilience reasons). That means the DAO must hold part of the operational load. The DCP was conceived as a way to house that decentralized execution. I personally proposed merging the DCP and OC structures to reduce redundancy.

@alexsotodigital

So I’m left wondering:

• What “operations” would the Operations Committee execute that wouldn’t fall under scoped roles within the Delegate Contribution Program?
• If their function is primarily supervisory or meta-coordination, is it worth electing a group for that, instead of assigning that work to capable contributors via roles?
• If they are also executors, why not treat them as operational roles (with defined accountabilities and skill requirements), rather than bundling execution under an elected group where popularity can outweigh qualifications?

Now, after some community calls, I understand that the separation (between the OC and the DCP) is intended to allow talent pools that include non-delegates to join the Operations Committee.
Although I believe there are simpler ways to resolve this (such as creating different eligibility criteria for each role), I assume that we will stick with both structures in the short/medium term.

@Eureka

From the 8 roles listed, there appears to be significant overlap with roles currently performed by both the Operations Committee and the Foundation.

Seen this way, if the question is: is there overlap? The answer is yes, and it is intentional: the DCP is executing work that supports OC goals.

In other words, Verified Delegates in the DCP aren’t replacing the OC; we’re augmenting it with tactical support, especially in areas that are lightweight or require specialized skill sets that don’t justify full-time positions (within the Foundation).

3. Not all roles are created equal, and that’s fine.

@Eureka

Scribe & Weaver
Given the DAO’s current activity levels, these functions could reasonably be consolidated into a single role. Maintaining two distinct positions feels disproportionate to current needs.

It’s worth clarifying that while they were originally presented together in the “Support Squad” framing, Scribe and Weaver serve different functions. The Scribe captures process documentation, meetings, and governance records. The Weaver identifies cross-cutting insights across threads, calls, and proposals. They may not both be urgent right now, but they are distinct.

In other words, the point is not to defend a particular role, but to create it based on the specific and current needs of the organization. Roles are created, changed, and destroyed. The important thing is to refine the system, not to define a perfect role.

@Eureka

Program Coordinator
This role already exists within the Operations Committee and is currently held by @EthereumTGU. Introducing a parallel role at the delegate level risks redundancy unless the scope is clearly differentiated.

Similarly, while “Program Coordinator” ranked high in the delegate poll, its true it may not be necessary to instantiate it within the DCP right now.

Anyway, the idea behind creating it was to highlight that this role is already being performed by someone in the Foundation or OC (and to highlight who, in order to improve accountability) and to open the door to programs that can be executed by the DAO down the line.

In summary:

• Let’s co-design DCP roles based on clearly expressed operational needs from OC/AC/Foundation.
• Let’s not fear role overlap if the intent is to support existing structures, not compete with them.
• Let’s treat role design as a dynamic process that evolves with Scroll’s maturity, not a fixed menu to launch all at once.

Appreciate everyone pushing this conversation forward