Improving oDAO Participation

After the latest issues with the oDAO and sparked by Greywizard’s oDAO dashboard, #trading had a discussion about how to better address the oDAO participation risk. We mainly talked about improving the ability to monitor oDAO performance and creating incentives for performance to improve. This is my and Valdorff’s attempt at a summary of the main ideas developed.

(In)ability of the Community/pDAO to Act

We discussed how any changes to the oDAO need to be enacted and enforced by the oDAO. Since it is autonomous, the pDAO is not able to act and its governance process does not apply here. The community is only able to make suggestions and we need the oDAO and the team to pick it up.



We need something to tell us that an oDAO member is actively doing their duties. One possibility is requiring everyone to participate in all votes to establish a heartbeat.



  1. The need for a heartbeat is still there, that hasn’t changed - the “how do we do it” has since the last time we had a conversation around it though
  • Langers likes the idea of making everyone submit balances on mainnet, regardless of whether or not consensus is reached, as a heartbeat that captures both the ruleset version each member is using (indirectly, since it only gauges changes that affect the rETH staker portion) and whether or not they’re actually alive. We might be able to get it into Atlas, which is good, but then we’re running without an adequate heartbeat system for a few months so we have to weigh the risks there.

  • He also is starting to come around to the idea of having a separate contract on Prater that the oDAO submit something to every time they submitted a balances update on mainnet. Contents would be a string with their Smartnode version, and the values they got for their balance submission. He’s not there yet because of added node op complexity / requirements, though the ability to “just use Infura / Alchemy for Prater” did seem like a selling point. We want to revisit this particular one next year when everyone’s back from vacations and stuff.


Subcommittee Submission Scheme

An alternative/improvement would be to have expected subcommittees submit each vote. This would give us a slightly sparser heartbeat, but has the advantage of zero smart contract changes and no increased gas costs.


poupas came up with this:

i’m thinking about a way to check for oDAO member liveness without needing new contracts and with 0 gas. the main idea would be something like:

note: this code would run on the smartnode/watchower. nothing is on-chain, except for the entropy source (0 gas cost)

  • for each duty (e.g. price submission) calculate the members that must vote, using “some on-chain entropy source”[note: could also be round-robin or some other fair and reproducable algorithm]. also calculate a backup committee.
  • wait for the main comittee to vote (x mins/hours/wtv).
  • if no quorum can be reached, the backup committee members should vote.

potential benefits:

  • we would detect inactive oDAO members (or members providing wrong info)
  • gas costs should be smoothed amongst oDAO members
  • this is done on the smartnode stack so it should be faster to implement


a35u: if the committees were different for submit prices and balances couldn’t you get almost all every day?
knoshua: you could get all, with one or two nodes submitting two tx each day, right? for example nodes 1-8 would submit prices and 8 - 15 would submit balances


Smartnode Version Tracking

Both heartbeat variants above work, but they only check for liveness, not proper version. An alternative would be to add some way to post messages on-chain that can include the current version



what about

  • we create and deploy a RocketNodeTrustedHeartbeat contract that’s just keeps a list of messages
  • we create an add-on that calls the contract with the smartnode version every day (it’d be very cheap)
  • we get butta and phiz and yorick to use them
  • prominent heartbeat dashboard on rocketscan
  • other odao members are pressured/shamed into enabling the addon as well


Note: instead of add-on and opt-in, it could be part of smartnode directly

Invis deployed a smart contract that allows oDAO members to emit events with data:

~35k gas for that event


Rewards linked to successfully contributing to consensus

It may make sense to align incentives with performance of duties. Care is needed to encourage “good” participation, without incentivizing cutting corners to “win” the most rewards.


knoshua: that’s the question, yeah. should someone that does only half the tx of someone else get half the rewards? my concern with that would be that submitting balances and such turns into a race for rewards and that could lead to behavior that is not desirable. Like optimizing for performance instead of reliability and decentralization. Or copying the first submission instead of calculating values yourself…

Valdorff: Yep - pass/fail metric with a time limit, rather than a race


Strike System


Honestly… More than reduced rewards, I’d prefer some kind of “strike” system leading to ejection
The key goals are reliability on oracle duties, and due diligence on contract upgrades
If someone is down one week every two months, I don’t think a 12% reduction in rewards is hitting the mark


Note: there would need to be discussion around what a strike is, how long a strike stays on record, and how many strikes results in a kick.

Communication with oDAO

We also talked about how there is no way for the community to communicate with many of the oDAO members. The expectation is not that every oDAO member hangs out in #trading. But we feel that the community should be able to reach every oDAO member. This could be discord, the dao forum or a different platform. Butta brought the idea of calls with the oDAO up again.


Great summary of the discussion.

I would like to reiterate the importance of some direct line of communication between the pDAO and the oDAO. I think regular calls may be too onerous for scheduling everyone. I don’t believe a read-only discord channel would be well used by all the oDAO members.

Perhaps the oDAO requires a dedicated DAO forum of its own. I believe this would be easier to follow for oDAO members.


Thank you for starting this discussion @knoshua . I would like us as the oDAO to take a step back and examine our actual purpose and objectives. In general, I see Oracles as a necessary evil because of the inability (in this case) to verify validator state and balances on the consensus layer. (I know there are a couple of other things that oDAO participants also do). What does the need for that verification look like post-Shanghai? Validator balances will tend towards 32 Eth and I think there was a move to include some kind of consensus layer state (I forget the detail) in the block. I’d argue that both (if true) remove and reduce the responsibilities of the oDAO.

In some ways, the oDAO working towards making itself redundant is a good objective in my eyes. Of course, active participation in the meantime is important and valuable but I wonder if we can all agree on the endgame it might also help this…?

1 Like