Livepeer Subgraph Audit Proposal

Direct Grant Application

Livepeer Subgraph Audit Proposal

1. Applicant + Payout Details

  • Applicant: BuildersDAO
  • Main contact: James (jmulq)
  • Payment address: 0x615fd4ed2cd90b8d33d2eb2e3df663f9722246b5 on Arbitrum

2. Scope

Problem Statement

The Livepeer subgraph is core ecosystem infrastructure. It supports Explorer views, governance surfaces, delegator tooling, and tokenomics analysis across the Livepeer ecosystem.

The subgraph has not yet had a structured audit, so Livepeer lacks a current baseline for its indexing performance and subgraph size, as well as a clear picture of current technical debt, data model issues, and indexing gaps. This creates risk when adding new features, because new indexing work may build on top of unmeasured or unresolved technical debt.

The current roadmap identifies per round delegator and orchestrator stake and earnings as an important indexing gap for income, tax reporting, and time-series views. Recent subgraph issues, including an edge case that caused indexers to error and affected delegator withdrawals, also reinforce the need for a comprehensive audit. Auditing the current subgraph first will give Livepeer a clearer foundation for future remediation and feature work, including known data discrepancies, non-deterministic indexing risks, technical debt, and schema constraints.

Proposed Solution

BuildersDAO will perform a focused technical audit of the Livepeer subgraph.

The audit will review the current codebase, schema, manifest, mapping logic, protocol coverage, query suitability, testing setup, maintainability, and failure-prone indexing patterns. The final output will be a structured audit report with prioritised findings, evidence, and recommended remediation steps.

This proposal is audit-only. Remediation PRs, InfraDAO indexing benchmarks, and implementation of per round stake/earnings indexing can be funded separately after the findings are triaged.

As part of the audit, BuildersDAO will hold one 60 minute community session with relevant Livepeer maintainers, ecosystem contributors, and active subgraph users. The goal is to gather known pain points, recurring data discrepancies, unreported issues, important query paths, and context from teams that have worked around subgraph limitations. Input from this session will inform the audit focus and be reflected in the final report where relevant.

Where useful, BuildersDAO will support findings with selected evidence checks against important subgraph entities, known transactions, provided datasets, chain logs, or contract state. These checks are intended to help identify and evidence specific issues; they are not exhaustive data reconciliation or a guarantee that every historical record is correct.

In Scope

  • Comprehensive subgraph audit covering repository setup, protocol coverage, schema, manifest, mappings, query suitability, testing, indexing performance, storage, and maintainability
  • InfraDAO baseline indexing metrics for the current subgraph
  • One community input session with interested maintainers, ecosystem contributors, and active subgraph users to gather recurring pain points, known discrepancies, unreported issues, and priority query/use-case needs.
  • Review of known data accuracy concerns or discrepancies raised by ecosystem contributors, using provided examples, datasets, endpoints, transactions, or account histories where available.
  • Selected evidence checks for important entities, queries, events, or protocol flows where useful.
  • Audit report and community retro post

Out Of Scope

  • Remediation PRs
  • Full implementation of per round delegator/orchestrator stake and earnings
  • Local or CI-based full indexing benchmarks
  • Exhaustive historical reconciliation of every indexed record

Dependencies / Assumptions

  • Livepeer confirms the repository branch, deployment hash, and subgraph endpoint.
  • Livepeer maintainers provide important Explorer/product queries where available.
  • Livepeer helps identify and invite relevant contributors or users for the community input session, such as Explorer maintainers, data consumers, and contributors who have previously worked around subgraph limitations.
  • Livepeer maintainers and ecosystem contributors provide any known subgraph data discrepancies, alternative indexed datasets, relevant endpoints, or account/transaction examples that can be used as evidence during review.
  • InfraDAO is available to run indexing benchmarks in a consistent environment.
  • Livepeer maintainers will confirm whether any findings should be treated as sensitive before public GitHub issues are created.
  • This audit will identify and prioritise remediation work, but implementation is not included in this grant.

3. Deliverables + Acceptance Criteria

Deliverable 1: Final Audit Report + Baseline Metrics

