[Draft] D_Agency proposal

🏦 Budgets/Grants
1

D_AGENCY DAO S1 BUDGET

One liner

D_Agency is a collective venture builder.
It is built up from the best talent in D_D to face and build collectively curated products and services that provide value for us and for others.

Summary

Agency DAO is a coordinated effort to assemble a super team of the best developers, designers, and product managers of Developer DAO, offering their collective services to build Products for web3 organizations, creating a revenue-generating program for the DAO, while helping our members have a flexible, well-paid source of income. The proposed budget is 56,400 $CODE to be distributed over four months.

Scope of work:

The first phase of D_Agency will work to set up the foundational structure to enable the future success of the proposed DAO dynamics within the exterior. The initiative will work to complete from one to three paid projects during Season 1. To accomplish that, the following steps need to be taken.

  • Assemble a Core Team that will deliver the initial projects.
  • Work with MBD Guild to build a framework that will funnel projects to D_Agency.
  • Create a base operational framework that will allow the Core Team to deliver on time.
  • Create a Reward System that will enable above-the-market rewards for Core Team, while ensuring revenue for the DAO.

Core Team

A core team is required to manage the process, infrastructure, and strategy and support all the building efforts. An initial managing structure will be needed in order to push the creation of the required relationships, traduce company-like funnels into decentralised structures, and provide the framework of trust that an external organization will need to open a client-provider relationship good enough to be able to target big enough projects to fund this proposal.

A multi-sig safe may be created and operated by the core team.
Current members in charge of the multi-sig:

  • Gordo
  • Erik_Knobl (Will does not receive rewards from this initiative)

Core team members will be evaluated at each season with the set of needs promoted to the next one.

Contributors to Agency DAO are expected to be the star builders of Developer DAO, and will be expected to deliver projects efficiently, and therefore should be rewarded with $CODE at a higher rate than any other project in the DAO, in addition to any other rewards depending on the project where they are recruited. The amounts are based on an hourly rate of 20 $CODE, as suggested in the $CODE Rewards proposal, and an average of 20 weekly hours.
20 $CODE * 80 monthly hours * 4 months = 6,400 $CODE / Season.

After the season, and always with a data-driven perspective to evaluate how D_Agency has performed based on a series of KPIs to be defined during the season.

Role Person Description/Tasks $CODE/S1
Coordinator Gordo * Lead the recruitment process for the initial team. 6,400
  • Stabilish & polish venture funnel. Coordinate with MBD Guild the framework for these relationships.
  • Create a Rewards System for top contributors|6,400|

Assigning CODE

Step one:

Qualifying funnel for interested people in participating at agency-dao.

Step two:

Based on the projects that go into the funnel and get accepted, a part of the season $CODE pool will be allocated to them accordingly based on the project effort per collaborator.

The assignment of $CODE is separated from each project economics and client relationship.

Leadership

Each project entering the final step of the qualifying funnel will need a leader.

The leader will assume responsibility for the project and the assignment of CODE to participants from start to finish. He/she will assume sole responsibility for the correct managing allocation of the tokens between the project participants.

Breakdown of project budgets and percentages:

  • 10% to Developer DAO.
  • 10% to D_Agency Core Team.
  • 80% to all Contributors in the season, based on the agreements.

Client Funnel

Define a qualifying process with MBD.

Create a reward structure for acquiring D_Agency matching clients/ventures.

Define and document verticals and project definitions that match the working possibilities of the team structure.

Collaboration with the MDB team to have collaborative conversations on potential projects that may be able to turn into a client. Document and profile documentation to define the correct client persona.

Seasonal Portfolio

Each season, D_Agency will create a Seasonal Portfolio where they will pool all $CODE received. A detailed DDIP will be released in the first month of Season 1 with the complete definitions on how this Portfolio will work, but the overall concept is that it will be split between all Contributors during the Season, depending on the overall contributions. This will take place at the end of the season.

D_Agency will handle the paperwork and legal structures required for our members to earn compensation with a superior hourly rate. Members simply have to show up and start contributing.

For Season 1, considering the uncertain value of $CODE, and to increase the rewards to our starting team of Contributors, Agency DAO proposes to give 10% of the total pool of the Seasonal Portfolio to Developer DAO.

