oDAO Compensation + Security Model

As I mentioned in my post showing my interest in oDAO membership, the community hasn’t created clearly defined expectations for the oDAO’s security model. Because the oDAO is a security feature of the protocol, its compensation is directly tied to this security in the same way that, under PoW, block rewards are part of the overall security of Ethereum.

Lately, there’s been a lot of discussion of inflation changes, likely sparked in part by my own writings on this subject where I argue for a more dynamic inflation model. While I make my stance clear on inflation in that article, I want to discuss the oDAO allocation in a more detail because I believe we should only make protocol changes after sufficient analysis and discussion of the security implications.

First, some numbers for context:

  • 135,000 of the approximately 900,000 RPL created annually are allocated to the oDAO
  • With a fairly high ~75 gwei gas average, this translates to roughly 8,761 RPL per oDAO member per year
  • In USD prices, that’s about $150k/yr per oDAO member at today’s RPL price
  • Based on a generous estimate of 5 hrs/wk of admin time per member, this compensation outweighs even a high level sysadmin compensation by ~70%

Second, some questions:

  • Is a sysadmin salary an appropriate framework for compensation comparison?
  • Since the RP network “secures” ETH and ETH/RPL floats, can we consider oDAO compensation as a function of ETH prices instead of RPL (even if they’re paid in RPL)?
  • Most importantly, how much oDAO security is enough?

Compared to the views expressed in the writing I linked above, I’ve evolved my thinking on oDAO compensation based on this mental framework of security. I now think it’s crucial that we discuss the minimum level of security we desire from oDAO compensation and target this level consciously after factoring in their gas and admin expenses.

For example, if we think 8 of the 14 members could be bribed with just three years of compensation, then the cost of such an attack is a measly ~1500 ETH at today’s RPL/ETH prices! Such a low cost to attack a ~200k ETH market cap coin underscores the hefty trust required in the oDAO members. Notably, this figure does not change if we increase the number of oDAO members since inflation is allocated equally to all its members – a bigger oDAO only makes it more difficult to coordinate such an attack.

Ultimately, we need to decide as a community what level of security we want to achieve from oDAO compensation (if any) because, right now, we aren’t achieving very much. From a pure security perspective, my previous suggestion of an ~80% reduction in compensation may have been overzealous, though perhaps if we’re relying on trust and other intangible factors so heavily, maybe it’s more honest. I do think it’s unlikely that an oDAO bribery attack would succeed, especially given that holding the members’ reputation and RPL holdings at stake makes them more likely to profit more from the protocol’s future success than immediate failure, but let’s be careful and deliberate here.

TL;DR: oDAO compensation factors into security for the protocol. How much security do we want to achieve from this compensation?

1 Like

IMO, no. We are paying for services from a very scarce set of people/orgs. Those who have an intersection of a) strong reputational capital, b) clear leadership within the Ethereum ecosystem, c) judgment to make the right decisions in moments of contention.

The more scarce a pool of talent is, the more we should be expected to pay for them.

Personally I think we’re paying oDAO In the wrong denomination (RPL when it should be ETH). I liked @Butta’s idea about building an oDAO revenue stream from MEV: MEV and Penalty System


Prevention of malicious action by the oDAO rests almost entirely on the reputational capital of the oDAO members and the prospect of damaging that reputation.

While alignment of interests is a nice thought, realistically the amount of compensation in RPL does not impact security in any meaningful way, nor does the RPL bond itself which is relatively negligible.


Agreed. Reputation is the big ticket item. The RPL bond is a slap on the wrist and the ayment is more in the spirit of an honorarium (meant as a kind of “thank you for service”). I do not see this as a “salary” type of role because there’s simply nothing like 2000 hours of work per year involved here. I’ll add that there’s also a “reputation payment” - folks serving to help the most decentralized LSD do have a badge of “public good” honor (which interestingly scales inversely with payment).

Imo, the payment should be much more than gas and effort. The gas portion makes more sense as ETH (or better yet, actual gas refunds), but I don’t really mind if we pay RPL equivalent for convenience. The effort is made purposely as low as possible, so hopefully that can be on the small side (enough to make up for the annoyance of doing it and ideally a bit more).

1 Like

Great discussion so far. The consensus here and on discord seems to be that we’re not going to achieve meaningful security from oDAO payments. Hopefully this helps frame future oDAO budget discussions a bit.

Yeah - I think IF we wanted to really pay for security, we’d want signed contracts with tech-savvy firms that do tech audits or tech escrow or something. Then the legal system is what would be there as a check/balance in addition to reputation. Don’t really recommend.

This is a big deal. If anyone sounds the alarm before the attack is ready life looks quite different for the attackers. And the various oDAO members know they have a higher chance of being caught as willing to do this, so they have that disincentive. Humans are not game theory robots, so “increasing friction for a practical attack” is relevant.

1 Like

Reputation is the key metric currently, however, as we move to expand the oDAO to community members and perhaps lesser institutions, having an effective capital bond/payment scheme will grow more important. As we weigh lowering oDAO emissions, we should also consider lowering the bond requirement.