Audit Methodology

A structured tokenomics audit, scored by a suite of advanced KPI tests across four core pillars.

1
Audit Execution
We run all 67 KPI tests against the project, across four weighted pillars.
2
Score Calculation
Those results roll up into a score for each of the four pillars.
3
Score Conversion
All four pillar scores then merge into one final score out of 100.

Every project runs the same 67 tests, grouped into 4 pillars. Each test reads the project's data and returns one result. Open any pillar to see the tests inside it.

Pillar Score=Points Earned÷Maximum Points
Each test scores 100 for a pass, 50 for a caution, and 0 for an alert. If a project does not provide the data a test needs, that test also scores 0, the same as an alert. Missing data is never excused.
Pass100Caution50Alert0
Some tests matter more than others, so each is weighted 0.5x, 1x, or 2x, based on how much it matters. A 2x test pulls the pillar score twice as hard as a 1x test, and a 0.5x test only half as hard.

Distribution Fairness measures who holds the token supply, how concentrated ownership is, and how control over the circulating float shifts across the first four years. Its 12 tests are grouped into the categories below. Select one to see its tests, their pass, caution, and alert thresholds, and how every audited project scored.

01Insider TGE Unlock
Do team or advisor tokens unlock at launch?

At launch, healthy projects keep team and advisor tokens locked so insiders cannot sell into the first wave of buyers. This measures how much of that allocation is instead liquid on day one and free to be sold, which lets insiders cash out and walk away early. A lower share is safer, and foundation tokens are left out since some early foundation liquidity is normal for funding the project.

Passing Criteria
Pass0%CautionAbove 0% to 5%AlertAbove 5%
Database Distribution
Pass82%Caution6%Alert6%Not scored6%
02Investor TGE Control
What share of initial float do investors control?

Only a fraction of the supply is actually tradeable when a token launches, and this measures how much of that initial float sits with investors. Investors usually bought in early and cheaply, so when they hold a large share of the thin launch supply they can push the price down fast. A project can still pass with a big investor allocation overall, as long as most of it stays locked at launch.

Passing Criteria
PassBelow 15%Caution15 to 35%AlertAbove 35%
Database Distribution
Pass67%Caution15%Alert15%Not scored3%
03Foundation TGE Control
What share of initial float does the foundation control?

The initial float is supposed to be freely tradeable at launch. Foundation tokens usually sit with the foundation rather than being liquid, so when a large part of that float is foundation controlled, the genuinely tradeable supply is smaller than the headline float suggests. A high reading means the float has been filled with tokens that are not actually circulating.

Passing Criteria
PassBelow 30%Caution30 to 50%AlertAbove 50%
Database Distribution
Pass53%Caution18%Alert26%Not scored3%

Supply cap, vesting and cliffs, float quality, and the four-year inflation and supply-shock schedule, the engine behind dilution. Its 27 tests are grouped into the categories below. Select one to see its tests, their pass, caution, and alert thresholds, and how every audited project scored.

01Total Supply Cap
Is the total supply capped, or can it be minted without limit?

With a cap, the supply can never grow past a set maximum, so dilution has a clear ceiling. This checks whether the supply is capped or can be minted without limit, where an uncapped supply can grow forever and every new token dilutes everyone already holding. A fixed maximum is the safer structure, since open-ended minting hands the team a permanent lever over the supply.

Passing Criteria
PassCappedAlertUncapped
Database Distribution
Pass98%Caution0%Alert2%
02Vesting Completion
Does the vesting schedule complete to 100% across all pools?

A readable schedule resolves to the full supply with a defined end for every pool. This measures how much of the total supply the combined schedule actually reaches by its final disclosed month, and when even one pool has no disclosed finish or is left to later governance, the end of the supply is unknown and future dilution cannot be predicted. The closer the schedule lands to 100%, the more honest and predictable the dilution ahead.

Passing Criteria
Pass>=99%Caution75 to 99%AlertBelow 75%
Database Distribution
Pass58%Caution20%Alert22%

Whether the token is structurally necessary, how broadly its utility spans the four pillars, and whether what's claimed is actually live. Its 14 tests are grouped into the categories below. Select one to see its tests, their pass, caution, and alert thresholds, and how every audited project scored.

01Stablecoin Replacement
Could a stablecoin replace the token without breaking the protocol?

This is the plainest test of whether the token is actually needed. It asks whether the protocol would still work if every use of the token were swapped for a neutral stablecoin like USDC. A token that cannot be swapped out holds important roles such as paying for transactions, securing the network, or serving as the unit everything is priced in. A token a stablecoin could cover instead exists mostly for fundraising or speculation rather than for any real function. The less replaceable the token, the stronger the result.

Passing Criteria
PassStructurally irreplaceableCautionStablecoin could cover most rolesAlertToken is fully replaceable by a stablecoin
Database Distribution
Pass0%Caution0%Alert0%Not scored100%
02Mandatory Utility
How much of the token's utility is required versus optional?