Acceptance criteria:

  • Current Livepeer subgraph is reviewed across schema, manifest, mappings, protocol coverage, query suitability, performance risks, and testing/CI.
  • Recent and known incident contexts are reviewed where relevant to identify related classes of risk, including:
    • The recent unhandled null / indexer error incident that affected delegator withdrawals.
    • Prior reports of non-deterministic indexing behaviour where context is available.
    • Known data discrepancies or accuracy concerns raised by Livepeer maintainers or ecosystem contributors.
  • InfraDAO baseline metrics are collected for the current subgraph.
  • Findings are documented with severity, evidence, and recommendations.
  • Findings are classified as:
    • Critical production / indexing risk
    • Non-breaking remediation
    • Breaking/schema-impacting
    • Future feature work
    • Larger redesign
  • Final audit report includes:
    • Audited commit and scope
    • Methodology
    • Prioritised findings table
    • Detailed findings with evidence and recommendations
    • Protocol coverage notes or matrix where useful
    • Selected evidence check notes where useful
    • Query suitability notes
    • Incident-related risk notes where applicable
    • Remaining risks and future work
  • Public GitHub issues or milestone items are created for non-sensitive findings where useful. Findings considered sensitive by Livepeer maintainers will remain in the report or be shared through the appropriate private channel.
  • Final forum update/retro is published documenting the audit output and recommended next steps.

4. Milestones + Payment Tranches

Total grant request: $6,500 USD-equivalent in LPT

This includes the required 10% allocation for reporting, retroactive post, and community engagement.

Milestone What Will Be Delivered Verification Method Target Date Payout Amount
1 Final subgraph audit report, baseline metrics, forum retro post Final report delivered, findings documented with severity/evidence/recommendations, issues or milestone items linked where useful, forum update published End of Week 2 $6,500

5. Update Cadence

  • Cadence: Lightweight updates as needed during the 2-week audit.
  • Working channel: Private Discord coordination with Livepeer maintainers.
  • Community input: One 60-minute input session during the audit window, open to relevant maintainers, ecosystem contributors, and active users suggested by Livepeer.
  • Public update: Final forum update/retro published on completion.

Updates may include:

  • Open questions
  • Blockers
  • Urgent findings
  • Scope risks
  • Expected completion timing

Given the short audit timeline, ongoing public progress updates are not expected unless the audit is delayed or a material issue is found.

6. Budget + Use Of Funds

Category Amount Notes
Audit and technical review $5,700 Protocol coverage, schema, manifest, mappings, query suitability, testing/CI, indexing resilience, recent incident review, selected evidence checks, and maintainability review
Coordination and reporting $800 Maintainer coordination, final audit report, and forum update/retro
Total $6,500 Paid in LPT using the Direct Grant conversion process

7. Impact

Expected Impact

If successful, this grant will give Livepeer a clear, prioritised view of the current subgraph’s correctness risks, technical debt, indexing gaps, production failure risks, and future remediation priorities.

Expected outcomes:

  • Current indexing gaps, technical debt, and data-model risks are identified and prioritised.
  • The recent class of null-handling/indexing-failure issue is reviewed for related risks.
  • Livepeer has baseline indexing metrics from a consistent InfraDAO environment.
  • Livepeer has a remediation backlog that can be used to fund or assign follow-on fixes.

How Impact Will Be Evidenced

Impact will be evidenced by:

  • Final audit report
  • Prioritised findings table
  • Detailed findings with evidence and recommendations
  • InfraDAO baseline
  • GitHub issues or milestone items where useful
  • Final forum update/retro

Risks + Mitigations

  • Risk: Some data correctness concerns require broader historical reconciliation to prove fully.

    Mitigation: The audit will use selected evidence checks where useful, but exhaustive reconciliation is out of scope and will be documented separately if needed.

  • Risk: Missing context from maintainers or downstream consumers limits parts of the protocol coverage or query suitability review.

    Mitigation: BuildersDAO will request key queries, known discrepancies, incident context, and relevant examples at kickoff. If some context is unavailable, assumptions and limitations will be documented in the report.

  • Risk: The audit identifies urgent production issues before the final report is complete.

    Mitigation: Critical findings will be surfaced to Livepeer maintainers as soon as they are identified rather than waiting for the final report.

