> For the complete documentation index, see [llms.txt](https://docs.projectcatalyst.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.projectcatalyst.io/open-funding/funding-basics/proof-of-adoption-and-standard.md). # Proof of Adoption & Standard ## PART I. Proof of Adoption, in plain words **How the money follows the usage. A guide for proposers, and for everyone checking the logic.** ### The deal *Note: Values shown in \[brackets] are the pilot's operating parameters: set for this cohort and frozen before the first measurement window opens (§13.2).* Every grant is paid in three parts: **\[40%] to build, up to \[40%] on adoption, and \[20%] for holding the pace afterwards** (§2). The build payment funds a working integration. It has to be live on Cardano mainnet within three months, and you prove it with a live demo (§4). The adoption payment is earned only if real people use what you built. We measure usage in **network fees**, the small payment every Cardano transaction makes to the chain, counted from your declared and verified on-chain footprint, from your live demo to the program end date (§1.1, §7). Finish below the floor and nothing is paid (§8). The kicker goes to teams still transacting at pace two months after their window closes (§10). ### Teams set their own target. Here's why that's not a loophole. Each team declares its own fee target. Several rules make gaming it a losing move. **There's a floor** (§3.1). Your target can't sit below the published program minimum for your category and grant size. **Ambition is priced at the door, in both directions** (§3.2 and §3.3). Every target is published and scored during selection, relative to the grant requested and against reference ranges measured from what's already live on Cardano. A timid target loses points. An aggressive target without strong evidence also loses points. **You declare at submission and the number is final**. Raising or lowering after submission is not permitted. The target you put in the proposal is the target you are held to. **Bonus rewards top performers above the floor** (§9). Only teams that reach their target are eligible. Among them, ranking is based on how much adoption they generated above the program floor, relative to the size of their grant measured against its category's yardstick (§9.2). **Your forecast follows you** (§11.1, §13.5). Declared versus delivered is published for every team as a calibration meter, and future rounds weigh ambition and calibration alongside results. Your target is your forecast, and we treat it like one. It is published next to what you actually delivered, published for everyone, and it carries into future rounds. Access to future rounds weighs both how much adoption you generated and how well you called your own shot. Declaring low to play it safe is allowed. It is also visible, permanently. ### How the adoption payment is earned Hit your target and you get the full adoption payment (§8). Land between the floor and your target and you get a share that grows with how far you climbed. Finish below the floor and you don’t qualify for this payment. Adoption also has to keep a rhythm: minimum fee levels across every floored 5-day epoch, with a small allowance for missed beats (§7). Breaking the rhythm beyond the allowance doesn't zero your payment, but it shrinks it, and it costs you the bonus and the kicker. A strong finish never rescues a project that went silent for most of its window. The strongest teams that both reach their target and generate the most adoption above the program floor share a published bonus pool (§9). Note: The bonus and the kicker serve different purposes. The bonus is a competitive reward for the strongest performers during the measured period - only teams that reach their target are eligible, and ranking is based on how much adoption they generated above the program floor relative to their grant size, measured against its category's yardstick (§9.2). The kicker is different: it is a fixed % of your own grant that only pays if you are still transacting at a meaningful pace two months after your window closes. One rewards peak performance; the other rewards whether the activity continues once the main incentive ends. ### Nobody self-reports anything Every counted fee comes from public chain data, computed by an open-source tool. Anyone who runs the tool gets the same result (§6.4). Dashboards are live from the day each integration ships (§11.1). Before your window opens, you publicly declare your footprint: exactly which contracts and addresses count. The footprint can grow. New pieces are publicly marked and count only from the day you add them. Nothing can ever be swapped out or redefined mid-window (§4.1). Every target is scored against published guidance ranges calibrated from live chain data (§3.3). True benchmarks for adoption on Cardano are hard to come by; building one is part of this pilot's job, and the pilot's own published results become the yardstick the next round inherits (§13.4). ### What doesn't count **Your own wallets. Ever** (§5.2). **Paying for transactions** (§12). No rewards, rebates, or compensation tied to transacting. One confirmed case is treated as manufactured volume, whatever the totals say: payment forfeited, findings published. Marketing your product is fine. Paying for its transactions is not. The rulebook draws the line, with examples. **Spikes** (§6.3). No single day may contribute more than **\[20%]** of your total, and the epoch rhythm applies throughout. A one-day surge cannot fake a month of adoption. **Two whales in a trench coat** (§6.1 and §6.2). At least **\[N]** distinct external wallets must show up during the measurement period - one per **\[10]** ADA of your program floor - and fees from any single wallet beyond **\[35%]** of your total count at half. Splitting one whale into many wallets to dodge this is exactly the pattern the challenge process and funding-trail checks are built to catch. Before any confirmation of adoption occurs, final numbers sit in public for at least **\[10]** days. Anyone can challenge them with evidence, and confirmed reports earn a reward (§11). Flags go through a confidential form and are reviewed internally by the Catalyst team. Unproven flags are never published, so an accusation alone can't hurt anyone. Confirmed cases are published with the evidence, the consequences follow, and the first reporter is rewarded. Decisions are final and there are no appeals. A payment under review waits for the ruling. ### How to read the numbers Cardano fees are deliberately tiny. A typical transaction pays roughly 0.2 to 0.6 ADA. Over the past 30 days (as of mid July 2026) the whole network collected about **\[7,500]** ADA in fees per day, against a full-year average of about **\[9,600]** ADA, so current activity sits at the cool end of the cycle. The 30-day figure is the official denominator for every share-of-network number we publish, and it is republished daily next to every project chart (§11.1). So targets are measured in hundreds of ADA, and hundreds of ADA is not a small achievement: | **A target of…** | **that's roughly…** | **which means…** | | ------------------ | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | 500 ADA per window | 40 to 50 real transactions a day, every day, for a month | \~1 in every 450 ADA of fees the entire chain collects; the fee footprint of a mid-tier live dApp | | 1,500 ADA | 125 to 150 a day | \~1 in 150; an established top-20 dApp | | 5,000 ADA | 400 to 500 a day | \~1 in 45; a top-10 dApp by fee footprint |
Transaction counts assume 0.33 to 0.4 ADA per transaction; 0.33 is the measured network average over the past year, and script-heavy integrations typically run higher. Shares divide the target by the official 30-day denominator (§11.1), about **\[225,000]** ADA per **\[30]**-day window today (July 2026). The dApp comparisons are indicative, drawn from the same public leaderboard data used to calibrate the guidance ranges (§3.3). A brand-new integration reaching even a single digit % of all current Cardano fee traffic within weeks of launch is a breakout, not a rounding error. Judge targets as a share of the network, not against the size of the grant. For scale: the largest comparable incentive program in crypto recovered about seven cents of network revenue per dollar spent.\* None of this means a project is expected to pay back the ecosystem's investment inside its measurement period, or even by the time the kicker settles. Four months measures ignition, not payback. The bet is longer: that an integration which earns real usage now has a good chance, over its useful lifetime, of returning more to the network than the grant that started it, in fees from what it enables directly, and in the products, teams, and capital it makes possible around it. The program counts only the fees, because fees are the part anyone can verify: the floor of what a working integration returns, not the ceiling. What the window proves is the simpler thing, that real people showed up. The years after are what the rest is for (Standard §1.3). References: * * * * \* Arbitrum's LTIPP (\~45M ARB), per Blockworks Research's program meta-analysis: roughly $0.07 of sequencer revenue per $1 of incentives. ### What success looks like This is a pilot, and the results will be a spread. Some projects will break out, some will land their target, and some will miss. Every result is published, including the misses. That's the point of a pilot (§13.3). Two things make it worth doing. The first is integrations that keep transacting after the money stops. That's what the kicker pays for, and it's the number we'll be judged on. The second is a public, reproducible benchmark dataset for what adoption on Cardano actually costs, so the next program starts smarter than this one could (§13.4). The long-run compass is simple: an integration that returns more to the network than the grant that funded it, in the products, teams, and usage it makes possible, with fees as the verifiable floor of that return. Nobody is asked to get there in a month. Everybody is asked to point in that direction. ### The TLDR version (for anyone with ten seconds) 1. Grants pay **\[40%]** to build, up to **\[40%]** only if real people use what got built, and **\[20%]** if they still use it two months later. 2. Usage means network fees from a project's verified footprint. Public data, open-source counter. Run it yourself, get the same number. 3. Teams declare their own targets: floored by the program, scored against real reference ranges at selection. The number declared at submission is final. 4. Timid targets lose points. Aggressive targets without strong evidence also lose points. 5. Bonus goes only to teams that reach their target. Among them, ranking is based on adoption above the program floor relative to grant size measured against its category's yardstick (§9.2). 6. Cardano fees are tiny by design. The whole chain makes about **\[7,500]** ADA a day on a 30-day average, so hundreds of ADA means dozens of real transactions daily. Judge share of network, not size of number. 7. Team wallets never count. Paying or rebating anyone to transact means manufactured volume: payment forfeited, findings published. 8. No spikes, no silence: daily caps plus a minimum rhythm every 5-day epoch, and breaking it shrinks the payment. No two-whale stories: **\[N]** distinct wallets minimum (one per **\[10]** ADA of floor), and any single wallet's fees beyond **\[35%]** count at half. 9. Final numbers sit in public for at least **\[10]** days before confirmation. Challenges are welcome, and confirmed ones are rewarded. 10. Holding your pace for two months after finishing is worth **\[20%]** of the grant. Every result gets published, hit or miss. The compass: genuine Cardano usage that keeps growing after the program ends, counted in fees because they can't be quietly faked. Direction required now, destination expected over years. *** ## PART II. The Transaction Integrity Standard (*the rulebook*) ### §1. Definitions and the direction 1.1 A few terms this document uses precisely. The **epoch** is Cardano's native five-day period, and its boundaries can be verified on-chain. Every schedule in this Standard runs on epochs. Because epochs have fixed on-chain boundaries, your schedule snaps to them. Your **measurement period** is everything from your Milestone 1 delivery to the program's fixed end date, the same end date for every project, and it has two parts. Your **entry epoch** runs from delivery to the end of the first full epoch after delivery: your dashboard is live and no floor applies while your integration ramps, and it gives every team at least one complete epoch to ramp, whenever in an epoch it delivers. Your **window** is the floored part that follows: it opens when your entry epoch ends and runs to the end date. At the M1 deadline the window is the minimum **\[6]** epochs (about 30 days). Deliver earlier and it runs longer, all the way to the program end date; how much longer depends only on how early you go live. In practice that is up to about **\[15]** epochs, an expected maximum set by the earliest a team can realistically deliver, not a hard cap; the schedule in §7.3 stretches to whatever length results. The window's floors, rhythm, and close are in §7. Your **counted fees** are the network fees credited to you after every rule in §5 and §6 has been applied, across your whole measurement period from Milestone 1 delivery onward, **your entry epoch included**. Floors apply only inside your window, but fees count from the moment you deliver: a team that arrives ready and converts from day one is credited for every one of those fees. Wherever this Standard refers to your **measurement period total**, it means this full total from delivery; "your window" means the floored epochs only. **Common funding source** means direct control or funding linkage between wallets; funds routed through a shared custodial or exchange intermediary do not by themselves constitute a common source. **1.2** Your **submitted target** is the fee target you declared in your proposal (§3.2). Your **floor** is the program minimum for your category and award size (§3.1). **1.3 Why this Standard measures in fees, and what that does not mean** This Standard measures adoption in Cardano network fees. That is a measurement choice for grant accountability, not a claim about L1 revenue, fee levels, or long-term protocol economics. Sustainable value comes from a thriving application layer; seeding that layer is what this pilot is for. This pilot is not measuring whether a product has achieved economic self-sustainability or generated its own protocol revenue. Those are later-stage outcomes. The pilot measures an earlier and narrower question: whether the funded integration attracted real external usage on Cardano during the measurement period. Fees are used because they are the hardest number to fake quietly and the easiest for anyone to re-verify from public chain data with the open-source tool. They work as a single unit across all four areas (oracles, stablecoins, programmable tokens, identity) where volume, TVL, or a dApp's own protocol revenue do not. Faking them may cost little, but it cannot be done quietly: every attempt leaves a permanent public trail for the checks this Standard runs (§6), and a caught team forfeits unpaid amounts and carries a published record (§11.5). Fees are proof of usage, not its price. What is priced is the difficulty of forging that proof under open challenge. Volume, TVL, and the dApp's own protocol revenue remain useful measures of mature product value. Where relevant, they appear on every dashboard as context (§11.1.3) and in the permanent calibration record. In a grant setting they are simply easier to inflate and do not span the areas cleanly. Counted fees therefore answer one question only: how much real, external activity did the funded integration bring to Cardano?
### §2. The three payments **2.1** Your grant is paid in three parts:
PartSharePays whenGoverned by
Build[40%]At grant start, to fund the workMilestone 1 delivery obligation (§4)
Adoptionup to [40%]After your window closes and the publication period ends§8
Kicker[20%][12] epochs after the window closes, after its own publication period§10
All amounts are denominated and paid in ADA. Fiat-equivalent values move with the market; the ADA amounts do not. **2.2** The bonus (§9) is a separate published pool on top of the grant, for the top-performing teams that reach their target and generate the most adoption above the program floor. ### §3. At selection **3.1 The floor.** Before applications open, the program publishes a floor for each integration category and award size. Your target may never sit below your floor. Floors listed below are calibrated against the network’s trailing **90-day** fee average (as of mid July 2026) so a one-week lull or spike cannot distort them, and they are frozen per §13.2. Floors are recalibrated between cohorts only, from published data. **Program Floors** Every proposal must declare a fee target that sits above a published program floor. The floor is the minimum adoption level the program will accept for a given integration type and award size. It cannot be negotiated downward. Floors scale sub-linearly with award size: **Required floor = base floor (@ 50,000 ADA) × √(award ÷ 50,000)** This reflects that grant size primarily funds build capacity (team, scope, runway), not market adoption. Adoption is bounded by product-market fit, so the minimum rises more slowly than the grant itself. **Program floors** (counted network fees in ADA over the measurement period)
Integration@50k@75k@100k@150k@200k
Oracles150184212260300
Stablecoins180220255312360
Programmable tokens (CIP-0113)100122141173200
On-chain identity (CIP-0170)50617187100

Using the official window denominator (§11.1), the trailing 30-day network fee total, about **\[225,000]** ADA at the time of writing, these floors represent roughly 0.02% to 0.16% of all Cardano fees collected during a typical measurement period. Larger grants carry proportionally larger absolute stakes: a 200,000 ADA award has four times the ADA riding on adoption and retention as a 50,000 ADA award. The floor defines minimum viability, the level below which adoption is judged to have failed regardless of grant size; proportional accountability is carried by the at-risk share of the grant and by selection expectations that rise with the ask (§3.3). **3.2 Your declaration.** Your proposal declares three things: your fee target (the target) for each integration you use, your expected transaction count (published as context), and a short breakdown of where the usage will come from. Name your channels, your existing users, your partner commitments, with rough volumes. If your team operates an existing product, name it, and state what share of your projected usage you expect from existing users. The target you declare at submission is final. It cannot be changed later. **3.3 Two-way scoring.** Your submitted target, relative to the award you request, is published and scored against the guidance ranges below, calibrated per §13.4. A target below the Credible range loses points for timidity. A target in the Aggressive range loses points unless supported by strong evidence. Your breakdown is scored for credibility, separately from the number itself. **Stretch Targets & How Ambition Is Scored** Your self-declared target must sit above the applicable floor. This is the number you are held to for the adoption payment. Selection uses the following guidance ranges (total counted fees over the measurement period): | **Integration** | **Credible** | **Ambitious** | **Aggressive (requires strong evidence)** | | ------------------------------ | ------------------------------- | --------------------------------- | ----------------------------------------- | | Oracles | 250 – 500 ADA (≈ 0.11 – 0.22 %) | 500 – 850 ADA (≈ 0.22 – 0.38 %) | > 1,100 ADA (> 0.49 %) | | Stablecoins | 300 – 550 ADA (≈ 0.13 – 0.24 %) | 550 – 1,000 ADA (≈ 0.24 – 0.44 %) | > 1,400 ADA (> 0.62 %) | | Programmable tokens (CIP-0113) | 180 – 320 ADA (≈ 0.08 – 0.14 %) | 320 – 600 ADA (≈ 0.14 – 0.27 %) | > 900 ADA (> 0.40 %) | | On-chain identity (CIP-0170) | 80 – 160 ADA (≈ 0.04 – 0.07 %) | 160 – 300 ADA (≈ 0.07 – 0.13 %) | > 450 ADA (> 0.20 %) | The band boundaries above are stated at the **\[50,000]** ADA reference award and scale with the same **√(award ÷ 50,000)** multiplier as the floors (§3.1). At every award size, the floor therefore sits below the Credible band, and the band that applies to you is the scaled one. A target that simply restates the floor scores weakly. A target that lands in the Ambitious band with a clear, evidence-based plan scores strongly. Targets in the Aggressive band are accepted only when accompanied by unusually strong prior traction, signed distribution commitments, or other hard evidence. Expectations also scale with the ask. The larger the award requested, the higher within the guidance ranges the declared target is expected to sit: at awards of **\[150,000]** ADA and above, a target below the Ambitious band requires specific justification in the usage breakdown, and "the floor plus a little" will not carry a large ask through scoring. **Methodology note** The absolute floor values preserve the relative ambition levels first published in the pilot’s category brief while converting them into the fee-based metric used throughout this Standard. The window denominator used throughout is the official §11.1 trailing 30-day figure, about **\[225,000]** ADA at the time of writing, republished daily on every project dashboard. Stretch ranges have been calibrated against the current Cardano Transaction Leaderboard (30-day activity). When the pilot closes, its full outcome data, published per §13.4, replaces these interim calibrations: floors and guidance ranges for any subsequent cohort are drawn from what this cohort actually did. ### §4. The Milestone 1 checkpoint **4.1 Your footprint.** Milestone 1 is a working integration, live on Cardano mainnet, demonstrated live, within **\[3]** months of selection. At that moment you publicly declare your footprint. It has three parts. First, your on-chain identifiers: script hashes, minting or token policy IDs, addresses, or, for identity products, the declared identifier your signed attestations carry. Second, your registered **message tag**, which your integration's transactions carry. Where no smart contract exists, the tag is your primary identifier. Third, your **own wallets**: team wallets and the wallets that fund your operations, identified by stake key. Declared identifiers must be newly deployed for the funded work. Nothing that carried traffic before your grant may be declared. Your footprint can grow: additions are publicly marked and count only from the day you declare them. Nothing may be removed, swapped, or redefined mid-measurement-period, and activity from before an identifier was declared never counts. **4.2 The clock.** Your entry epoch (§1.1) opens at Milestone 1 delivery, and your public daily dashboard (§11.1) begins the same day; your floored window (§7) opens when it ends. The Milestone 1 deadline is published as a calendar date, set so that a delivery at the limit still leaves the full minimum **\[6]** floored epochs before the program's fixed end date. Because your entry epoch runs to the end of the first full epoch after delivery (§1.1), delivering earlier within an epoch lengthens your ramp, never your floored obligations. Deliver earlier and you earn epochs (§7.3). Miss the Milestone 1 deadline and your window never opens: the adoption payment, the kicker, and the bonus are all forfeited, your outcome is published like every other, and the non-delivery becomes part of your track record (§13.5). Where non-delivery reflects misrepresentation rather than failure, §11.5 applies to the build payment already made. **4.3 Target confirmation.** The fee target declared in your proposal is final and cannot be changed. At Milestone 1 you confirm that the integration is live on mainnet and publicly declare your on-chain footprint (§4.1). No adjustment to the target is permitted. ### §5. What counts **5.1** A transaction's fee counts toward your target when the transaction actually runs your integration: your contract executes, your token is minted or moved, your valid signed attestation carries your declared identifier. It must also not come from one of your own declared wallets (§4.1). Somebody just sending money to your address, or attaching your tag to an unrelated transaction, is not usage, and its fee does not count. **5.2** Fees paid by your own declared wallets never count. Usage means other people using your product, not you using your own product. Fees traceable to undeclared team-controlled or team-funded sources are handled under §11.3 and §12. **5.3** Integration types at a glance.
IntegrationTarget unitWhat counts
Oracles (real-time oracle price feeds)Fees generatedFees paid by transactions that consume your declared oracle price feed
Stablecoins (verified stablecoin asset policies)Fees generatedFees paid by transactions moving your declared, verified stablecoin policy
Programmable tokens (CIP-0113)Fees generatedFees paid by mints, transfers, and rule updates under your declared policy
On-chain identity (CIP-0170)Fees generatedFees paid by valid signed attestations carrying your declared identifier
Custody-style products whose value is holding capital rather than moving it are out of scope for this pilot. Fees are the only measured unit. **5.4 Multiple integrations.** Each integration you use is measured separately, against its own target, floor, and rhythm, and paid on its own fraction. Your overall §8 fraction is the average of your per-integration fractions, each clamped at 1 and weighted by the share of your combined declared target it carries. Over-delivery on one integration does not lift another; declare each target accordingly. Bonus eligibility (§9.1) requires every integration to reach its own target. The kicker (§10) is measured on your combined counted fees. ### §6. What counts at a discount, or not at all **6.1 The external wallet minimum.** At least **\[N]** distinct external wallets must transact with your integration during your measurement period. External means stake keys that are not on your declared own-wallet list, and each distinct stake key counts once. **\[N]** is **one wallet per \[10] ADA of your program floor (§3.1), rounded up** - it scales with your category and award size exactly as the floor does, and is shown to you when you apply. However large your fee total, it does not meet your target without this minimum.
**External wallet minimums**
Integration@50k@75k@100k@150k@200k
Oracles1519222630
Stablecoins1822263236
Programmable tokens (CIP-0113)1013151820
On-chain identity (CIP-0170)578910
The ratio is calibrated from live chain data (§13.4): across the highest-fee dApps on Cardano over a trailing 30-day window (epochs 638-643), the most fee-concentrated genuine usage pattern observed runs about 9 ADA of fees per distinct wallet, and typical patterns run 2 to 7 ADA. One wallet per 10 ADA of floor therefore sits just below the most concentrated real usage on the network: every genuine adoption shape observed today clears the minimum at floor level, with margin that grows toward target level, while a total carried by a handful of wallets cannot. Products whose genuine shape is a few large counterparties should raise this with the program early (§6.2). If your measurement period closes below this minimum, your counted fees are treated as below your floor: the adoption payment does not pay (§8), and bonus (§9) and kicker (§10) eligibility are not met. **6.2 The concentration discount.** Counted fees from any single external wallet, beyond **\[35%]** of your measurement period total, count at **\[half]**. There is no hard exclusion. Wallet clusters whose funding traces back to a common source are treated as a single wallet, both here and for §6.1. Splitting one whale across many stake keys is challengeable conduct (§11.3), and the funding trail is the evidence. Products whose legitimate shape is few large counterparties should document that architecture with the program before their window opens; the discount still applies, but documented architecture is context in any challenge review. **6.3 The daily cap.** No single day may contribute more than **\[20%]** of your measurement period total. Activity above the cap on that day simply does not count. **6.4 Computation order.** The open-source counting tool applies this Standard in one deterministic pass, in this order: eligibility (§5), then the external wallet minimum (§6.1), then the concentration discount (§6.2), then the daily cap (§6.3), then totals, floors, and formulas (§7 through §10). It reads only public chain data, and running it again gives the same result. The tool's computation is the rule. **6.5 Scope.** Wherever §5, §6, or §12 refers to your window, read it as the measurement period in question. The eligibility rules, wallet minimum, concentration discount, and daily cap of §5 and §6 apply to every measured period, the measurement period, the kicker period (§10), and the bonus retention period (§9.5), computed over that period's totals. ### §7. The rhythm **7.1 Floors.** Your entry epoch carries no floor and runs from Milestone 1 delivery to the end of the first full epoch after delivery (§1.1). Your window opens at that boundary and closes at the program end date; delivered at the deadline, that is the minimum **\[6]** epochs, and the schedule below is written for that base case (§7.3 stretches it for longer windows). The epoch floor rises as your window advances. In each of your first **\[3]** epochs, your counted fees must reach at least **\[1/12]** of your target. In each of your final **\[3]**, at least **\[1/6]**. You may miss any **\[1]** epoch's floor without consequence. That is your allowance. **7.2 Beyond the allowance.** Each floor miss beyond your allowance applies a **\[15%]** haircut to your adoption payment. This is the rhythm factor in §8.1: **\[0.85]** raised to the number of misses beyond the allowance. And any miss beyond the allowance makes you ineligible for the bonus (§9) and the kicker (§10). Misses are never forgiven retroactively. A strong finish does not repair a broken rhythm. **7.3 Earned epochs.** Your entry epoch stays a single ramp whatever your window length; the schedule here applies to the floored window that follows it. Deliver Milestone 1 early and your window stretches to the program's end date. Your pace is your target divided by your full window. The first **\[half]** of your window's epochs carry a floor of **\[half]** your pace, and the rest carry your full pace. An odd window puts its middle epoch in the gentler half, and at **\[6]** epochs this reduces exactly to §7.1. Your allowance stretches too: **\[1]** miss, plus **\[1]** more for every **\[3]** epochs you earned, never more than **\[2]** in total. Your schedule is fixed on the day you deliver. **7.4 Window close.** Every window closes at the program's fixed end date, whatever day you delivered Milestone 1. Reaching your target early does not end your window: it locks in your full adoption payment, and epoch floors scheduled after the epoch in which you reached your target no longer apply. Counted fees keep accumulating until the window closes, and they still feed your bonus ranking (§9.2) and your kicker baseline (§10.1). If you never reach your target, you are paid under §8 on what you counted. ### §8. The adoption payment **8.1 The formula.** **Adoption payment = 40% of the grant × rhythm factor (§7.2) × clamp( (min(counted fees, target) − floor) ÷ (target − floor), 0, 1 )** That one line is exactly what the counting tool computes. Unfolded, it is four steps, and you only need four numbers to run them: your **grant**, your **floor** (§3.1), your **target** (declared at submission, always above the floor per §3, so the denominator is never zero), and your **counted fees** at window close (§5, §6). * **Step 1: cap your fees at your target.** Take your counted fees. If you delivered more than your target, use the target itself. That is the "min": over-delivery still helps your bonus ranking and your kicker baseline, but the adoption payment itself maxes out at 100%. * **Step 2: work out how far you climbed.** Subtract your floor from the Step 1 number, then divide by (target minus floor). That is the "clamp" range: below your floor the result would be negative, and it becomes zero; at your target it is exactly 1. * **Step 3: find your rhythm factor.** Misses within your allowance: 1.00. Each miss beyond it multiplies by 0.85 (§7.2). * **Step 4: multiply the three together.** 40% of your grant × Step 3 × Step 2. That is your adoption payment, in ADA. **8.2 Worked examples.** Everything below is illustrative. It shows how the mechanics work, not what you should aim for. Your floor comes from the §3.1 tables for your category and award size, and your target is yours to declare, unique to your product and your plan (§3). Every example uses the same team: awarded 100,000 ADA, program floor 212 ADA, declared target 600 ADA, delivering at the Milestone 1 deadline for the minimum **\[6]**-epoch window. The adoption portion at stake is 40% of the grant: 40,000 ADA. With a 600 ADA target, the §7.1 epoch floors are 50 ADA in each of the first three epochs (1/12 of target) and 100 ADA in each of the last three (1/6), with **\[1]** free miss. The team finishes the window with 480 ADA of counted fees and a clean rhythm. The four steps of §8.1: * **Step 1:** 480 is below the 600 target, so it stays 480. * **Step 2:** (480 − 212) ÷ (600 − 212) = 268 ÷ 388 ≈ 0.691: the team climbed **69.1%** of the way from floor to target. * **Step 3:** clean rhythm, so the factor is **1.00**. * **Step 4:** 40% × 100,000 = 40,000, then 40,000 × 1.00 × 0.691 ≈ **27,630 ADA**. Where each number came from, so you can run your own:
Number in the exampleWhat it isWhere yours comes from
100,000The grantYour award
40,000The adoption portion, 40% of the grant§2.1
212The floorThe §3.1 table, for your category and award size
600The targetDeclared by you at submission, final
480Counted feesThe counting tool, after §5 and §6
1.00Rhythm factorYour misses beyond the allowance (§7.2)
That was the clean case. Scenarios A to C deliver the same 480 ADA with three different rhythms; scenario D reaches the full target:

Epoch-by-epoch fees (floors: 50 · 50 · 50 · 100 · 100 · 100)Floor missesRhythm factorAdoption paymentKicker (20,000 ADA)
A. Clean rhythm50 · 60 · 70 · 100 · 100 · 100none1.00≈ 27,630 ADA (69% of the full 40,000)still in play
B. One miss, inside the allowance50 · 60 · 70 · 100 · 90 · 1101 (epoch 5)1.00≈ 27,630 ADA (69%)still in play
C. Slow start, big finish0 · 0 · 120 · 120 · 120 · 1202 (epochs 1 and 2)0.85≈ 23,480 ADA (59%)forfeited
D. Target reached 70 · 80 · 90 · 110 · 120 · 130none1.0040,000 ADA (100%)still in play · bonus eligible (§9.1)
C in full, through the same four steps: 40,000 × 0.85 × 0.691 ≈ 23,480 ADA. Read the table this way. A and B are paid identically: the allowance is real, and one missed floor costs nothing at all. C delivered the same 480 ADA, but two silent epochs put one miss beyond the allowance: the 15% haircut takes about 4,150 ADA off the adoption payment, and the forfeited kicker takes 20,000 ADA more. The second missed floor cost that team roughly 24,000 ADA, not 15%. A strong finish does not repair a broken rhythm (§7.2); the rhythm rule is why a launch plan for the first weeks matters as much as the launch itself. D is what the full 'up to 40%' looks like when earned: a steady climb to the target, and reaching the target is also the gate to bonus eligibility (§9.1). Each further miss compounds: a third missed floor would multiply by 0.85 again (≈ 19,960 ADA). And two boundaries the table doesn't show: * Finish below the floor, say 180 ADA, and the adoption payment is zero, however clean the rhythm. * Reach 600 ADA before the window ends and the full payment locks in at that moment; floors scheduled after that epoch no longer apply (§7.4). Deliver Milestone 1 early and the same logic runs on a longer window with gentler floors (§7.3): the fractions and the allowance stretch, the principle does not change. **8.3 Settlement.** Payment follows the publication period (§11.2). If a confirmed challenge removes activity, your payment is recomputed on the corrected totals. Violations of §12 override this section entirely. ### §9. The bonus **9.1 Eligibility.** Three conditions must all be met: * Your counted fees reached your target by window close * Your rhythm stayed within your allowance * Your integrity record is clean A confirmed integrity finding disqualifies you, whatever your numbers. **9.2 Ranking.** Only eligible teams are ranked. **Ranking score = (counted fees − floor) ÷ √(award ÷ 50,000) ÷ your category's Ambitious band midpoint at the 50,000 reference award** (§3.3). A score of 1.0 means you delivered your category's Ambitious midpoint above your floor, at your award's scale. Higher score ranks higher. Counted fees and floors sum across integrations for this score. Ties at the cutoff are both funded; ties expand the winner list, never the pool. The formula unfolds into three steps: * **Step 1:** adoption above your floor. Counted fees minus your floor (summed across your integrations, §5.4). * **Step 2:** level the award sizes. Divide by √(award ÷ 50,000). A 100,000 award divides by 1.41, a 200,000 award by 2. Same logic as the floors (§3.1): money funds build capacity, and adoption does not scale one-to-one with money, so a four-times award is asked for twice the performance, not four times. * **Step 3:** put it on your category's yardstick. Divide by your category's Ambitious band midpoint at the 50,000 reference award (§3.3). That makes an identity product and a stablecoin product comparable: each is measured against what Ambitious means in its own category. A score of **1.0** therefore has a plain meaning: at your award's scale, you delivered your category's Ambitious midpoint above your floor. The Ambitious midpoints at the 50,000 reference, from the §3.3 table: Oracles **675**, Stablecoins **775**, Programmable tokens **460**, On-chain identity **230**. **A worked ranking.** Illustrative: four eligible teams (each reached its own target with a clean rhythm and a clean record, §9.1), in a funded cohort of ten, so the top **3** win (§9.3):
TeamAwardFloorCounted feesStep 1: above floorStep 2: ÷ √(award÷50k)Step 3: scoreRank
Oracles, small50,000150825675÷ 1.00 → 675÷ 675 → 1.00joint 2nd
Oracles, large200,0003001,6501,350÷ 2.00 → 675÷ 675 → 1.00joint 2nd
Identity50,00050395345÷ 1.00 → 345÷ 230 → 1.501st
Stablecoins100,0002551,000745÷ 1.41 → 527÷ 775 → 0.684th
Three things the table shows: * **The award leveling at work.** The large oracle team delivered twice the absolute adoption of the small one (1,350 vs 675 above floor) on four times the grant, and they score identically. Raw fee totals decide nothing on their own. * **The category yardstick at work.** The identity team ranks first with the smallest fee total on the board: 395 ADA of counted fees is a modest number, but one and a half times an Ambitious performance in a category where fees run small. Categories compete on performance against their own bar, not on the size of their numbers. * **The tie rule at work.** The two oracle teams tie at 1.00 for the last two winning places, so both are winners: ties expand the winner list, never the pool (§9.2). The stablecoin team, eligible but fourth at 0.68, takes no bonus, and loses nothing else: its adoption payment and kicker are untouched by the ranking. And the payout, to close the loop (§9.4, §9.5): the identity and small oracle teams can each earn up to 25,000 ADA (50% of their grants), the large oracle team up to 100,000 ADA. Together that is 150,000 ADA against the **\[400,000]** pool, so no pro-rata reduction applies; each winner takes 60% at the ranking and the remaining 40% **\[12]** epochs later if their pace holds (§9.5). **9.3 Number of winners.** The number of bonus-eligible winners scales with the size of the funded cohort: | **Funded cohort size** | **Bonus-eligible winners** | | ---------------------- | -------------------------- | | 1-5 | 1 | | 6-9 | 2 | | 10-12 | 3 | | 13+ | 4 | **9.4 Bonus size.** The bonus pool is **\[400,000]** ADA. Each winner receives up to **\[50%]** of their own base grant, or a pro-rata share of the pool if the full amounts would exceed it. The pool is a ceiling, not a spending target: it never pays more than its published size, and it may go partly unspent if outcomes don't support it. **9.5 Payout. \[60%]** of the bonus is paid at the ranking. The remaining **\[40%]** is paid after the **\[12]** epochs following your window close, the same period the kicker measures (§10.1), if your average per-epoch counted fees across those epochs are at least **\[50%]** of your window pace. The retention numbers are computed and published exactly the same way as your final window numbers. ### §10. The kicker **10.1** The kicker is **\[20%]** of your grant. It pays in full if your average per-epoch counted fees over the **\[12]** epochs after your window closes are at least **\[50%]** of your window pace. Your **window pace** is your average counted fees per epoch across your window, that is, the fees you earned once floors were live. That rate is bounded below by your category floor (scaled to your award, §3.1) ÷ **\[6]** and above by your category's Ambitious ceiling (scaled to your award, §3.3) ÷ **\[6]**. Those bounds come from the published §3 tables, not from your declaration, so a low target cannot shrink the bar, a stretched or throttled window cannot dilute it, and one breakout window cannot inflate it beyond reach. The kicker is deliberately binary: "still alive, at pace" is an honest yes-or-no question. All counting rules apply during the kicker period (§6.5). 10.2 Your post-finish dashboard stays live and public throughout. Kicker numbers are published for **\[2]** epochs before confirmation, and they can be challenged like any others. ### §11. Publication, meters, and flags **11.1 The meters.** These are public, live, and per project from your Milestone 1 delivery onward. You don't need to do anything for them. They come straight from chain data. 1. **Your fee bill.** Counted fees over time. The headline number. 2. **Your transaction count.** Published alongside as context. Your activity appears on public surfaces beyond these meters, including the Cardano leaderboard and the program's Dune dashboard. Those show gross tagged activity; the meters above are the official counted numbers, and the tool's computation is the rule. 3. **Your context metrics.** Alongside counted fees, your dashboard surfaces the industry-standard context: transaction volume, active addresses, and, where they apply, TVL and protocol revenue, from the same public data industry trackers use. Shown for context and comparison; payment is on counted fees, for the reasons in §1.3. 4. **Your wallet meter.** Progress against your \[N] minimum, and each wallet's share of your total. 5. **Your daily chart.** Day by day, from delivery onward. 6. **Your match.** How your tag activity lines up with your declared-identifier activity. A persistent, unexplained gap is itself grounds for a challenge. 7. **Your fee weight.** Median fee per transaction and fee per byte, against the category reference. Persistently heavy transactions without a product reason are grounds for a challenge. 8. **The network denominator.** Network-wide Cardano fees per day, shown as a trailing \[30]-day average on every chart. This average is the official denominator for every share-of-network figure the program publishes. The **\[90]-**day and **\[365]**-day averages are shown alongside as context, so nobody can accuse the program of picking a flattering baseline. 9. **Your cohort meter.** New versus returning external wallets, per epoch. 10. **Your calibration.** Your declared target next to your delivered total, as a ratio, for every team. 11. **Your origin split.** Counted fees split between wallets with and without prior interaction with your team's earlier deployments. If your pace looks too slow to reach your target, we tell you as soon as the data shows it, not at the end. **11.2 Publication before payment.** When your window closes, your final numbers are published for **\[2]** epochs, about 10 days, before any payment moves. **11.3 Flags.** Anyone can flag suspicious activity at any point in the program through the flagging form. Flags are confidential: they are not published, and an unproven flag never touches a project's public record. Grounds include, without limitation: wallets that are secretly yours, meaning funded, controlled, or compensated by your team without being declared; automated or scripted traffic; wallet clusters with a common funding source (§6.2); engineered transaction weight (§11.1); a tag and identifier mismatch; and any other pattern that credibly demonstrates manufactured usage, or the intent to manufacture it. A flag opens a review only when it points to something checkable: a wallet, a pattern, a funding trail. Flags that name no verifiable evidence are closed at intake and pause nothing. The program bears the burden of confirmation; a project is never required to disprove an unevidenced pattern. A flag is confirmed only by public chain data or concrete evidence, never by opinion. When one is confirmed, the exposed activity is uncounted and payments are recomputed (§8.3), or §12 applies. A confirmed report earns the first reporter a reward (§11.5). Reports that don't hold up cost the reported project nothing, and nobody ever learns they were made. The program reserves the right to pause or withdraw unpaid amounts if confirmed manipulation resurfaces at any time. Integrity of the program is the key priority of this phase. Traffic a project can credibly demonstrate it neither controls, funds, nor procured is excluded from counted fees but is never grounds for a §12 finding or payment pause against that project. **11.4 Who decides.** Flags are reviewed internally by the Catalyst team. This is deliberate: the pilot stays small, and so does its process. There is no fixed deadline to reach a finding, and no appeal. The team communicates 1:1 with the reporter and, where needed, with the flagged project, rather than in public: accusations are private, findings are public. A payment affected by an open review does not move until the review concludes; everything else proceeds on schedule, and reviews that hold up a payment are handled first. When a case is confirmed, the finding, the evidence, and the written reasoning are shared with the project team first, and then published, and §11.5 applies. When it is not, the reporter is told the review is closed, nothing is published, and nothing changes. Any team member with a direct interest in a project steps out of that project's reviews. Decisions are final. Because the dashboards are public from day one, flag what you see when you see it, not when a payment is near. No payment waits forever, though: a review that holds a payment and has not reached a confirmed finding within **\[30]** days releases that payment and closes as not-confirmed. A finding can still land later; §11.5 then applies to amounts already paid. **11.5 What confirmation costs.** A confirmed §12 case forfeits every payment not yet made, whenever the confirmation lands. Amounts already paid become a repayment obligation of the legal entities and individuals named on the grant agreement, recorded and published. The same entities and individuals may be disqualified from every future round and program run by this program's operators; the published ruling states whether disqualification was applied. Consequences attach to people, not only project names: KYC and KYB happen at grant issuance, and that is what they are for. Reporter rewards are available from a separate, capped pot. The pot is a ceiling, not a spending target, and no reward is paid where a link between the reporter and the flagged project's team, wallets, or funding is established. ### §12. Never pay for engagement **12.1 The rule.** You may not pay, reward, or otherwise incentivize anyone to transact. A confirmed case is treated as manufactured volume, whatever the totals say. Every payment not yet made is forfeited. Amounts already paid become a recorded repayment obligation, you and the named individuals on your grant agreement may be disqualified from future rounds, and the findings are published; the published ruling states whether disqualification was applied (§11.5). **12.2 Banned.** * Per-transaction rewards or rebates, of any kind. * Transact-to-earn points or tokens redeemable for value. * Covering users' fees from any undeclared source. * Compensating market makers, "ambassadors," or power users for activity during any measured period, including the kicker and bonus retention periods. * Any informal arrangement to the same effect. **12.3 Allowed.** * Marketing, advertising, content, and conference presence. * Hackathons, education, and documentation, as long as rewards aren't conditioned on measured-period transactions. * Sponsored-fee UX, where your team pays network fees on users' behalf as product design. This is permitted, provided those fees originate from your declared own wallets. That also means they never count (§5.2). The exclusion is not a UX judgment: fees paid from your own wallets are indistinguishable, on-chain, from self-dealing, and a measurement program cannot pay on a number its grantee can print. **12.4 Ask first.** Product-native reward mechanics, where rewarding actions *is the* product (loyalty integrations, points-as-the-product), need a written program ruling before your window opens. The default rule: allowed only if the reward carries no team-provided redeemable value during the measurement period. Otherwise it is paying for transactions. Rulings are published. ### §13. Meta-rules **13.1 No ratchet.** Your realized performance is never used to raise your own targets or floors in any future round. Floors are recalibrated cohort-wide only, from published data. Doing well this round can only ever help you next round. A confirmed integrity finding is the one exception: it follows you (§11.5). **13.2 Pre-registration.** Floors, targets, methodology, and the counting-tool version are frozen and published before a cohort's first window opens. Changes apply to future cohorts only. **13.3 Portfolio expectation.** We expect outcomes to be power-law distributed: some breakouts, some targets landed, some misses. Program-level results are published either way. The pilot also pre-registers what it is trying to learn: how teams set targets against published ranges, whether declaration calibration predicts retention, and which categories hold their pace after payment ends. And it pre-registers its own bar: the methodology surviving its first challenges intact. The decision to scale/iterate this pilot into a next version keys on these learnings. **13.4 The benchmark.** No reliable benchmark for adoption on Cardano exists today; producing one is part of why this pilot exists. This cohort's floors and guidance ranges are calibrated from public chain data, the trailing 30- and 90-day Cardano Transaction Leaderboard data, and are published with their sources. When the pilot closes, the program evaluates the full cohort's outcomes with the counting tool: declared targets, delivered fees, calibration, retention, and cost per counted-fee ADA. That published dataset becomes the reference from which floors, ranges, and the design of any next round are drawn. This cohort is scored against honest interim yardsticks; the next one inherits real ones. The pilot also tests the measurement itself: whether counted fees are a good proxy for durable adoption, and how they track against volume, active users, and protocol revenue. What is learned sets the metric for any next round; this Standard chose the most fake-resistant proxy available for a pilot, not a permanent KPI for the ecosystem. **13.5 The calibration record.** Declared versus delivered is published for every team and carries into future-round selection, where ambition and calibration are weighed alongside results, and the record carries each project's context metrics (volume, and where they apply, TVL and protocol revenue) alongside its counted fees. Top performers by §9 ranking and well-calibrated teams receive fast-track access to any subsequent round. Declaring low is allowed; but it is also a permanent public record. ### §14. The TLDR rules on one page * Three payments: **\[40%]** to build, up to **\[40%]** on adoption, **\[20%]** kicker for pace held **\[12]** epochs after finishing. * Declare your target at submission. It is floored by the program and scored for ambition against published reference ranges. The number declared at submission is final and cannot be changed. * After a floorless entry ramp of at least one epoch, your window opens after the entry ramp and closes at the program end date for everyone: deliver early and your window is longer than the minimum **\[6]** epochs. Fees count from the moment you deliver; floors start only when the window opens. Reaching your target early locks in the full adoption payment; floors after that point no longer apply. * Only your declared, newly deployed footprint counts. The footprint can grow publicly; it cannot be swapped or redefined mid-window. Your own wallets never count. * Payment scales from the floor: below it nothing, above it proportional, at your target the full adoption amount. No cliffs at the finish line. * Keep the rhythm: epoch floors with 1 allowed miss (up to 2 with earned epochs). Each extra miss cuts the payment **\[15%]** and forfeits bonus and kicker. * No day counts beyond **\[20%]** of your total. At least **\[N]** distinct external wallets (one per **\[10]** ADA of floor). Any single wallet’s fees beyond **\[35%]** count at half. Splitting wallets to dodge this is challengeable. * Everything is published live. Final numbers sit in public for **\[2]** epochs before payment. Challenges with evidence are rewarded. * Never pay, reward, or rebate anyone for transacting. §12 draws the line. * The bonus: only teams that reach their target are eligible. Ranking is based on adoption above the program floor relative to grant size measured against its category's yardstick (§9.2). * Top 1-4 teams (depending on cohort size) can each receive up to **\[50%]** of their own grant. **\[60%]** pays at ranking, **\[40%]** if pace holds 12 epochs later. * The compass: durable external usage on Cardano, counted in fees because they can't be quietly faked. Direction required now, destination expected over years. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.projectcatalyst.io/open-funding/funding-basics/proof-of-adoption-and-standard.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.