Seeking guidance on industry roles in blockchain protocol / infrastructure (India & remote)

You’re not alone in this — I’ve seen a few people with solid protocol backgrounds feel weirdly “blocked” when they go industry-hunting, because the market doesn’t have a clean label for what you do. Most job posts say “blockchain engineer” but mean “Solidity + integrations + backend”. Then the few roles that are actually infra get flooded and the screening becomes super proof-driven.

What has worked for people I know is: stop leading with the PhD (even if it’s impressive) and lead with what you shipped. 

Client work is a cheat code here. “I touched Nethermind execution client” already tells the right hiring manager: ok, this person can operate in a real codebase with real constraints. If you can say one concrete thing like “I worked on X subsystem” + “I chased Y class of bug/perf regression” + “I added tests/benchmarks so it doesn’t come back”, you’ll get taken seriously faster than any research summary.

Also, India vs remote: I wouldn’t interpret “slow adoption” as lack of opportunity. Infra hiring tends to be global anyway. The real constraint is usually payroll/legal setup. If you’re okay doing contractor-style for 3–6 months, your option set expands a lot. If you need India payroll only, it becomes narrower, but still possible.

Curious: what part of Nethermind did you touch (sync/state/perf/networking/EVM-ish)? And are you aiming for engineering-heavy roles or research-heavy roles where writing/spec work is still part of the job?

Hi, I worked on integrating DAG based consensus, called Sailfish, with nethermind client to increase the throughput. This work involved dealing with engine API calls with the nethermind client, fork management and consensus client logic. I am interested in both engineering and research teams.

I’ve interviewed a few people for blockchain protocol engineering / client development roles, and honestly your work is the kind that real infra teams respect — even if job posts don’t describe it well. Consensus–execution integration, Engine API, fork management, and consensus client logic are exactly where things get tricky in production, because the failure modes aren’t obvious until you hit reorgs, timing issues, or weird edge cases.

If you want to convert this into “easy to evaluate” proof for remote blockchain infrastructure roles (or India-based teams hiring for protocol work), I’d suggest you keep two things ready:

One concrete debugging story For example: a fork-choice / reorg situation you handled, a payload validity mismatch, engine API calls behaving unexpectedly under throughput, or a case where “it worked locally” but broke under real load. Even a 6–8 line story with what broke → what you traced → what you changed → how you verified helps a lot.

Something a hiring manager can quickly look at This can be a link to the code you contributed (even if it’s just a couple of commits), a short design note explaining the integration decisions, a small benchmark result showing throughput improvement, or a test/runner that reproduces the issue you fixed. Basically: “here’s the work, here’s how to validate it.”

Also, since you said you’re open to both engineering-heavy and research-heavy teams: the best “middle path” I’ve seen is targeting teams that do protocol R&D but also ship client code — things like client teams, interoperability teams, rollup infra teams, and protocol engineering groups where reading specs + implementing them is part of the job.

Curious question: in your Sailfish + Nethermind work, what was the hardest part — Engine API semantics, fork-choice/reorg handling, testing & reproducibility, or performance tuning? Your answer will map really cleanly to the role titles you should search for.

Hi, thank you for the insights. 

I worked as a PH.D research intern at Nethermind and there I chose to research and integrate various consensus algorithms for Ethereum. In this process, I chose one consensus algorithm called Sailfish, a DAG based consensus similar to IOTA( only in structure). Here multiple participants are allowed to propose there own blocks. And the consensus algorithm ensures it outputs a finalized linear chain (not in all cases). I made few designs for integration with a PoC. The PoC consensus client has to guide the ethereum execution client. Transaction life cycle ( submission of transactions, building of blocks by execution clients, feeding them to consensus client -> getting finalized blocks -> executing them in the execution client) has to be taken care of. The main challenge is in the design of fork-choice and re-org handling. Specifically, in ethereum execution client there exists only parent block but here there exists multiple due to the DAG structure. This introduces some complexity and challenges in re-org handling later down the transaction life cycle. I would say, re-org handling was the difficult and exciting part.  I spent most time in the design challenges of integration and ended up making a PoC in the last minute.

 I am new to job search in web3, and I rarely see the research engineer kind of roles in the dashboards. Should I approach the teams directly instead of waiting for the jobs to appear?