8. Prior Work + Relevant Context

BuildersDAO has experience building, auditing, and improving subgraphs with a focus on schema design, mapping correctness, protocol coverage, performance, maintainability, and The Graph best practices.

BuildersDAO is well suited to this work because:

  • BuildersDAO has previously contributed review work around the Livepeer subgraph through PR#168 and PR#175.
  • The team has domain experience with subgraph auditing
  • InfraDAO can provide practical indexer-side benchmark data
  • The output directly supports future Livepeer subgraph work, including per round stake and earnings indexing.

Team

BuildersDAO is the applicant and accountable delivery entity. The named contributors below are included for transparency and community review.

  • James M — Project Lead / Audit Reviewer

    James will coordinate the grant, manage Livepeer communication, maintain the GitHub milestone, review audit findings and support technical delivery where needed, and own the final report and retro post.

    Relevant background: James has 9 years of software development experience, including several years working in web3 infrastructure and The Graph ecosystem. He has led and contributed to subgraph audits, ground-up subgraph builds, optimisation work applying The Graph best practices, bespoke Substreams data pipelines, and Rust/Elixir-based data systems. He is especially focused on making indexed data accurate, efficient to serve, easy to maintain, and practical for real product use cases.

  • Shashwat D — Auditor & Engineer

    Shashwat will contribute to auditing the Livepeer subgraph schema, manifest, mapping logic, and protocol coverage.

    Relevant background: Shashwat has 6 years of software development experience, specializing in data indexing infrastructure, multi-chain data extraction, and standardised protocol tracking within The Graph ecosystem. As an open-source contributor to Messari, he designed and implemented production subgraphs for high-volume DeFi and streaming protocols—including Livepeer, GMX, and Ribbon—authoring custom AssemblyScript mappings and an open-source SDK to normalise heterogeneous smart contract events into unified schemas for institutional analytics. His infrastructure work extends to Graph BuildersDAO, where he engineered high-performance data pipelines utilising both Subgraphs and Rust-based Substreams to process millions of on-chain events daily.

  • Ciaran L — Auditor & Engineer

    Ciaran will contribute to auditing the Livepeer subgraph schema, manifest, mapping logic, and protocol coverage.

    Relevant background: Ciaran has 6 years of software development and data engineering experience. Formerly working in biotech, he has recently moved into the web3 space, where he has contributed to Operations, Business Development and subgraph auditing efforts at BuildersDAO.

  • InfraDAO — Indexing Benchmark Partner

    InfraDAO will run baseline indexing benchmarks in a consistent environment and provide sync, entity count, and subgraph size metrics.

    Relevant background: InfraDAO operates indexing infrastructure and can provide indexer-side measurements that are more representative than local-only benchmarking.

9. Network Engineering SPE Rubric Fit

Primary Eligibility Area

  • Tooling & Infrastructure

This grant fits Tooling & Infrastructure because the Livepeer subgraph is shared ecosystem data infrastructure used by Explorer, governance, delegator tooling, and analytics surfaces.

Design Principles Check

  • Community-originated

    Comes from a Livepeer roadmap item (Subgraph Audit & Stake/Earnings Indexing) identifying the need for subgraph audit, benchmarking, and stake/earnings readiness.

  • Pre-agreed pricing

    Total grant request is capped at $6,500

  • Impact-linked payment

    Payments are tied to a final audit report and retro post.

  • Transparent by default

    Work will be coordinated with maintainers during the audit and documented publicly through the final forum update/retro.

  • Speed

    Proposed timeline is 2 weeks.

Impact Evidence Plan

  • Named adopters who will use it:

    Livepeer subgraph maintainers, Explorer maintainers, governance/data consumers, delegator tooling maintainers, and future subgraph remediation implementers.

  • Downstream dependency:

    Explorer views, governance surfaces, delegator tooling, tokenomics analysis, and future per round stake/earnings indexing depend on the subgraph.

  • Capability confirmed in the wild:

    The final output will include a published audit report, prioritised findings table, evidence-backed recommendations, and a remediation backlog that can be used to fund or assign follow-on fixes.

