DXdao Budgeting

The stated goal of the DXdao is to develop, govern, and grow DeFi protocols and products. The DXdao has a treasury currently worth about $1.2M which it can use towards this goal. As the community grows and product efforts gain momentum, it is important to bring forth the topic of budgeting.

First, I think it is important to do budget planning with conservative assumptions about the treasury value. While it is possible that more money could be infused through continued minting of DXD from the bonding curve, or that the value of the treasury, currently denominated almost entirely in ETH, could appreciate, I believe it is important that the DXdao plan with the ETH it has.

I propose that DXdao set a budget that allows for a 12 month runway. The aim is to build products that will strengthen DXdao’s position, increasing its treasury in the short term through stronger valuation of DXD and in the long term through product revenue growth. If DXdao spends the money well, and the treasury value grows, DXdao can then reconsider the length of its runway and its burn rate.

With just over 4900 ETH in the treasury, a runway of 12 months would translate to a spend of around 400 ETH per month. At current ETH prices around $240, that translates to a burn rate of about $96,000 per month.

How should the DXdao spend its money?

With a nascent product suite, I think that product development should receive the lion’s share of the spending. And the rest of the spending should be on business and community development. This could evolve over time and in response to the kind of traction the products pick up. I think a good starting ratio could be 3:1. So the goal would be to get to spending $72,000 per month on product development, and $24,000 per month on business development.

What is the DXdao’s current spend rate?

Here are the two main current work proposals:

From these we see the spend rates can be approximated as follow:

$3,500 per month on biz dev and marketing
$12,166 per month on software development

If we take the target spend rate to be the $96,000 per month mentioned above, then we can see there is still room to increase our spend. But there is also a lot to spend on. For one thing, the current work proposals are under market rate, and if the DXdao wants to retain these folks, I expect it will need to increase compensation. And there are several projects which need to be staffed, including but not necessarily limited to further developing Mesa, Omen, and the DXdao home site, as well as launching DXswap and potentially developing Mix.eth. Furthermore, there will need to be attention given to the DAOstack platform, the Alchemy UI, and security audits for new code, which will involve engaging with a security auditing firm.

At $8,000 per month average pay, around 12 people can be supported full time. This could be roughly 3 active product teams, and one business development team. This should be further augmented by issuing reputation in lieu of crypto compensation.

For onboarding new workers to DXdao, I think it makes sense for everyone to initially start at a lower rate while they are building up a rapport for the DAO. This will help make sure the DXdao doesn’t commit funds to underqualified or underperforming people, and will hopefully filter for people who are passionate about the DXdao and want to be involved for the longer term. There also should be a preference for workers who wish to earn REP, as opposed to those who just want to make money.


Imo it’s perfectly reasonable that good development teams with great things they want to build for the dxdao may want to just get paid in ETH and may not want the illiquid responsibility/liability of governing.

Technically REP isn’t money and it’s a community asset. Devs like to do what they do best, develop, and that does not mean they don’t care about the DAO. You can be a valued member of the dxdao’s community and not have or need REP. There already are people like this.

With regards to Mix.eth, being conservative is something I agree with.

A good middle ground could be some way of paying a portion in DXD after a certain period, so the dev team has a stake in our asset. This also incentivizes the team to plan for a strong revenue stream with their product, which effectively pays them more if it succeeds.


I believe the majority of the spending should be on development, with regard to marketing. Alot of marketing generally is a scam and has to come from a reputable centralized source, the most important question is what do the DXDAO holders get from these budgets. If you incentize DXDAO holders and REP holders they will do most of the marketing for the development team, unless these development teams such as OMEN want to have their own marketing internal budgets from the displacement of capital all of which is needed because the community has to do social media engagement and otherwise relay that to aformentioned communities.


Also I do think we should be giving runway approaches, so we can displace capital but if a team is not meeting expectation budgeting is reduced and limited until the time periods and quality of the product is met. I understand there is unintended outcomes for development so leeway can occur in time periods but with regards to development quality surely not.

Some random thoughts:

I would say that the bulk of marketing spend should be connected to product launches and campaigns, with a minimal retainer for ongoing needs (social media, explainer blogs, website, and such).

On the dev side, it should be a bit clearer how spec/implementation funding is split. Right now I’m working on a pretty lengthy proposal for “DXmint,” which is a Synthetix fork, and a big part of what’s holding me back from fleshing it out further is the uncertainty of its funding (compared to other pitches the Curve Labs is working on) and the extent of the work going into the proposal itself (which is becoming a significant amount of unpaid work at this point).


