Dev team funding

Governance
1

So. The latest passed set of votes included 3 months of funding for the dev team. Per the vote text “(this is interim funding; we likely want to fund longer based on a roadmap, but that can be a separate vote)”. So I wanted to get the ball rolling on that. There’s been a minor amount of discussion on discord.

Rough outline I’d like to get a temp check on:

  • 12 month main cadence
    • Team and pDAO communicate about roadmap + budget. Team finalizes roadmap, pDAO finalizes budget, team accepts budget or not, we go to vote, payment is one lump sum up front.
    • These discussions would look roughly like what we got around the recent roadmap discussion in May.
    • Trying to avoid micromanaging the dev team that’s served us well, while also avoiding being permanently married to this specific team forever.
  • Team MUST provide quarterly updates on the roadmap. These need not be big discussions as for the main cadence – think of them like the zoomed out version of the biweekly reports.
    • The next big roadmap and discussions can happen any time after the last scheduled quarterly update.
    • To be really explicit about a potential cadence, it could look like:
      • We decide on a Roadmap to cover a year starting October 1st
      • Team provides a quarterly update the first week of January
      • Team provides a quarterly update the first week of April
      • Team provides a quarterly update the first week of July
      • After that update, we start discussing the next roadmap. We approve a roadmap that is valid starting October 1st.

Ok. So some things we need to iron out:

  1. Is that general plan ok? If not, what would you like to see changed?
  2. Is 12 months the right cadence? The team have expressed a desire to have it be that long to prevent (a) overhead and (b) being steered by the flavor of the month tooo much. Is there interest in getting even more out of the way and doing 18 months?
  3. Were the discussions around the roadmap in May sufficient? Do we need to formalize what those look like? Does the one in May count for the initial cycle (starts September)?
  4. Are we paying the right amount? Some team input might be useful here. Would more money translate to a bigger team? Is a bigger team desirable? Would more money translate to any other advantages?
5 Likes
2

Nice work.

I don’t see any issue with twelve months. As long as pDAO can vote to shorten it in the future, 18 months seems fine as well.

1 Like
3
  1. I think this is ok
  2. 12 months is good, but could there be a problem with huge fluctuations in RPL price?
  3. Yes, they were sufficient. Formalization would be good. The one in May should count.
  4. ?
4

I don’t have brass tacks backing this up but I suspect the team is a very cost efficient way to pay for dev work, compared to other mechanisms (grants/bounties, contractors, hiring other daos or even other teams).

This is due to a few facts:

  1. They are already subject matter experts, so they work at a high rate of efficiency
  2. Contractors are expensive
  3. Running grants/bounties through the full process for every single roadmap item and piecemeal deliverable has a cost to both the GMC and the person claiming the grant/bounty.
  4. They’re very, very aligned with the success of the protocol- they prioritize work and spend to that end.

Which is all to say that yes, some team input would be useful- If they feel that RPL inflows are the main factor preventing them from hiring, and they have a desire to increase staffing, we should increase those inflows, as we get very good ROI by funding the team.

4 Likes
5

I am happy to give them more money for hiring from the oDAO for sure.

6
  1. This seems basically ok to me. One question I had was when is the deadline the roadmap / budget process is expected to be approved? I wouldn’t want to be on a team that found out 3 weeks (or even eight weeks) before the end of their runway whether the next year had been approved. That decision should be finalized 6 months before the end of each runway I think. Them knowing for sure that funding was there provides some more stability. Perhaps another point to get feedback on.
  2. 12 months seems fine, but see point 1, I think there should be some crossover / overlap for stability. Even if we did 18 months, as written there’s still this cliff where at least theoretically, it could end.
  3. I might not have been as keyed in at the time, but weren’t the May discussions more about getting feedback on community priorities? Is the quarterly update more status (what we did, what we’re going to do), or a roadmap building exercise?
  4. Agree, looking forward to team input.
7

As I wrote above, that discussion would start 3 months ahead of the end. I suspect it could be 2-3 weeks to do it right. Then 2 weeks of voting. So that would give 7-8 weeks of clarity. If team would prefer more, we can probably figure out how to do some of the discussion ahead of the last quarterly update, or change the updates a bit or something.

3.

I wrote up a yearly “plan roadmap with the community” and a quarterly “update community on status”. I think May was not-quite the roadmap planning I’d like to see, but a fine first foray that direction. I would’ve liked more back and forth than there was.