3 Likes

While I don’t have any feedback on any particulars of the proposal, I do support it, having worked on downstream dependencies like the Explorer. Especially given the recent incident, which importantly affected delegator withdrawals, this kind of audit should rebuild delegator trust, and prevent similar events from occurring in the future. Furthermore, deliverables like “future feature work” and “larger redesign” will be insightful after talking with various stakeholders during the community session, especially given the proposed plans for Livepeer 2.0.

1 Like

Hey @jmulq, thanks for submitting this Direct Grant application. I’m happy to publicly support it.

The Livepeer subgraph is critical ecosystem infrastructure, and its accuracy and reliability have become increasingly important as technical debt and edge cases have accumulated. The recent indexing incident involving our subgraph further highlights the importance of this work.

Funding lane: Direct Grant

Category: Tooling & Infrastructure (shared ecosystem data infrastructure)

Amount: $6,500 USD-equivalent in LPT ($5,700 audit and technical review, $800 coordination and reporting)

Decision

The Review Team approved this Direct Grant for BuildersDAO (@jmulq) to audit the Livepeer subgraph, delivered as a single milestone: a prioritized final audit report.

Rationale

Assessed against the Network Engineering SPE rubric.

  • Process compliance & scope fit. The SPE commissioned this audit after the Explorer subgraph incident and asked BuildersDAO for an audit-only proposal. That is what landed: diagnosis and reporting only, with remediation, the per-round stake/earnings feature, historical reconciliation, and full benchmarking out of scope. The subgraph feeds Explorer, governance, delegator tooling, and analytics, so it sits squarely in Tooling & Infrastructure.
  • Delivery confidence. The team ships without a long ramp: James M (9 yrs, The Graph ecosystem), Shashwat D (6 yrs indexing, prior Livepeer subgraph work via Messari), Ciaran L (6 yrs), plus InfraDAO for indexer-side baselines. Their familiarity with this subgraph is why they can read the root cause of the incident quickly (an unhandled null to field from Tenderize contract-to-contract calls, latent since ~2021).
  • Clarity & structure. One milestone with a clear definition of done: findings tiered from critical production risk down to larger redesign, each with evidence and a recommendation, non-sensitive items filed as public GitHub issues, and a closing forum retrospective. Targeted for end of Week 2 with one 60-minute community input session.
  • Quality bar & impact. The outage blocked delegator withdrawals and forced a multi-day resync over an edge case an audit should have caught. As the Technical Director put it, the subgraph breaking cost far more than an audit that could’ve prevent this, and it is the delegator who pays when this layer fails. The audit surfaces the remaining edge cases before the next incident, rebuilds delegator trust, sets InfraDAO baselines, and yields a ranked backlog for staged remediation.

Conditions & Alignment

  • Anchor to the real failure. Incident GitHub issues shared with BuildersDAO so the audit is grounded in the actual root cause.
  • Findings public by default. Non-sensitive findings filed as public GitHub issues; live production-risk items disclosed privately first, then published once safe.
  • Remediation stays separate. This grant covers audit and reporting only; remediation is scoped and priced as staged follow-up once findings are ranked.
  • Closeout. Final forum retrospective on completion, per the Monthly Reports guide, in this thread.

Mehrdad, on behalf of Network Engineering SPE

Welcome @jmulq to the Livepeer Community!

I want to add a perspective from the operational side. I’ve been running my own self-hosted indexing of Livepeer protocol events for the past three years, with on-chain verification built in — the latest version is the Livepeer Protocol Explorer, approved by the Engineering SPE. Building and operating that taught me the issues in the subgraph are real and hard to manage day-to-day.