Success Metrics and KPIs

  • 1-3 projects are on schedule/delivered at the end of the Season.
  • 50% of the tasks assigned to Contributors are being done on time.
  • 60% of Contributors at the end of the Season are willing to continue on the project.

Financial implications

This is the detailed list of all $CODE requirements for the goals of the project:

Concept S1 $CODE
Permanent Roles 6,400
Seasonal Portfolio 50,000
TOTAL: 56,400
3 Likes
2

This idea is dope! I may have missed this, but how will clients pay the agency?

1 Like
3

This is a super interesting proposal :clap: :clap:

Given the plan is to work on client projects, what are your plans with the revenue from this initiative? Seems like a great use case for a separate entity so it can operate independently from the DAO but return value by either some kind of equity/revenue share as well as offering paid roles to contributors of the DAO. This could be a great opportunity for people to earn more meaningful meatspace funds and would love to see us encourage that as much as possible.

Interested to hear your thoughts!

2 Likes
4

The payment can happen in many ways. Each project leader should drive the client relationship and establish that reward. I could be a token if there is a DAO <> DAO relationship, it could be on stables, it could be on dollars and the set up of any needed company for the existence of a project.

The goal of D_Agency is as explained, to behave like a venture builder. In which it provides value and talent to potential projects that may be happening inside de DAO being investors of potential internal “startups” that could be viable products and the same for externals of the DAO.
Once up & running we could even start conversations to behave like an investor if the team is capable enough.

In any case, the breakdown may be happening as explained and should be revisited each season.

1 Like
5

The independency of D_Agency is something that has been through discussions since the proposal of the idea. The revenue would be redirected as described on the breakdown.

In any case, the goal is literally to be a connexion from the D_D talent to the “outside” world with the outside world referring from an economic point of view. And to create the developments needed to make those relationships happen under its hood.

It is literally based on the willingness of testing how that bridge should be landed. Attracting economic/equity value and having the tools and set up to be able to hold it. All without introducing purely economic behaviours into D_D as those change community dynamics for the worse.

2 Likes
6

thanks for the swift answer :slight_smile: his initiative is great, love to see it

The revenue would be redirected as described on the breakdown.

assume by :point_up_2: you meant :point_down:

definitely try to join future calls to get up to speed. re legal structure, getting some standards in place for how these arrangements work between this kind of “subsidiaries”/agencies and also entirely separate projects that spin out of the DAO is an important goal for S1, foundation will likely be retaining counsel to help figure this these out from a tax and legal perspective is that helps :slight_smile:

incubator/accelerator/venture arm of D_D is a long-term no-brainer IMHO so the DAO can truly become self-funded if that can be born out of here to amazing. we’re hoping to tread this path with [DRAFT 1] - B3NZ Season 1 Budget Application and lay some rails behind us so wonder if some cross over there too.

Can I ask how you decided on 50,000 $CODE? Just curious really.

Contributors to Agency DAO are expected to be the star builders of Developer DAO, and will be expected to deliver projects efficiently, and therefore should be rewarded with $CODE at a higher rate than any other project in the DAO

also not sure I could support :point_up:… every other project that is important is currently being paid the same rate, think it’s unfair to break that rule and would love other opinions. cc @stewards

7

legal structure, getting some standards in place for how these arrangements work between this kind of “subsidiaries”/agencies and also entirely separate projects that spin out of the DAO is an important goal for S1,

So, what would be current suggestion for S1?

every other project that is important is currently being paid the same rate, think it’s unfair to break that rule and would love other opinions.

It’s not about the importance. It’s about the quality of the work that needs to be delivered, the dedication, and the speed we would ask in return. We would need to recruit senior builders for these projects, and we would need to reward them accordingly.

8

So, what would be current suggestion for S1?

There isn’t a formal recommendation, yet. Out the gate, it can be run through the foundation. Suspect answer is some kind of US entity depending on where core contributors are based and if it’s owned by the foundation, or not, but I’m not a lawyer/tax attorney etc. etc.

It’s not about the importance. It’s about the quality of the work that needs to be delivered, the dedication, and the speed we would ask in return. We would need to recruit senior builders for these projects, and we would need to reward them accordingly.

Yeah I get that. The upside here though for the core team is pretty massive if it went really well. Plus, how are the senior people doing other high quality work across projects/guilds going to feel that this group have some kind of special privilege/are valued more than them?

