Livepeer Subgraph Audit - Retrospective
Introduction
BuildersDAO completed the Livepeer Subgraph Audit under a single $6,500 Network Engineering SPE Direct Grant milestone.
This engagement was audit-only, and its purpose was to establish a clear view of the subgraph’s correctness risks, indexing gaps, technical debt, performance characteristics, and suitability for downstream queries. It did not include remediation PRs.
The audit was performed against livepeer/subgraph commit b13e4f2.
Commitments Delivered
Final audit report
BuildersDAO delivered a comprehensive audit covering the schema, manifest, mapping logic, protocol and event coverage, repository setup, tests, dependencies, indexing resilience, storage patterns, maintainability, and use of current The Graph features.
The report includes a prioritised findings table, detailed evidence and recommendations, query suitability analysis, incident context, limitations, and suggested work for the future. Findings are separated by severity and remediation type so maintainers can distinguish urgent fixes from non-breaking improvements, schema-impacting changes, future features, and larger redesigns.
Evidence:
The final report also includes a remediation roadmap that groups findings into delivery waves, records dependencies, and provides rough effort estimates. This gives us a more practical starting point for scoping follow-on work than severity labels alone.
Indexing baseline
InfraDAO indexed the audited deployment in a consistent environment and supplied the requested point-in-time baseline:
| Metric | Result |
|---|---|
| Genesis-to-head sync time | 22 hours, 16 minutes, 26 seconds |
| Total entity count | 1,704,481 |
| Database size | 8.31 GiB |
| Final indexed block | 495,999,604 |
| Indexing errors encountered | None |
This gives Livepeer a reference point for later remediation work. It is a single point-in-time measurement rather than an automatically repeatable benchmark. The final report recommends confirming whether it can be repeated for remediation PRs and documenting the graph-node version and RPC configuration used.
Community input
BuildersDAO held the planned open community session with maintainers, ecosystem contributors, and active users. The discussion covered recurring indexing failures, data discrepancies, protocol coverage, rebuild reliability, RPC usage, schema usability, and product requirements such as historical stake and earnings data.
This input was mapped into the report rather than treated as anecdotal background. It helped focus the audit on operational problems experienced by downstream users and highlighted areas where static code review alone would not have been enough.
Query suitability and production context
The audit reviewed important Explorer, product, and governance queries against the subgraph schema. Ellipfra supplied production query-traffic data covering 276,402 queries over an eight-day capture window, 138 distinct query shapes, and 47 days of aggregate volume history.
This evidence made it possible to distinguish frequently used query paths from hypothetical concerns and to identify which costs belong to the subgraph data model and which belong to frontend query construction.
Evidence:
Incident review and selected validation
The audit reviewed the recent null-handling/indexer failure incident, prior reports of non-deterministic behaviour, relevant repository issues, contract implementations, and deployment artefacts.
Selected findings were checked against the deployed subgraph, direct contract state, chain data, and the Livepeer Protocol Explorer. This was targeted validation rather than exhaustive historical reconciliation, which remained outside the grant scope.
Delivered Beyond Commitments
Explorer and frontend findings
Reviewing the Explorer’s checked-in GraphQL queries alongside Ellipfra’s traffic data surfaced several query-design and product issues outside the subgraph itself. These were documented under a separate EXP- prefix so to distinguish between subgraph and front-end specific issues.
Community verification and revision
After the first report was published, @MikeZupper independently checked the findings against the audited commit, protocol deployment artefacts, and contract behaviour. @rickstaa also reviewed the report against the codebase and existing issues. Their feedback identified useful corrections, dependencies, additional edge cases, and opportunities to improve remediation guidance.
BuildersDAO reviewed that feedback and issued an updated report. Unsupported or non-reproducible items were removed or set aside, overlapping items were consolidated, and supported additions were incorporated. This additional review cycle materially improved the accuracy and usefulness of the final output, and will further help to guide planning for any remediation work.
Commitments Not Delivered
Original two-week target
The final report was not completed within the proposed 2 week window. The initial completion report was published on 4 September, followed by a further community review and revision cycle.
The additional time supported data checks, production query analysis, independent verification, and corrections to the report. Those additions improved the result, but the delivery estimate should still have included a dedicated external-review and revision period. A future audit of comparable scope should allow three to four weeks, or explicitly separate the initial report from the community-review closeout.
Public GitHub remediation backlog
The report provides a remediation roadmap with delivery waves, dependencies, and rough effort estimates, and links existing issues where relevant. However, the non-sensitive findings were not all converted into individual public GitHub issues or a dedicated remediation milestone during the audit engagement.
This should be revisited during maintainer triage. Creating every issue before that review could produce noise or duplicate existing reports, but agreed findings should ultimately become grouped, actionable work items with dependencies, sequencing, and rough effort recorded.
No production remediation, exhaustive historical reconciliation, local or CI-based full indexing benchmark tooling, or per-round stake and earnings implementation was delivered. These items were explicitly outside the approved audit scope rather than missed commitments.
Impact
The audit gives Livepeer an evidence-backed view of the current subgraph rather than a collection of isolated incident reports or assumptions. Maintainers now have:
- A prioritised set of correctness, reliability, performance, schema, protocol coverage, testing, and maintainability findings.
- A measured indexing and storage baseline for evaluating future changes.
- Recommendations that distinguish non-breaking work from coordinated schema migrations and larger feature work.
- Production query evidence showing which data paths matter most to downstream users.
- A clearer separation between subgraph issues and Explorer/frontend query issues.
- External community review confirming the value of the report and strengthening its technical conclusions.
The audit itself did not change production behaviour, so it would be inaccurate to claim that reliability or query performance has already improved. Its immediate impact is reduced uncertainty and a stronger basis for prioritising, scoping, and verifying remediation. The larger network impact depends on the findings being converted into shipped changes.
Key Learnings
- Static review and live validation are complementary. Code inspection identifies broad risk classes, while targeted chain and data comparisons establish whether a suspected issue is active and material.
- Production query traffic substantially improves a query review. It prevents effort being spent on theoretical patterns while expensive real-world queries remain overlooked.
- Community review should be planned as part of delivery. Maintainers and operators hold operational context that may not exist in code, documentation, or issue trackers.
- Benchmark results need enough context to be interpreted and repeated. The final report records the indexed block and calls for the graph-node version and RPC configuration to be documented, as well as asking whether the measurement can be made repeatable for remediation PRs.
- Two weeks was too aggressive for an audit that included community discovery, indexer coordination, production traffic analysis, live validation, and external review.
Conclusion & What’s Next
The approved audit milestone is complete. BuildersDAO will now coordinate with Livepeer to arrange a remediation-scoping kickoff. The purpose of that session will be to review the final roadmap, confirm priorities and dependencies, and agree how the work should be grouped, validated, benchmarked, and funded.
Recommended next steps are:
- Hold a remediation-scoping kickoff with Livepeer maintainers.
- Triage the final findings and confirm the proposed delivery waves, priorities, and dependencies.
- Convert agreed non-sensitive findings into grouped GitHub issues or milestones, including dependencies and rough effort.
- Scope urgent correctness and reliability work first.
- Batch compatible non-breaking improvements into a focused remediation release.
- Plan schema-impacting changes as a coordinated migration with downstream consumers.
- Coordinate separately with the Explorer team on the supplementary frontend query findings.
- Repeat the InfraDAO benchmark after material changes using a comparable environment.
A deeper Ellipfra query analysis or broader historical reconciliation can also be scoped separately if Livepeer needs stronger evidence for query optimisation or historical data correctness.
Thank you to the Livepeer maintainers and community members who contributed context and review, and to InfraDAO and Ellipfra for supplying the indexing and production-query evidence used in the audit.