I’ve also tried to run the Livepeer subgraph myself from scratch, and I was never able to rebuild the index fresh — it consistently fails on specific blockchain events and never proceeds past them. That matches my broader experience: the hard problems here aren’t cosmetic. They fall into a few categories I have concrete insights on:

  • Correctness — stored values that don’t reconcile against contract state
  • Indexing performance — RPC call volume per event, which drives both sync time and infra cost
  • Event coverage — contract events that are partially or not at all captured
  • Resilience — the ability to rebuild the index from genesis without deterministic failures
  • Verifiability — continuously proving the index matches on-chain data, not just at audit time
  • Modernization — staying up to date with best practices, libraries, and APIs from The Graph’s subgraph tooling

The outcome that matters to me (and I hope the broader Livepeer community): an index that stays current, runs fast with minimal RPC overhead, is highly available, and can be verified against the chain with trust. I have detailed notes in each of the categories above and I’m glad to share them — looking forward to the live call to discuss any of these directly.

1 Like

Livepeer Subgraph Audit: Final Report and Next Steps

Hey everyone! We have completed the Livepeer Subgraph Audit funded through the Network Engineering SPE Direct Grants programme.

This post provides a high-level summary of the work completed and our recommended next steps. The individual technical findings and supporting evidence are contained in the full audit report rather than repeated here, however we’re happy to discuss any of these findings in detail with the Livepeer community.

Links

Work Completed

During the engagement, BuildersDAO:

  • Reviewed the subgraph’s schema, manifest, mappings, protocol coverage, repository setup, tests, and dependencies.
  • Assessed correctness, indexing resilience, maintainability, storage patterns, and adoption of current The Graph features.
  • Reviewed relevant Livepeer contracts, historical incidents, repository issues, and previous contributions.
  • Held an open community session to gather recurring pain points, reported discrepancies, indexing concerns, and downstream data requirements.
  • Reviewed production Explorer queries against the subgraph schema.
  • Used query-traffic data courtesy of Ellipfra to understand which queries are used most frequently and where query-serving costs are concentrated.
  • Performed selected data checks against the deployed subgraph, contract state, chain data, and the Livepeer Protocol Explorer.
  • Coordinated with InfraDAO to establish a point-in-time indexing baseline.

The audit was performed against Livepeer subgraph commit b13e4f2.

High-Level Outcomes

The audit identified findings across a range of severities and areas.

Each finding includes supporting evidence, its likely impact, and a recommended course of action. Findings have also been classified by priority, to assist with planning future remediation work.

The query review also surfaced several Explorer and frontend query opportunities. These have been documented separately from the subgraph findings so that ownership and remediation requirements remain clear.

Indexing Baseline

InfraDAO indexed the current deployment and supplied the following 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 is a point-in-time measurement from one controlled environment. It should be repeated under the same conditions after substantial remediation work to provide a meaningful A/B comparison.

Community and Production Context

The open community session provided great insight from people who maintain, consume, and have previously worked around limitations in the current subgraph. We have used the context from this session to help direct attention towards real concerns and downstream requirements.

Ellipfra also supplied production query-traffic data covering 276,402 queries over an eight-day capture window. This allowed the query suitability review to focus on real usage rather than hypothetical query patterns.

We would be more than happy to coordinate a deeper analysis with Ellipfra if Livepeer finds that useful when prioritising future Explorer or query-performance work.

Limitations

This was an audit-only engagement. It did not include remediation PRs or implementation of per-round delegator and orchestrator stake and earnings indexing.

The data-validation work was targeted and evidence-driven, rather than an exhaustive reconciliation of every historical entity. The report is therefore a technical audit and prioritisation tool, not a certification that every indexed record is historically correct.

Recommended Next Steps

The immediate next step is for Livepeer maintainers and relevant ecosystem contributors to triage the findings and agree on remediation priorities.

From here, we suggest that the issues are batched into several categories of fixes:

  • Urgent correctness and reliability fixes
  • Compatible, non-breaking improvements (subgraph-only ugrade)
  • A coordinated migration for schema-impacting changes
  • Explorer and frontend query improvements
  • Separate implementation of per-round stake and earnings indexing
  • Repeat InfraDAO benchmarking after material changes

BuildersDAO can be available to support the triage process and to scope remediation work once Livepeer has reviewed the report.

Grant Completion

This completes the single audit milestone under the approved $6,500 USD-equivalent Direct Grant, including the audit, community engagement, reporting, and this completion post.

