Docs·Metrics reference

Metrics reference

Creators, KOLs and referrers

The creator tier ladder and its four caveats, the two competing authorities for KOL earnings, and what is never published about a referral.

Version
1.0
Updated
2026-08-29
Source
Metric definitions v1.2

Creator tier#

idRead
creatorTierCreatorRegistry.tierOf(creator) — Unranked, Bronze, Silver, Gold, Platinum, Diamond
creatorLaunches, creatorGraduated, creatorNetRaisedWeiCreatorRegistry.statsOf(creator)
creatorStatsSyncedAtstatsOf().syncedAt
creatorStatsStaleisStale(creator)

The tier is derived on every read and never granted — there is no grantTier. It walks the ladder down and returns the first rung whose minGraduated and minNetRaisedWei are both met.

Four caveats that change a creator figure#

CaveatDetail
Dev launches are excludedFrom every aggregate the registry computes.
Only a complete() launch contributes its net raiseA live curve contributes 0. This was unconditional once, and made the ladder rentable in a single transaction.
The aggregate is dated by the oldest page of a syncsyncedAt = stamp.startedAt, from a multi-page sync.
isStale only detects launches added since the syncA launch that graduated after a sync is invisible to it, so a fresh-looking statsOf can still be behind. Publish syncedAt and indexedLaunchCountOf and let the reader judge.

CreatorSynced(creator, launches, graduated, netRaisedWei, tier) fires on every completed sync, whether or not the tier moved — a tier change is a diff of consecutive logs, not an event. A published “creators promoted this week” figure built on the event count would count every sync instead.

KOL figures#

idReadAuthority
kolRankKolRegistry.rankOf(address) — max(voteRank, rankForFees(feesEarnedWei))Derived on chain
kolAllocationCapBpsKolRegistry.allocationCapBpsOf(address) — 1000…3000 bps by rankOn chain
kolEligibleKolRegistry.isEligible(address)On chain
kolInGoodStandingKolRegistry.isInGoodStanding(address)On chain
kolClaimableWeiKolSplitter.claimable(address)On chain — outstanding, not lifetime
kolAllocationsWeiΣ KolSplitter.Allocated.amount for that KOLIndexed from logs — the only complete lifetime figure
kolFeesEarnedWeiKolRegistry.feesEarnedOf(address)An off-chain attestation, written by a keeper

Two authorities for lifetime KOL earnings#

Two things that do not exist, and what to use instead
AbsentDetail
A lifetime allocation total per KOLOn no contract. claimable zeroes on claim, allocatedPctTo is deleted at window close, and totalClaimable / totalHeld are outstanding liabilities that fall. Sum the Allocated logs.
An enumerable KOL list or leaderboard viewOn none of the three KOL contracts. Only eligibleCount, activeCount and activeEligibleCount, which can be stale in the too-large direction because activity expires by the clock with no transaction. resync(address[]) is permissionless and repairs it.

isEligible carries no freshness guarantee — it never reads activeUntil, so a KOL attested eleven months ago still reads eligible. A published “verified KOLs” count must be built on isInGoodStanding, or must state that it is not time-bounded.

Referrers#

idRead
referrerEarnedWeiΣ ReferralLedger.FeeReceived.referrerShare for that referrer
referrerClaimableWeiReferralLedger.claimable(referrer) — outstanding
referrerRateBpsReferralLedger.rateBpsOf(referrer)

Code-level aggregates only. Referee identities are never published, and leaderboard exclusions apply to every public board and export with a scope naming that exclusions were applied — never silently.