It breaks the model that $CODE rewards are flat across the DAO. Particularly when there is a real, potentially large, financial upside to this for the core team.

$CODE is about Governance. Do the people on this project deserve more governance that other people on other important projects?

This assumes you’re doing higher quality more/important work than any other guild/project with no evidence to support that. Seems to me it would be better for the leads of this project to choose the best people rather than create this discrepancy between people’s value at a fundamental level as the upside if it is successful is still there.

9

Yes, it is, but, it is of course an initial approach, able to be changed after it is kicked off and susceptible to any comments, that’s the draft goal.

When I say revenue is it literally the revenue the project has generated after being finished successfully.

I’m not considering $CODE as a source of revenue but as a governance token. In fact, my humble opinion is that CODE should never have economic value, but social and community value. I’ve seen many examples of failing to do so. I’ll try to summarise a text defending this approach.

I would love you to develop here your thoughts, I’m really interested in experimenting and pushing this concept further. Blockers, ideas, pushers, examples… etc.

I do not have a general overview of the DAO as there is a lot going on, so of course open to being discussed.
Putting my view of $CODE allocation. Just to point out that for me in order to be a long-term approach it should be non-buyable, non-tradable, only earnable, and by social / community value and then adding a lot of potential layers of diminishing during time, etc to avoid stacking and promote activity.

Thanks for your response!

10

This may just be a misunderstanding on my part but I’m under the impression that this proposes that Agency contractors would receive an amount of CODE as compensation for their work for the DAO. The only way I could see that making much sense is if the amount of code they receive is allocated as a portion of the CODE the D_D sends to the Agency based on the value returned to D_D.

I’m not all that into the idea of a flat hourly CODE rate across the DAO in the first place but would rather create systems that allocate CODE based on the value created for D_D.

2 Likes
11

I too would like some clarification on this matter with regards to @Colin4ward 's point. A flat rate does not incentivize people to work at a high level and will serve create aggressive mediocrity. In a public facing, revenue generating entity working with partner organizations, I do not believe that should be our target.

1 Like
12

Very cool idea. I think @Colin4ward & @kempsterrrr questions/points about value alignment btw the Agency and D_D have merit. Would be smart to get crystal clear on that before launching this.

I would caution against only allocating 10% of revenue to Agency overhead. To be successful you will need marketing, biz dev, biz ops, talent coordination, and legal advisory at a minimum. Good talent doesn’t come cheap and people won’t work for native tokens for long.

2 Likes
13

I believe the idea here is the team delivering on the project that generates revenue receive 80% of that revenue to divide between them how they see fit. outlined here:

  • 10% to Developer DAO.
  • 10% to D_Agency Core Team.
  • 80% to all Contributors in the season, based on the agreements.

Is that correct @Erik_Knobl @Gordo ?

This may just be a misunderstanding on my part but I’m under the impression that this proposes that Agency contractors would receive an amount of CODE as compensation for their work for the DAO. The only way I could see that making much sense is if the amount of code they receive is allocated as a portion of the CODE the D_D sends to the Agency based on the value returned to D_D.

Regarding the $CODE allocations. Think there are some fundamental questions in Colin’s point here we should establish. Proving $CODE as an incentive to stand-up this project is 100% something I’d personally support, should everyone involved continue to get lots of $CODE for the work season after season, not so sure. Guess it will depends on how this all plays re structure and value returned etc.

Reiterate my point that I don’t think anyone should get a unique hourly rate of $CODE though and I couldn’t support this as a @stewards knowing that. The team have the potential here to see a massive upside from the work alongside their Governance allocation, increasing the hourly rate by 5 $CODE breaks the system/model of flat rate and risks setting a bad precedent. why is this work is more valuable to the DAO than say School of CODE?

would encourage other @stewards to weight in here

14

@mulford.eth @kempsterrrr @Erik_Knobl @chuck25

Regarding the allocation of CODE:

Problem:

How to reward (in governance terms) to people who contribute under the umbrella of the Agency?

Solution:

(potential)

Basis:

Open to be improved was to distribute the D_D Agency the absolute allocated $CODE (Seasonal portfolio => 50,000) between the ones who provide services during the season, through D_D Agency.

