oDAO Membership Interest - Patches

After Mav called for interested parties to “throw their hat in the ring”, I’ve decided to put myself forward for consideration to run an oDAO node. I’m going to borrow the interview questions from Wander (whose candidacy I support!)

What is your history of involvement with Rocket Pool?

Most of you probably know me well already, but in brief:

I started following Rocket Pool’s development before the prater betas in 2021 and joined the community in September. I run a Rocket Pool node and have staked from home since November. In March the team assigned me the Rocket Scientist role with encouragement from the community.

Since joining, I have contributed as much to the community as I can manage. Some highlights:

  • Almost 15k messages in #support, the vast majority of which have been helping Node Operators in whatever ways I am able.
  • Assumed responsibility for the administration and development of faucet-bot, which dispenses Goerli and Ropsten ETH in #faucet.
  • Contributed a smattering of commits to rocket-watch, smartnode, the docs.rocketpool.net repositories, and to Ken’s encryption guides.
  • Wrote and maintained a list of supplemental guides for Node Operators.
  • Optimized the smartnode vanity miner, and then wrote a stand-alone vanity miner with even more performance gains.
  • Worked with @hanniabu and others to flesh out https://rocketpool.support
  • Wrote a script to audit the guardian wallet’s activities during deploy to help dispel some concerns from Maker governance.
  • Identified medium-to-high priority bugs in smartnode, or pathological dependency interactions with smartnode (such as the infamous snap docker runtime issue).

What do you see as the oDAO’s role in the protocol?

The most immediately obvious role is the most utilitarian one- the oDAO submits balance and price data to the execution layer for use by the stack of Rocket Pool contracts. While this functionality is automated, it’s my view that oDAO node operators should treat this work as an on-call rotation, and ensure that it is reliably completed, even if it means sacrificing some sleep now and then.

Beyond that, the oDAO is responsible for making proposals related to certain internal levers such as the length of the scrub period, and adjusting its own parameters by proposing to invite or expel other oDAO members or adjust the bond size. My approach to these decisions will be to prioritize the health and growth of the network and the platform above other concerns. I’m currently in favor of ongoing discussions to reexamine the inflation distribution. I hold the opinion that oDAO members should be compensated beyond just gas reimbursement, as participating in the oDAO constitutes a certain amount of skilled labor, but that the current compensation may prove to be on the high side. I’d like to see the team’s income decoupled from their participation in the oDAO, so that the topic of oDAO compensation can be independently addressed.

Ultimately I believe the oDAO should pursue the means to render itself redundant, though given the current platform design, I understand this may not be achievable in the near term.

What are your priorities for Rocket Pool?

I don’t think it is the role of the oDAO nor pDAO to try and prioritize the development team’s backlog. That said, their current priorities around the upcoming merge feel correctly triaged. In a more steady state I’d like to see pDAO bootstrap disabled as soon as convenient, but with security and stability prioritized. We’re at a weird point in history at the moment where rEth demand and node operator supply have suddenly swapped from too high / too low respectively to too low / too high, but I don’t think that will be the case indefinitely, and am supportive of short term efforts to improve rEth demand and longer term efforts to scale node operator supply, e.g., through the SaaS work and collateral revisions that are ongoing. I believe Rocket Pool’s growth has only just begun, but also believe we should aim to capture as much of the staking market as we can without damaging the security of Ethereum, and no more.

How do you secure your node and keys?

I currently run a node on hardware in my apartment, and use Ken’s hardware security key guide to protect they keys, as well as all the standard security tools that the guides outline (2fa, ssh keys, ufw). If selected, I would likely keep the oDAO node at a mid-sized collocation facility with a focus on security and uptime guarantees, and expand my security posture to include things like network intrusion detection systems and physical two-factor authentication providers. I wouldn’t run anything co-tenant on the instance, and only use open source software with verifiable security practices.

The colocation facility will be able to provide better uptime guarantees than my home internet, which is just fast enough to run a node, and allow me to have a fallback in place, which is not something I have bothered with for my home staking node.

Can you disclose your identity publicly for the purpose of accountability?

I have been onymous from pretty much day one of my involvement in Rocket Pool. My name is Jacob Shufro; I’m an engineer with over 10 years of industry experience and the official title of ‘Staff Software Engineer’. I work at a crash data aggregation and analytics company. My background has traditionally focused on developing and maintaining low-latency, high-throughput, real-time systems in C, with a bit of additional experience in the fields of embedded software and cloud-based distributed systems. In my free time I make pizza and foster cats with a rescue organization.


So glad you decided to throw your hat in, too, @Patches!

Patches has gone far above and beyond as a positive contributor to the RP ecosystem and is an excellent choice. I wholeheartedly support him as an oDAO member, as well.


@Patches represents the type of person that we want as involved as much as possible in the RPL ecosystem. He’s technically knowledgable, personable, positive, and always available and contributing in Discord support to help technical and non-technical people. I believe his addition would strengthen the oDAO team and greatly benefit us long term. I would support his membership application.

1 Like

i strongly support you as an odao member Patches.

1 Like

I am in complete support of Patches for oDao. His contribution to the project and community is immense.

1 Like

Wholeheartedly support Patches in becoming an oDAO member. His dedication and commitment to Rocket Pool is phenomenal in the work and time he has put in helping others.

1 Like

Given the additional oDAO responsibilities in redstone, I’d like to add that I’d be happy to run an archive node.


Hello again.

A lot has happened since I wrote this post, and much of it has better informed my view of the responsibility of the oDAO and its members’ roles within the ecosystem. I figured I’d post a quick update on what my priorities are for the oDAO.

Note that I am a member of the Rocket Scientists, who have an oDAO seat operated by Ken, but am still interested in operating an oDAO node myself.

  • First, to improve our ability to detect bugs, I’d like to build a custom watchtower implementation, with its own suite of tests. This would probably require a formal specification of watchtower duties, similar to Joe’s treegen specification, to truly be a “clean room” alternative.
  • Second, I’d like to implement treegen separately. In the interest of breaking up the work, custom watchtower would likely use stock treegen until stable.
  • Once stable, I’d like to actually separate the treegen image from the watchtower image- oDAO members should be able to pick which watchtower and which treegen they would like to use independently

Unfortunately, two watchtowers is not much better than one watchtower in terms of consensus, though it does still help us identify bugs with either implementation. So once stable, I’d like to support the development of a third implementation of each of watchtower/treegen by a third party, and would work to encourage oDAO members to coordinate and ensure that no implementation accounts for 50%+ of the vote. This long-term goal would improve the consensus model for the oDAO, as well as the security (a supply chain attack would now have to successfully compromise a majority of software sources, instead of just one).

This work can be carried on to a larger conclusion- the implementation of an alternative smartnode stack- which would provide additional security to the pDAO as well.

My motivations here come from a perception that the team wants a robust oDAO, but isn’t positioned to improve these things themselves, as a second implementation of watchtower from the team itself would have diminished returns in terms of security and decentralization. Instead, the pDAO and oDAO should take the reins on these projects, so I have prioritized this work to start shortly after my responsibilities to the Rescue Node quiet down.