Trustless PPM: Verifiable Performance Data for HighPotential

HighPotential’s yield distribution algorithm, Performance Based Returns (PBR), relies on the ingestion of offchain sports performance data. The PBR formula, copied below, utilizes these offchain datapoints to produce the m and M_adj values, where raw stats are collected from Opta and converted into Player Performance Metrics (PPM).

I = R · m/M_adj · s/S

PPM is a weighted basket of coefficients that quantifies player performances in real-time. The coefficients form the first part of the proportional distribution formula, where each asset’s vault receives ETH yield proportionally to the quality of its real world performances.

A downstream effect of the PBR algorithm is that price discovery can be correlated to real-time sports performances, which are necessarily dynamic in relation to one another. This occurs due to performance-based incentives on the demand side, fixed supply side parameters, and perpetual arbitrage opportunities where undervalued assets can receive outsized returns.

The economic mechanism would need a separate post in itself, so that is not the focus here. Instead, we want to cover why anyone should trust HP’s offchain data ingestion at all.

The problem, precisely stated

PBR for each staker is computed from two values per matchweek: m, the points earned by each player vault, and M_adj, the adjusted total across all subscribed vaults. Both are derived from raw match statistics through our published PPM conversion algorithm. For settlement to be trustworthy, three things must be provable:

1. The raw stats are genuine — the real data from our provider, locked in before match outcomes were known, not fabricated or edited after the fact.
2. The conversion is honest — the outputs were produced by exactly the published algorithm, with no possibility of a thumb on the scale.
3. Only verified values settle — the treasury contract that distributes yield accepts m and M_adj only after both proofs check out.

One constraint shapes everything: the raw data is licensed, so we cannot simply publish it onchain for anyone to re-derive. The architecture has to deliver verifiability without disclosure.

The key insight: proofs of computation, attestations of provenance

A zero-knowledge proof can guarantee point 2 completely. Running the PPM conversion inside a zkVM — a virtual machine that produces a succinct cryptographic proof of its own execution — means anyone can verify that the published algorithm, and only that algorithm, produced the results. The proof verifies onchain for a fixed, small cost, no matter how much data went into it.

But a zkVM proof attests to computation, not provenance. It proves “these input bytes produced these outputs” — it says nothing about whether those bytes are the real feed. We could run the honest algorithm over dishonest data and produce a perfectly valid proof. So point 1 needs something independent of the platform, and the architecture provides two layers of it:

• Realtime commitments. While matches are in play, the middleware posts running cryptographic commitments of the raw data to a contract on Base. This locks the data in before outcomes are known — history cannot be quietly rewritten later.
• An independent oracle cross-check. At settlement time, Chainlink’s decentralized oracle network fetches the same match data directly from the source and posts a digest of it onchain. A quorum of independent nodes must agree for the digest to land at all.

The zkVM proof and the oracle digest then meet onchain. Inside the zkVM, the guest program recomputes the digest of the data it was given. The verifier contract requires that this digest exactly matches the one the oracle network fetched independently. If we had fed the prover anything other than the genuine feed, the digests would differ and the proof would be rejected.

The settlement flow

Each matchweek runs through the same lifecycle:

1. Before kickoff, the fixture list for the matchweek is published to an onchain registry — the single source of truth for which matches count, fixed before a ball is kicked.
2. During matches, live PPM streams to the UI exactly as it does today, while commitments of the underlying feed are posted onchain every few minutes.
3. At settlement — after the matchweek ends, plus a buffer for the data provider’s post-match corrections — the oracle network and our own systems each fetch the final stats. The conversion runs inside the zkVM, producing the proof.
4. Verification. The onchain verifier checks three things: the proof is valid against the published algorithm’s pinned verification key, the proof’s per-fixture input digests match the ones the oracle network fetched independently, and the fixture set matches the registry. All three passing means: real data, locked in before outcomes were known, converted by exactly the published code.
5. Challenge window. A short delay before distribution, during which anyone can flag a committed feed that contradicts publicly observable match facts. Disputes are resolved by selectively disclosing the specific data points in question against the onchain commitments — verifiability without publishing the licensed feed wholesale.
6. Distribution. The treasury contract executes PBR with the attested values.

The property we care about most falls out of this structure: every failure mode is a stall, never a wrong distribution. A digest mismatch, an oracle disagreement, a prover outage — each one delays settlement until resolved. None of them can ever push incorrect yield.

What this costs, and what it doesn’t

Verifiability is only worth having if it doesn’t degrade the product, so the design isolates it completely from the user experience:

• Realtime stays realtime. The live PPM feed in the UI is a direct path with no onchain dependency. The stats are published in the UI at the same time as they are attested to onchain. So it is an optimistic display for when verification happens at the conclusion of the matchweek, at settlement.
• Onchain costs are constant. A handful of commitment writes, two oracle requests, ten digest storage writes, and one proof verification per matchweek — is low operational overhead on Base. Because a zk proof’s verification cost does not grow with its input size, the architecture costs the same whether we cover one league or twenty.
• The algorithm can evolve. Every revision of the PPM conversion ships as published, audited code whose verification key is rotated onchain through a timelocked governance process. Watchers see every change queued before it activates, and the verification guarantee travels with every upgrade. There is deliberately no admin key that can swap the algorithm silently.

For the proving itself, we are currently benchmarking the two leading production zkVMs — RISC Zero and SP1 — against the real PPM workload. Proving runs on our own hardware: at one deterministic job per matchweek, self-hosting is both the cheapest option and the one that keeps licensed data entirely within our infrastructure. Notably, this changes nothing about the trust model — a zk proof is equally sound no matter who generates it, which is the entire point of the design.

Built to outlive its own components

A system meant to run over the long term should assume everything around it will change, so the durable layer is deliberately simple: hash fingerprints, parameter registries, and a governance timelock. Everything intelligent around that core is replaceable — the algorithm (new audited code, new verification key, through the timelock), the criteria (registry updates), the oracle scripts, even the zkVM itself, since the stored digests are plain hashes that any present or future proof system can bind to. The archive only ever grows; no upgrade rewrites it. And because hash functions are quantum-resistant, the anchors underneath everything are already aligned with where Ethereum itself is heading.