But, of course, this does not work perfectly because it is on a percentage basis based on an absolute allocation of CODE to the D_D Agency. So as more people join less they will receive. Not good, no incentives in providing value/service, in fact, it generates the opposite, picking less with fewer people.

Potential solutions:

  • Remove the fixed absolute portfolio and allocate based on value. Easy to be measured and based on “profit” and other KPIs
  • Reward with fixed values to D_D Season members
  • Reward with variables to service providers, but, as service providers, only if they show a willing, based on points to detail in the future (more than one project done with D_D Agency, lateral contributions that helped Agency flourish, contributions to the DAO in other terms, etc… )

It has been the core point of view since the initial idea. The goal is to have a working structure that behaves for real and interacts for real. Those percentages are to kick off and to do it fast.

In any case, those percentages are based on the project finished and executed. Assuming we are working with MBD guild, [DRAFT 2] needs to go deep in this section.

I do not want in any case to end up overplanning based on a potential future. The goal is to be agile, do stuff, fail, and modify and loop again.

Yes, we had discussions about how to allocate to the providers that make that contract work. I think it is important to reward accordingly, especially at the initial stages as those people are the ones that will make this happen. If we are putting this into doubt is to rise it up.

So… I think its time for [DRAFT 2]

1 Like
16

Thanks for your detailed response @Gordo - are you already working on another daft? Given the deadline is tomorrow (Sunday) @ Midnight UTC you may not have the time to do so.

My suggestion would be to disconnect the two types of rewards here. Governance and share of revenue generated. The idea behind rewarding a flat rate in Governance was to create an equal (albeit maybe not fair) way to budget for S1 so we didn’t have blockers in Governance (like this convo) with everyone trying to figure out what they feel their value is worth in $CODE, vs others.

$CODE allocation is to incentivise/reward initial action to be taken in elevated Governance, not make a financial difference to their lives. Others may have a different view but I don’t think increasing the $CODE per hour from 15 to 20 is going to be the thing that motivates the best people to join this initiative. I suspect what will motivate them is the quality of the opportunity to build something great and earn more meaningful returns from project revenue.

What would be great to see updated on this proposal is an estimation (fine to be generous) of the hours the Core team will need to perform to set up this initiative and then use that to calculate the $CODE allocation. Think it is fine to add a bounty pool or extra % on top to ensure there is a $CODE budget to reward others but personally don’t think continuing to reward every contributor for elevated Governance for all work they do for every via this initiative necessarily makes sense.

$CODE to reward the Core team for setting this up and then maintaining it though does. Others may have different views but that makes the most sense to me.

In case it is useful for inspiration, here is how bankless consulting scoped their budget application

17

I was on it

It was like that, I was trying to clarify the section explaining the rewards per project and with CODE separately. (I’m as well not a fan of hourly CODE)
Your comment gave me an idea to reward the allocated code to Agency collaborators.

As it is an absolute value and there is no other way. In order to push distribution and motivation. I propose creating distribution slots on those 50k, which at the end of the season are distributed (by kudos/value offered to the Agency):

  • 1st. 5000
  • 2nd. 4000
  • 3rd. XXXX

And so on… until let’s say 10 slots

Instead of requiring to put hours on an abstract, let’s work on the reverse, if criteria are met (reach goals) unblock CODE. I did not even count on having CODE allocated as the motivation was from a business perspective a good idea and a potential cool to work environment so seeing it raise and being able to profit from it accordingly is motivation enough.

18

I really don’t think there needs to be this 50k CODE budget, certainly not with no real definition of how that number has been calculated and where it is going. no other revenue generation initiative is doing this, they are estimating hours they’ll put in and then calculating the $CODE rate. this is what I think should happen here given it is what is explicitly defined in [DRAFT 2] Rewarding Contributions in $CODE and that I just don’t see why this team should get way more governance rewards than anyone else.

the real rewards here are the revenue split.

I understand this hourly calculation isn’t ideal for most people but we do not have an alternative system and the deadline is today. It was created to avoid these protracted debates and make things simple/equal, albeit maybe not fair vs value created.

Believe these estimations could be pretty easy… you and @Erik_Knobl decide how many hours you’re each willing to contribute per week, then multiply that by roughly how many core team members you’re expecting to have.

we should definitely re-examine this in Season 1 though regarding the hourly rate and if we should continue using it, or not.

19

[Draft v2]