1 Like
8

Hey, just a heads up that we are considering this and will post a response shortly.

1 Like
9

Hey everyone!

Sorry about the delay.

We support a 12 month cadence and fully accept the roadmap co-development and quarterly update requirements.

In terms of payment, we have spent some time forecasting the next 12 months. We are currently being paid 3.33% of RPL inflation to develop and innovate the protocol. As many have pointed out we maintain a very tight team.

There are reasons why we keep the team lean:

  • Funding is a consideration, we like to be long term sustainable
  • Bear markets happen
  • We avoid the typical tech expansion and inevitable downsizing because it is a waste of talent and money (acquisition and onboarding costs)
  • Small experienced teams tend to outperform
  • We want to leave room for the DAO to grow and not have the team do everything

That said, we have committed to grow the team by 3 headcount this year:

  • Ecosystem Lead - actively manage ecosystem relationships to help drive adoption of Rocket Pool
  • Senior Software Developer - expand our development capacity to deliver more
  • Junior Software Developer

Additionally, the team shoulder a number of other operational costs these include:

  • Chainlink oracle costs
  • Cloud costs for infrastructure
  • Smart contract audits
  • Bug bounties

At current funding and RPL market rate, our additional headcount puts us running at a significant loss. This we can absorb, for now, due to cash flow management but an increase in funding would mean we break-even. As the wider market conditions improve it would also allow us to expand further.

We are requesting an increase to 5% of RPL inflation + our oDAO payments (that are progressively reducing). We believe this rate is still an extremely good deal for the protocol but gives us the ability to maintain our capacity and grow as the market improves.

Please let me know your thoughts

4 Likes
10

I would maybe advocate for an estimated breakdown of the spending, if the team is comfortable with that level of transparency.

While I’m unsure the Rocket Pool DAOs are established enough to engage with that level of detail productively yet, I think there are still some advantages to making that information public:

  • In general transparency is worthwhile.
  • It would set a positive precedent for other service providers pitching to Rocket Pool.
  • The Rocket Pool DAOs would better understand the maintenance cost of the protocol and its infrastructure in its current state, versus the development cost to improve it.
  • The Rocket Pool DAOs will need to engage directly with other service providers at some point. ‘Practicing’ on the core team as if they are an external party could help set expectations and processes in a safer environment.
1 Like
11

Whoops - I had some thoughts I’d meant to post after langers and just… didn’t. Thankfully LFW’s post made me notice.

  • I think it would make sense to have a payment amount assuming 1.5 hires and then another step once all 3 are active.
    • Right now we have 1 active and 2 in varieties of “soon!”. I like optimism, but I think the cost for a one-time step is low enough here.
  • I would like some up and downside protection for the DAO and core team. I might suggest something like “If price 3xes (vs USD), then halve the RPL” and “if price 1/3rds, then double the RPL”.
    • The thought here is that many costs are fiat-based, so this helps extremes.
    • This would apply to only the pDAO component.
    • Note that the RPL amount doesn’t 3x in either case, just 2x, so there’s still plenty of number up = yay and number down = sad.
    • I don’t think we want to be looking at this with a fine-tooth comb – ie, if it switches one way it now takes a 3x to switch back. Would also suggest a massive TWAP as the metric (maybe 4 weeks) to avoid jumping the gun based on volatility and obviate market manipulation.
12

I agree that transparency is a noble goal and we strive for it as a team. Although there is a trade off vs having a certain level of autonomy.

We also have issues such as NDAs. We try hard not to be restricted by them (to enable us to be transparent) but at times it is not always possible.

That said, like many organisations, most of our costs are head-count rather than expenses so it is relatively easy to work back from there. For obvious privacy reasons, we don’t want to have to enumerate salaries.

We are open to discussing cost if the pDAO decide they are not getting value for money. This would probably be a good approach, whether it is with us, or any other service provider.

13

Granted, you posted this before Fornax was onboard. We have 1 hire left, a junior. Happy to have a one-time step although it is feeling less needed?

I would have preferred a simple “protocol pays X% for development” but a floating fiat-based price seems fair on both sides: protocol isn’t over paying (in fiat terms) and team have some guarantee.