What if we use a small amount of the funds in a lending protocol like Compound or Aave, and spend the interest instead of the raised money?


Completely agree with this. I feel that the DXdao community is currently growing into the funding it has now raised and answering some questions for the first time. Hopefully before long the DXdao can gain a transparent view into its funding priorities and allocations.

Regarding the idea of Curve Labs working on a Synthetix fork, I really appreciate the ambition and I think the ability to carry out serious forks is a core part of DXdao’s value prop . . i.e. “Decentralize X.” However, I would be concerned that it is too ambitious of a project given the DXdao’s current budget and competing priorities. To de-risk the effort and make sure you are not committing too much unpaid time drafting the proposal, I think it could make sense to float the idea in DAOtalk or on the BizDev call and get some community feedback upfront.


A budget is a great idea that will provide certainty to build for the long term.

To me, there are two parts to this discussion:

  1. Where and how much to spend

  2. How to structure it and make decisions about spending and budgeting

To touch on #2 first, there will be recurring costs (or fixed) that are paid every month of the budget (like salary) and variable costs that are one off payments (like a security audit).

The two work proposals that John linked to were for defined dev and marketing efforts for a specific period of time (45 days). Going forward, these should be recurring costs and codified into monthly budget line items, because there is consistent work that is needed by the DXdao for marketing and development.

When discussing additional expenditures, we should ask whether it is a recurring cost or a variable cost and know that recurring costs can have a larger effect on the burn rate.

In terms of structure, there should be set categories (or departments) to track how costs are allocated. Separating costs by product seems like a good way to focus resources. So instead of just “marketing”, Omen would have a budget and a portion of that would be for marketing, but that would be separate from Mesa’s or Mix.ETH’s budget. Of course, DXdao needs its own marketing and community management at the DAO level.

Some categories that I was thinking:

  • Core devs
  • Core community marketing
  • Governance
  • Partnerships & biz dev (DAOstack & alchemy?)
  • Mesa
  • Omen
  • DXswap
  • Mix.eth
  • Legal?

At the moment, I don’t know if anything should be a recurring cost except for Core Devs and core community marketing but I think some of the products might have known one-time costs. DXdao could set aside funds for a product’s launch and then have a team allocate them to more specific items when the date nears.

MakerDAO’s process for on boarding personnel can be found in MIP 7. They currently have 1. Oracle Team 2. Smart Contract Team 3. Risk Team 4. Legal team, in addition to the governance facilitator (now 2 people).

Returning to #1 (where and how much to allocate) I don’t have much to say on the amounts but in general, I think we should try to limit our recurring costs and identify and allocate for specific tasks (say, an updated white paper or a 2 month long marketing campaign) when possible.

Also, we should strive to pay a competitive wage in ETH (or Dai), but I think it makes sense for most people to start as “part-time workers” first to contribute to the DAO (perhaps its complemented by REP or DXD) and then a more typical salary. As John said, the two work proposals paid below rates. and given the previously demonstrated work, the compensation should be raised to market rates.

I also think paying part of compensation in DXD aligns interests between the DAO and the recipient (while also putting downward sell pressure on DXD).

I created a google sheet of a sample DXdao budget. I put the existing recurring costs (core dev and core community marketing) and then just added a bunch of random variable costs with amounts to visualize it better. Feel free to play around with it, if you want to add a variable cost, you can do it on the second sheet.

Anyway, just some additional thoughts. Would love to hear more from others on where costs might pop up and best ways to allocate funding.

Also, there could be a distinction between the budget (planning) and funding (through voting). A budget might include things that still need to be approved by REP holders down the line.


Thanks for making this google sheet! Would it be possible to see how the numbers change based on number of devs and dev salaries? It’d be super helpful to know how much DXDao can afford to pay devs given the discussion around current rates being far below market.


There are some great ideas here touching on a lot of different subjects, and coming from different perspectives, so I’ll try to synthesize and contribute a bit as well:

Budget: Yes, product development should receive lion’s share of the spending. Whether the ratio between development and biz dev is 3:1 or some other ratio, I agree with @Powers that the more important ratio to focus on would be to minimize recurring costs over variable costs. The thing I would add about any marketing budget, that can piggy back on @icocountdown’s claim that “Alot of marketing generally is a scam” is a desire to stick to–for lack of a better word–grassroots marketing styles. When I think personally about the projects I’ve been drawn too it hasn’t been through slick marketing campaigns but through incentives that encourage users to get involved and participate with the platforms that dxDAO builds. Projects like Synthetix, Keep, Balancer are all running campaigns rewarding early adopters of their platforms. So, I would much rather see a one-time variable cost line-item on the budget for an incentive like Mesa LP Incentive or Mesa Challenge Tasks, then recurring marketing costs that don’t have the same quantifiable deliverables as dev work.