This measures, across everything the token is used for, the share that is mandatory, meaning you must hold or spend the token, against the share that is optional and merely nice to have. A mandatory use forces real demand, since holders cannot avoid acquiring the token to do the thing. An optional use creates no such floor, because anyone can skip it. When most of the utilities are mandatory, the token sits on a genuine demand floor, while a token whose utilities are mostly optional has a weak one. The larger the mandatory utility share, the stronger the result.

Passing Criteria
Pass>= 50%Caution25 to 50%Alertbelow 25%
Database Distribution
Pass0%Caution0%Alert0%Not scored100%
03Demand Durability
Is token demand driven by product usage, or only by rewards?

This separates demand that comes from actually using the product, where doing the thing requires the token, from demand that exists only because staking pays a yield. Staking is locking the token up in exchange for rewards, and reward-only demand is fragile, since it falls away the moment the yield drops or the rewards run out, and it is circular when those rewards are paid in the token itself. Usage demand is sturdier, because it lasts for as long as people keep using the product. The more demand rests on usage rather than rewards, the stronger the token.

Passing Criteria
Pass>= 60%Caution30 to 60%Alertbelow 30%
Database Distribution
Pass0%Caution0%Alert0%Not scored100%
04Token Demand Growth
When the protocol grows, does demand for the token grow with it?

This tests whether demand for the token is tied to the protocol getting bigger. Demand is structurally coupled when more usage mechanically needs more token, through transaction fees, a required stake, or tokens burned on each use, so demand rises with adoption on its own. It is discretionary when demand grows only if the team decides to route value back to the token, is not automatic, and decoupled when the protocol can grow with no effect on token demand at all. The more demand scales with usage by design, the stronger the result.

Passing Criteria
PassStructural, scales with usageCautionDiscretionary, not automaticAlertDecoupled from token demand
Database Distribution
Pass0%Caution0%Alert0%Not scored100%

Whether the protocol earns real, verifiable revenue and how much of it actually reaches token holders versus the treasury. Its 14 tests are grouped into the categories below. Select one to see its tests, their pass, caution, and alert thresholds, and how every audited project scored.

01Revenue Diversity
How many independent revenue sources does the protocol earn from?

This counts the protocol's independent revenue sources, where independent means a genuinely distinct user activity or counterparty, not several fee line items of the same underlying action. Each independent source matters to a holder because revenue that rides entirely on one activity, one product, or one customer is a single point of failure no matter how large the headline number. When several unrelated sources each carry weight, the income survives any one of them stalling, while a concentrated stream collapses the moment its single driver slows. The more independent the sources, the stronger the result.

Passing Criteria
Pass>= 3 sourcesCaution2 sourcesAlert1 or none
Database Distribution
Pass2%Caution2%Alert2%Not scored94%
02Revenue Verifiability
Does the protocol's revenue settle on-chain where anyone can verify it?

Verifiability grades how much of the captured revenue an outsider can confirm for themselves, judged by where the fees settle. When the revenue-generating activity runs on-chain and every fee passes through the chain, the full figure is independently auditable by anyone at any time. When the revenue mixes on-chain and off-chain sources, part can be checked and part must be taken on trust, so it can be monitored but never fully confirmed. When it is purely off-chain, fiat settlement, off-chain commissions, or undisclosed treasury deals, the reported number cannot be verified at all and the holder is left trusting the team's word. The more of the revenue that settles on-chain, the stronger the result.

Passing Criteria
PassMostly on-chain, auditableCautionMix of on-chain and off-chainAlertPurely off-chain, unverifiable
Database Distribution
Pass0%Caution0%Alert0%Not scored100%
03Recurring Usage
Does the revenue generating usage recur per user, or is it a one-off event?

This looks at whether the activity that produces revenue repeats across a user's lifetime or fires only once. Recurring usage, a fee on every trade, a per-transaction service, or repeat consumption, means revenue compounds as a returning user base keeps paying. Periodic or seasonal usage still recurs but in bursts with quiet gaps between them. One-off usage, a single onboarding payment, a one-time mint, or a launch-only event, charges each user once and forces the protocol to keep acquiring new users just to hold revenue flat. The more the usage recurs per user, the stronger the result.

Passing Criteria
PassRecurring or continuousCautionPeriodic or seasonalAlertOne-off per user
Database Distribution
Pass0%Caution0%Alert0%Not scored100%

Each pillar earns its own score from the tests inside it, then takes that share of its points. The four pillars' points sum into a single final score out of 100, with the heavier pillars worth the most.

Final Score=Distribution Fairness20+Monetary Policies25+Token Utility25+Value Flow30
A pillar's points reflect how much it matters, not how many tests it runs.

The final 0-100 score maps onto a twelve-step rating scale, from D at the bottom up to AAA.

Rating (D → AAA)=Final Score
0-25
25-30
30-40
40-45
45-50
50-60
60-65
65-70
70-80
80-85
85-90
90-100
DDDDDD
CCCCCC
BBBBBB
AAAAAA

Your tokenomics,
audited end to end.

A structured tokenomics audit, scored by a suite of advanced KPI tests across four core pillars.