A massive thank you from the BuildersDAO team to the Livepeer contributors who joined the community session or supplied technical context, and to InfraDAO and Ellipfra for providing the indexing and production-query data used in the review.

Thanks @jmulq and team. This is a strong report.

Before commenting, I did two verification passes. First, I checked each finding against the audited commit (b13e4f2). Then I verified the ABI and contract behavior claims against the deployment artifacts in livepeer/protocol, specifically deployments/arbitrumMainnet, and the BondingManager source. Everything checked out.

The live confirmations for BDR-1 using real gateway balances, BDR-10 using 25 orchestrators, and BDR-20 using Governor.state() are exactly the evidence standard I hoped this audit would set.

Additional discoveries

The checked-in BondingManager ABI is stale in both directions, which resolves BDR-34.

I checked all 14 BondingManagerTarget versions deployed on Arbitrum, from the February 2022 migration through July 2026. Every version declares only the three-argument WithdrawFees(indexed address,address,uint256) event.

The one-argument overload exists only in hand-maintained ABI files. It appears to have carried over from the L1-era ABI and has also propagated into vendored ABIs in downstream projects. It has never been emitted on Arbitrum, so I would drop BDR-34 rather than implement it.

This is the inverse of BDR-21. The same abis/BondingManager.json file is missing a real event, TreasuryReward, which is emitted at BondingManager.sol:968, while including a phantom event. Regenerating the ABI from the deployment artifact, as BDR-21 recommends, fixes both problems. The TreasuryReward handler and entity work can then build on the corrected ABI.

BDR-19 also slightly understates the BondingVotes surface. In addition to DelegatorBondedAmountChanged, the contract emits DelegateChanged and DelegateVotesChanged. Those events should be included if a data source is added.

BDR-11 should note that declarative eth_call support requires specVersion 1.2.0 or later and apiVersion 0.0.9. This makes it dependent on BDR-14 and BDR-15. BDR-17 states its dependency clearly, but BDR-11 currently reads as immediately actionable.

Additional remediation items

These issues are present at b13e4f2 and are not covered by the report:

Issue Where Class
BigInt values are compared with !==, which compares identity rather than value in AssemblyScript. Both guards are always true, so the rewardCut and feeShare timestamps update on every TranscoderUpdate, even when the values are unchanged. bondingManager.ts:555, 559 Correctness
getBlockNum() is uncached and makes roughly one identical eth_call per event in the same block. A per-block cache on a singleton entity works with specVersion 0.0.2 today, unlike BDR-11, which requires an upgrade first. helpers.ts:568–575 Performance
The Uniswap slot0 price call runs for every WinningTicketRedeemed, resulting in one eth_call per ticket. BDR-6 covers revert behavior but not this cost. The result could be cached by block or round, as lptPriceEth already is. ticketBroker.tsgetEthPriceUsd() Performance
Transaction.gasUsed stores the gas limit, not the actual gas used. Accurate values require handlers with receipt: true, which needs specVersion 1.0.0 or later. This should be included in BDR-14 or the field should be renamed. helpers.ts:147 Correctness
When a voter is also the old delegate in updatePollTallyOnBond, such as a self-delegated transcoder switching delegates during a poll, the handler keeps two in-memory copies of the same Vote. The final vote.save() overwrites the nonVoteStake and voteStake updates saved through oldDelegateVote. Also, createOrLoadVote never returns null, so the if (oldDelegateVote) and if (newDelegateVote) guards are always true and the newDelegateVote == null branch is dead code. pollTallyHandlers.ts Correctness
Delegator counts start from a hardcoded Arbitrum One snapshot of 3,520 and are updated through event-shape heuristics without a zero floor. This design can drift, although I have not measured the current discrepancy. helpers.ts:193–196, bondingManager.ts:121–124, 277–278, 344–345 Correctness

Testing and CI

BDR-36 stops at re-enabling the Mocha integration suite. I would also add Matchstick unit tests through graph test and run the Subgraph Linter in CI. Its checks for unchecked loads, unguarded division, and entity overwrites directly cover several of the report’s main bug classes.

