Applicant: Safi El-Hassanine
Project: PRSpec — Automated EIP Specification Compliance Checker
Requested Funding: $15,000 (Phase 3 initial milestone) — with Phase 4 ($20,000) contingent on successful Phase 3 delivery
Note: I have intentionally structured this as a milestone-based request. Phase 3 can be funded independently, and Phase 4 funding is only requested after Phase 3 deliverables are verified. This reduces risk for ESP and demonstrates my confidence in execution — Phases 1–2 were completed entirely without funding.
Duration: 4 to 6 months
RFP Reference: Ethereum Foundation ESP — Integrating LLMs into Ethereum Protocol Security Research
- Executive Summary
- What PRSpec Does Today
- Background & Motivation
- Technical Approach
- Deliverables
- Project Plan & Timeline
- Budget Breakdown
- Team Qualifications
- Success Metrics
- Maintenance Plan
Ethereum upgrades are accelerating — Dencun, Pectra, Fusaka — yet manual specification review remains the critical bottleneck. Security researchers spend hundreds of hours per upgrade reconciling consensus specs and execution specs against client implementations, often catching specification drift only after testnet deployment.
PRSpec automates the mechanical part of this work. It fetches EIP specifications (including execution-specs and consensus-specs from their canonical repositories), pulls the corresponding implementation files from multiple Ethereum clients, and uses large-context LLM analysis to identify deviations, missing checks, and edge cases — before code reaches testnet.
Unlike generic code analysis tools, PRSpec understands protocol semantics. It doesn't just compare text — it maps specification constraints to code regions and flags violations even when variable names change or code is restructured.
This is not a proposal for future work. PRSpec is a working tool today. It currently analyzes 6 EIPs across 3 Ethereum clients (go-ethereum, Nethermind, Besu) in Go, C#, and Java, with 62 passing tests and real analysis outputs. This grant request funds the next phase: production GitHub Action integration, cross-client differential analysis, and pilot deployment with client teams.
PRSpec is functional and actively producing results. Here is what has been built:
| Capability | Status | Details |
|---|---|---|
| EIP Specification Fetching | Working | Fetches EIP markdown, execution-specs (Python reference), and consensus-specs (beacon chain) from canonical GitHub repos |
| Multi-EIP Support | Working | EIP-1559, 4844, 4788, 2930, 7002, 7251 registered; 1559 and 4844 fully analyzed |
| Multi-Client Analysis | Working | go-ethereum (Go), Nethermind (C#), Besu (Java) — 5 files per EIP per client |
| Multi-Language Parsing | Working | Regex + optional tree-sitter parsers for Go, Python, C#, Java with EIP keyword matching |
| LLM Analysis | Working | Gemini 2.5 Pro and GPT-4 backends; structured JSON output; parallel file analysis |
| Report Generation | Working | JSON, Markdown, and HTML reports with executive summaries |
| CLI Tool | Working | Full Click-based CLI with progress bars, configuration panels |
| Test Suite | Working | 62 tests passing (unit, integration, multi-client) |
| CI Pipeline | Working | GitHub Actions running tests on Python 3.9–3.12 |
Example real output: PRSpec analyzed Nethermind's EIP-1559 implementation (5 C# files) and found 9 issues at 98% confidence, including a non-standard configurable minimum base fee that deviates from the specification, and a FeeCollector property that contradicts the mandatory fee burn mechanism. These are the kinds of findings that automated tools typically miss — they require understanding the intent behind both the spec and the code.
Validated by Nethermind core team: This finding was reported to Nethermind, and a core developer (@LukaszRozmej) confirmed that the FeeCollector is an intentional chain-specific extension (for Gnosis Chain) that “could be refactored better not to pollute the default config and spec.” PRSpec correctly identified a real spec deviation before any grant funding.
Ethereum Foundation engagement: The execution-specs team (@danceratopz, #2 contributor to ethereum/execution-specs) provided architectural guidance on using fork-to-fork diffs (the WET principle) for precise EIP boundary detection — directly informing PRSpec's spec extraction pipeline.
Every Ethereum upgrade requires that multiple client teams independently implement the same specifications. Cross-client consistency is what makes Ethereum secure, but verifying it is almost entirely manual:
- 400–600 hours per major upgrade for spec reconciliation across client implementations
- 3–4 week feedback loops between spec finalization and compliance verification
- 15–20% of security research time spent on mechanical comparison rather than deep analysis
With Pectra shipping and Fusaka in active development, the Ethereum ecosystem is processing more concurrent specification changes than ever. The coordination cost scales superlinearly — each new EIP multiplied by each client team. Human reviewers are Ethereum's scarcest resource; they should focus on nuanced judgment calls, not mechanical diff work.
Existing tools address related but distinct problems:
- Formal verification proves mathematical correctness but requires manual specification translation
- Static analysis checks code quality but lacks semantic understanding of protocol specs
- Fuzzing discovers edge cases but cannot verify spec alignment
- Transaction analysis monitors runtime behavior but offers only post-hoc detection
PRSpec fills the gap: automated specification-to-code alignment with semantic understanding, operating at PR time rather than audit time.
Specification Layer Analysis Layer Output Layer
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ EIP Markdown │ │ │ │ JSON Reports │
│ Execution Specs │────▶│ LLM Analyzer │────▶│ HTML Dashboard │
│ Consensus Specs │ │ (Gemini / GPT) │ │ CLI Output │
└──────────────────┘ └──────────────────┘ │ GitHub Action │
│ └──────────────────┘
Code Layer │
┌──────────────────┐ │
│ go-ethereum (Go)│ │
│ Nethermind (C#) │────────────┘
│ Besu (Java) │
│ + future clients│
└──────────────────┘
Specification Layer: Fetches EIP documents, execution-specs (Python reference implementations from ethereum/execution-specs), and consensus-specs (beacon chain markdown from ethereum/consensus-specs). Extracts sections, identifies constraints.
Code Layer: Per-client, per-EIP file registries mapping each EIP to the specific source files that implement it. Multi-language parsers (Go, C#, Java, Python) extract functions, classes, and methods with EIP-keyword filtering.
Analysis Layer: Sends specification + code to a large-context LLM with a structured prompt that enforces JSON output. The prompt is EIP-agnostic — it reads the EIP number, title, and focus areas from context, so the same pipeline works for any EIP. Files are analyzed in parallel via thread pool.
Output Layer: Generates JSON (machine-readable), Markdown (documentation), and HTML (human review) reports with executive summaries, per-file status, confidence scores, and actionable issue descriptions.
Traditional diff tools compare text; PRSpec compares intent:
- Extracts semantic constraints from specifications (e.g., "the base fee must increase by 1/8 when blocks are full")
- Maps constraints to code regions using AST analysis + LLM reasoning
- Detects drift when code violates extracted constraints, even if variable names change or structure is refactored
Example: Nethermind's IEip1559Spec interface includes a FeeCollector address property. A text diff would show a normal interface definition. PRSpec flags it as a HIGH severity deviation because EIP-1559 requires the base fee to be burned, not collected — a semantic violation invisible to syntactic tools.
- No data retention: Code is sent to the LLM for analysis and not stored beyond the local output directory
- Deterministic prompting: Structured JSON output schema ensures reproducible results
- Minimal permissions: GitHub Action will require only read access to PR diffs
- Local LLM support (planned): Ollama integration for sensitive codebases where no code should leave the infrastructure
| Deliverable | Status |
|---|---|
| Working prototype with EIP-1559 analysis against go-ethereum | Done (v1.0) |
| Multi-EIP architecture supporting 6 EIPs | Done (v1.1) |
| Parallel analysis engine with executive summaries | Done (v1.3) |
| Multi-client support: Nethermind (C#) + Besu (Java) | Done (v1.4) |
| 62 passing tests, CI pipeline, full documentation | Done (v1.4) |
| Deliverable | Phase | Description |
|---|---|---|
| Cross-client differential reports | Phase 3 | Compare how multiple clients implement the same EIP; identify where implementations diverge |
| Production GitHub Action | Phase 4 | Zero-config CI integration: uses: prspec/action@v1 in any client repo |
| PR-level analysis | Phase 4 | Analyze pull requests against canonical specs; post findings as PR comments |
| Pectra/Fusaka EIP coverage | Phase 3 | Add file mappings and analysis for current upgrade EIPs (7702, 2935, etc.) |
| Security dashboard | Phase 4 | Web interface for security teams to monitor spec compliance across clients |
| Local LLM support | Phase 4 | Ollama backend for privacy-sensitive analysis |
| Pilot with 2+ client teams | Phase 4 | Deployed in real client team workflows |
| Comprehensive documentation | Ongoing | Setup guides, API docs, contribution guidelines |
Duration: 6 months (Feb 2026 – Aug 2026)
Completed ahead of schedule, pre-grant, demonstrating execution capability.
- ☑ Multi-EIP architecture supporting 6 EIPs (1559, 4844, 4788, 2930, 7002, 7251)
- ☑ Multi-client analysis: go-ethereum (Go), Nethermind (C#), Besu (Java)
- ☑ Multi-language parsers with EIP keyword matching
- ☑ Parallel analysis engine (~3x speedup)
- ☑ JSON/Markdown/HTML reports with executive summaries
- ☑ 62 passing tests across unit, integration, and multi-client suites
- ☑ CI pipeline (GitHub Actions, Python 3.9–3.12)
Goal: Enable differential analysis to find where client implementations diverge from each other.
- Build cross-client comparison engine that analyzes the same EIP across multiple clients in a single run
- Generate differential reports highlighting where implementations agree and disagree
- Extend EIP coverage to Pectra/Fusaka upgrade EIPs (7702, 2935, etc.)
- Add Prysm (Go) and Lighthouse (Rust) consensus client support
- Implement spec embedding cache for faster repeated analysis
Goal: Ship production-ready GitHub Action, pilot with real client teams.
- Build and publish
prspec/action@v1GitHub Action - Implement PR-level analysis (analyze diffs, not just full files)
- Build security team dashboard for monitoring compliance across clients
- Add local LLM support via Ollama for privacy-sensitive workflows
- Conduct internal security audit of the tool itself
- Pilot deployment with 2+ client teams
- Transition documentation and community onboarding
Following discussion with Nethermind core developers (issue #10522), a promising direction emerged: using PRSpec to analyze the specifications themselves — flagging EIPs and devp2p specs that lack type sizes, constraints, or precise may/should/must logic. This would shift PRSpec from detecting code-vs-spec drift to also detecting spec ambiguity that causes implementation divergence in the first place. This direction will be explored after Phase 4 delivery.
This is the initial funding request. Phase 3 is a self-contained deliverable.
| Category | Amount | Details |
|---|---|---|
| Development | $11,000 | Cross-client differential engine, Pectra/Fusaka EIP coverage, Prysm + Lighthouse support |
| Infrastructure | $2,500 | LLM API costs (Gemini/GPT) for testing and analysis across all clients |
| Documentation | $1,500 | Technical writing, cross-client report examples, onboarding materials |
Requested only after Phase 3 deliverables are verified and accepted.
| Category | Amount | Details |
|---|---|---|
| Development | $14,000 | GitHub Action, PR-level analysis, security dashboard, Ollama local LLM |
| Infrastructure | $2,500 | CI runners, GitHub Actions compute, hosting for dashboard |
| Security Audit | $2,000 | Third-party review of GitHub Action permissions and data handling |
| Community & Pilots | $1,500 | Onboarding materials, pilot coordination with 2+ client teams |
Total across both milestones: $25,000 - $35,000
Initial request: $15,000 — ESP bears no risk on Phase 4 until Phase 3 is proven.
Open to discussion: These numbers reflect estimated costs, not fixed requirements. I am fully open to lower amounts or alternative structures — partial funding, deferred payments, or a smaller scope per phase. I built Phases 1–2 entirely self-funded because I believe in this project; the budget is about sustaining momentum, not a precondition for building. What matters most is ESP's support and alignment, not the specific dollar amount.
Safi El-Hassanine — Principal Engineer
Software engineer with 7+ years building production systems across fintech and distributed systems. My interest in Ethereum protocol security grew from watching the coordination challenges of the Merge and subsequent upgrades — recognizing that security bottlenecks are increasingly organizational, not technical.
Relevant experience:
- Built and scaled CI/CD pipelines processing 10M+ daily transactions
- Developed static analysis tools for Solidity smart contracts (open source)
- Deep familiarity with Ethereum protocol specs through independent research and client codebase study
- Experience with LLM application development: RAG systems, structured prompting, local model deployment
Execution proof: PRSpec Phases 1–2 were completed before grant funding, on personal time and resources. The tool works today. This grant funds the production and deployment phases.
| Metric | Target | Measurement |
|---|---|---|
| Spec drift instances caught | 10+ real findings across clients | Tracked in public issue reports |
| Client teams piloting | 2+ teams using PRSpec in their workflow | Integration confirmations from maintainers |
| False positive rate | <15% | Labeled dataset of historical spec-code mismatches |
| EIP coverage | 10+ EIPs with full file mappings | Registry count in codebase |
| Review time savings | 30%+ reduction in manual spec review | Time-tracking survey with pilot teams |
| PRs analyzed (with GitHub Action) | 100+ per month by month 6 | GitHub Action telemetry (opt-in) |
Open Source: All code is released under the MIT license. Repository: github.com/Fosurero/PRSpec
Active Development (Months 1–4): Weekly progress updates to ESP. All milestones tracked in GitHub Issues and documented in the changelog.
Transition (Months 5–6): Prepare for community stewardship — contribution guidelines (already in place), onboarding documentation, and optionally transfer to EF GitHub organization if desired.
Post-Grant: I commit to 12 months of advisory support (1–2 hours weekly) to ensure smooth knowledge transfer. Community-driven maintenance with client teams contributing EIP adapters.
Ethereum's security depends on faithful reconciliation of specifications and implementations across multiple independent client teams. This is mechanical, high-stakes work that scales poorly with human effort alone.
PRSpec automates the mechanical comparison, letting human intelligence focus on the judgment calls that only experienced protocol engineers can make. The tool works today. This grant funds its path to production.
Contact:
Safi El-Hassanine
Sofyelhelaly(at)gmail.com
https://x.com/Safy__H
GitHub: github.com/Fosurero
Repository: github.com/Fosurero/PRSpec