Skip to content

BhargavaShastry

I find cross-implementation failures before they become production incidents — differential testing of Ethereum clients, cryptographic libraries, and compilers that turns disagreement between systems into reproducible evidence.

Security Engineer at the Ethereum Foundation. Beyond the day job, I design and build AI-driven triage and vulnerability-discovery pipelines that scale this method — agentic systems with auditable logs and human review at the decision points.

LatestCross-checking the post-quantum signature behind the web
10+years in security300+compiler commits10public findings11publications
See case studiesDiscuss a scoped review

Independent engagements are limited and subject to conflict review. Employer affiliation does not imply endorsement.

01 — About

About Me

Turning disagreement into evidence

My working thesis: in a system with more than one implementation there is no ground truth — only witnesses that can disagree. I make them disagree under controlled conditions. I build 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 before it becomes a production incident.

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 design and build AI-driven pipelines that decompose vulnerability research into context building, harness generation, PoC validation, and triage: deterministic orchestration, auditable logs, and human review at the decision points.

The method has deep roots — a Ph.D. on fuzzing and static analysis at TU Berlin, 300+ commits to the Solidity compiler's fuzzing infrastructure, contributions to Google's OSS-Fuzz — and I work in the open where I can: upstream fixes merged in Erigon, Nethermind, revm, and the executable Ethereum specs, most recently cross-checking post-quantum cryptography implementations against each other.

Core Expertise

  • Differential Testing & Fuzzing
  • AI-Driven Triage & Vuln Discovery
  • Ethereum Protocol Security
  • Post-Quantum Cryptography
  • Side-Channel Analysis
  • Bug Bounty Triage
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.

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.
Independent differential validation of a multi-implementation system before release.revm fixNethermind fixexecution-specs tests

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.
Side-channel review of high-consequence cryptographic code, delivered through responsible disclosure.Security advisory 2026-07TF-PSA-Crypto ChangeLog

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.
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
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
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
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

There is no ground truth in Ethereum — only witnesses that disagree. How differential fuzzing across ~8 execution clients catches consensus splits within hours of a commit, how LLM property-based testing attacks the blind spots all clients share, and how a three-witness severity model (reporter, AI swarm, network blast radius) keeps AI-era bounty triage honest. Takeaway: a green checkmark is an agreed-upon guess.

Berlin Ethereum Day, 2026Berlin
Slides

Fuzzing the Solidity Compiler

Updated iteration of the Devcon 5 talk: nine bugs found via semantic fuzzing of the compiler's code generation.

EthCC 3, 2020Paris
Slides

Fuzzing the Solidity Compiler

The compiler-fuzzing pipeline presented to a fuzzing-practitioner audience: generating valid programs, differential oracles, and OSS-Fuzz integration.

FuzzCon EU, 2020Europe
Slides

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, 2020
Slides

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.

Devcon 5, 2019Osaka
SlidesVideo

Open Discussion on Solidity Fuzzing

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

Ethereum Meetup, 2019Berlin
Slides

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), 2019Berlin
Slides

06 — Writing

Recent Writing

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

All posts
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.

Apr 26, 202611 min read

Cross-checking the post-quantum KEM behind the web — Part 3: blind spots and what's next

Part 3 of 3. What a clean multi-way negative does and doesn't prove — the methodology's blind spots — plus the takeaway and how to reproduce the work.

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

07 — Publications

Publications

Peer-reviewed research in security, fuzzing, and program analysis

Ethereum Foundation

Finding and Understanding Miscompilation Bugs in the Solidity Compiler

B. Shastry

arXiv preprint arXiv:2607.07217, 2026

Ph.D. — TU Berlin

Follow the White Rabbit: Simplifying Fuzz Testing Using FuzzExMachina

V. Ulitzsch, D. Maier, B. Shastry

Black Hat 2018

Taking Control of SDN-based Cloud Systems via the Data Plane

K. Thimmaraju, B. Shastry, T. Fiebig, F. Hetzelt, J.P. Seifert, A. Feldmann, S. Schmid

Symposium on SDN Research 2018

Best Paper Award
The vAMP Attack: Taking Control of Cloud Systems via the Unified Packet Parser

K. Thimmaraju, B. Shastry, T. Fiebig, F. Hetzelt, J.P. Seifert, A. Feldmann, S. Schmid

Cloud Computing Security Workshop 2017

Static Program Analysis as a Fuzzing Aid

B. Shastry, M. Leutner, T. Fiebig, K. Thimmaraju, F. Yamaguchi, K. Rieck, S. Schmid, J.P. Seifert, A. Feldmann

RAID 2017

Static exploration of taint-style vulnerabilities found by fuzzing

B. Shastry, F. Maggi, F. Yamaguchi, K. Rieck, J.P. Seifert

USENIX WOOT 2017

Leveraging flawed tutorials for seeding large-scale web vulnerability discovery

T. Unruh, B. Shastry, M. Skoruppa, F. Maggi, K. Rieck, J.P. Seifert, F. Yamaguchi

USENIX WOOT 2017

Towards Vulnerability Discovery Using Staged Program Analysis

B. Shastry, F. Yamaguchi, K. Rieck, J.P. Seifert

DIMVA 2016

A First Look at Firefox OS Security

D. Defreez, B. Shastry, H. Chen, J.P. Seifert

MoST 2014

Fraunhofer Secure IT

Towards Taming Privilege-Escalation Attacks on Android

S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, A.R. Sadeghi, B. Shastry

NDSS 2012

Practical and lightweight domain isolation on android

S. Bugiel, L. Davi, A. Dmitrienko, S. Heuser, A.R. Sadeghi, B. Shastry

ACM SPSM 2011

08 — Work

Work with me

For protocol, infrastructure, and cryptographic implementation teams that need independent evidence their critical implementations behave consistently before release. I take on a small number of engagements, in three shapes:

Differential-testing diagnostic

A bounded entry engagement for teams that suspect cross-implementation or oracle risk: a threat and divergence model, a target matrix, a harness and coverage roadmap, and a prioritized-risk debrief.

Critical implementation review

For teams approaching a hard fork, protocol upgrade, or cryptographic rollout: independent testing of high-consequence behavior, reproducible findings with severity analysis, and remediation verification.

Team workshop & advisory

For security and engineering teams building their own fuzzing or differential-testing capability: a tailored workshop with exercises and reference material, plus follow-up 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.

Do not include vulnerability details, secrets, credentials, or source code in an inquiry — use the PGP key for sensitive reports. Also open to conference talks, podcasts, and research collaboration.

Start a structured inquiryPGP key for sensitive reports

Prefer plain email? bshastry@posteo.de

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.