I think the TWAP would have to be more like 3 months. I am doing the analysis but the volatility of RPL even over 4 weeks is quite a lot. Just roughly, it looks like we would have had to adjust the funding 14 times in the last two years if we were using a 4 week twap. Each change would be a pDAO vote so this is a lot of work for the pDAO. 3 months is probably not a bad cadence for governance voting.

1 Like
14

I won’t belabour the points past this as I think they are tangential to the discussion, but I wanted to respond some here.

I would like to argue against the idea that autonomy opposes transparency, and vice-versa.

It’s quite possible to be both autonomous and be transparent. It’s fine to have a line item on the budget that’s just: “Contingency / Flexibility Pool”. When and if that pool is used, it can be followed up with a report of what it was used for.

For Maker Core Units, we were expected to try to stay within total budget limits, but were free to shift money freely between budget categories (actual expenses per category were then reported publicly.)

Just to be clear, I don’t think internal company expenses are that important to share, but things that can be considered protocol expenses, ie oracle, infrastructure, audits and bug bounties probably are worthwhile to breakdown more explicitly?

Yes and no. In practice there ends up being a difference between (for lack of better terms) ‘internal’ providers and ‘external’ providers.

External providers tend to be hired on something vaguely resembling a contract basis. With (ideally) clear deliverables or responsibilities and a fixed budget per project or time. With external providers, yes, value for money tends to be the level on which the discussion happens.

Internal providers tend to be more directly managed by the DAOs, more internally transparent and can generally be trusted with more sensitive tasks / responsibilities.

There are advantages and disadvantages to both, but the dividing line tends to be one of alignment. External providers engage with a DAO and expect to profit from the interaction. Internal providers don’t tend to profit on an entity level, instead individuals are compensated for their time.

Grants programs make a good example.

  • External: A blackbox service provider that manages grants in exchange for either fixed payment per unit time, or a cut of the grant revenue.
  • Internal: A grants committee elected by a DAO, the members of which are compensated for time on an individual level (if compensated at all.)
1 Like
15

I’m confused where you see 14 times? I see 2 with essentially no TWAP (just looking at zoomed out coingecko).

Price starts at $35 2 years ago. Would get updated if it went to 3*35=105 or (1/3)*35=11.67. It does indeed fall below $11.67 in June 2022. Now it would need to get to $35 or $3.89 to trigger a change. It gets over that in September 2022 for a little bit - with a TWAP, I suspect it wouldn’t trigger till January 2023. Now again we need to fall outside of 11.67-105, which has yet to happen.

On the other point, I still like the single step - but yayyy fornax onboard :slight_smile:

16

My bad. That will teach me for rushing the calculation. Apologies, I was using 1/3 rather than 3x, doh! You are correct.

17

We have had some further internal discussions around using a fiat model.

Even with a large massive TWAP, someone has to monitor and action the funding changes. Given the capacity of the pDAO (in its current state) it would probably be best to minimise operational burden as much as possible. We discussed the idea of doing a fiat model with the oDAO and came to the a similar conclusion.

From a team cost perspective, we are used to being paid in crypto. We have treasury processes in place to manage it, so we are comfortable bearing the downside.

The issue with setting a fiat target is it treats the team as a cost-centre rather than a strategic partner. As the team delivers value to the protocol, they should be able to expand to create more value. In the TWAP case, the team would have to ask permission to expand rather than managing it themselves. The TWAP actually hinders our ability to grow. As the RPL price rises, we will have more income but when it hits the boundary, it will get reset back to baseline.

We would ideally like to continue with a set amount of funding 5% of RPL inflation. If the community feel that would be overpaying in a potential bull market, we would be happy to discuss. But bear in mind, they are able to adjust it on the 12 month cadence.

18

I’m having trouble understanding this stance together with the desire to expand as market improves. Wouldn’t you then have to worry about the next bear market and the risk of needing to downsize?

1 Like
19

We would always be conservative compared to a typical VC funded organisation. It doesn’t mean we cannot grow, it just means we would not be bringing on hundreds of people.

Ultimately, if we feel we can manage our cash-flow and step up our head-count then we will do so.

20

My preference would be for team hiring being more based on need and less on market movements and a conservative management of cash flows.
The pDAO seems better equipped to absorb price swings and it is in the pDAO’s interest to not have protocol development slowed down. In that sense, something closer to Val’s suggestion seems preferable.

1 Like