Skip to content

Security Engineer · Ethereum Foundation

Bhargava Shastry

I run independent implementations against each other — Ethereum clients, post-quantum cryptography libraries, compilers — and turn every disagreement into a reproducible bug report.

Recently: a confirmed-exploitable timing channel in Mbed TLS (security advisory, Jul 2026), upstream fixes merged in Erigon, Nethermind, and revm (findings), and 25 miscompilation bugs found in the Solidity compiler (paper).

LatestTrust No Single Witness

Method: input, to independent witnesses, to divergence, to evidence

10public findings · 2025–261security advisory5EVM implementations cross-checked11publications
See case studiesDownload CV (PDF)
Explore the method

01 — About

About Me

“In a system with more than one implementation there is no ground truth — only witnesses that disagree. So: trust no single witness.”

Read the long version →

That's the whole method. I make the witnesses disagree under controlled conditions: coverage-guided differential fuzzers that run Ethereum's execution clients, post-quantum cryptography libraries, and compilers against each other, so every divergence becomes a reproducible bug report.

I practice this as a security engineer at the Ethereum Foundation — differential fuzzing of execution clients, hard-fork readiness testing, and bug-bounty triage. To scale the method, I build AI-assisted pipelines for context building, harness generation, PoC validation, and triage, with deterministic orchestration, auditable logs and human review at the decision points.

The roots are a Ph.D. in fuzzing and static analysis at TU Berlin, Solidity compiler fuzzing infrastructure, and contributions to Google's OSS-Fuzz; the timeline below carries the rest of the history.

Core Expertise

  • Differential Testing & Fuzzing
  • AI-Driven Triage & Vuln Discovery
  • Ethereum Protocol Security
  • Post-Quantum Cryptography
  • Side-Channel Analysis
  • Bug Bounty Triage

Experience

2019 - Present

Security Engineer · Ethereum Foundation

Differential fuzzing, hard-fork readiness, and bug-bounty triage across Ethereum clients.

2017 - Present

Independent Security Researcher · Freelance

Open-source security research, fuzzing tools, and contributions to OSS-Fuzz and Open vSwitch.

2011 - 2012

Security Researcher · Fraunhofer Secure IT

Android platform security research; published at NDSS and ACM SPSM.

2007 - 2008

Software Engineer · Ittiam Systems

VoIP phone software and tests.

Education

2013 - 2019

Ph.D. in Computer Science · Technische Universität Berlin

Static analysis and fuzzing techniques for open source bug detection

2008 - 2010

M.Sc. in Computer Science · Ecole Polytechnique Fédérale de Lausanne (EPFL)

Specialized in security of microcontrollers and embedded systems

2003 - 2007

B.Tech. in Electrical Engineering · National Institute of Technology Karnataka (NITK)

Undergraduate thesis on digital signal processing and embedded systems

Download CV (PDF)

Technologies & Tools

GoRustC++PythonSolidityEthereumEVMgoevmlablibFuzzercargo-fuzzAFLFoundryDockerLLM Agents

02 — Case Studies

Case Studies

Three examples of what differential validation looks like in practice — what was at stake, how it was tested, and what changed upstream. Every claim links to a public artifact.

01

Ethereum execution clients

Finding cross-client divergence before it can split the chain

Stakes
Ethereum runs on independently developed execution clients that must agree on every state transition. A single divergence between them can partition the network — and hundreds of billions of dollars in value ride on that agreement.
Approach
Coverage-guided differential fuzzing of state-test execution across geth, Besu, Nethermind, Erigon, and revm, built on goevmlab, plus hard-fork readiness testing validated against the executable specs.
Result
Upstream fixes merged across clients — a genesis-block BLOCKHASH divergence in revm, coinbase state touched on failed transactions and an EVM memory-size overflow crash in Nethermind — and regression tests upstreamed to the executable spec ahead of a fork.

Demonstrates

Independent differential validation of a multi-implementation system before release.

revm fixNethermind fixexecution-specs tests
02

Cryptographic implementations

Timing side channels in a TLS stack that ships everywhere

