HyperClaim

Revenue participation instruments are everywhere in finance. Infrastructure concession funds manage $90 billion annually by collecting shares of toll road, airport, and port revenue. Revenue-based financing has deployed over $12 billion to startups through capped percentage-of-revenue repayment. The Islamic sukuk market exceeds $1.38 trillion outstanding, built entirely on the principle of returns derived from real economic activity rather than interest.

Yet digital public infrastructure - protocols, networks, coordination systems - has none of this. Protocols generating billions in cumulative fee revenue have no standardized instrument for channeling a defined percentage of that revenue to early-stage funders. The financial instruments available to backers of these projects are borrowed from a world that assumes equity exits: acquisition, IPO, token listing. For an open-source protocol governed by a foundation, those exits may never come.

The HyperClaim is designed for this reality.

How It Works

A HyperClaim is a revenue participation instrument encoded as a Hypercert. When Commons Lab provides early-stage capital and incubation support to a protocol or infrastructure project, the investment agreement includes a HyperClaim with two tranches:

Recovery tranche.A percentage of the project’s usage-based fee revenue flows to Commons Lab until cumulative payments reach a defined multiple of the original investment (typically 3-5x). Once the cap is hit, this tranche terminates automatically. The founder’s heavy obligation ends.

Residual tranche. A smaller percentage of fee revenue continues for a defined long duration. This is the ongoing relationship - small enough to be negligible for any individual protocol, but meaningful across a portfolio of 10-15 infrastructure projects generating real usage.

Both tranches are encoded on-chain, with settlement handled by a smart contract that reads the protocol’s fee accumulator and routes payments in stablecoins. The Hypercert makes the obligation transparent, auditable, and transferable to qualified buyers.

Why Two Tranches

The two-tranche structure solves a tension between founder psychology and investor economics, and it has direct precedent.

Earnest Capital’s SEAL (Shared Earnings Agreement with a Long-term component) uses an almost identical architecture: Part 1 captures a percentage of earnings with a 3-4x cap; Part 2 maintains a small residual equity position that persists indefinitely. Tyler Tringas, who designed it, argued that a capped revenue share is better for both parties than a perpetual one - the same logic underpinning the HyperClaim. In infrastructure finance, senior/junior tranching is standard: India’s Utkrisht Impact Bond gave UBS Optimus first right to distributions with a capped return, with service providers receiving surplus.

The recovery tranche handles what founders care about: a finite obligation that ends. The residual tranche handles what the portfolio needs: ongoing exposure to protocols that grow for decades, at a percentage low enough that founders don’t feel extracted from. For a protocol generating $10 million in annual fees, 0.5% is $50,000 - meaningful to the fund holding it, invisible to the protocol’s P&L.

The Parameters Are Conservative

The research validates that the HyperClaim sits at the modest end of established ranges. Revenue-based financing instruments typically take 2-8% of revenue with 1.5-5x caps. Infrastructure concessions capture 9-77% of revenue over 20-99 year terms. Sukuk profit-sharing ratios run 30-70%. The HyperClaim’s recovery tranche (3-8%, 3-5x cap) and residual tranche (0.25-1%, 20-year duration) are deliberately conservative, reflecting the public-goods nature of the underlying infrastructure.

What Counts as Fee Revenue

The HyperClaim attaches to usage-based fee revenue: transaction fees, bridge fees, API fees, compute fees, subscription fees, data access fees - any revenue generated by users or agents interacting with the infrastructure. It does not attach to token sales, grant income, or treasury investment returns. The precise definition is negotiated per deal.

This flexibility matters because digital public infrastructure takes many forms. A privacy-preserving payment protocol collects transaction fees. A decentralized compute network charges for processing. A coordination platform might charge subscription fees. The HyperClaim works across all of these because it attaches to the revenue surface, whatever shape that takes.

The Hyperfund

A single HyperClaim residual tranche is a small asset. A portfolio of them is something else.

The Hyperfund is the aggregated collection of HyperClaim residual tranches held across Commons Lab’s portfolio. As each incubated protocol matures and begins generating fee revenue, its residual tranche contributes to a diversified stream of infrastructure-correlated cash flow. The portfolio logic is identical to infrastructure concession funds - diversified claims across multiple assets, where a few high-performers drive returns and the portfolio absorbs individual failures.

For Commons Fund LPs, the Hyperfund represents something most crypto funds can’t offer: predictable, usage-correlated revenue that can be valued using discounted cash flow models rather than speculative token multiples. The closest analog in traditional finance is a portfolio of infrastructure concession royalties. In Islamic finance, it resembles a diversified musharaka sukuk portfolio - returns from real economic activity, transparent and verifiable.

Relationship to the Coordination Stack

The HyperClaim addresses a specific gap in how open-source and public goods infrastructure sustains itself financially. Most funding mechanisms for digital public infrastructure are one-time (grants) or speculative (token launches). Optimism’s Superchain fee split demonstrates that formulaic protocol-level revenue sharing is technically and governmentally viable, but it operates between protocols, not between investors and protocols. The HyperClaim creates that missing instrument.

The mechanism is generalizable. Any incubator, accelerator, or ecosystem fund backing protocol-stage companies faces the same equity-exit mismatch. We intend to publish the full specification and welcome collaboration on its development.