Then to touch on @ingalandia point about what token is best to pay for budget items, I am open to idea of paying a certain about in DXD, because it’s akin to getting stock options, but I think it would be important that their is some kind of vesting period. In terms of who to hire and onboard, and prevent committing funds under qualified or underperforming people it seems we could do one of two things: The first would be post tasks that we need done and let teams bids on them. The second would be in line with the idea of having budget divided and separating costs in terms of project. For each project, Omen, Mesa, etc we could basically assign a project manager that would have recurring costs (salary) and then a variable cost budget to complete the dev tasks needed for that project. The PM would be able to select from bids–e.g. part-time contractors needed to complete specific tasks–that he or she deemed competent to complete said task.

The rationale behind this is that if we are giving ourselves a 12-month runway want to aggressively grow and gain market share against competitors then we will want active dao members to divide our energies and be specializing in a specific sub-project or two.

Lastly, any budget we choose for the next year is using current ETH price, and since the Treasury holds so much ETH any budget that’s passed should imo contain a strategic plan for how to hedge given different possible ETH fluctuations. Something like a bell-shaped curve and what we would do in given situations, so if it happens we can act fast and not have to take time and discuss. I’m saying, basically try to decide what treasury does to hedge if ETH moves 10%, 20%, 30% within x amount of time.

So, using the Google Doc Sample Budget by @Powers as an example, in dollar terms a 5% increase in ETH will increase Treasury by close to $60,000, which is more or less 1-month budget.


I’ve already presented the fork on a bizdev call, and the response was positive. But, to be honest, I don’t think collecting ‘community feedback’ in this way makes sense. I’d rather just speak with the REP whales directly (early on in this process) and see what they’re willing to pay for and get their feedback. It’s just not clear to me who they are or what the right line of communication is to interface with them.

Once there’s a greater sense of confidence from the decision-makers directly, then collecting inputs from a wider audience makes sense imho. A dedicated and specific channel to interface with the main decision-makers would be immensely helpful.


I remember you mentioning that, it did seem like a cool idea. Would it be possible to do a 2-3 paragraph summary in a daotalk thread?

1 Like

You need to be aware that whales care about community feedback. It is not like they are hanging out in a private group chat and know exactly what outcomes will happen on proposals. Especially whales are worried to vote on the wrong outcomes because they will get slashed 4% of their REP. Therefor community consensus is also very important for the bigger REP holders.


Hey Corkus,

I think you’re misunderstanding my intent here.

In most project specification processes (especially for larger projects), the process is to get buy-in and inputs from key decision makers, create a version of the project plan, iterate with this small group to reach a certain level of consensus, and then expand to the large group — in our case, the community. This process is typically used to minimize overhead in regards to creating the project proposal itself—in the two years I worked at DAOstack, I saw plenty of people stop proposing to the Genesis DAO because of the excess overhead occurred by working on proposals that never got passed. It was, in my opinion, a notable reason for “DAO member apathy,” and some great folks noped out due to the disorganization.

It’s possible I’m overthinking this and just throwing something on DAOtalk works, but it’d be great to have better signals specifically from key decision-makers early on in the proposal creation process — at the end of the day these are the only signals that matter in regards to getting a proposal passed. This is what I mean by “interface.” Perhaps we can imagine some sort of off-chain app where REP holders vote on ‘ideas’ and not ‘full proposals.’

I hope this offers clarification at what I’m trying to express here, I’m sorry if it came off as disregard for the community as a whole.


Could you present your project similar as dOrg did with Mix.eth ? I believe there needs to be some skin in the game here. The designs and project idea was weeks of work without actually a guarantee of success.

1 Like

I think with these revelations:

Developers have to tell us what they need, it’s impossible to discuss budget limitations if developers won’t say what they want or need financially from the treasury. We can debate this for years but we will still never know what they want or what contraints they encounter. Really all developers have to come up with rugged proposals of exactly what they want from the treasury and we can do a fair vote. Stopping development especially from the mix.eth side is a shame this early in the game, you haven’t told us what you want and what you need and defined it in constraints and time. Also we need to understand how it will help DXDAO holders who are in the funding model that are contributing, there cannot be any further contributions if development stops and you won’t tell us what you need - it will stop contributions financially and general community involvement in the DXDAO. So please give us clear guidelines of what you want and also how it will help REP and DXDAO holders, there is no point us contributing to projects that do not help us retain the treasury.


I’ve got a few thoughts on the road moving forward, I’ll parrot what others have said and add my two cents:

Emphasize community based marketing events. Competitions to create memes, write articles, produce media, xyz. Great way to engage the active community we have, incentivize participation, and build organically created/circulated content. Bonus here is that we’re not tied to payment in DXD or ETH. The DXD issued each month could be largely allocated to community events and competitions. This has no burden on the treasury but employs a large purse to encourage and empower our community.

Payments need to be better, across the board. I agree that we should be working on a sliding scale with runway to incentivize longevity and continued productivity, but to hire the best talent (which DXD 100% should strive for) wages need to at least be competitive with position standards. I suppose I follow into the “senior” level of experience as a content write/marketer, and after 6 months working full-time for DXD I’d still be at a 50% paycut from my current paygrade (background and resume in the crypto industry). I’ve mentioned previously that I’d like to put forth a proposal to create a “light paper”. I still intend to do that 100%, though I can’t justify dropping my existing work responsibilities to do so given the general ballpark figures for funding.

Lastly (and perhaps most importantly of my points), we should absolutely treat the DAO’s fund more akin to what it is- an investment fund. Beyond development and marketing, invest via direct investments. Invest in other DAOs and DeFi applications. Allocate resources to market making on mesa. Convert to DAI and use it to stake and provide liquidity. We should also diversify so we aren’t so tied to Ethereum’s price. Even if nothing is allocated to investment, a major portion of the treasury should be converted to DAI in case the price of ETH tanks. Ethereum has doubled in 3 months. It could double again in the next 3 months, or it could just as easily halve.

At this point I don’t have concrete numbers in place for any of this but generally speaking my point of view can be summarized as:

  • emphasize community-based and competition marketing strategies. Employ DXD holdings and issuance here.
  • Pay workers competitive wages. Shoot for the best talent. Less quality is better than more garbage.
  • Limit exposure to ETH fluctuations.
  • Actually invest through with the treasury.

EDIT: Would also like to say it’s really great to see a lot of the community taking an active role in the success of this project. I’m really excited to see where this all goes.


IMHO growing from ~15K to ~96K burnrate should not be a goal, it’s not a good goal. I would rather set it as a maximum monthly burnrate that we agree not to exceed in order to have at least 12 months of burn rate.

The actual burn rate should be determined by the quality of the proposals towards achieving the goals of dxDAO, nothing else. If in a given month, “only” $20K is spent, then it’s fine. Quality of work >> Quantity of work.

Regarding compensation, I think also that having a fixed compensation price set it not optimal, everybody’s situation is different and it would be sad to exclude great people because they cannot afford to be paid too low (because they have kids, live in a city, whatever…). Maybe we should reuse a model like what companies like Buffer established to make compensation fair and transparent? https://open.buffer.com/transparent-salaries/


Wouldn’t it be possible to have a complete backlog to see what has to be done by the community? This way we can completely see where the “$$$” go and if this makes sense.

Also, as the community will commit to finance the work done based on the “Live” backlog, it would be great to see the people financed (dev or any other profiles, test, marketing, comm, sales…) committing themselves on the cards / tasks in this backlog (timing and deadline).
(for example for 1 task or issue: 1 dev commits for 2 days of work, and to be delivered in 4 days).
The community could add a 10% or 20% time/money in case of unknown issues.

And to make it even more transparent, which is super important, tools like Hubstaff can be used for the timetracking (and it even screenshots every 3 or 10 min so that anyone can do its own due diligence anytime). It can be linked to the backlog on Github for example, so that the time tracker is also linked automatically to the issue.

Also, we have to consider the current practices. Being paid on hourly rate, twice a month is very important to attract the best talents. The hourly rate for a good dev is between 35 and 60$/hour (up to 100 for US based for example), it wouldn’t be fair to be paid 2K/mo or it would mean the commitment won’t be more than probably 1week of work per month.

Operations, this is probably where most of the projects under “grant” failed to deliver and this is where I guess there is a challenge for our entire community : defining the right frame so that people can work properly and so that the money spent is perfectly used.


I already find bosses using timetracking an Orwellian nightmare, so now imagine everyone being able to see what you are doing every 3 to 10 min. That looks like huge privacy violation and considering workers as kids incapable of working without supervisions.
I think we want to encourage self-motivated productive workers who value privacy.

I also think that the philosophy should be “We don’t care about you working, we care about you getting work done”.

Also note that heavy monitoring of dxDAO workers has legal implications and could lead to them being requalified as employees. And by the dxDAO not having the corporate veil, this means people responsible for this decision may be the ones having to compensate them.

That seems way more reasonable to me.