Stakes
Mbed TLS runs on billions of embedded devices. A secret-dependent timing path can leak private-key material without ever failing a functional test — the class of bug ordinary test suites cannot see.
Approach
Constant-time analysis of secret-data paths in the bignum and elliptic-curve code, followed by coordinated disclosure with the maintainers.
Result
A variable-time division reachable from RSA prime generation fixed in Mbed TLS 3.6.7 and TF-PSA-Crypto, and an ECC modular-reduction timing channel later confirmed exploitable and fixed under the July 2026 security advisory.

Demonstrates

Side-channel review of high-consequence cryptographic code, delivered through responsible disclosure.

Security advisory 2026-07TF-PSA-Crypto ChangeLog
03

Post-quantum cryptography

Cross-checking post-quantum standards before the migration wave

Stakes
ML-KEM (FIPS 203) and ML-DSA (FIPS 204) implementations are young, and migrations are starting. Implementations that silently disagree mean broken interoperability at best — and exploitable divergence at worst.
Approach
A coverage-guided differential fuzzer co-linking mlkem-native, BoringSSL, and libcrux, with functional-equivalence and constant-time oracles — including an honest analysis of where coverage does and does not reach.
Result
A reproducible cross-implementation testing harness and a four-part public series documenting the method, the results, and the blind spots.

Demonstrates

Differential validation of cryptographic standards ahead of production deployment.

ML-KEM seriesML-DSA post

Working on a system where independent implementations must agree? Discuss a scoped review.

03 — Research

Security Research

Current focus areas — differential testing of Ethereum clients and cryptographic implementations, and the AI-driven triage and vulnerability-discovery pipelines that scale it

01

Ethereum Protocol Security

2022 - Present

Differential fuzzing I build and run across Ethereum execution clients, plus hard-fork readiness testing — catching consensus divergences before they can split the network.

  • Coverage-guided differential fuzzing of state-test execution across geth, Besu, Nethermind, Erigon, and revm, built on goevmlab
  • Hard-fork readiness testing for upcoming upgrades: gas repricing, block-level access lists, and new EIP semantics validated against the executable specs
  • Upstream fixes merged in Erigon, Nethermind, revm, and ethereum/execution-specs
  • Earlier: EIP-7702 differential fuzzers across geth, Nethermind, and Besu; PrecompileFuzzer for the Prague hard fork; EthFuzzNet network-resilience testing
GoRustPython
goevmlabexecution-specs
02

AI-Driven Triage & Vulnerability Discovery

2026 - Present

Pipelines I design and build that put LLM agents to work on client security — vulnerability research decomposed into context building, harness generation, PoC validation, and triage, with deterministic orchestration, auditable logs, and human review at the decision points.

  • Agent frameworks that decompose vulnerability research into context building, harness generation, PoC validation, and triage
  • Autonomous audit pipelines run against Ethereum client codebases in sandboxed environments
  • Bug-bounty triage for the Ethereum Foundation: reproducing reported issues, confirming cross-client blast radius with differential harnesses, and assessing consensus, finality, and denial-of-service impact
  • A three-witness severity model — reporter, AI swarm, network blast radius — keeps AI-era triage honest
  • Built the internal tooling that manages the submission-to-triage workflow end to end
PythonGo
Ethereum Bug BountyTrust No Single Witness (slides)
03

Post-Quantum Cryptography

2026 - Present

Differential testing of post-quantum standards: cross-checking independent ML-KEM (FIPS 203) and ML-DSA (FIPS 204) implementations against each other.

  • Built a coverage-guided differential fuzzer co-linking mlkem-native, BoringSSL, and libcrux
  • Functional-equivalence and constant-time checks across implementations
  • Published a four-part blog series on the approach and results
CRust
ML-KEM seriesML-DSA post
04

Cryptographic Side-Channel Research

2026 - Present

Constant-time analysis of widely deployed cryptographic libraries: finding secret-dependent timing paths in Mbed TLS / TF-PSA-Crypto and reporting them through coordinated disclosure.

  • Reported a variable-time division in mbedtls_mpi_mod_int reachable from RSA prime generation on a secret-data path — fixed in Mbed TLS 3.6.7 and TF-PSA-Crypto
  • Flagged a timing side channel in the ECC optimized modular reduction (ecp_modp) that was later confirmed exploitable, leading to the July 2026 Mbed TLS security advisory