No tests currently run in CI. The only compile check happens implicitly during the pull request preview deployment. Nothing gates the tag-to-production deployment.

Questions

  1. The InfraDAO baseline reports a clean 22h16m genesis sync with “no indexing issues.” Community input #7 and my own experience indicate that genesis re-indexing fails on some events. Was the baseline recorded after the recent abort fixes in #243 and #249? It would help to document the graph-node version and RPC configuration used.

  2. Will the baseline measurement be scripted and repeatable? That would let remediation pull requests show their sync-time impact before and after each change.

These are my findings and recommendations, not blockers or final conclusions. Please push back on anything that seems incorrect, unnecessary, too critical, or more complicated than the value it provides. If I missed context or got something wrong, I would rather correct it now. My goal is to help strengthen the remediation plan, not expand the scope without good reason.

Thanks again to everyone who contributed to this report. I appreciate the time, care, and hard work that went into it.

Cheers!

Hi Mike! happy to hear you are pleased with the quality of the audit, and thanks for giving it such a thorough check. I’m OOO right now, but I will dedicate some proper time to dig in to the additional issues you have found, cheers!!

Thanks @MikeZupper for your thorough review.

Thanks @jmulq, @ciaran, and the team. I went through the report against b13e4f2 and the issues I’ve filed. Very valuable deliverable which provides a solid basis for improving the subgraph. A few comments:

BDR-1: Good finding, though I think there may be a simpler fix. reserveClaimed should already subtract the claimed amount from broadcaster.reserve in the same transaction, so winningTicketRedeemed should not need to touch the reserve at all, only the deposit. Reordering the zeroing would still leave it deducted twice. More detail in #257.

BDR-6 / BDR-9: Agreed on the call sites, but logging only makes the failure visible, it does not make the stored value correct. And in the case #248 is really about, a lagging node returning a plausible but incorrect value with no revert, nothing is logged at all.

BDR-3 / BDR-4: Valid findings, but slashing is disabled protocol-side, so I would put these at lower priority. They also need to land together; otherwise the handler exposes the #243 abort. I would drop BDR-34: that signature was replaced in protocol PR #511 in December 2021, before the L2 contracts existed.

A few items I did not see in the report, in case they were deliberately set aside rather than missed: #229 (fee math keyed off faceValue rather than amountToTransfer, fixed by indexing WinningTicketTransfer), #27, #230, #26, #69, plus #237.

Two final asks:

  1. Could the findings be turned into concrete work items: what should be grouped, what should land first, rough effort.
  2. Could InfraDAO give a rough sense of how the 22h sync time, 1.7M entities, and 8.31 GiB footprint compare with other subgraphs, even just whether each is typical, heavy, or light?

Thanks again. This is a solid piece of work.

Hi @MikeZupper and @rickstaa , thanks for your comments - some really great catches in there, and apologies again for the OOO delay. I’ve just finished checking these findings and rolling them into a fresh version of the audit with some minor tweaks, and I’ve passed on the benchmarking questions to infraDAO. All of what you have found/ asked should be adequately covered by a read of the audit, with the exception of @rickstaa 's missing issues:

  • issue #26 and #69 have been intentionally set aside as they were not reproducable my end.
  • issue #229 has now been rolled into BDR-1, as it is tightly coupled.
  • issues #27, #230 and #237 have had new findings raised to acknowledge them.
    also note that the table has intentionally been left un-priority-sorted to maintain consistency in finding numbering. Ill send across the audit by the same channels as the previous version so you can distribute it however is best, cheers!
1 Like

Hey @Ciaran, thanks for your response and for updating the audit.

I reviewed the new report and took another look at #26. I agree that the original finding is no longer fully valid. However, it did lead to finding a data inaccuracy that can be addressed together with BDR-43. I’ve logged this for your team in #273.

I also reviewed #69, which I was able to reproduce. However, it’s informational and relatively low priority at the moment. I’ve added more context in this comment to help with future prioritization.

Other than that, good to go from my side. Looking forward to infraDAO’s response and to discussing the next steps for addressing the remaining findings.