C
Mbed TLS advisory 2026-07TF-PSA-Crypto ChangeLog
05

Compiler Security

2018 - 2022

Core contributor to the Solidity compiler's testing infrastructure, with 300+ commits focused on fuzzing and correctness testing.

  • 303 commits to the Solidity compiler, primarily in fuzzing and testing
  • Built ABI encoder v2 differential fuzzer
  • Discovered and reported numerous compiler correctness bugs through structure-aware fuzzing
C++Solidity
Solidity
All research areas4 more, from P2P & Networking Security to ERC-4337 / Account AbstractionView the full archive

04 — Findings

Selected Findings

The evidence index behind the case studies. Don't take the numbers on faith — every entry below links to a public artifact: a merged fix, upstreamed tests, or published research.

Security advisoryJul 2026

Exploitable timing side channel in Mbed TLS ECC modular reduction

Flagged a secret-dependent iteration count in the optimized modular reduction (ecp_modp); later confirmed exploitable and fixed under a coordinated security advisory.

Mbed-TLS/mbedtls
PaperJul 2026

25 miscompilation bugs in the Solidity compiler

SolSmith, a semantics-aware differential fuzzer, surfaced miscompilation bugs that had gone unnoticed — some for years — with a root-cause analysis of each.

ethereum/solidity
Fixed upstreamJul 2026

Variable-time division on Mbed TLS RSA prime-generation path

Reported a variable-time DIV in mbedtls_mpi_mod_int reachable from RSA prime generation with secret data; fixed in Mbed TLS 3.6.7 and TF-PSA-Crypto.

Mbed-TLS/TF-PSA-Crypto
Merged testsJun 2026

Hard-fork readiness tests upstreamed to the executable spec

EIP-8037 regression tests — state-gas refund on failed CREATE2 with init storage — merged into ethereum/execution-specs ahead of the fork.

ethereum/execution-specs
Merged fixMay 2026

Snap-sync trie-node response-limit fix in Nethermind

Fix to FlatSnapServer's trie-node response limit, merged upstream as part of sync-protocol security testing of Ethereum's wire protocols.

NethermindEth/nethermind
Merged fixJan 2026

BLOCKHASH returned zero for block 0 in revm

revm's BlockHashCache incorrectly returned zero for the genesis block — a correctness divergence caught by differential state-test fuzzing; fix merged upstream.

bluealloy/revm
Merged fixDec 2025

EVM memory-size overflow crash in Nethermind

Extreme memory-expansion requests could overflow the EVM's memory-size computation and crash the client; guard merged upstream.

NethermindEth/nethermind
Merged fixDec 2025

Coinbase touched on failed transactions in Nethermind

Nethermind's state-test path touched the coinbase account even when the transaction failed, diverging from other clients; fix merged upstream.

NethermindEth/nethermind
Merged fixDec 2025

Spec-aware blob base-fee fraction in revm's state-test runner

The statetest runner applied one blob base-fee update fraction across all forks; spec-aware fix merged upstream to keep differential comparisons honest.

bluealloy/revm
Merged fixDec 2025

State-test messages aligned with other clients in Erigon

Erigon's statetest harness constructed transaction messages differently from other clients, skewing cross-client comparison; fix merged upstream.

erigontech/erigon

Bug-bounty submissions and client-security reports are disclosed privately by default; this is the subset of the work with public artifacts. More on GitHub.

05 — Talks

Talks

Conference presentations and invited talks on fuzzing, compiler security, and vulnerability research

Trust No Single Witness: Differential Fuzzing & Bug-Bounty Triage for Ethereum Clients

How differential fuzzing across ~8 execution clients catches consensus splits within hours of a commit, how LLM property-based testing attacks shared blind spots, and how a three-witness severity model (reporter, AI swarm, network blast radius) keeps AI-era bounty triage honest.

Berlin Ethereum Day '26Long version

Fuzzing the Solidity Compiler

Threat model: incorrect code generation. Randomly generated valid Solidity/Yul programs stress the compiler's codegen and optimizer before releases ship — nine bugs found via semantic fuzzing.

Devcon 5 '19Devcon 5 videoEthCC 3 '20FuzzCon EU '20

Can A Fuzzer Match A Human: Solidity Case Study

A fuzzer is no match for a human tester — but it finds security-critical bugs humans miss, and it shines at differential (A/B) testing.

Ethereum Foundation '20

Open Discussion on Solidity Fuzzing

The state of Solidity compiler testing — unit, regression, and fuzz tests — and where community input could help.

Ethereum Meetup '19

Vulnerability Search Problem and Methods

Why vulnerabilities are expensive, and how static analysis and fuzzing complement each other in finding them.

TU Berlin (Invited Talk) '19

06 — Writing

Recent Writing

Long-form notes on differential testing, most recently a series cross-checking post-quantum cryptography implementations

All posts
Jul 20, 20265 min read

Trust No Single Witness

In a system with more than one implementation there is no ground truth available to the test harness — only witnesses that can disagree. That changes how I test Ethereum clients, cryptographic libraries, compilers, and AI-assisted security pipelines.

Jun 23, 20267 min read

Cross-checking the post-quantum signature behind the web

The KEM keeps a web conversation private; the signature decides whom you're talking to. I differential-fuzzed ML-DSA-65 across CIRCL, BoringSSL, and mldsa-native — and the real lesson wasn't the clean negative. It's that a clean negative is worth exactly as much as the coverage behind it, and my first attempt had a hole big enough to drive 16 million executions through without noticing.

Jun 16, 20267 min read

A Green Checkmark Is an Agreed-Upon Guess

We obsess over test inputs and coverage and almost never examine the oracle — the thing that decides an answer was correct. A passing test isn't proof of correctness; it's a statement that the system and its oracle agree. Here's why that distinction is suddenly everyone's problem, especially in how we evaluate AI.

New writeups land in the feed first — subscribe via RSS.

07 — Publications

Publications

Research in security, fuzzing, and program analysis

Ethereum Foundation

Ph.D. — TU Berlin

Fraunhofer Secure IT

08 — Work

Work with me

I'm a security engineer at the Ethereum Foundation. Beyond that, I'm glad to hear about roles and teams working on hard verification problems, research collaboration, conference talks, and podcasts — no formality needed, just email.

bshastry@posteo.deLinkedInCV (PDF)

My work has been merged upstream by the Nethermind, Erigon, revm, Mbed TLS, and Solidity teams — the review threads are public.

Independent engagements — limited

Scoped security engagements

For teams that need independent evidence before a release, upgrade, or standardization milestone.

Differential-testing diagnostic

Fixed scope · timing confirmed in proposal

For teams that suspect cross-implementation or oracle risk.

You get: A divergence and threat model, a target matrix, a harness and coverage roadmap, and a prioritized-risk debrief — the same artifact structure as the case studies above.

Critical implementation review

Milestone-bound scope · timing confirmed in proposal

For teams approaching a hard fork, protocol upgrade, or cryptographic rollout.

You get: Independent tests of high-consequence behavior, reproducible findings with severity analysis, and remediation verification.

Team workshop & advisory

Tailored session · follow-up office hours

For teams building their own fuzzing or differential-testing capability.

You get: A tailored workshop with practical exercises and reference material, followed by focused office hours.

Good fit

Multi-implementation systems — L1/L2 clients, cryptographic libraries, compilers, virtual machines — approaching a release, upgrade, audit, or standardization milestone, where a reproducible divergence is worth far more than an opinion.

Poor fit

Smart-contract application audits, generic penetration testing, or anything that conflicts with my Ethereum Foundation responsibilities — I run a conflict check before any details are shared.

  1. 01Inquiry
  2. 02Conflict check
  3. 03Scoped proposal
  4. 04Delivery & debrief
Start a structured inquiryPGP key for sensitive reports

Do not include vulnerability details, secrets, credentials, or source code in an inquiry — use the PGP key for sensitive reports.

Independent engagements are limited, subject to conflict review, and represent my own views and work — they are not offered, endorsed, or reviewed by the Ethereum Foundation.