Integrity board
Projects market numbers. Almost none get checked. This is every claim we tested against the chain itself, in one place: the reported figure, our independent check, the method, and the verdict. Each finding is dated. How we check →
314 independent claim-checks across 43 projects. 217 confirmed, 45 corrected, 32 to verify, 20 unconfirmable.
41 projects sit on the verdict spine, 5 checked across all 11 dimensions; the rest are filling in. Every substrate project carries at least one check.
8358cab079778dbe…. Verify the key → The verdict spine
Each project's fingerprint: 11 dimensions in a fixed order (6 freedom · 5 returns), coloured by verdict, filled by how independent the check is. Same shape every time, so profiles compare at a glance. Open a row for the signed receipts behind it.
Morpheus 43 claims 4 corrected 2026-06-08
Infra Verified· 4 checks
Compute providers are registered and serving on the Morpheus marketplace. source →
The registry enumerates to 55 active providers, 36 on Base and 19 on Arbitrum, read from getActiveProviders on the LumerinDiamond. MorScan reports 40 on the same day, which matches neither basis: it sits above the Base active set and well below the two-chain total. The likeliest reading is that MorScan indexes Base and counts registered rather than active providers, but its basis is not published, so that is inference. The figure to cite is the enumeration, with the chain split stated. Direct registry enumeration on both deployments, summed and split per chain. Replaces a MorScan status figure that had no independent leg; MorScan is a MOR-earning builder subnet and cannot check Morpheus on its own account.
Established on-chain Worth separating two counts that are easy to conflate. MorScan reports providers registered; our own SessionClosed index shows 29 distinct providers that have actually closed a session with a receipt. That is a floor on the serving set, not a check of the registry, and the two are not the same number by construction. This figure is rendered on the site through MorpheusNetworkLive, always attributed to MorScan. RESOLVED 2026-08-17. This row sat unverified naming LumerinDiamond enumeration as the check that would settle it; the enumeration already existed in refresh-mor-compute-providers.ts and only needed manifesting. Worth noting the gap it exposed: MorScan's count is not reproducible from the registry on either chain basis.
Multi-chain deployment across Ethereum L1, Arbitrum, and Base. source →
Core contracts deployed and source-verified on all three explorers. Confirmed deployment + verification across the three chains.
Verified on-chain Multi-chain deployment confirmed on-chain.
Permissionless to run a compute provider (no allowlist/KYC). source →
— Checkable via the registration path ABI (does it gate on an allowlist?); not yet inspected.
Check pending Editorial Likely match; the same on-chain method that closed governance would resolve it.
Provider hardware/client diversity across the network. source →
— Provider set is indexed by count; hardware/client diversity not characterised.
Check pending Editorial Count is known; diversity is not yet characterised.
Governance Overstated· 4 checks
The Builders staking contract behind the UUPS proxy is the source-verified implementation we reviewed. source →
The EIP-1967 implementation slot on the Base Builders proxy 0x42BB446eAE6dca7723a9eBdb81EA88aFe77eF4B9 points at 0x18faef315b40a6d9cf49628f1133b1aa507513b0, source-verified on BaseScan as BuildersV4. Direct storage read of slot 0x360894...bbc, stored verbatim as an identity string and compared for exact inequality by check:primary-drift on every run.
Established on-chain This is the artefact behind the no_central_control verdict: the 5-of-9 Safe can repoint this slot with no timelock, so which implementation it points at is the thing that has to stay watched. The watch was blind until 2026-08-17. The slot was hex-parsed to a JavaScript number, which cannot hold 160 bits, so the stored value round-tripped to 0x18faef315b40a700000000000000000000000000 and the drift guard was comparing addresses by percentage; a replacement landing within 10% of the current address would not have fired. Now stored as an opaque string and compared for exact inequality, so any repoint raises an ERROR.
No central team, company, or foundation controls the protocol (whole-stack). source →
One 5-of-9 Gnosis Safe (0x1FE04BC1...) holds owner/upgrade authority across the core contracts on both chains: Base Builders staking (0x42BB446e, UUPS, no timelock), Base LumerinDiamond inference, and the Ethereum-L1 Distribution contract where capital deposits sit (0x47176B2A..., upgradeable proxy, no timelock). The MOR OFT token is on a separate Safe (0xf3ef0016...). Traced owner/upgrade authority across the core contracts on both chains to the 5-of-9 Safe; confirmed no timelock.
Overstated on-chain Governance rubric stage G0 (a single 5-of-9 Safe, no timelock, over the deposit + staking + inference contracts). Path to match: add a timelock (G1), then make MRC/Snapshot binding through it with the Safe reduced to emergency scope (G2). Verified across Base core + L1 deposit; Arbitrum reward contract + signer independence are the remaining, non-load-bearing refinements.
MRC proposal system with Snapshot voting for MOR holders. source →
The Snapshot space and the MRC process exist and are public. Confirmed the live Snapshot space and MRC process.
Verified Cross-checked A true sub-claim a blunt dimension-level inflated would have unfairly tarred: Snapshot/MRC voting is real, even though it is not binding through a timelock (see the control claim).
Atomic Governance model. source →
— Described in docs; not independently stress-tested.
Check pending Editorial Model documented, not independently tested.
Distribution Verified· 3 checks
Fair launch: no pre-mine, ICO, VC, or insider allocation; every MOR earned through contribution. source →
Emissions-only issuance, no team/VC allocation, verifiable on the emission contract. Confirmed emissions-only issuance with no allocation tranche.
Verified on-chain One of the fairest launches in DeAI: no VC/pre-mine, contribution-only issuance.
24/24/24/24/4 contributor-type emission split. source →
— A design parameter; on-chain contributor-type attribution is only partial.
Check pending Editorial Design parameter; per-contributor-type on-chain attribution not fully reconstructed.
MOR holder base is broad (independently countable on-chain). source →
14,556 holders (balance > 0) from our own Alchemy enumeration of all 1,030,340 MOR Transfer logs since deploy, balances reconstructed locally. 0.02% from MorScan. getLogs Transfer enumeration + net-balance reconstruction, count(balance > 0); computationally independent of MorScan.
Verified on-chain Independently verified: our own enumeration (14,556) matches MorScan’s signed count (14,553) within 0.02% (rule 25 - independence, not just integrity). Not score-bearing.
Censorship Check pending· 2 checks
Provider registration is permissionless (no KYC/allowlist). source →
— Checkable via the registration path ABI (does it gate on an allowlist?); not yet inspected.
Check pending Editorial Likely match; the registration-ABI inspection that resolves it is the same on-chain method used for governance.
No protocol-level content policy (the protocol does not pause/blacklist/filter inference by content). source →
— Checkable - inspect the LumerinDiamond + proxy-router ABI for pause/blacklist/content-filter functions. Not yet done.
Check pending Editorial Provider-level self-censorship is off-chain and separate; not claimed here.
Data Check pending· 3 checks
End-to-end TEE attestation (v6.0.0 Intel TDX 2026-03-18; v7.0.0 Secret Labs 2026-04-23). source →
— Releases + audits are public; attestation is verifiable by design, but the quote was not run this session.
Check pending Editorial unverified, not unverifiable: an attestation quote would upgrade this to onchain.
Prompts are P2P-encrypted between consumer and provider. source →
— Architecture described; not independently confirmed.
Check pending Editorial Checkable but not confirmed this session.
Self-custodial wallets (no platform custody). source →
— Checkable (no custody contract in the flow); not yet confirmed.
Check pending Editorial Likely match.
Open source Verified· 4 checks
Bug bounty programme paying up to $100,000 from the Protection Fund, smart contracts only. source →
The programme is public, dated and specific, and it is stricter than the one we previously recorded. Version 2 (7 Aug 2026) replaced the old range with a $100,000 ceiling capped at 10% of demonstrated funds at risk, requires a passing Foundry proof of concept against a pinned mainnet fork, and lists 20 in-scope addresses in an appendix. Payouts are discretionary and drawn from the Protection Fund, so the ceiling is a cap rather than a reserve; we have not verified any payout. Read the published programme in a browser (mor.org is behind a bot checkpoint, so curl cannot reach it). Ingestion only, verdict human-set.
Check pending Editorial Corrects our own figure: we carried '$500-$150k', which the 7 Aug 2026 rewrite superseded. Still `unverified` rather than `match`: a published programme is not evidence of a paid bounty, and the terms make payment explicitly discretionary and subject to Protection Fund liquidity. The scope exclusions are worth reading, since admin-key and centralisation findings are out of scope in all forms, which is exactly the surface our governance verdict marks inflated.
MIT license across 52 public repositories. source →
GitHub API confirms the public repo set and MIT licensing. Repo count + license read from the org.
Verified Cross-checked Core code is public and MIT-licensed.
Four audits (OpenZeppelin, Cyfrin, Renascence, Code4rena). source →
Audit reports are public. Confirmed public reports.
Verified Cross-checked Caveat recorded: OpenZeppelin flagged modified local LayerZero contracts (divergence risk). Second caveat added 2026-08-13: the MOR Token page attributes the work to OpenZeppelin and Renascence plus a Cyfrin/CodeHawks bounty contest, not the four separate audit firms our claim lists. The canonical audit index is the docs page now cited; reconcile the exact set at the next review.
Smart contracts are source-verified. source →
The Builders proxy (UUPS, Base 0x42BB446e) implementation slot reads 0x18faef315b40a6d9cf49628f1133b1aa507513b0, source-verified on BaseScan as BuildersV4 (Solidity 0.8.20, exact match). The LlamaAI verification gap is resolved. eth_getStorageAt(0x42BB446e, EIP-1967 impl slot) -> 0x...18faef...; BaseScan shows Source Verified / Exact Match, ContractName BuildersV4.
Verified on-chain Closes the LlamaAI Builders-contract forensic: the live implementation is verified as BuildersV4. Residual risk (graded under governance): UUPS upgrade authority is a 5-of-9 Safe with no timelock, so a future upgrade could swap to an unverified implementation - monitored by a check:primary-drift ERROR on the impl slot.
Utility Understated· 7 checks
Providers post live price bids, so the marketplace has a supply side quoting prices. source →
The contract carries 729 active bids across 394 models, out of 407 active models and 461 registered, enumerated from the LumerinDiamond on Base. MorScan reports 538 on the same day and the same chain, so on a like-for-like basis it under-reports the marketplace by about a quarter. The direction is worth noting: the independent read is HIGHER, so the status endpoint understates inventory rather than inflating it. Per-model enumeration summed across the active model set, counting returned ids rather than trusting a total field. There is no global bid enumerator on the Diamond.
Understated on-chain A bid count is a supply-side signal and says nothing about whether anyone buys at those prices. Rendered on the site attributed to MorScan. RESOLVED 2026-08-17 by the enumeration this row named. The MorScan figure is not merely unverified, it is low against the contract.
Real inference usage exists (and is attested on-chain). source →
37.1B attested input+output from our own index of the LumerinDiamond SessionClosed receipts on Base, the same contract Morpheus indexes. The anchor read 10.6B when this verdict was first authored in June 2026 and has climbed every month since. sum of provider-signed SessionClosed receipt inputTokens+outputTokens; the legacy gap reproduces Morpheus’s documented clamped fallback.
Established on-chain Attested throughput matches our independent sum from the same on-chain contract, and the anchor is now wired so the figure cannot fossilise again. Never cite the 33.8B estTokens (our own beta-inflated estimation artifact; see the estTokens_legacy_overcount flag). Use attested (~10.6B) or Morpheus’s published 14.93B.
Inference sessions are open and running on the Morpheus marketplace. source →
— Not checked, and deliberately not wired for drift: this is an instantaneous count, so a band on it would route on ordinary hour-to-hour variation and tell a reader nothing. The cumulative session count is the measured anchor, judged in the mor_total_sessions row.
Check pending Editorial Rendered on the site as a liveness signal, attributed to MorScan. Carried as a claim rather than a measurement because it is a snapshot of a moving system read from a party that earns MOR.
MorScan publishes a cumulative Morpheus session total. source →
316,124 sessions closed, from our own index of LumerinDiamond SessionClosed events on Base. Enumerate SessionClosed receipts on the LumerinDiamond and count them; previously cross-checked against a full Alchemy getLogs enumeration of SessionOpened and SessionClosed.
Understated on-chain Understated, and not an error on MorScan's part: they apply a narrower "real session" basis that excludes early-terminated sessions, so their total sits about a third below the raw closed-session count. Recorded so the two numbers are never treated as the same measurement. Our on-chain count is the one to cite; MorScan's is the one to attribute if their basis is what you want. The manifest note has pointed at this verdict since July 2026 and it had never actually been written, which is precisely the gap this pass exists to close.
Access entitlement is governed by a published design model (Yellowstone / Lumerin Model). source →
Budget = computeBalance/100 and stipend = amount x computeBalance/(totalMORSupply x 100), both live on-chain; the same-day stake hold enforces the daily ration in place of the specified getSpendBalance, which is not registered on the Diamond Read SessionRouter.sol on the deployed Diamond and called its views directly.
Verified on-chain Recorded under rule 26 (design intent is not deployed behaviour). The design docs describe the intent correctly, and three deployed details differ from them: getSpendBalance is absent, rationing keys on session stake rather than wallet balance, and Lake Travis's paid-overflow path was never built.
MOR is a work token, earned through contribution. source →
Emission mechanism on-chain (contribution-based issuance). Confirmed emission-based issuance.
Established on-chain Work-token mechanism measured on-chain.
Staking grants yield / access / public-good weight (builders staking is live and material). source →
~1,791,046 MOR summed across 180 builder subnets in our own harvest (src/data/mor-subnet-staking.json), read from the same 0x42BB contract by an independent pipeline. ~6% under MorScan, explained by our narrower coverage (180 vs 280 subnets). Sum of per-subnet totalStaked across our harvested list; MorScan totalDeposited as the cross-check anchor (its allPoolsTotal 9.77M was rejected as undocumented).
Established on-chain Two independent reads of the same Builders contract agree within a coverage-explained ~6%. Staking is live and material; MorScan is itself a builder subnet, so attribute + cross-check, never sole-source. Freshness wired 2026-08-16: baseline 1,791,046 (our own harvest total at authoring; live is already +17%, so this routes on first run). Wiring corrected 2026-08-17. This verdict was banded against MorScan's aggregate while its baseline came from our own 180-subnet harvest, so a documented coverage gap was being reported as drift in our figure. Both legs now come from the same harvest. MorScan's number stays the reported leg, which is what it is.
Accrual Established· 2 checks
Value accrues via protocol-yield capture (staked-capital yield routed to the protocol). source →
DeFiLlama summary/fees/morpheus-ai (dailyFees), August 2026: total1y $737,188, totalAllTime $9,863,562. Trailing-year revenue is down about 24% from the $976K read in July, so the decline the row described has continued. No fee-burn; accrual stays structurally thin. adapter tracks stETH rebasing + Aave V3 interest on capital-provider deposits.
Established Cross-checked Accrual is measured, not asserted: yield routed to the protocol, revenue ~$0.98M/1y (match), no fee-burn. Revenue falls with TVL. Freshness wired 2026-08-16: baseline 9,817,540 (DeFiLlama totalAllTime at authoring). Basis corrected 2026-08-17: this was banded on the cumulative all-time total, which only ever rises, so the band could register growth but was structurally incapable of registering decline. Rebased on the trailing year from the same stored response, which can fall. REFRESHED 2026-08-17: refreshed onto the August 2026 read; the July score-log row described the same decline, so no editorial figure went stale.
Value accrues via staked access. source →
Staked-access mechanism is on-chain (staking + session-access contracts). Confirmed the staked-access mechanism on-chain.
Established on-chain Accrual mechanism measured on-chain.
Supply Verified· 3 checks
42M MOR max supply cap. source →
Cap enforced on the contract. Read the cap on the emission/token contract.
Verified on-chain Hard cap on-chain.
Fair-launch issuance (no allocation tranches). source →
Emissions-only issuance confirmed on-chain. Confirmed no allocation tranche.
Verified on-chain Emissions-only; no VC/pre-mine tranche.
Total supply = circulating, no locked tranches. source →
Live cross-chain totalSupply (Arbitrum + Eth + Base) reads total = circulating with no locked tranches. Read totalSupply across the three chains.
Verified on-chain No locked tranches; total equals circulating.
Revenue Overstated· 5 checks
Protocol revenue ~$0.98M/1y. source →
DeFiLlama fees adapter, August 2026: $737,188 total1y, $9.86M all-time. Trailing-12m fee total from the open adapter.
Verified Cross-checked The revenue figure reconciles; sustainability is the separate, load-bearing question below. REFRESHED 2026-08-17: refreshed onto the August 2026 read alongside protocol_yield_revenue, which shares the same source.
Capital providers deposit into the Distribution contract, and the yield on those deposits funds the protocol. source →
$16,216,544 protocol TVL across Morpheus chains. DeFiLlama protocol TVL summed across the chains its morpheus-ai adapter covers, refreshed into meta.primary_data.
Established Cross-checked Carried because the protocol_yield_revenue verdict beside it states that revenue falls with TVL, and until now nothing measured the TVL. This is the principal the yield is earned on, so a sustained fall here shows up as falling revenue a quarter later. Same aggregator as the revenue leg, so the two move on a consistent basis.
Provider payments settle out of a funded account when a session closes. source →
122,996 MOR held by the compute funding Safe 0x5160C0311A95E0A1072FA85Df23712A7BA1cD4b1 (Gnosis 5-of-9). Direct ERC-20 balance read, refreshed into meta.primary_data and scaled to whole MOR.
Established on-chain The near-term constraint the pool figures hide. The compute pool is the long-dated subsidy; this Safe is the account closeSession actually pulls from, it is topped up by manual multisig action, and if it runs dry closeSession reverts and user stake stays locked. That makes a falling balance a liveness signal rather than a tokenomics one, which is why it is wired separately from compute_subsidy_sustainability. Stored in wei until this pass, so the drift band was reporting in units nobody reads; converted to whole MOR here, snapshot and series together.
The compute emission pool is a long-dated subsidy that keeps accumulating.
Pool peaked ~2,805,000 MOR mid-July 2026 and is now falling ~899 MOR/day as claims (~3,811/day) exceed accrual (~2,912/day) getComputeBalance read at archive blocks 30/60/90 days back, differenced against live accrual.
Overstated on-chain Not a contradiction of anything Morpheus states; the project publishes no pool-trajectory figure. Recorded because our own earlier framing (a reservoir that only grows, 'runway is years, not months' on 100-200 MOR/day of demand) was overtaken by the July 2026 crossover. Years of runway remain at the current rate, so the correction is directional rather than existential.
Demand is real economic demand, not emissions theatre. source →
no independent source exists Our deep on-chain work found the user-paid-vs-subsidised split genuinely unmeasurable: demand is gateway-masked (sessions open via the API Gateway wallet, not end users), and estTokens is contaminated by the free open beta (near-zero pricing).
Editorial Editorial Load-bearing for the dimension: the paid share is genuinely unmeasurable on-chain, not merely unchecked. The earlier ‘tiny demand’ framing was corrected to ‘real and growing’, but no paid ratio is asserted.
Liquidity Established· 2 checks
DEX liquidity / depth. source →
DEX pool depth is on-chain-measurable; confirms thin liquidity. DEX pool depth read on-chain.
Established on-chain Thin DEX liquidity, hence the low dimension score (4/15).
CEX listings and volume. source →
CoinGecko tickers/volume confirm limited CEX listings and thin volume. Read tickers + volume.
Established Cross-checked Off-chain, api-grade (corrected from any on-chain label). Confirms thin liquidity.
Thesis verdicts 4 checks
Thesis: real inference demand is served and growing. source →
Our LumerinDiamond index, recomputed 2026-08-17: attested monthly throughput rose every full month from February through July 2026 (1.72B, 1.89B, 2.33B, 3.00B, 7.12B, 16.11B input+output tokens), so the growth claim holds through the last complete month. Cumulative attested throughput is 37.4B. August is partial and tracking below July: 5.26B over the first 16 days, an implied ~10B month against July's 16.11B. max daily + monthly sums of provider-signed receipt input+output tokens across the full series.
Verified on-chain Reproduced independently from our own index of the same on-chain contract Morpheus indexes. Demand is real and growing. Re-read 2026-08-17 from our own index rather than wired on trust. The month-on-month growth the thesis rests on is confirmed through July, and August is the first month tracking below its predecessor. That is one partial month and not yet a break in the trend, but it is the first candidate for one, so the cumulative anchor is wired here to catch the next move.
Thesis: it is genuinely permissionless and private (TEE). source →
— Permissionless registration + TEE attestation are both verifiable by design, but neither was run to a grade this session.
Check pending Editorial unverified, not unverifiable: the registration ABI + a TEE quote would settle it.
Thesis: fair-launch integrity - no VC or pre-mine. source →
Emissions-only issuance verified on-chain; no allocation tranche. Confirmed emissions-only issuance.
Verified on-chain The clearest verifiable leg of the token thesis: a genuine fair launch.
Thesis: that demand is genuine economic demand, not emissions-subsidised. source →
no independent source exists The user-paid share is gateway-masked and estTokens is beta-contaminated - genuinely unmeasurable on-chain.
Editorial Editorial The deepest value question, honestly open: demand is real and growing, but the paid-vs-subsidised split cannot be settled on-chain.
Measured facts & caveats 3 notes
The session opener is the on-chain gateway wallet, not the end demand source, so opener concentration overstates true concentration and the binding trigger is structurally unmeasurable from openers alone.
Our pipeline's estTokens (33.8B) over-counts the Dec-2025/Jan-2026 open-beta legacy fallback ~5x: our legacy proxy is 23.1B (almost all of it Jan 2026) vs Morpheus's clamped ~4.3B. Root cause is DURATION, not tps - during the free open beta near-zero pricing pushed session endsAt far out, so tps*paidDuration explodes; legacy tps are already <500, so a tps clamp does NOT fix it, and Morpheus's tighter duration capping lives in their private indexer (we don't reproduce it). It is OUR estimation artifact, not a Morpheus claim. Use the attested input+output basis (~10.6B, equal to Morpheus's tokensReceipt) for any displayed or cited token figure; never cite estTokens.
We independently index Morpheus sessions from LumerinDiamond SessionOpened events on Base: ~307,732 closed sessions vs MorScan’s 118,128. This is a definitional difference (MorScan’s headline counts completed sessions, excluding ~90k early-terminated; we count all closed), not a discrepancy - so it carries no verdict. Recorded as a provenance note that we index independently. MorScan is a third-party indexer, not Morpheus infrastructure.
Venice 22 claims 2 corrected 2026-08-09
Infra Check pending
Venice runs open-source models on distributed GPU compute sourced from decentralised provider networks (Akash, Hyperbolic, Prime Intellect). source →
— GPU-provider sourcing is off-chain; the named networks are themselves permissionless marketplaces, but Venice's specific routing split is not on-chain and was not independently rebuilt this session.
Check pending Editorial All inference routes through a single Venice-controlled, closed-source proxy (a central chokepoint), so infrastructure decentralisation is capped regardless of provider diversity. The 'decentralised AI' positioning is marketing; Venice itself describes a centralised platform.
Governance Overstated· 2 checks
Token-weighted governance: VVV holders can propose and vote on platform decisions, with voting power proportional to staked VVV. source →
No on-chain governance: VVV mint authority and StakingV2 upgrade authority are held by a 4-of-6 Gnosis Safe v1.4.1 (0x2D8CB8DC), with no timelock and no enabled modules. No Governor, Snapshot execution, or timelock deployed. Traced control on Base: VVV.owner() = StakingV2 (UUPS proxy); StakingV2.owner() = Safe 0x2D8CB8DC; read Safe threshold (4), owner count (6), version (1.4.1), and modules (none).
Overstated on-chain Governance rubric stage G0 (instant unilateral control: a 4-of-6 Safe, no timelock, over the mint + upgrade authority). Path to match: add a timelock (G1, exit window), then make voting binding through it with the Safe reduced to emergency scope (G2). Signer independence of the 6 owners unverified, which caps the stage, never upgrades it.
Venice is a centralised company with a utility token, not a DAO; the company retains full operational control. source →
Confirmed: a 4-of-6 Safe controls emissions and staking-logic upgrades; no distributed governance exists. The same on-chain control trace that grades the token-weighted-voting claim confirms Venice's own centralisation statement.
Verified on-chain Venice's transparency verified: it says it is centralised, and on-chain control confirms exactly that. The inflated verdict sits on the separate token-weighted-voting claim, not on Venice's honest self-description.
Distribution Verified· 2 checks
No presale, no ICO, no private sale, no VC token allocation; self-funded, with 50% of genesis airdropped to the community. source →
No sale contract; issuance is owner-mint emissions on the token contract. Allocation as documented, no VC/private tranche. Company raised a Series A (July 2026) as equity, separate from token allocation. Enumerated owner-gated functions from the verified VVV source (no sale/vesting-sale path); cross-read the allocation. Launch-fairness is the binary no-premine/ICO/VC claim.
Verified Cross-checked Distribution rubric: launch-fairness = match (no premine/ICO/VC token sale). One of the fairer launches in DeAI. Ongoing holder concentration is a separate claim, unverified below.
Ongoing distribution is broad/fair (top-holder concentration is not insider-heavy). source →
— Top-N non-infra holder share on Base was not rebuilt this session (holder-index endpoint gated). ~35M of effective supply is company treasury + staked + vesting, so circulating concentration needs the holder index to grade.
Check pending Editorial Checkable via a top-holder index on Base (exclude burn 0x0, staking, treasury, LP). The upgrade that moves this to D1/D2.
Censorship Verified· 2 checks
VVV holders cannot be frozen or blacklisted at the token layer. source →
Verified VVV source exposes no pause, freeze, or blacklist function; owner-gated functions are mint + transferOwnership only, and the contract is not upgradeable (no EIP-1967 slots). Enumerated the verified ABI for pause/blacklist/freeze; read EIP-1967 implementation/admin slots (both zero = immutable).
Verified on-chain A real on-chain censorship-resistance property. Distinct from inference-layer content policy below.
Uncensored model access: paid users can disable Safe Mode, and Venice runs open-source models that cannot be centrally recalled. source →
— The open-weight model list is checkable via api.venice.ai/api/v1/models; content-uncensoring is a proxy/policy setting (off-chain), not rebuilt to a grade this session.
Check pending Editorial Venice controls the proxy and can gate users/models/content at the routing layer (the free tier is already blocked in the UK under FSMA). Censorship resistance here is a business decision, not an architectural guarantee. Some users report censorship creep.
Data Check pending· 2 checks
No prompts, responses, or conversation history stored server-side; history and Memoria are local-only (browser IndexedDB / FAISS). source →
— The proxy is closed-source; no independent privacy audit exists (the third-most-requested feature). Privacy rests on architectural isolation and policy, not a cryptographic guarantee for the base modes.
Check pending Editorial Verifiable in principle via an independent privacy audit or traffic analysis; not confirmed. The core privacy claim is currently trust-based.
TEE and E2EE private-inference modes (via NEAR and Phala) are hardware-attested and verifiable. source →
— TEE attestation is verifiable by design (a quote can be checked, as with Morpheus); the quote was not run this session.
Check pending Editorial unverified, not unverifiable: an attestation quote would upgrade this to onchain. Distinct from the base no-storage modes, which are policy-based.
Open source Overstated· 2 checks
Venice's smart contracts are source-verified on BaseScan; CLI (MIT) and the ironclaw runtime (Apache-2.0/MIT) are open source. source →
VVV token and StakingV2 both show verified source on BaseScan (Solidity 0.8.26). Queried getsourcecode for VVV and StakingV2: both verified. GitHub licenses read from the org.
Verified on-chain The specific contract-verification and OSS-tooling claims hold. The broader 'open platform' reading is corrected below.
Venice is an open, transparent platform. source →
Core inference engine, proxy, and platform code are closed-source; only peripheral repos are public. Privacy claims cannot be independently verified because the proxy code is not published. Reviewed the public repo set against the described architecture; the load-bearing inference/proxy code is not among them.
Overstated Cross-checked Open-source rubric stage O1 (public but thin: peripheral code + verified contracts + one audit, but the core is closed and the Trust Security report is not publicly downloadable).
Utility Established· 2 checks
Staking VVV (as sVVV) grants a pro-rata share of Venice's daily inference capacity plus emission yield. source →
StakingV2 contract live on Base (UUPS proxy, 51 functions incl. stake/claim); the staking mechanism exists on-chain. Confirmed StakingV2 as VVV's owner and read its function set (stake/claim/owner/upgradeToAndCall).
Established on-chain Mechanism measured on-chain; whether staking demand is durable is tested in the thesis verdicts.
Locking sVVV mints DIEM, each DIEM representing $1/day of perpetual API credit. source →
DIEM token + mint/escrow contracts live on Base (tracked by the DIEM mint-history index). DIEM mint/escrow events indexed on Base; the lock-to-mint loop exists on-chain.
Established on-chain Multi-step utility loop verified on-chain (stake -> sVVV -> DIEM -> credit).
Accrual Verified
A revenue-funded buyback-and-burn (monthly since Dec 2025, plus per-event burns on new subscriptions and credit purchases) accrues value to VVV. source →
33.83M VVV at the 0x0 burn address (2026-08-09), matching within the <2% drift gate; effective supply 80.75M (on-chain totalSupply 114.57M minus burn). sum of Transfer-to-0x0 on the VVV contract, tiered by USD at burn time; cross-checked against BaseScan and CoinGecko, and against venicestats with a <2% drift gate.
Verified on-chain Positive control: a third-party dashboard figure that holds against on-chain ground truth; the daily refresh re-verifies and warns above 2% drift. VVVBurnChart (the on-chain index) is the authoritative source; venicestats is corroborated, not cited alone. The buyback-burn is a genuine, measurable value accrual; staking yield itself remains emission-funded (see emission_honesty).
Supply Verified
VVV has no hard cap (uncapped, inflationary via emissions minus burns), with a disinflationary emission trajectory. source →
No cap() on the contract; owner-mint issuance confirmed; CoinGecko max_supply null. Live effective supply 80.75M (on-chain totalSupply 114.57M minus 33.83M burn) = CoinGecko total 80.75M. Read totalSupply and balanceOf(0x0) live; confirmed no cap function and owner-gated mint; reconciled effective supply against CoinGecko.
Verified on-chain Supply rubric: uncapped and emission-funded (S0-adjacent) but with an aggressive disinflationary trajectory and a net-burn offset. The research JSON's tokenomics.supply figures (78.8M total @ 2026-02-28) are stale versus the live 80.75M effective; flagged for the freshness harness.
Revenue Verified· 2 checks
Platform revenue funds an on-chain buyback-and-burn. source →
DeFiLlama reports $1,909,106 all-time and $1,896,605 in the trailing year through the open-source dimension adapter, with $616,638 in the trailing 30 days. The fees and revenue endpoints return identical figures for Venice, so there is no take-rate split to separate. This anchor read $1.43M all-time when the verdict was authored. DeFiLlama dimension adapter reads the on-chain buyback flow; ingested via refresh-defillama-metrics.ts.
Verified Cross-checked This is the buyback spend measured on-chain, not total company revenue. The revenue magnitude claim is graded separately below. Re-read 2026-08-16: the all-time total has risen by roughly a third since authoring, and close to a third of everything ever recorded landed in the last 30 days. The buyback-and-burn claim still reconciles; what has changed is the scale it operates at, which is a Value Accrual input for the next monthly rather than a verdict flip here. Basis corrected 2026-08-17: this was banded on the cumulative all-time total, which only ever rises, so the band could register growth but was structurally incapable of registering decline. Rebased on the trailing year from the same stored response, which can fall.
Venice runs at roughly $60M ARR with a ~$200M annualised addition rate. source →
no independent source exists Venice publishes no revenue. The ARR figure is a third-party extrapolation from signup pace and a 5% paid-conversion assumption; it is not auditable against any disclosed or on-chain revenue. The only directly verifiable revenue proxy is the on-chain buyback flow above.
Editorial Editorial Load-bearing for the dimension: no disclosed revenue exists to verify, so the revenue magnitude is genuinely unverifiable, not merely unchecked. Never present the Delphi estimate as a Venice figure.
Liquidity Verified
Good liquidity on Base and major centralised exchanges. source →
66 tickers; Coinbase the top venue plus Aerodrome DEX depth; ~$6.4M 24h volume against a ~$555M market cap (~1.2% turnover); ~48% below ATH. Read the ticker set and 24h volume live; confirmed real CEX + DEX venues.
Verified Cross-checked Liquidity is real and multi-venue; structural language only (turnover %, % from ATH), no absolute price in editorial.
Thesis verdicts 4 checks
Thesis: real private-inference demand is served and growing. source →
— Venice inference is off-chain; there is no on-chain inference counter (unlike Morpheus's LumerinDiamond), so the throughput trajectory is Venice-published and not independently rebuilt. The DeFiLlama buyback-flow ramp is a weak corroborating proxy.
Check pending Editorial Honest limit: demand is real by every external signal but not independently measurable on-chain.
Thesis: the token captures real, measurable value via a revenue buyback-and-burn. source →
33.83M VVV at the burn address on-chain and rising; monthly buyback + per-event burn flows indexed on Base. On-chain burn balance and per-event/monthly burn flows measured directly.
Verified on-chain Venice's clearest verifiable value-accrual: a genuine, on-chain, revenue-funded burn. This is the strongest leg of the token thesis.
Thesis: fair-launch integrity - no VC or pre-mine token sale. source →
No sale contract; owner-mint emissions only; documented allocation with no VC/private tranche. The July 2026 Series A is company equity, not a token allocation. Enumerated owner-gated functions (no sale path) and read the allocation.
Verified Cross-checked Holds for the token. Keep the company Series A (equity) distinct from token distribution when writing prose.
Thesis: inference is genuinely private and permissionless. source →
— Privacy rests on a closed-source proxy with no independent audit; access can be gated by Venice (UK free tier blocked). TEE attestation and the model list are checkable but were not verified to a grade this session.
Check pending Editorial The deepest open question on the value prop: private-by-policy and permissionless-with-a-central-chokepoint, both checkable (privacy audit + TEE quote + model API), neither independently confirmed yet.
Bittensor 21 claims 6 corrected 2026-07-06
Infra Out of date· 2 checks
A few subnets dominate emissions (top-10 ~56%; Chutes ~14.4%). source →
Top-10 subnets take 40.05% of emissions on the chain read. That is up from 33.2% when this verdict was authored, so the gap to the 56% narrative has roughly halved without closing. uniform alpha emission x alpha price / total = standard dTAO emission-value share
Out of date on-chain Lead with current truth: network emission is ~33% top-10 concentrated NOW and falling. Pine's 56%/14.4% was correct for March 2026; this records the de-concentration trend - not a Pine error, and NOT a claim that Bittensor is currently highly concentrated. The falling trend nobody else tracks is the finding. Re-read 2026-08-16: concentration has risen materially since the original chain read, which moves the finding from "the narrative is well above the chain" toward "the narrative was early". The verdict stays outdated because the 56% figure is still well above what the chain shows, but the direction of travel now favours the concentration argument rather than refuting it. Wired so the next move is caught by the router rather than by someone re-reading the prose.
Permissionless network of AI subnets: anyone can register a subnet or run a miner/validator; 128+ active subnets and thousands of GPU nodes. source →
129 registered subnets on-chain (get_all_metagraphs_info, Subtensor finney); subnet creation and miner/validator registration are permissionless (gated only by a TAO burn). QUALIFIED 2026-08-13 by Bittensor's own subnet guide: registration is open and price-gated (cost doubles per registration, decaying to a 1,000 TAO floor), but emission is not. "That is root's switch, subnet_emission_enabled" - and "New subnets register with it off, and owners cannot set it." So anyone may create a subnet; whether it earns anything is a root decision. Read the registered subnet set on-chain; registration path is open with a burn cost.
Verified on-chain The subnet layer is genuinely permissionless. Block production, however, is authority-based and OTF-controlled (see governance).
Governance Overstated· 2 checks
Bittensor is a decentralised, community-governed network. source →
Bicameral by design but centrally gated: a 3-member Triumvirate (OTF employees) proposes ALL changes (proposal monopoly); a 12-seat Senate of top validators votes 50%+1. OTF controls PoA block production and demonstrated a centralised override (SN28: OTF used root stake to crash a subnet ~98%). Protocol changes ship through OTF-merged runtime upgrades (e.g. PR #2781, verified live). NEW 2026-08-13, and it is Bittensor's own documentation: the validating guide states "The legacy on-chain senate-vote extrinsic - and the collective and membership pallets behind it - have been removed from the runtime, so top root members no longer form a voting senate" and "Privileged operations (runtime upgrades, protocol changes) are dispatched through sudo, held by a multisig of Rao Foundation keys." The project documents sudo-multisig control of runtime upgrades in plain language, which settles the question the charter's decentralisation language leaves open. Characterised the proposal/veto structure, block-production authority, and the SN28 root-override event.
Overstated on-chain Substrate governance-rubric adaptation: proposal power is monopolised by a 3-member OTF Triumvirate and block production is authority-based, with a demonstrated root override (SN28) - G0-equivalent central control, mitigated by the Senate veto and the dTAO market mechanism (the separate match below). Far more centralised than the 'decentralised' marketing. The inflated verdict no longer rests on our inference: Bittensor's docs say the senate pallets were removed and privileged operations run through a Rao Foundation sudo multisig. Claim attributed to the charter, which is where the decentralisation language is actually published; the contradicting page is cited in the evidence.
dTAO shifted subnet emission allocation from a validator oligarchy to a market-based (price-weighted) mechanism. source →
Code diff (pallets/subtensor/src/coinbase/subnet_emissions.rs) confirms get_shares() switched from get_shares_flow() (net-flow / Tao Flow) to get_shares_price_ema() weighted by root_proportion * (1 - miner_burned) and renormalized, i.e. effective emission proportional to root_proportion_i * moving_price_i * (1 - miner_burned_i); the prior price-EMA path was un-deprecated. Live on finney mainnet: runtime specVersion 440 at block 8760464 (2026-08-03) contains the PR #2781 merge commit 6016381e (ancestor of the v440 release tag, ahead_by=0 = contained and not reverted; first shipped in spec 422 / v3.4.7-422 on 2026-06-23). On-chain emission share resolvable as price-weighted (moving_price) across 128 subnets; top-10 = 39.70% (corroborating, consistent with the price-based path). read the actual Rust diff of the allocation function + on-chain runtime spec_version read + git ancestry of the PR merge commit against the live runtime release tag + price-weighted emission-share readout across all subnets
Verified on-chain Confirms the 2026-08 review's project-page and tokenomics-article claim that Bittensor reverted to price-based emissions. A merged PR alone is not proof of live deployment; this check confirms the code is in the running finney runtime (spec 440) and not reverted. The dtao-subnet-economics article's flow-based mechanism walk-through is period-accurate for Nov 2025-Jun 2026 and flagged for a fuller rewrite.
Distribution Overstated· 2 checks
Fair launch: no ICO, no pre-mine, no VC allocation, no token sale; all TAO earned through mining (Bitcoin-style). source →
Issuance is 100% mining-based from genesis (Jan 2021); no sale/pre-mine tranche exists. The fairest launch model in DeAI. Confirmed the mining-only issuance and absence of any sale allocation.
Verified Cross-checked Launch fairness is genuine. Ongoing ownership concentration is a separate, contrasting claim below.
Ownership/stake is broadly distributed. source →
Extreme concentration: top 1% of wallets control ~90% of stake (Gini ~0.98). Per-subnet alpha capture is severe in places: Templar (SN3) 95.6% one coldkey, Targon (SN4) 88.3%, plus an owner-self-capture cluster (6 subnets with owner holding 51-77% of their own alpha). On-chain per-subnet alpha-stake shares by coldkey; network-level Gini from published analysis.
Overstated on-chain The central tension: the fairest launch mechanism (100% mined) produced the most concentrated ownership (Gini ~0.98). Distribution rubric D0 on ongoing concentration despite a fair launch. Positive controls exist (Ridges, Score/SIRE ~29% top-1) and are recorded in the flags.
Censorship Verified
Permissionless subnet creation and miner registration; no protocol-level content policy on subnets. source →
Registration is permissionless on-chain (gated only by a TAO burn); no protocol content filter. Caveat: OTF demonstrated a root-level override (SN28), so entry is open but the root can intervene. Confirmed the open registration path; recorded the demonstrated override.
Verified on-chain Permissionless entry holds; the SN28 root override is the qualifier (open to join, but OTF can act at the root).
Data Verified
Miners run models on their own hardware; validators score independently; wallets are self-custodial (coldkey/hotkey). source →
The coldkey/hotkey wallet model is self-custodial on-chain; miners run models locally on their own hardware. Genuine data sovereignty relative to hosted competitors. Confirmed the self-custody wallet model and local-execution design.
Verified on-chain The strongest freedom dimension: local hardware + self-custody. Off-chain model behaviour is not measurable, but the sovereignty architecture is real.
Open source Verified
All core code is open source (MIT) across 64 public repos, with active development. source →
Core code is open (MIT); the Subtensor runtime is public - we read the PR #2781 Rust diff directly this cycle. Caveat: no formal security audit of the core chain. Confirmed the public MIT repos and read core Subtensor source directly.
Verified on-chain Fully open-source and independently readable (we verified the emission-mechanism change against the actual source). The assurance gap is the absence of a formal security audit.
Utility Established
TAO is essential utility: staking is required to participate, registration requires a TAO burn, and TAO governs the network (with dTAO subnet tokens). source →
Staking, registration-burn, and the dTAO subnet-token mechanism are all on-chain and load-bearing for participation. Confirmed the staking/burn/dTAO mechanisms on-chain.
Established on-chain Utility is essential and on-chain; one of the strongest token-utility profiles in DeAI.
Accrual Established
Value accrues via staking and the dTAO market mechanism. source →
Accrual is stake/emission-based via dTAO market pricing; there is no protocol fee distribution or fee-burn to holders. Measured, honestly disclosed. Confirmed the emission/dTAO accrual path and the absence of a fee-share mechanism.
Established on-chain No overclaim: accrual is emission/market-based, not revenue-fee-based. The subsidy question is graded under revenue.
Supply Verified
21M hard cap, Bitcoin-style disinflationary halving, no ICO/pre-mine/VC. source →
CoinGecko max_supply = total_supply = 21,000,000; circulating ~9.6-10.7M depending on staking treatment. Bitcoin-modelled emission with supply-milestone halving (first halving ~Dec 2025). Confirmed the 21M cap and the disinflationary halving model.
Verified Cross-checked Supply rubric S2/S3 (hard cap, Bitcoin model, predictable). Circulating % varies with staking treatment; use structural framing. The concentration issue is a distribution finding, not a supply-integrity one.
Revenue Overstated· 4 checks
Subnet economics are driven by real demand. source →
Emission budget 3,559 TAO/day (1.30M TAO/yr), derived from the on-chain TotalIssuance delta. Independently measured demand revenue is $1.12-5.61M/yr, the annualised band from OpenRouter's own token series for Chutes (SN64) priced at Chutes' listed rates, which is 0.45-2.25% of the budget. Adding every dated self-report for a subnet with no measured leg gives a generous ceiling of $16.0M/yr, 6.4%. Participant rewards are overwhelmingly inflation-funded on every basis, but NOT by 'under 5%': that figure fails once the ceiling is itemised and the budget priced correctly. Emission from the TotalIssuance delta over a 300-block window, not from BlockEmission storage, which reads 1 TAO/block against actual issuance of 0.494 and would overstate the budget 2x. Revenue split into a measured leg (a third party settles it) and reported claims (the subnet settles its own), never summed into one figure.
Overstated Cross-checked Re-authored 2026-08-18 onto a refreshable basis. The prior wording asserted a $360M/yr emission budget, which prices TAO at ~$274; TAO last traded there on 27 May 2026 and was $205 on the 9 August assessment date, so the dollar level was stale by about a third when written. The 3,600 TAO/day it rested on is confirmed by the chain. Graded api rather than onchain-reconciled because the binding half is OpenRouter's series, not a chain read. Measured coverage is one subnet of 129: a floor on demand revenue, not a census.
Value locked in DeFi on Bittensor. Our own framing; the project publishes no chain-TVL claim.
$42,824,796 total value locked across Bittensor chains. DeFiLlama chain-TVL sum, refreshed by scripts/refresh-primary.ts into meta.primary_data.
Established Cross-checked Recorded with its limit stated. Bittensor TVL is capital in DeFi on the Subtensor chain, largely subnet-token liquidity, not the emission economy the review rates. The emission rows carry that. Kept because subnet-token liquidity is the surface a holder actually transacts against.
Named Bittensor subnets generate real demand-side revenue: Targon on track for $10.4M annually and Chutes for $2.4M (DL News, 15 October 2025). source →
no independent source exists none: Pine Analytics' $1.3-2.4M range is itself self-reported (Chutes to DL News) plus an unaudited March-2026 estimate, 'neither independently audited' (Pine's words). Pine is an analyst, not an independent auditor.
Editorial Editorial Network-wide demand-side revenue is $3-15M (unverifiable) against an on-chain annual emission budget of ~$360M. The inflation-subsidy direction is robust even at the generous revenue ceiling, but the revenue figure is not independently established, so no precise subsidy ratio is asserted as verified. Attribution 2026-08-13: neither Bittensor nor the two named subnets publishes these figures. chutes.ai states only 'Powering Trillions of Tokens per Month'; targon.com publishes GPU, uptime and latency counters and no revenue. The ~$10M and $10.4M ARR figures are third-party or social-media sourced, which is why this stays unverifiable. FIGURE CORRECTED 2026-08-13. We had recorded 'Chutes ~$10M ARR (self-reported to DL News)'. The DL News article we cite says $2.4 million for Chutes, not $10M, so our number was roughly 4x the source and attributed to a source that does not support it. Targon's $10.4M is correct and was likely the figure that leaked across. The verdict stays unverifiable: these are forward-looking subnet-team projections reported by a journalist, with no independent series behind them, and Chutes' annualised emission subsidy alone dwarfs either number.
A subnet (Lium, SN51) ran a revenue-funded 2,500 TAO buyback-and-burn from real GPU-credit sales. source →
no independent source exists Traced the OTF relay to the primary Lium post; confirmed SN51 = lium.io on taostats and that lium.io is a live, priced GPU-rental marketplace (a real paying-revenue product). Lium published no burn tx hash, and without their treasury coldkey the specific 2,500 TAO buyback-burn extrinsic could not be isolated on taostats. The revenue-origin claim (GPU-credit sales) is off-chain and cannot be verified on-chain by nature.
Editorial Editorial Used as an attributed, hedged demand datapoint in the review's 'The product in practice' section (an early exception to the emission-subsidy pattern). Recorded as unverifiable so it is never later treated as an independently confirmed burn/revenue figure. Verified: primary source, SN51 identity, and that Lium is a live paying GPU product. Not verified: the burn transaction (no published hash) and the GPU-revenue attribution (off-chain).
Liquidity Verified
Deepest liquidity in DeAI: Binance, Coinbase, Kraken, and highly liquid markets. source →
73 tickers; ~$120.5M 24h volume against a ~$2.0B market cap (~6% turnover), with Binance/Coinbase/KuCoin as top venues - materially deeper than the other DeAI flagships. ~72% below ATH. Read the ticker set and 24h volume live.
Verified Cross-checked The 'deepest liquidity in DeAI' claim holds: ~$120M/24h dwarfs the other flagships. Structural framing only.
Thesis verdicts 4 checks
Thesis: subnet economics are self-sustaining, funded by real demand rather than emissions.
The network mints 3,559 TAO/day (1.30M TAO/yr) to pay participants, derived on-chain. Demand revenue anyone but the subnet can settle is $1.12-5.61M/yr, all of it one subnet's OpenRouter traffic. Even summing every self-report on top, $16.0M/yr against a $249M/yr budget: emissions fund the overwhelming majority of participant rewards. Compared the on-chain minted budget to the measured revenue floor and to the generous self-reported ceiling.
Overstated Cross-checked Motive-neutral: some subnets have real products, and Chutes' OpenRouter traffic is real money. The network-level economics are still emission-subsidised. Attribution 2026-08-13: no Bittensor page asserts self-sustaining, demand-funded subnet economics, so the thesis is ours to test, recorded as none-published. Re-authored 2026-08-18: the ratio is deliberately not the banded figure, because revenue is billed in dollars and the budget minted in TAO, so a falling TAO price raises the ratio without a dollar of extra demand. The band sits on the minted budget, which moves only if the protocol does.
Thesis: the largest live decentralised AI network, with real subnets competing to produce digital commodities. source →
129 subnets on-chain, ~$2.0B market cap, deepest DeAI liquidity - a real, large, live network by every measurable structural signal. Subnet count on-chain; market scale from CoinGecko.
Verified on-chain Scale and liveness are real. Whether the subnets do genuinely useful work is unmeasurable on-chain (subnet_output flag).
Thesis: Bittensor is genuinely decentralised in governance and block production. source →
Proposal power is monopolised by a 3-member OTF Triumvirate; block production is authority-based (OTF); OTF demonstrated a root override (SN28); stake is Gini ~0.98. dTAO added genuine market allocation, but root control remains centralised. Assessed proposal/veto power, block-production authority, override precedent, and stake concentration together.
Overstated on-chain The sharpest correction: PoA block production and Triumvirate proposal control make Bittensor far more centralised than marketed. Covenant AI's April 2026 exit alleged specific governance abuses. dTAO is a real decentralising step but does not reach the root.
Thesis: a fair-launch, hard-capped, Bitcoin-modelled token. source →
21M hard cap (CoinGecko max = total); 100% mining issuance, no sale/pre-mine tranche. Confirmed cap and mining-only issuance.
Verified Cross-checked The token-model half of the thesis is solid; the concentration of the resulting distribution (Gini 0.98) is the counterweight.
Measured facts & caveats 5 notes
Templar (SN3) alpha stake is 95.6% held by a single coldkey (top-5 = 100%), with only 2 validators. Incontestable on-chain fact, block 8362435.
Targon (SN4) 88.3% held by one non-owner coldkey; 6 validators. On-chain, block 8362435.
Six of 15 subnets have the owner coldkey holding the plurality/majority of their own subnet's alpha stake: Metanova 76.8%, TAOHash 75.3%, Affine 67.3%, Hippius 61.9%, Synth 61.4%, Nineteen 51.6%. Owner self-stake means these owners earn validator dividends in addition to the 18% owner take. The dividend accrual is mechanical and follows from holding stake regardless of intent. High owner self-stake is consistent with both extractive self-capture and genuine owner bonding to their own subnet; the chain settles the stake share, not the motive.
Positive controls, recorded with equal weight to the capture findings: Ridges (SN62) 29.1% and Score/SIRE (SN44) 29.2% top-1 coldkey, near-zero owner self-stake - the most distributed validator bases in scope. Not every subnet is captured.
Whether a subnet produces genuinely useful off-chain AI work cannot be verified on-chain; the chain records emission, stake and weights, not service quality. Emission capture is settleable; 'real work' is not.
Virtuals Protocol 20 claims 2 corrected 2026-08-09
Infra Verified· 2 checks
Agent creation, tokenisation, and settlement happen on-chain on Base (a decentralised platform). source →
AgentNftV2 registry and VIRTUAL token live and verified on Base; token/settlement layer is genuinely on-chain. Confirmed the canonical registry (0x50725af) and token contract are deployed and verified on Base.
Verified on-chain The settlement/tokenisation layer is on-chain. The agent runtime is not, per the next claim.
The GAME agent runtime / inference engine is decentralised infrastructure. source →
— The GAME inference engine runs on centralised hosted servers operated by Virtuals (documented architecture, a single point of failure); it is off-chain and was not independently rebuilt this session.
Check pending Editorial Infrastructure decentralisation is capped by the centralised GAME runtime regardless of on-chain settlement. The 'decentralised platform' framing holds for tokenisation, not for compute.
Governance Overstated· 2 checks
Virtuals is a decentralised platform (core protocol under decentralised control). source →
The canonical AgentNftV2 registry is a TransparentUpgradeableProxy whose ProxyAdmin (0x9988299c) is owned by a single EOA (0xc31Cf1168b2f6745650d7B088774041A10D76d55), with no timelock. That EOA can unilaterally upgrade the core agent-registry logic. Read the AgentNftV2 proxy admin slot, resolved the ProxyAdmin, read its owner(), and confirmed it is an EOA (no code).
Overstated on-chain Governance rubric stage G0 for the core registry: a single EOA holds instant, unilateral upgrade authority, no timelock. Path to match: move the ProxyAdmin to a timelock-gated multisig, then to binding token governance. Distinct from the token layer, which is decentralised (next claim).
The VIRTUAL token itself is decentralised and beyond team control. source →
Canonical L1 VIRTUAL (0x44ff86, Ethereum): ownership renounced (owner = 0x0), not upgradeable (no EIP-1967 impl slot), totalSupply fixed at exactly 1,000,000,000. The Base token is bridge-minted via the canonical Base Standard Bridge (0x4200...0010), not a discretionary team mint. Read L1 owner() (0x0), totalSupply (1B), EIP-1967 slot (zero); confirmed the Base contract is an OptimismMintableERC20 whose minter is the Standard Bridge.
Verified on-chain A genuine decentralisation sub-claim: the token is renounced, fixed, and non-upgradeable. The governance correction sits on the protocol contracts, not the token.
Distribution Verified· 2 checks
Fair distribution: 60% to public circulation via IDO, with no VC allocation. source →
Allocation as documented; issuance is fixed (L1 supply renounced at 1B). Launch was a public IDO (Fjord Foundry LBP, Enjinstarter, PAID Network, Dec 2021 as PathDAO), not a private VC sale. Confirmed fixed 1B supply on-chain and read the allocation + IDO venues.
Verified Cross-checked No-VC and public-IDO hold. It was a paid public sale (ICO/IDO), not a free airdrop, and traces back to the PathDAO migration. The 35% ecosystem treasury can emit up to 10%/yr for 3 years subject to DAO approval - a capped dilution vector, not an uncapped mint.
Ongoing token distribution is broad (not insider-concentrated). source →
— Top-N holder concentration across Base/L1/Solana was not rebuilt this session.
Check pending Editorial Checkable via a multi-chain holder index; the upgrade that grades ongoing concentration.
Censorship Verified· 2 checks
VIRTUAL holders cannot be frozen or blacklisted at the token layer. source →
L1 token ownership renounced and non-upgradeable; standard ERC-20 with no blacklist/pause path. Confirmed renounced ownership and no upgrade path; no blacklist/freeze mechanism.
Verified on-chain Token-layer censorship resistance is real. Platform-layer is not, per the next claim.
The agent platform is censorship-resistant. source →
The GAME Cloud is a hosted service governed by terms of service; the team controls which LLMs are available and can restrict agents at the runtime layer. Reviewed the hosted-runtime architecture; agent execution depends on a team-controlled service.
Check pending Editorial Platform-layer censorship resistance is limited: the runtime is a hosted, team-governed service. Distinct from the token-layer property above.
Data Check pending
Agents own their data and identity. source →
Agent personality data, voice/visual assets, and long-term memory are stored on Virtuals-hosted infrastructure (Stateful AI Runner); the token/NFT is on-chain but the agent state is custodied off-chain by Virtuals. Reviewed where agent state actually lives (hosted runner, not self-custody).
Check pending Editorial Only the token/NFT is on-chain; the agent's data and memory are custodied by Virtuals. Data sovereignty is low and off-chain.
Open source Verified
Strong open-source presence: 32+ public repos including protocol-contracts, with verified on-chain contracts. source →
AgentNftV2 and the VIRTUAL token show verified source on the block explorers; the protocol-contracts repo is public. Confirmed contract verification on-chain and the public repo set.
Verified on-chain Open-source rubric ~O2 on contracts (verified, public). The GAME runtime is not fully open, so platform transparency is partial.
Utility Established
VIRTUAL is the platform asset for an agent launchpad: bonding-curve launches, tiered launch system, and veVIRTUAL governance, across multiple chains. source →
The launchpad is live on-chain: 1,233 graduated/Sentient agents in the canonical AgentNftV2 registry (2026-08-09). Read the registry totalSupply live (graduated-agent count).
Established on-chain The launchpad mechanism and its scale are real on-chain. Whether the launched agents are productive is the thesis question below.
Accrual Established
Value accrues via launch/trading fee capture (1% agent-trading tax) plus a buyback-and-burn programme. source →
DeFiLlama's multi-stream adapter indexes the protocol take (the tax-manager outflow + the 1% agent-trading tax) across chains; fee capture is measurable on-chain. DeFiLlama indexes the fee streams on-chain; the buyback-burn specifics were not independently rebuilt this session.
Established Cross-checked Fee capture is measurable; the specific buyback-burn totals (13M VIRTUAL / 25 tokens) are checkable via burn events but not rebuilt here (unverified sub-claim).
Supply Verified
Fixed 1B VIRTUAL supply, no VC allocation, with deflationary pressure from buyback-and-burn. source →
L1 canonical totalSupply exactly 1,000,000,000, ownership renounced, not upgradeable (= CoinGecko max_supply 1B). Circulating ~657.8M (65.8%). Read L1 totalSupply and owner (renounced); reconciled circulating against CoinGecko.
Verified on-chain Supply rubric S2 (capped + predictable, majority circulating, no discretionary mint). The 35% treasury's capped, DAO-gated emission is the only inflation vector.
Revenue Verified· 2 checks
Virtuals generated ~$470M of 'Agentic GDP' (2025). source →
no independent source exists 'Agentic GDP' is an off-chain aggregate construct, not protocol revenue and not defined against any on-chain, auditable base. It cannot be independently verified.
Editorial Editorial Never present Agentic GDP as protocol revenue; the on-chain figure is $20.7M/1y (above). Genuinely unverifiable, not merely unchecked. SOURCE FOUND 2026-08-13: the figure was previously recorded only as 'Virtuals marketing' with no citation. It is a dated, project-issued press release, which is a real publication, so this moves off unsourced. The verdict stays unverifiable: aGDP is Virtuals' own coinage measuring 'total economic value created, exchanged, and reinvested by autonomous agents', with no published methodology we can reproduce and no independent series to check it against.
The protocol earns real, on-chain multi-chain revenue. source →
$20.7M trailing-1y / $73.1M all-time on-chain protocol revenue (DeFiLlama virtual-protocol multi-stream adapter, 2026-08-02); reconciles the self-reported annual run-rate within ~14%. DeFiLlama indexes the multi-stream protocol take across chains - Base legacy streams + cbBTC prototype + tax-manager sentient outflows + Ethereum + Solana + the 1% agent-trading tax - replacing ecosystem/treasury transfers with the tax-manager outflow to avoid double-counting. Our own naive getLogs self-index was not tractable, so we cite DeFiLlama's open adapter.
Verified Cross-checked On-chain revenue corroborates the self-reported run-rate within ~14%; all-time take $73.1M. Sustainability caveat: revenue is ~97% below the Jan 2025 peak. The $470M 'Agentic GDP' headline is an off-chain construct, not protocol revenue (see next claim). Basis corrected 2026-08-17: this was banded on the cumulative all-time total, which only ever rises, so the band could register growth but was structurally incapable of registering decline. Rebased on the trailing year from the same stored response, which can fall.
Liquidity Verified
Strong liquidity: major CEX listings and multi-chain on-chain liquidity. source →
457 tickers; real CEX plus Aerodrome DEX depth; turnover runs at a 7-day median of ~8.2% of market cap; ~89% below ATH. Volume skews to mid-tier venues (HTX, Biconomy, Toobit) alongside the majors. CoinGecko ticker list paginated to a real total, and turnover as the median of the trailing 7 daily volume/market-cap points. Refreshed by scripts/refresh-primary.ts.
Verified Cross-checked Liquidity is real and multi-venue; structural language only. The deep drawdown (~89% from ATH) matches the revenue collapse. CORRECTED 2026-08-17: this row recorded '100 tickers', which was not a count but CoinGecko's page size. The endpoint serves 100 per page and publishes no total, so an unpaginated read returns the ceiling and it reads like a measurement. The real figure is 457, and the exactly-round 100 was the only thing on the record that hinted at it. The paginated reader now flags the bound instead of reporting it as a total.
Thesis verdicts 4 checks
Thesis: the launched agents form a productive economy ('a society of productive AI agents'). source →
Of 1,232 graduated agents (2026-08-10 index), 1,036 (84%) traded under $1k in 30 days (dead or near-dead), 514 (42%) had zero DEX trades, and just 3 (0.2%) traded over $1M/30d. The whole graduated set turned over $17.6M in 30 days. The live set has thinned since the June read: dead/near-dead 71% to 84%, and agents above $1M/30d 25 to 3. Per-token 30d DEX volume across the graduated registry; dead/near-dead = under $1k/30d, which includes agents with no DEX trades at all. See the survivorship metric_flag for the full breakdown.
Overstated on-chain The sharpest correction, and it has sharpened further. The 'productive society' framing is contradicted by an 84% dead/near-dead rate, up from 71% at the 2026-06-09 read while the graduated count barely moved (1,221 to 1,232), so the tail grew by agents going quiet rather than by new launches. The concentration tightened at the same time: agents turning over $1M or more in 30 days fell from 25 to 3. Verdict unchanged at inflated, on stronger evidence; refreshed via the freshness harness band-crossing routed 2026-08-14.
Thesis: Virtuals is the dominant on-chain AI-agent launchpad. source →
1,233 graduated/Sentient agents in the canonical Base registry (live), a large multi-chain launchpad footprint. Registry totalSupply read live.
Established on-chain Scale is real and measurable. Whether that scale is productive is the next thesis verdict.
Thesis: a fixed-supply, no-VC token with real on-chain value accrual. source →
L1 supply fixed at 1B and renounced; DeFiLlama-tracked on-chain fee capture ($20.7M/1y, $73.1M all-time); no VC token allocation. Supply/renouncement read on-chain; revenue via DeFiLlama; allocation documented.
Verified on-chain The token-economics half of the thesis holds; the value question is whether agent demand recovers (revenue ~97% off peak).
Thesis: the agents do genuinely useful work. source →
no independent source exists Agent output, performance, and quality are off-chain; the chain records token trades, graduation, and fees, not whether an agent does useful work.
Editorial Editorial The survivorship index measures trading liveness, not service quality; agent usefulness has no independent on-chain measure.
Measured facts & caveats 5 notes
Of 1,221 graduated/Sentient agents on Base, 512 (42%) had zero DEX trades in 30 days; 870 (71%) traded under $1k/30d (dead or near-dead); only 25 (2%) traded over $1M/30d. Graduated-agent 30d volume $105.3M. Filtering to exactly the 1,221 graduated tokens matters: all-VIRTUAL-paired 30d volume was ~$658M (about 6x), most of which is not graduated-agent activity.
Excluding contract/platform founder addresses, the graduated agents trace to genuine EOA creators with moderate concentration: largest single creator 85 agents, top-10 creators 224 of 910 EOA-attributed agents (25%). 312 agents sit under contract-coded founder addresses (platform/factory defaults; one contract, 0xf66dea7b, is the registered founder for 279 agents). Those contract founders are recorded here and excluded from creator concentration - a caught aggregation artifact, not silently dropped.
Descriptive association, not causal: the largest genuine (EOA) serial creators' agents are almost entirely dead or near-dead - the 85-agent creator 99%, the 73-agent creator 100% (by <$1k/30d). EOA-creator near-dead rate 74% vs 71% overall. Whether serial launching relates to abandonment by selection, non-viability, or both is not determined, and it is not universal (some small serial creators have live agents). The chain settles that these creators' agents are inactive, not why.
Agent usage, performance and quality are off-chain; the chain records token trades, graduation and fees, not whether an agent does useful work. Survivorship here measures DEX trading liveness, not service quality.
Genuinely alive agents, recorded with equal weight to the dead-agent findings: top graduated agents by 30d volume - DEUS $17.2M, OPG $7.8M, TIBBIR $6.4M, CAS $5.2M, PEAK $5.1M; 25 agents clear $1M/30d. The network is concentrated in a small live set, not dead.
Aethir 18 claims 7 corrected 2026-06-09
Infra Check pending
Enterprise-grade decentralised GPU compute network: 440,000+ GPU containers distributed across 94 countries. source →
— GPU container count and geographic distribution are off-chain reality on a closed-source, self-certified surface (zero public repos). Per the WS1 rule, off-chain hardware claims are not deep-reconcile targets. Corroborated by Aethir's own dashboard (not contradicted by its own surface, unlike io.net) but not independently verifiable.
Check pending Editorial The physical GPU layer's decentralisation cannot be independently confirmed: closed-source, off-chain hardware. Recorded honestly as off-chain, not as a pass.
Governance Overstated
Community/DAO governance (a DAO Treasury and community control of the protocol). source →
No on-chain governance found. The ATH token's owner (mint authority) is a 2-of-3 Gnosis Safe (0x1246aE66) with no timelock; the DAO Treasury allocation exists but no on-chain voting or governance mechanism is deployed. Read the token owner and resolved it to a 2-of-3 Gnosis Safe; searched for a Governor/voting contract (none located).
Overstated on-chain Governance rubric stage G0 (a thin 2-of-3 Safe, no timelock, holds the token mint authority; no on-chain voting). Path to match: on-chain governance binding through a timelock. The DAO Treasury allocation is not the same as functional governance.
Distribution Overstated· 2 checks
50% of supply is allocated to compute providers / node operators (supply-side favourable distribution). source →
Allocation as documented: 50% to compute providers (linear vesting). Read the allocation table; confirmed total supply on-chain (42B).
Verified Cross-checked A genuine supply-side-favourable allocation. Ongoing insider concentration is a separate claim below.
Distribution is broad/fair (not insider-heavy). source →
Insider allocation is material: 12.5% team + 11.5% investors + 5% advisors (~29%), plus a private/pre-sale tranche. This is a VC-backed launch, not a fair launch. Summed team/investor/advisor allocations from the tokenomics table.
Overstated Cross-checked Distribution rubric ~D1: notable insider allocation, vested. Unlike Venice/Virtuals, Aethir is VC-backed; the 'fair/broad' reading is overstated for the insider share, even though the 50%-to-providers slice is genuine.
Censorship Verified
ATH holders cannot be frozen or blacklisted at the token layer. source →
Verified AethirToken source exposes mint + owner only; no pause, freeze, or blacklist function, and the contract is not upgradeable (no EIP-1967 slot). Enumerated the verified ABI (no pause/blacklist); confirmed non-upgradeable.
Verified on-chain Token-layer censorship resistance holds (but the owner can mint - see supply). Network-layer resistance is limited: closed-source, Aethir controls what runs.
Data Check pending
Enterprise workloads run on distributed containers the client controls. source →
— Aethir controls the Indexer matching layer and has visibility into the network; the runtime is closed-source, so client data sovereignty is not independently verifiable.
Check pending Editorial The matching/orchestration layer is centrally controlled and closed-source.
Open source Overstated
A transparent, decentralised compute network. source →
Zero public GitHub repositories. Only the ATH token contract is source-verified on Etherscan (Solidity 0.8.18, the bare minimum); the network code, Checker Node client, and orchestration are entirely closed-source. Checked the GitHub org (no public repos) against the described stack.
Overstated Cross-checked Open-source rubric stage O0 (opaque: core code not public). A verified token contract is not network transparency. This is the weakest freedom dimension (2/15).
Utility Established
ATH is used to pay for GPU compute, plus staking (Gaming/AI/EigenLayer pools) and node operation. source →
Compute-payment utility is on-chain-verified and now indexed rather than observed. 1,250 DepositServiceFee events on AETHIR_CORE (0x226D...a42d, Arbitrum) carry 9,786,507,650 ATH of gross service-fee throughput since July 2024, paid by 61 distinct payer addresses. Indexed DepositServiceFee events; the compute-payment flow is real and on-chain.
Established on-chain Compute payment is genuine on-chain utility. Staking-pool mechanics exist but were not independently rebuilt this session. Denomination question settled 2026-08-17 on the thesis_durable_demand row: the fiat leg is the one that measures demand.
Accrual Established
Value accrues to the ATH token. source →
On-chain: 80% of service fees flow to GPU operators (supply-side), the protocol retains ~20%; there is no fee distribution to token holders and no buy-and-burn. Holder value accrual is indirect and thin. Measured the fee split (80% operators / 20% protocol) on-chain; confirmed no burn/fee-share mechanism.
Established on-chain Aethir is honest about this: value accrual to holders is indirect. Measured, not asserted; no overclaim to correct.
Supply Overstated· 2 checks
42B total supply, ~48% circulating, disinflationary emissions. source →
On-chain totalSupply exactly 42,000,000,000; circulating ~20.13B (47.9%) per CoinGecko. Team vesting to Dec 2028. Read totalSupply live; reconciled circulating against CoinGecko.
Verified on-chain Current supply figures reconcile. Low circulating % + vesting to Dec 2028 = supply overhang. The hard-cap claim is graded separately below.
Supply is hard-capped at 42B (capped supply type). source →
The AethirToken contract has an active mint() function and NO on-chain cap(); mint authority is a 2-of-3 Gnosis Safe with no timelock. The 42B is a governance-discretion cap, not enforced by code. Confirmed mint() present, cap() absent (reverts), and owner = 2-of-3 Safe. totalSupply currently equals the stated 42B, so no over-mint has occurred.
Overstated on-chain The 'hard cap' is not code-enforced: a 2-of-3 Safe can mint beyond 42B. No over-mint has happened (supply = 42B), so this is a latent-authority correction, not evidence of active inflation. Supply rubric caps below S2 because the cap is discretionary.
Revenue Overstated· 3 checks
$166M ARR (current run-rate). source →
Measured against our own index rather than a vendor. Over the 13 months the price history covers, deposited service fees convert to $78.7M at daily ATH prices, and the monthly figure fell from $12.5M in September 2025 to $3.0M in July 2026. The $166M ARR claim is not supported on any basis we can compute. CORRECTED 2026-08-17: this row previously said monthly fees fell to 'under $1M' by June 2026; the indexed figure for that month is $3.6M, so the decline is real but was overstated by roughly 3.6x. Full-history getLogs on the deposit event, summed monthly and converted at daily CoinGecko ATH prices. Replaces the Token Terminal and dashboard readings the row previously rested on, neither of which we could re-run.
Out of date on-chain Motive-neutral: $166M was a defensible peak-ARR at the time, not a fabrication. But revenue has more than halved and Aethir's OWN dashboard now shows $51.7M ARR. Do not cite $166M as current. Denomination question settled 2026-08-17 on the thesis_durable_demand row: the fiat leg is the one that measures demand. CORROBORATED 2026-08-17 against Token Terminal, which publishes its own monthly Aethir fee series built from a different pipeline. It agrees with our index to within 0.6% to 2.9% across the last five months (July: ours $3.02M, theirs $3.0M) and within 6% to 16% on the volatile early-2026 months, where a daily-price conversion is most sensitive to timing. Two independent methods reaching the same series is the strongest check available on this index, and it confirms the USD decline is a real decline rather than an artefact of how we convert.
Protocol revenue is $176.7M ($166M ARR). source →
Protocol-level revenue (the 20% fee cut) is ~$33.6M all-time (DeFiLlama Revenue) / ~$32.7M (our own 20% split); the other 80% flows to GPU operators. The 'network revenue' headline overstates protocol revenue roughly 5x. Separated gross developer service-fee throughput from the protocol's 20% take; DeFiLlama Revenue confirms the protocol line.
Overstated on-chain Explained, not a category error: gross throughput is real ($163.5M, match above), but labelling it protocol 'revenue' overstates the protocol take ~5x. Protocol revenue is ~$33M all-time / ~$17.4M per year (DeFiLlama).
Real, on-chain-verifiable service-fee revenue: $176.7M lifetime network revenue / $127.8M in 2025. source →
$163.5M all-time net service fees (our own on-chain index); calendar-2025 $117.8M. Corroborated by DeFiLlama $167.9M and Token Terminal $165.1M (calendar-2025 $118.0M, matching ours to 0.2%). Summed DepositServiceFee minus WithdrawServiceFee amounts (1,213 deposits, 64 withdrawals; gross 8,101,465,682 ATH = exact unit match to Aethir's own dashboard), USD-converted at DeFiLlama daily ATH prices. Start 2024-07-22.
Verified on-chain Aethir's gross revenue is REAL and on-chain-verified - the positive-control case for a closed-source project. The ~8% gap is the gross dashboard lifetime figure vs our net on-chain fees. This is GROSS developer spend; protocol-level revenue is graded next. NOT REPRODUCIBLE AS AN ALL-TIME DOLLAR FIGURE, recorded 2026-08-17. This row's $163.5M was hand-run in June 2026 by converting the whole ATH history at daily prices. The committed index (scripts/refresh-aethir-fees.ts) can only price the rolling 366-day window src/data/price-history.json covers, so it cannot regenerate that number and the article no longer attributes an all-time dollar figure to us. What IS reproducible, and what the editorial now binds, is the trailing year: ours $78.7M against DeFiLlama's total1y $82.1M, 4.1% apart. Treat the all-time leg as DeFiLlama's to state.
Liquidity Verified
Strong liquidity: major CEX listings (OKX, Bybit, KuCoin, Bitget, Gate.io, Coinbase, Upbit) with healthy volume. source →
58 tickers; real CEX (Upbit, Bybit, LBank, CoinW, HTX); ~$4.5M 24h volume against a ~$82M market cap (~5.5% turnover); ~97% below ATH. Read the ticker set and 24h volume live.
Verified Cross-checked Liquidity is real and multi-venue; structural language only. The ~97% drawdown from ATH matches the revenue collapse.
Thesis verdicts 3 checks
Thesis: enterprise GPU demand is durable and growing. source →
Demand has fallen, and the token-denominated counter-reading does not overturn it. Monthly service fees ran $12.5M in September 2025 against $3.0M in July 2026 on our own index. Deposits measured in ATH rose over the same window, which prompted the question of which denomination measures demand, and the logs answer it: across 11 months the correlation between log ATH deposited and log ATH price is -0.90, with an elasticity of -0.48. If compute were priced in ATH there would be no reason for deposit volume to track price inversely at all, so pricing behaves as fiat-denominated and settled in ATH. The elasticity is about -0.5 rather than -1, which is the part that matters: a pure settlement artefact would leave dollar spend flat, and dollar spend roughly halved. So the ATH rise is mostly the token falling, and real demand fell underneath it. Full-history DepositServiceFee enumeration reported in ATH and converted at daily prices, then regressed: corr(log ATH deposited, log monthly mean price) = -0.898, beta = -0.48 over the 11 complete months the price history covers. The elasticity is the discriminator: 0 would mean ATH-denominated pricing, -1 would mean fiat pricing with flat real demand.
Overstated on-chain Motive-neutral: the mid-2025 peak was genuine, but on-chain demand has contracted >70%, so the 'durable/growing' framing overstates current reality. The revenue is real; its trajectory is down, not up. RESOLVED 2026-08-17. The question flagged for September, which denomination measures demand, is answered from our own logs rather than deferred: deposit volume tracks price inversely at -0.90, which only happens if prices are set in fiat and settled in ATH. Aethir's own docs do not state the denomination anywhere I could reach, and secondary write-ups asserting 'priced in USD' were not usable as sources, so this rests on the measurement. Grade unchanged; the ATH counter-reading is recorded because it is real, not because it wins.
Thesis: Aethir earns real, independently-verifiable enterprise compute revenue. source →
Our own on-chain AETHIR_CORE index ($163.5M all-time gross) reconciles the dashboard within ~8% and matches DeFiLlama/Token Terminal to ~0.2% on calendar-2025. Independent on-chain reconstruction of the service-fee stream.
Verified on-chain The strongest leg: the best on-chain revenue verification in DeAI. Real gross demand, independently confirmed. (Protocol take is ~20% of this; see the headline-basis correction.) NOT REPRODUCIBLE AS AN ALL-TIME DOLLAR FIGURE, recorded 2026-08-17. This row's $163.5M was hand-run in June 2026 by converting the whole ATH history at daily prices. The committed index (scripts/refresh-aethir-fees.ts) can only price the rolling 366-day window src/data/price-history.json covers, so it cannot regenerate that number and the article no longer attributes an all-time dollar figure to us. What IS reproducible, and what the editorial now binds, is the trailing year: ours $78.7M against DeFiLlama's total1y $82.1M, 4.1% apart. Treat the all-time leg as DeFiLlama's to state.
Thesis: Aethir runs a large, genuinely decentralised GPU network. source →
— The hardware footprint is off-chain, closed-source, and self-certified; not independently verifiable (per the WS1 off-chain-reality rule). Not contradicted by Aethir's own surface, unlike io.net.
Check pending Editorial Honest limit: the network scale is plausible and dashboard-corroborated but cannot be independently confirmed on-chain.
Measured facts & caveats 2 notes
Aethir's '$176.7M total network revenue' and '$166M ARR' headlines are GROSS developer service-fee throughput. The protocol retains only the 20% fee cut: DeFiLlama 'Revenue' = ~$33.6M all-time / ~$20.8M per year, and our own 20% split of the on-chain fees = ~$32.7M all-time. The other 80% flows to GPU operators (supply-side). Headline 'revenue' overstates protocol-level revenue roughly 5x.
Device and compute claims (GPU container count, compute hours, container performance) remain closed-source and self-certified (zero public GitHub repos). Only the service-fee revenue stream is on-chain-verifiable; the hardware and utilisation claims are not.
Akash Network 12 claims 1 corrected 2026-08-13
Infra Established
Akash is a permissionless proof-of-stake network secured by an independent validator set. source →
84 bonded validators against a 100-validator cap, securing 91,466,381 AKT (30.8% of total supply bonded). Stake is concentrated: the largest validator holds 11.5%, the top 5 hold 37.3% and the top 10 hold 60.1%, giving a Nakamoto coefficient of 5 (five validators can halt the chain). Enumerated the full bonded validator set via Cosmos REST and computed the stake-share distribution and the >33% Nakamoto coefficient directly from validator tokens. Ingestion only, verdict human-set.
Established on-chain Recorded as a measured anchor rather than a pass or a fail: the set is genuinely open and 84-strong, and it is also concentrated enough that five operators could stop it. Validator decentralisation is separate from provider (compute) decentralisation, which this check does not cover.
Governance Verified· 2 checks
Akash governance directs a community-owned treasury funded by the community pool tax on issuance. source →
4,365,024 AKT in the x/distribution community pool. Direct Cosmos REST read of the community pool balance for uakt, refreshed into meta.primary_data.
Established on-chain Recorded as the scale check on the governance_authority verdict beside it. Binding votes only matter to the extent there is something to vote over, and single proposals have asked for a large fraction of this balance, so the pool size is what bounds how many of them can pass. Proposal 322 raised the tax on issuance from 50% to 70%, which grows this pool while shrinking staker take.
Akash protocol parameters are set by on-chain token-holder governance, not by the core team. source →
Confirmed at G2 on the governance ladder. The live x/mint and x/distribution parameters carry authority akash10d07y265gmmuvt4z0w9aw880jnsr700jhe7z0f (the gov module account), and Proposal 322 executed MsgUpdateParams on both modules after a token-holder vote that closed 15 May 2026 (55.46M AKT yes, 0.82M no, 2.25M abstain). Monetary policy and the community pool are changed by binding on-chain votes, with no separate admin key in the path. Read the passed proposal's executed messages and their authority address, and confirmed the live parameters match what the proposal set. Ingestion only, verdict human-set.
Verified on-chain A confirming positive, and the strongest kind: a consequential change (halving the inflation ceiling) was made by a binding token-holder vote and is visible in the live chain parameters. The check covers protocol parameters and the community pool; it says nothing about who controls the Overclock Labs codebase or the off-chain roadmap.
Open source Verified
The Akash stack is developed in the open under a permissive licence. source →
Confirmed. The github.com/akash-network org carries 73 public repositories; the core node repo (akash-network/node) is Apache-2.0, 1,104 stars, not archived, and was last pushed 2026-07-24, three weeks before this check. Direct GitHub org/repo metadata reads. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: permissive licence, active core repo, no archived-and-abandoned pattern. Covers the licence and development-activity claim only, not audit coverage. Freshness wired 2026-08-17. Wiring limit, stated so nobody reads more into it than it carries: what is re-measured is the star count, because that is the quantity the verdict states. The failure modes that would actually overturn an open-source verdict are the repo being archived, relicensed, or going quiet, and none of those move stars. They are on the Phase 4 backlog. A star-count band is a prompt to go and look at the repo again, not a check that it is still open.
Accrual Verified· 4 checks
AKT spent on leases is 'burned' by the burn-and-mint escrow: the purchased AKT is pulled out of circulation rather than recycled to the treasury. source →
On-chain permanent AKT burn (x/bme total_burned uakt) = 0. AKT is held in the BME vault (balances 562,506 AKT + remint_credits 262,506 AKT, 2026-07-26), not destroyed. Direct read of x/bme vault_state via Cosmos REST, cross-referenced against the AEP-76 mechanism spec.
Verified on-chain RECONCILED as consistent measures of DIFFERENT layers, not a contradiction. Messari's 'burned' = AKT pulled OUT OF CIRCULATION into the BME vault (Messari's own words: 'pulls the purchased token out of circulation', 'now-shrinking circulating supply'); AEP-76 confirms: "'Burn' moves AKT into a BME vault module account; circulating supply goes down", provider payouts consume vaulted AKT first (remint credit), and NET permanent burn happens only on price appreciation between top-up and settlement. On-chain permanent burn = 0 (no net appreciation effect yet), fully consistent with the 53,520 being a circulating-supply/vault figure. CAVEAT: the exact 53,520 at the 31 Mar block could NOT be numerically re-derived on-chain this session -- public LCDs are pruned (no state at block ~26.15M) and x/bme exposes no burn-history endpoint; an archive node or Numia index is needed for a precise tie-out. Directionally consistent: vault AKT grew from ~53,520 (Mar 31) to ~562,506 balance (Jul 26) as leases accumulated. RE-ANCHORED 2026-08-17 onto 620,854 ACT. The verdict does not change: this is a cumulative BME counter that only ratchets up, so a 10% rise is the mechanism working rather than a figure going wrong. Re-anchoring stops a monotonic counter re-firing the band every few weeks.
The burn-and-mint escrow is live on-chain and settles leases through the AKT vault (activated 23 March 2026, Mainnet 17 / Proposal 318). source →
On-chain x/bme vault (AEP-76): 968,221 ACT minted and 799,299 ACT burned cumulatively since activation; 586,153 AKT held as vault backing / remint credit; 0 AKT permanently burned. The loop is demonstrably operating on-chain. Direct read of x/bme vault_state (total_minted, total_burned, balances) via Cosmos REST GET. scripts/refresh-primary.ts onchain-rpc handler; snapshot in meta.primary_data.
Verified on-chain Re-read 2026-08-16 from the refreshed x/bme snapshot: ACT minted has grown roughly a quarter since the July reading, so the loop is still settling leases rather than having stalled after activation. Refutes the community claim (@BecauseYrBored, Jul 2026) that 'no on-chain market buy has ever appeared': the BME loop runs on-chain with substantial ACT mint/burn. But see the bme_akt_permanent_burn flag: the on-chain permanent AKT-burn counter reads 0, so 'AKT burned' as usage-driven destruction is not what the vault shows. Separately, card/fiat (AkashML) demand is converted to AKT off-chain via Coinbase (Osuri, 24 Jun 2026) and does not flow through this on-chain loop at all.
Permanent AKT destruction by the burn-and-mint escrow. Our own framing of the AEP-76 vault, not a figure Akash publishes. source →
0 AKT permanently burned (x/bme vault_state.total_burned, denom uakt). Direct Cosmos REST read of vault_state.total_burned for uakt, refreshed by scripts/refresh-primary.ts into meta.primary_data.
Established on-chain Carried as its own row because it is the number every "AKT is being burned" reading of Akash turns on, and it has read zero since BME activated in March 2026. Under AEP-76 net destruction only occurs when AKT appreciates between vault top-up and provider settlement, so a permanent burn is a price outcome, not a usage outcome. Zero is the honest anchor; the moment the counter moves the freshness router raises it, because a first non-zero reading against a zero baseline crosses every band.
ACT compute credit is redeemed by providers rather than accumulating unspent, so the burn-and-mint loop closes. source →
799,299 ACT burned (redeemed) against 968,221 ACT minted since activation, so 82.6% of issued credit has been claimed. Direct Cosmos REST read of vault_state.total_burned and total_minted for uact; the share is the ratio of the two refreshed values.
Established on-chain The mint counter alone would not distinguish a working loop from one issuing credit nobody redeems. Redeemed ACT tracking most of minted ACT is the evidence that providers are actually settling through BME. The residual is credit issued but not yet claimed, which is expected for in-flight leases.
Supply Out of date· 2 checks
AKT issuance is pinned at a maximum 8% annual inflation (Proposal 283, March 2025), with a 50% community pool tax on it. source →
Superseded. The Akash x/mint parameters now read inflation_max 4.0%, inflation_min 3.0%, goal_bonded 67%; live inflation is 4.0% and annual provisions are 11,869,907 AKT against a 296,747,666 AKT total supply. The x/distribution community_tax reads 70%. Governance Proposal 322 (passed 15 May 2026, 55.46M AKT yes vs 0.82M no) executed the change: inflation max 8% -> 4%, min 4% -> 3%, community pool tax 50% -> 70%. Direct Cosmos REST reads of the live mint/distribution parameters, cross-read against the passed governance proposal that set them. Arithmetic check: annual_provisions / total_supply = 4.00%, matching the queried inflation. Ingestion only, verdict human-set.
Out of date on-chain A correction to OUR figure, not to a live Akash claim: Proposal 322 halved the inflation ceiling three months before this check and our review still taught the 8% cap and the 8.94% realised rate. The direction favours the project (issuance roughly halved; ~26.5M AKT of forecast supply removed over 24 months per the proposal), and the raised 70% community tax means stakers now take 30% of a smaller pot: ~3.56M AKT/yr against 91,466,381 AKT bonded is ~3.9% nominal, close to flat in real terms rather than the ~7.3% nominal the review carried. Supply is still formally uncapped. Editorial corrected 2026-08-13; the Supply Dynamics and Revenue Sustainability scores are flagged for the monthly review rather than moved here.
AKT has no hard cap; the 388,539,008 AKT figure is a genesis-schedule target, not a supply ceiling. source →
Confirmed uncapped. On-chain bank supply reads 296,747,666.10 AKT and the x/mint module continues to issue at 4% annually with no cap parameter; nothing in the module enforces 388,539,008. The on-chain figure matches CoinGecko's 296,746,575 total supply to within 0.0004%. Direct Cosmos REST read of the base-denom bank supply (uakt, 6 decimals) via the coldstart cosmos source, cross-checked against the aggregator figure. Verdict human-set.
Verified on-chain A confirming positive: Akash is straight about being uncapped, and the chain agrees. The aggregator 'max supply' of 388.5M is the genesis schedule target and should not be read as a ceiling; at 4% inflation the chain passes it inside a decade.
Revenue Verified
Akash earns protocol revenue as a take rate on compute leases paid by tenants. source →
$1.90M trailing-1y / $5.84M all-time on-chain lease fees (DeFiLlama akash-network adapter) DeFiLlama sums on-chain lease fees paid by users (revenue = AKT burned). Token Terminal lists Akash but exposes no revenue metric.
Verified Cross-checked Windows differ (Messari full-year 2025 vs DeFiLlama trailing-1y to 2026-06), so no precise ratio, but both put Akash protocol revenue in the low single-digit millions per year and the on-chain lease fees confirm it is real. The standout finding is the definitional gap (see flag): the loud '~$5M compute spend' is gross spend, an order above the ~$1-3M/yr the protocol actually earns. Basis corrected 2026-08-17: this was banded on the cumulative all-time total, which only ever rises, so the band could register growth but was structurally incapable of registering decline. Rebased on the trailing year from the same stored response, which can fall. Both legs re-read 2026-08-17. The trailing year has eased slightly against the $2.1M this verdict was authored on, which is a softening rather than a break: the claim is that Akash earns a take rate, and it does.
Thesis verdicts 1 check
Akash's headline on-chain compute spend represents independent third-party tenant demand for its permissionless GPU marketplace. source →
Now enumerated rather than traced. Grouping all 1,454 active leases by payer gives 529 distinct payers and total paid demand of about 11,675 ACT a day, of which the single largest holds 72.5%. That address is akash1scs6vfgwamnnarmsz26yy63244pakvul5rszxs, the wallet the claim names as AkashML, and it is topped up from one custody account (akash1226a4mhmdseh3mz34rslc0ud4pc9k4dwnn2d83) which is itself fed by three upstream accounts, a pattern consistent with a funded corporate tenant. Setting that payer aside leaves about 3,209 ACT a day across the remaining 528. So the shape of the claim reproduces: paid demand is overwhelmingly one payer. Two things it does NOT establish, both stated because the chain is silent on them. Nothing on-chain identifies the custody account as Overclock Labs or AkashML; that attribution rests on the claim's naming, not on our reads. And the second-largest payer (19.9%) receives no MsgSend from that custody account or any other, so it does not share the funding path and there is no basis for folding it in as company-related. Full enumeration of active leases, summing price-per-block by lease.id.owner and converting at a measured block time (5.895s). Funding paths for the top three payers traced through cosmos/tx event queries on transfer.recipient. Lease prices are uact, so daily figures are dollars without touching AKT's price. Attribution of any address to a named company is NOT derived here.
Established on-chain Reconciles the demand-quality thesis, not a single figure. Verdict is 'unverifiable' because the quantitative payload that would move a score (the company/independent split and its price correlation) was NOT reproduced -- but the underlying structure IS on-chain confirmed: named AkashML deployment wallets are genuine heavy compute tenants topped up weekly from a single custody account fed by an exchange-like hub. This SUPPORTS, with wallet-level evidence, the demand-source characterisation already in the review (AkashML managed inference is the demand driver, converted to AKT manually off-chain via Coinbase, settling differently from raw on-chain leases). Flag Returns Sustainability for the monthly review; do NOT adopt the thread's split figures or 43%-treasury framing into editorial without independent verification. UPGRADED 2026-08-17 from unverifiable to established. The row was graded unverifiable because the company-versus-independent split 'could not be reproduced'. It could: every lease names its payer, so the split is a grouping rather than an investigation. Worth remembering as a pattern, since the previous session traced wallets by hand and queried transaction events when the answer sat in one endpoint. CORRECTED 2026-08-17, same day: the first version of this row said that excluding the top TWO payers leaves ~891 ACT/day, 'the same order as the roughly $562/day of independent demand the claim asserted'. That quietly treated payer #2 as company-funded to make our figure meet the claim's. The funding trace does not support it: payer #2 receives no MsgSend from the custody account that tops up payer #1, or from anywhere. The defensible exclusion is one payer, leaving ~3,209 ACT/day, which is several times the claim's independent-demand figure. Concentration is measured; the attribution behind it is not ours.
Measured facts & caveats 2 notes
Three figures co-exist and measure DIFFERENT things; do not conflate them. (1) Lease REVENUE (protocol take): Messari ~$3.15M full-year 2025, ~$1.0M annualised Q1-2026 run-rate. (2) Lease FEES on-chain (DeFiLlama): $1.90M trailing-1y / $5.84M all-time (2026-08-17). (3) Akash self-reported '~$5M Q1-2026 compute spend' is a broader GROSS figure across all categories, NOT protocol lease revenue, and must not be annualised as revenue.
RESOLVED 2026-07-26 (see bme_akt_burned_figure reconciliation). BME 'burn' has TWO layers: (1) 'removed from circulation' -- AKT moved into the BME vault as ACT backing (circulating supply down, NOT destroyed), and (2) 'permanent burn' -- net AKT destroyed ONLY when AKT appreciates between top-up and settlement (fewer AKT reminted to providers than vaulted). Confirmed by Messari's own 'pulled out of circulation / shrinking circulating supply' wording AND the AEP-76 spec ("'Burn' moves AKT into a BME vault module account; circulating supply goes down"). On-chain: permanent burn (total_burned uakt) = 0; the AKT Messari counts sits in the vault (balances 562,506 + remint_credits 262,506, 2026-07-26). Messari's '53,520 AKT burned (31 Mar 2026)' is the layer-1 circulating-supply figure, NOT total-supply destruction. Editorial must not imply permanent destruction.
NEAR Protocol 10 claims 2 corrected 2026-08-04
Infra Out of date
NEAR is secured by a permissionless validator set, with the top 100 producing blocks and chunks. source →
414 validators in the active set at epoch 4660, staking 615,761,399 NEAR (47.2% of total supply), with 100 block-producer seats as documented. Stake is comparatively well spread for an L1: the largest validator holds 6.4%, the top 10 hold 39.7%, and it takes 8 validators to reach a third of stake. Enumerated the full current validator set via RPC and computed stake shares and the >33% Nakamoto coefficient from validator stakes. Ingestion only, verdict human-set.
Out of date on-chain A correction to our own figure, not to a NEAR claim: the 698 we carried counts staking pools rather than the active validator set, which the chain puts at 414. The decentralisation read is the more useful finding, and it is good by L1 standards: a Nakamoto coefficient of 8 is well above the 5 we measured on Akash the same day.
Distribution Editorial
The NEAR Foundation holds a treasury sized by its genesis allocation (Operations 11.4%, Foundation Endowment 5.8%, NEAR Foundation 10%). source →
NOT MEASURABLE from public sources, established rather than assumed. The two nameable Foundation accounts hold 63,965.65 NEAR combined, 0.0049% of the 1.3039B supply. foundation.near holds 869.32 NEAR, has zero staked across all 40 staking pools it has ever delegated to, and has no lockup contract. nf-payments.near holds the rest, mostly 61,881 NEAR staked with one validator. No published disclosure names a Foundation account set, and the majority of the self-reported treasury is fiat held off-chain. Liquid balance, every historically used staking pool queried individually, and the DERIVED lockup account (sha256(owner)[0..40]+'.lockup.near') asserted against get_owner_account_id before being trusted. The derivation is proven by nf-payments, whose lockup resolves and names the right owner.
Editorial on-chain The absence is the finding and it is not neutral: NEAR is the one position we hold, and a treasury of this size sitting in accounts no outsider can name is a governance fact, not a data gap. Recorded as unverifiable rather than unverified because it is a permanent limit under current disclosure: fiat in bank accounts cannot be read from a chain at any effort. What WOULD close it is the Foundation publishing its account set, which several peer foundations do. The review's genesis percentages are now labelled as genesis rather than current holdings.
Open source Verified
NEAR develops its protocol in the open. source →
Confirmed. The github.com/near org carries 289 public repositories; the reference client nearcore is GPL-3.0, 2,610 stars, not archived, and was pushed the same day we ran the check with 484 open issues. Direct GitHub org/repo metadata reads via the coldstart github source. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: copyleft licence, same-day commits, a large public org. Covers the licence and development-activity claim only, not audit coverage. Freshness wired 2026-08-17. Wiring limit, stated so nobody reads more into it than it carries: what is re-measured is the star count, because that is the quantity the verdict states. The failure modes that would actually overturn an open-source verdict are the repo being archived, relicensed, or going quiet, and none of those move stars. They are on the Phase 4 backlog. A star-count band is a prompt to go and look at the repo again, not a check that it is still open.
Accrual Established
The February 2026 Intents fee switch routes a share of settlement fees into NEAR buybacks. source →
$4.56M trailing-1y / all-time protocol-retained Intents revenue; 30d $480,690 (DeFiLlama forward-annualised $5.27M) DeFiLlama summary/fees/near-intents?dataType=dailyRevenue (NEAR's net captured revenue since the Feb-2026 fee switch); DISTINCT from base-chain `near`. Ingested into meta.primary_data by refresh:primary; verdict human-set.
Established Cross-checked The durable buy-pressure slice. We deliberately quote trailing-1y ($4.56M, ~$4.6M) to stay consistent with the page's TTM fee basis, NOT DeFiLlama's forward-annualised $5.27M (30d run-rate x ~11), which overstates because fee-switch revenue is <1y old. Prior editorial figure was ~$4.0M (Jun 2026). Auto-tracked by refresh:primary + check:primary-drift. Freshness wired 2026-08-16: baseline 4,560,000 (trailing-1y protocol-retained Intents revenue at authoring ($4.56M)). Basis corrected 2026-08-17: this was banded on the cumulative all-time total, which only ever rises, so the band could register growth but was structurally incapable of registering decline. Rebased on the trailing year from the same stored response, which can fall.
Supply Overstated· 2 checks
99.99% of NEAR is circulating, with all vesting complete and no remaining overhang.
The two aggregators disagree by ~54.0M NEAR. CoinGecko reports circulating 1,303,818,416 against its OWN total of 1,303,818,394, so its circulating figure exceeds its total and it plainly models no lock-up. NearBlocks reports circulating 1,249,836,992 of 1,303,845,705, i.e. 95.86% circulating and 54,008,711 NEAR non-circulating. Chain total supply confirmed on two independent RPC endpoints. Read total supply from the chain, then compared each aggregator's circulating basis against it and against itself.
Overstated on-chain ATTRIBUTION: none-published. NEAR does not claim 99.99% circulating; we did, by restating CoinGecko. The claim-source audit caught the first draft of this row citing CoinGecko as the claim source while also using it as an independent source, which is the [S] = [D] error rule 30 exists to prevent. Our error and a flattering one, which is the pattern the holdings rule exists for: on the single project we hold, the unchecked source was the one that made supply look cleanest. CoinGecko failing its own internal self-check (circulating > total) is exactly rule 30's test, and it was never run. Neither basis is asserted as correct here; what is established is that 99.99% is unsupported and that ~4% of supply sits with a holder nobody has identified, which connects to the foundation_treasury row above. Supply Dynamics flagged for the September review.
Validator rewards are set so that, annualised, they equal 2.5% of total supply. source →
The documented rate is confirmed and the treasury split is not. The live protocol config returns max_inflation_rate = 1/40 (2.5%) at protocol version 86, matching the docs exactly. It also returns protocol_reward_rate = 0/1, so the protocol treasury now takes nothing and stakers receive the whole 2.5%; our review's 90/10 split is superseded. Total supply reads 1,303,466,759.24 NEAR from the finalised block header, matching CoinGecko's 1,303,466,786 to seven significant figures. Direct RPC reads of the live protocol config and the finalised block header, repeated across three unaffiliated endpoints to rule out a single-provider artefact. Ingestion only, verdict human-set.
Verified on-chain The claim NEAR publishes is the one the chain enforces, which is the point of the check. The correction here is to our own page: the 10% protocol-treasury slice no longer exists on-chain, so stakers take the full 2.5%. At 615.8M NEAR staked (47.2% of supply) that is roughly 5.3% nominal before validator commission.
Revenue Verified· 4 checks
NEAR earns protocol revenue from base-chain gas, of which 70% is burnt. source →
$1.49M trailing-1y / $17.97M all-time protocol revenue (August 2026 read, down from $2.0M trailing-1y in June). Chain TVL is carried separately and was itself corrected this month. DeFiLlama summary/fees/near?dataType=dailyRevenue (dimension adapter); chain TVL via /v2/chains. Ingestion only, verdict human-set.
Established Cross-checked Independent on-chain anchor established where we record no NEAR protocol-revenue claim. DeFiLlama snapshot 2026-06-09: trailing-1y $1,995,116; all-time $17,892,926; Near chain TVL $155,263,835. Not a verification of a project figure. CROSS-CONFIRMED: Token Terminal Revenue 3y-sum $17.7M matches the DeFiLlama all-time $17.9M to ~1% (TT Revenue = NEAR burnt + Near Intents fee-switch). Freshness wired 2026-08-16: baseline 17,900,000 (all-time protocol revenue at authoring ($17.9M)). Basis corrected 2026-08-17: this was banded on the cumulative all-time total, which only ever rises, so the band could register growth but was structurally incapable of registering decline. Rebased on the trailing year from the same stored response, which can fall. REFRESHED 2026-08-17: refreshed onto the August 2026 read; the review quotes the Intents figures rather than this one, so no editorial number went stale.
Value locked in DeFi on NEAR. Our own framing; the project publishes no chain-TVL claim.
$54.6M to $92.5M depending on the day read: DeFiLlama's Near series flapped across 15-19 August 2026 (see freshness_paused). The $92,732,035 trailing-7d median stored on 2026-08-17 sat in the high state and should not be quoted as a point estimate. DeFiLlama chain-TVL, refreshed by scripts/refresh-primary.ts into meta.primary_data. The stored figure is the trailing-7d median of the chain's own daily series. That was chosen against one- and two-day dropouts and does NOT survive the sustained flap seen from 15 August 2026, where three of five days read low: a median then reports whichever state dominates the window rather than the truth. Freshness banding is paused on this row until the adapter settles.
Established Cross-checked Recorded with its limit stated. This is DeFi capital sitting on NEAR, not intents volume and not AI activity, so it does not speak to the thesis this review rates; the revenue rows beside it do. It is carried because it is the one measure of on-chain capital at risk on the chain, and because a reader who sees a TVL number elsewhere should be able to find ours and see what basis it is on. OYM holds NEAR, which is a reason to keep this anchor measured rather than asserted. CORRECTED 2026-08-17: this anchor carried $53,662,628, a DeFiLlama index dropout captured on 16 August and accepted after a re-read of the same endpoint agreed with itself. A source cannot corroborate itself: the chain's own daily series shows 15-16 August as the only sub-90M days in a 92-94M band, so the figure understated NEAR TVL by 42% for a day. The read is now a trailing-7d median, which returns the right answer on this incident and on the 4 August one before it.
NEAR's own revenue dashboard reports $500.0K net protocol revenue over the trailing 30 days. source →
Confirmed on the net figure. Summing the two independent DeFiLlama adapters for the same window gives $518,859 of 30-day revenue ($489,013 Intents protocol revenue + $29,846 base-chain revenue), 2.2% above NEAR's published $500.0K. The gross figure does not tie as cleanly: NEAR publishes $2.39M against DeFiLlama's $2.74M of 30-day Intents gross fees, a 12.8% gap that is a basis difference, not a discrepancy we have resolved. Compared NEAR's published dashboard tile against the sum of two independent adapters over the same 30-day window. The dashboard tile is rounded to $500.0K, so treat its precision as plus or minus $500. Ingestion via refresh:primary; verdict human-set.
Verified Cross-checked A confirming positive, and a rare one: NEAR publishes a revenue dashboard and the number on it survives an independent check. The net figure ties to within 2.2% of two open-source adapters. The gross figure sits 12.8% below DeFiLlama's, which is worth resolving before either gross number is cited, and is why we quote the net. ATTRIBUTION NOTE 2026-08-13: revenue.near.org states in its own footer that the figures are 'Pulled directly from onchain sources, including the NEAR Intents smart contract' and then, separately, that 'Figures shown are illustrative'. A project hedging its own published revenue page is worth recording: it is why we reconcile the net figure against two independent DeFiLlama adapters rather than resting on the dashboard.
NEAR Intents generates cross-chain settlement fees at scale. source →
$40.39M trailing-1y / $40.76M all-time gross Intents fees; 30d $2.92M DeFiLlama summary/fees/near-intents?dataType=dailyFees (Intents Verifier contract across chains); DISTINCT from base-chain `near` gas fees. Ingested into meta.primary_data by refresh:primary; verdict human-set.
Established Cross-checked Independent on-chain anchor for the Intents fee-switch flow. Our ~$40.4M editorial annualised-run-rate figure equals DeFiLlama near-intents total1y ($40,385,821) to <1%; verified first-hand on the near-intents Fees tab 2026-08-04 (cumulative volume $24.42B, 30d fees $2.92M). primary_data.value stores totalAllTime ($40,759,941); auto-tracked by refresh:primary + check:primary-drift. Freshness wired 2026-08-16: baseline 40,760,000 (all-time gross Intents fees at authoring ($40.76M)). Basis corrected 2026-08-17: this was banded on the cumulative all-time total, which only ever rises, so the band could register growth but was structurally incapable of registering decline. Rebased on the trailing year from the same stored response, which can fall.
io.net 9 claims 2 corrected 2026-08-13
Infra Overstated· 2 checks
io.net operates a large distributed fleet of supplier devices. source →
— Not checked. Supplier hardware is off-chain, so there is no chain to rebuild it from; the only independent measurement we have of io.net's fleet is Messari's Q1 2025 verified active-GPU count, which is the anchor used by the active_gpus verdict and is now too old to speak to the current registered total.
Check pending Editorial The companion to active_gpus, which judges the marketed headline. This row records the registered-versus-active split from the same self-reported endpoint. The active share matters because supply-side marketing counts registration while a buyer can only rent what is online.
io.net offers instant access to 30,000+ GPUs across 130+ countries. source →
6,720 daily-average verified active GPUs (Messari, Q1 2025, the most recent independent measurement). io.net's own inventory API contradicts the current headline on the same day we read it: 2,447 devices total and 1,199 active, against 30,000+ marketed. The inventory is listed per GPU class and is dominated by single-card units (709 RTX 4090, 584 H100 80G PCIe spot, 512 H100 80GB HBM3); only 128 of the 2,447 devices are NVLink, SXM or DGX class, so the device count cannot be reconciled to 30,000 GPUs by multi-GPU hosts. Independent anchor = Messari's verified active-GPU measurement (Q1 2025). Corroborated current by reading io.net's own io-explorer inventory endpoint and its per-hardware breakdown directly (2026-08-13), which is self-reported and therefore used as a self-contradiction rather than as the independent leg. Active-GPU reality is off-chain and cannot be rebuilt from a chain.
Overstated Cross-checked io.net does not have one headline to check, it has two, and they differ by more than 10x on adjacent pages. Against the lower figure their own explorer is ~12x short; against the higher one, ~130x. Either way the gap is not a rounding difference. CORRECTION 2026-08-13: an earlier version of this verdict, authored the same day, credited io.net with cutting its headline from 327,000 to 30,000+. That was wrong. The 320,000+ figure is still published on /cloud, so this is inconsistency rather than a correction on their part, and the credit was not deserved. Per the independence rule the explorer is self-reported (Messari remains the independent anchor); as a self-contradiction it is highly defensible.
Distribution Established
No published concentration claim; the tokenomics page states the allocation split only. source →
The top 10 IO token accounts hold 58.82% of the 798,213,540 total supply, and all 10 owners are now labelled: 30.46% in two Squads multisig vaults Solscan names 'ocean foundation', 13.71% in the project's distribution and vesting apparatus, and 14.64% in exchange custody (2026-08-14). Read the 10 largest token accounts, resolved each to its owner, then classified every owner three ways: ed25519 curve membership (off-curve means no private key, so a program-derived address rather than a wallet), the programs its transaction history touches (SQDS4ep… identifies a Squads multisig vault, magnaSHy… the Magna vesting programme), and the source of its inbound IO traced one hop up. Explorer labels are attributed to Solscan, never inferred from an address prefix. Ingestion only, verdict human-set.
Established on-chain The 2026-08-13 read was left unclassified on the assumption that excluding infrastructure accounts would move the figure a long way. Labelling every owner shows it moves less than that, and what remains is project-side rather than public float. Exchange custody accounts for 14.64%: Binance 10 and Binance 3 per Solscan, plus two Coinbase-associated accounts, one funded directly by Coinbase-labelled hot wallets and one funded by Coinbase 5 and topped up from a single unlabelled hot wallet. Strip those out and 44.17% of total supply is still project-held, split between the two 'ocean foundation' Squads vaults (30.46%) and the distribution apparatus (13.71%): the Magna vesting PDA, a Squads multisig drawing a fixed 2,376,973 IO on the 11th of each month, and two wallets created on 2026-07-15 by durable-nonce operator signing, the larger of which now pays that monthly instalment and traces up to the Squads vault that seeded its operator with 85.57M IO in July 2024. That is consistent with the 5/15 distribution-fairness score, so the labelling sharpens the evidence rather than moving the grade.
Censorship Established
The IO token can be frozen by a central authority (token-layer custody surface). source →
The IO SPL mint has freezeAuthority = NULL: no authority can freeze an IO token account, so there is no token-layer censorship lever. Combined with the null mint authority the token is immutable at the SPL layer. Direct keyless Solana RPC read of the mint account's authority fields. Ingestion only, verdict human-set.
Established on-chain Speaks to the token only. It says nothing about censorship at the layer that matters most for io.net, which is whether the company can refuse or remove a workload or a supplier from its own orchestration platform. That surface is off-chain and remains unassessed.
Open source Overstated
io.net is an 'Open Source AI Infrastructure Platform'. source →
The platform code is not public. The github.com/ionet-official org carries 9 public repositories, and none of them is the orchestration stack: they are a setup script, a launch BINARIES repo (75 stars, no licence), a docs site, a chatbot, an attestation API and demo apps. Only three carry any licence at all (MIT, MIT, Apache-2.0). A reader who takes the tagline at face value cannot inspect, audit or self-host what io.net actually runs. Enumerated every public repository in the org with its licence, star count and description, and checked io.net's own docs for a source repository. Ingestion only, verdict human-set.
Overstated Cross-checked Graded against the tagline as a reader would read it, and we should say what the charitable reading is: io.net's own meta description pairs the phrase with 'leading open source models', so the words may be intended to describe the MODELS it serves rather than its own code. That reading is not available from the hero heading alone. Publishing the orchestration and scheduling stack would flip this to match; distributing binaries does not. Attribution note: the homepage URL is deliberate and the claim-source audit's bare-domain warning on it is expected. The claim IS the homepage title ('The Open Source AI Infrastructure Platform - io.net', also og:title and twitter:title); there is no deeper page to cite because the tagline is the page. Do not 'fix' this by pointing it at a docs page that says something else.
Supply Check pending· 3 checks
IO's circulating supply is 168.77M (21.1% of max). source →
381.48M circulating (47.7% of the 800M max) per CoinGecko, August 2026. The 298.34M figure this row carried was a June read; the aggregators that disagreed then (CryptoRank 168.77M) are further out now, and the review itself quotes no fixed number, binding the live figure into the fact strip instead. second aggregator; not a chain computation
Editorial Editorial Two aggregators disagree on circulating supply (~77% spread) due to different locked/vesting treatment. Aggregator-vs-aggregator disagreement is contested, not reconciled; verdict is unverifiable per the independence rule, not inflated. STALE, flagged 2026-08-17 without re-authoring: both legs of this row date from June 2026 and our own circulating-supply refresher read 381.48M (47.69% of max) on 2026-08-15, roughly 28% above the 298.34M recorded here as the independent leg. The verdict stays unverifiable because every figure in play is an aggregator restating the project, not because the number is current. Re-author against the refresher and wire it. REFRESHED 2026-08-17: refreshed onto the August 2026 read; the review carries this figure as a live binding, so no editorial number went stale.
IO is burned as clients pay for compute, offsetting supplier rewards. source →
— Not checked. IO is an SPL token, so a burn that reached the token would show as a reduction in Solana total supply; reconstructing the burn series from Solana history would settle it. We have no such index. Deliberately not wired for auto-evaluation: the only refreshing feed for this figure is io.net's own endpoint, so banding it would compare a reported number against itself and read out as a match.
Check pending Editorial The scale question is what the burn is set against. The same endpoint reported 6,514,485 IO in cumulative epoch rewards when read on 2026-08-16, so on io.net's own accounting roughly three and a half tokens are paid out for every one burned. Both sides come from the same self-reported surface, so this is not evidence the burn reached the token, only that io.net does not claim it outweighs emissions. The figure is labelled "overall_total_burn" and is cumulative, so it only ratchets upward.
IO has a fixed maximum supply of 800 million tokens. source →
Confirmed fixed and enforced at the token layer. getTokenSupply on the IO SPL mint (BZLbGTNCSFfoth2GYDtwr7e4imWzpR5jqcUuGEwr646K, 8 decimals) returns 798,538,520.02 IO, just under the 800M headline and matching the CoinGecko total exactly. getAccountInfo shows mintAuthority = NULL, so no key can issue further IO; the only direction supply can move is down, through the burn side of the IDE reward loop. Direct keyless Solana RPC reads of the SPL mint account. The null mint authority is the on-chain proof that the cap is enforced by the token itself rather than by policy. Ingestion only, verdict human-set.
Verified on-chain A confirming positive on the token layer, and it sits oddly beside the GPU-count finding: the supply claim is one of the few io.net numbers a reader can check in a single RPC call. The 1.46M gap to the 800M headline is consistent with cumulative IDE burns (1,205,710 IO on io.net's own epoch summary), which we have not tied out transaction by transaction. BURN OBSERVED 2026-08-17: the supply read has fallen from 798,538,520.02 (12 August) to 798,178,410.00, a drop of 360,110 IO in five days. With mintAuthority null the only direction supply can move is down, so this is direct evidence that burning reaches the token, which is the question the burn-ledger row could not answer from io.net's own feed. It does NOT reconcile the reported cumulative burn: 360K in five days is a large fraction of the 1.82M io.net reports all-time, so either burns have accelerated sharply or the two figures are measuring different things. Wiring the supply read is what makes that gap visible; closing it needs the SPL supply-history index.
Revenue Check pending
Clients pay for io.net compute, and that spend is denominated in IO. source →
— Not checked. DeFiLlama carries no fees or revenue adapter for io.net, so there is no independent aggregator leg; a Solana index of payments into the deployment-engine accounts would be the check.
Check pending Editorial This is the closest thing io.net publishes to a revenue figure, and it is token-denominated rather than dollar-denominated, so it moves with the IO price as well as with demand. It is carried as a reported figure only. Note the units: purchased IO is client spend, not protocol take.
Render Network 9 claims 2 corrected 2026-06-13
Infra Editorial
The Foundation approves all node operators and can remove them. source →
No on-chain artefact exists. Both of Render's non-token Solana programmes were enumerated exhaustively (45 accounts): 32 per-epoch emission receipts, 1 emission schedule, 1 emission distributor, 4 mint circuit breakers, 5 account circuit breakers, 3 Anchor IDL accounts. Zero operator or node-registry accounts. Network::NodeOperators exists only as an emission-distribution bucket, not as a set of operators. Every account owned by either programme classified by Anchor discriminator against the programmes' own on-chain IDLs. An operator registry would have to be one of them.
Editorial on-chain PRIMARY SOURCE READ 2026-08-17, and it is narrower than our prose was. The docs describe an interest form (renderfoundation.com/gpu) feeding an on-boarding QUEUE handled by 'The Render Network Team'. They state no approval criteria and no removal power, so the review's earlier 'Foundation controls who participates and can remove operators' went beyond the source on the removal half; that clause is now cut. The absence is the finding and it cuts against Render, not for it: approval, refusal and removal all happen inside OTOY's systems with nothing a third party can audit, so the permissioned claim can only ever be Render's own. Recorded as unverifiable rather than contradicted, because nothing here disputes that approval happens; what is established is that it cannot be checked. Prose was corrected from asserting the behaviour flatly to attributing it and stating the absence.
Governance Established
Render governs through a decentralised RNP framework led by the Render Network Foundation, in which any community member can submit and vote on proposals; approved RNPs are 'incorporated into the Render Network's development roadmap and implemented by core Render Network contributors'. source →
The vote is real and the execution layer is a multisig with no timelock. The two programs holding RENDER's mint and freeze authority are both upgradeable and both name the same upgrade authority (7CVt936gVDXfKeXdRs5xcWVkrEaYGMTV3HA2K7j4Bqa7), which is a Squads multisig vault: System-Program-owned and dataless, but OFF-CURVE, so no single private key controls it (Solscan: 'Squad Vault "render"', #Squad Vault; history is vaultTransactionExecute). There is no on-chain delay between a decision and a change. Render's own framing is consistent with this: they say core contributors implement, not that execution is trustless. What is absent is any disclosure of who holds the multisig, its threshold, or the controls around it, so the gap is between a documented community vote and an undocumented execution key set. npm run watch:control-surface program probe: program -> programData -> upgrade authority -> account-shape classification by ed25519 curve membership. Multisig identification attributed to Solscan's label. Ingestion only, verdict human-set.
Established on-chain Graded established, not inflated: Render does not claim trustless execution, so grading this as an overstatement would test a claim they never made (the same error corrected on Giza on 2026-08-13). It is recorded because it is the missing technical half of a governance story the docs tell only socially, and because the 8/20 governance score rested on process evidence (proposal counts, turnout) with nothing on the execution layer. Score unchanged; the existing 8/20 already reflects heavy Foundation influence. CORRECTED 2026-08-14: the authority was first recorded as a single keypair and is a Squads multisig, which is materially better than first stated. The finding that survives is the absence of a timelock and of any published disclosure of the signer set. Flagged for the monthly review rather than moved.
Censorship Established
The RENDER token can be frozen by a central authority (token-layer custody surface). source →
The RENDER SPL mint has freezeAuthority = SET, to a PDA of program distZXJ5FYrPhjBhB5P2BQ9B2AsPzJ4TcUSz6hKssP1, and mintAuthority = SET, to a PDA of program circiqFCstNzaFBji1udQ6txgQBrn29pVSYHNJQo3wZ. So the token carries a live freeze lever. Followed one step further (2026-08-13): BOTH programs are upgradeable (BPFLoaderUpgradeable, upgrade authority present, not frozen), and both name the SAME upgrade authority, 7CVt936gVDXfKeXdRs5xcWVkrEaYGMTV3HA2K7j4Bqa7. CORRECTED 2026-08-14: that authority is a SQUADS MULTISIG VAULT, not a single keypair. It is System-Program-owned with no data, which is why an owner-and-size read mistook it for a wallet, but it is OFF-CURVE (no private key can exist for it), Solscan labels it 'Squad Vault "render"' with a #Squad Vault tag, and its history is vaultTransactionExecute calls. So 'program-controlled' still does not mean autonomous (the programs remain upgradeable, with no timelock), but replacing them requires the multisig's threshold, not one signature. This is the only one of the four assessed Solana natives (NOS/GRASS/AI16Z/RENDER) with a live freeze authority. Four-hop read: mint -> authority PDA -> owning program -> programData upgrade authority -> authority account shape. Shape now tested by ed25519 CURVE MEMBERSHIP, not owner+size: a Squads vault is System-owned and dataless exactly like a wallet, and only the off-curve test separates them. Automated by npm run watch:control-surface; multisig label attributed to Solscan.
Established on-chain An on-chain custody anchor and a genuine lever: a live (program-controlled) freeze authority means RENDER accounts can be frozen at the SPL layer. Orthogonal to the review's censorship score, but a real token-layer fact. Surfaced by the WS3 T2 Solana source. DEEPENED 2026-08-13: the earlier wording ('a program-controlled PDA') understated the surface, since it implies autonomous code. Both controlling programs remain upgradeable by a single keypair with no timelock, so the freeze and mint levers are one signature from arbitrary change. On-chain this is one signer; how that key is custodied off-chain (HSM, MPC, shared control) is not observable and is not claimed either way. Both programs are now on the control-surface watch list.
Open source Established
Render develops its core rendering software in the open. source →
Largely CLOSED. The github.com/rendernetwork org has only 4 public repositories, and they are governance/tooling (RNPs = Render Network Proposals, a Cinema4D plugin, an advent ToS), not the rendering engine. The core render engine is OTOY's proprietary Octane software, which is not public. So the value-producing code cannot be independently audited. Direct GitHub org/repo enumeration. Ingestion only, verdict human-set.
Established Cross-checked Confirms the mostly-closed reality: only governance proposals + plugins are public; the core renderer is proprietary OTOY software. Surfaced by the WS3 coldstart run.
Supply Overstated· 4 checks
Emissions are perpetual: outflows must continue in some capacity indefinitely, and the schedule must be designed such that there is no end to emissions. source →
The DEPLOYED EmissionScheduleV0 on Render's emission_distributor programme carries six steps and the last sets emissions to 0 per epoch from 2028-12-01, stepping down through 380,284/epoch (from 2026-12-01) and 335,544/epoch (from 2027-12-01) first. As deployed, emissions end. Programme identified from its on-chain Anchor IDL (emission_distributor v0.1.0), account matched by Anchor discriminator, layout self-checked by requiring the rndrMint field to equal the RENDER mint before trusting any later offset.
Overstated on-chain VERDICT VOCABULARY NOTE: recorded as `inflated` because the schema carries no `contradicted` verdict and `inflated` is the closest honest fit, the reported duration being longer than the deployed artefact supports. The finding is stronger than a magnitude dispute: the contract sets emissions to ZERO from 2028-12-01 while the proposal says there is no end to them. This is the design-intent-versus-deployed-behaviour trap, and we fell into it: the 2026-08-13 score-log row cited RNP-001 to establish that the supply behaves as disinflationary-not-fixed, which is a behaviour claim sourced to a design document. The contract is the artefact that pays. QUALIFIER THAT MUST TRAVEL WITH THIS: schedule_authority (7CVt936gVDXfKeXdRs5xcWVkrEaYGMTV3HA2K7j4Bqa7, the Squads vault already recorded on token_admin_surface) can call updateEmissionScheduleV0, so the end date is current deployed state, not a guarantee. The finding is that the two disagree, not that emissions are certain to stop. QUOTE VERIFIED AT SOURCE 2026-08-17 via the GitHub contents API on rendernetwork/RNPs RNP-001.md, verbatim: "Perpetual Emissions: Under the Burn-and-Mint Equilibrium, outflows must continue in some capacity indefinitely in order to reward network activity. The schedule must be designed such that there is no end to emissions." claim_source_url points at the docs BME page rather than the RNP file because github.com blob URLs bot-gate to a 404 for non-browser clients and a citation a reader cannot open is worse than one a layer removed.
Year one emissions 9.13M RENDER, year two 5.91M (35% reduction). source →
Both figures reconcile EXACTLY against the deployed contract: 12 epochs x 760,567 = 9.13M and 12 x 492,132 = 5.91M, at a 30-day epoch. But they are the schedule leg only. The receipts show a second burn-rewards mint alongside it (190,141.75/epoch to epoch 14, then 60,000/epoch), so actual issuance is ~6.72M a year, and 23,248,298.50 RENDER has been minted across 32 epochs since 2023-11-19. Summed totalMinted + totalBurnRewardsMinted across every receipt account, matched by Anchor discriminator. Receipts are per-epoch and exhaustive, so this is a direct sum rather than a supply-delta inference.
Understated on-chain Motive-neutral: the published figures are correct for the leg they describe, and the leg they omit is a reward rather than a hidden mint. But an emission headline that leaves out 14% of issuance is understated, and only the receipts show it. Of the 107.4M governance-approved BME inflation pool, 23.25M has been minted; the schedule as deployed spends roughly a third of the pool before it stops.
RENDER migrated to Solana, and the Solana mint now holds the bulk of supply. source →
484,343,683 RENDER on the canonical Solana SPL mint. Live getTokenSupply read scaled from base units, refreshed into meta.primary_data; also an input to the computed cross_chain_total_supply anchor.
Established on-chain Given its own row rather than left as an unnamed input to the cross-chain total, because the per-chain split is the thing that decides which explorer a reader should trust. The Solana leg is the majority; the Ethereum ERC-20 and the Wormhole bridge lock are the other two legs of the computed total. Judging only the sum would hide a divergence in one leg.
RENDER has a fixed/disinflationary supply. source →
The canonical Solana RENDER SPL mint (rndrizKT3MK1iimdxRdWabcF7Zg7AR5T4nud4EkHBof, 8 decimals) reads 484,352,722.34 RENDER on-chain, a COMPONENT of the CoinGecko cross-chain total 533,532,274.56 (the ~49M difference is legacy RNDR still un-migrated on Ethereum; max 644M). mintAuthority is SET to a program-controlled PDA (owner program circiqFCstNzaFBji1udQ6txgQBrn29pVSYHNJQo3wZ), consistent with Render's on-chain Burn-Mint-Equilibrium: new RENDER is minted programmatically, so supply is emission-driven, not a fixed cap. Manual SPL reads via the coldstart Solana source + mint-authority owner-classification. Ingestion only, verdict human-set.
Established on-chain The Solana leg is the canonical home of a still-migrating multichain token; supply is minted by a program (BME), not fixed. Complements the existing computed cross-chain total anchor with the mint-mechanics dimension. Surfaced by the WS3 T2 Solana source. ATTRIBUTION 2026-08-13: Render's own RNP-001 contradicts any reading of the supply as fixed - 'Perpetual Emissions: Under the Burn-and-Mint Equilibrium, outflows must continue in some capacity indefinitely... The schedule must be designed such that there is no end to emissions.' The burn-mint page supports disinflationary, not fixed.
Measured facts & caveats 2 notes
Revenue is not disclosed; a previously-asserted ~$1M (burn-derived) figure and 696x P/Revenue ratio were a fabrication, removed May 2026 and now guarded by check-revenue-consistency. No revenue figure may be asserted.
Encrypted transport for creator assets is claimed but not independently verified.
Vana 8 claims 2 corrected 2026-08-12
Governance Overstated
The Vana Foundation stewards the protocol but does not control the network; governance decentralises progressively. source →
Stage G0 across the whole core stack. All eight core contracts are UUPS proxies (EIP-1967 admin slot zero) and every one of them names the same 3-of-7 Safe (0x5eca5208f29e32879a711467916965b2d753baf4) as DEFAULT_ADMIN_ROLE, which is the sole gate on _authorizeUpgrade. There is no timelock anywhere in that path and no on-chain governance contract executes through it. A second 3-of-7 Safe (0xe6a285b08e2745ec75ed70e4fe41e61b390bbb86) holds MAINTAINER_ROLE (pause, parameter and trusted-forwarder updates) and shares five of seven signers with the first, so the two Safes are not separation of duties: the same three shared signers can act on both. Signer identities are not published. Read on Vana L1 (chainId 1480) via rpc.vana.org, 2026-08-16. For each of the eight core proxies: EIP-1967 implementation and admin slots (admin slot zero on all eight, so UUPS rather than transparent); RoleGranted logs from deployment via the Vanascan Blockscout API to enumerate candidate role holders, each then confirmed live with hasRole(DEFAULT_ADMIN_ROLE) and hasRole(MAINTAINER_ROLE) rather than trusted from the log; every holder classified by codesize plus getThreshold()/getOwners()/VERSION(). Ingestion only, verdict human-set. Scope-matched deliberately: the claim is about the network, so all eight core contracts were enumerated rather than one, per the verdict spec's scope-matching rule.
Overstated on-chain Graded against the governance ladder in specs/oym-verdict-framework-spec.md 4a. Instant unilateral upgrade authority over the fund- and permission-holding contracts is G0, so the 'does not control the network' framing is inflated today, whatever the roadmap says. Consistent with the existing 8/20 score, so no score change is proposed; the verdict supplies the evidence the score previously lacked. Unpublished signer identities cap the multisig at its stage and never raise it.
Censorship Established
Permission grants are recorded on-chain and cannot be tampered with; data revocation takes immediate effect. source →
True today, conditional in the contract. revokePermission and revokePermissionWithSignature both carry the whenNotPaused modifier in the verified deployed implementation (0x1473d4c66e230fd7f8c3e48a4dfc026e259c1edf), and pause() is gated on MAINTAINER_ROLE, held by a 3-of-7 Safe. Three signatures suspend a user's ability to withdraw consent, for as long as the pause stands. paused() returned false on all eight core contracts when read, so the immediate-effect claim holds in the live state; the authority to suspend it exists and sits off the user's side. Read the modifier on both revoke entry points from the verified source of the currently pointed-to implementation, resolved the pause() role gate, resolved the role holder to a Safe by getThreshold()/getOwners(), then read paused() live on every core contract. Verdict human-set.
Established on-chain Recorded as a finding rather than a correction: the claim describes the live state accurately, and a pause path is ordinary engineering practice. What it is not is unconditional. The check that would settle whether this ever bites is monitoring paused() on the permissions contract; a caller-side reader can already do that.
Data Overstated· 2 checks
Only the data owner can create or revoke a permission grant; no other party can modify one. source →
Confirmed on the deployed contract. The source-verified DataPortabilityPermissions implementation (0x1473d4c66e230fd7f8c3e48a4dfc026e259c1edf, solc 0.8.24, verified on Vanascan) gates both paths on the signer: _addPermission reverts NotFileOwner(fileOwner, signer) unless the signer owns the file being shared, and _revokePermission reverts NotPermissionGrantor(permissionData.grantor, signer) unless the signer is the account that granted it. Neither path carries a role-gated or admin override. The contract is live and used: permissionsCount() returns 136,856 grants, and revocations are exercised (at least 1,000 PermissionRevoked events, where the explorer API caps the result set). Pulled the verified source of the implementation the proxy currently points at (EIP-1967 implementation slot), not the GitHub repo, so the gating read is against deployed bytecode's verified source. Located the two revert conditions by line and read the surrounding function bodies. Grant count read live. Verdict human-set.
Verified on-chain A confirming positive, and the narrow claim is exactly right: within the logic that is deployed today, consent really is owner-gated with no back door. The separate, broader claim about who controls that logic is verdicted below and does not hold.
Consent is enforced by the chain, not by any central party; nobody, not even Vana core contributors, can modify data permissions. source →
Not supported as stated. DataPortabilityPermissions is a UUPS proxy whose _authorizeUpgrade is gated only by onlyRole(DEFAULT_ADMIN_ROLE), with no timelock, and that role is held by a single Safe v1.4.1 multisig (0x5eca5208f29e32879a711467916965b2d753baf4) with a threshold of 3 of 7. Three signatures replace the permission logic instantly, with no on-chain notice and no user exit window. This is not theoretical: the implementation behind that proxy has been replaced four times since deployment (Upgraded events at blocks 4131308 on 2025-07-24, 4426010, 4456355, 4525757 and 5363667 on 2025-10-17), and DataRegistry has been upgraded eight times, most recently at block 6519234 on 2026-01-05. Separately, both addPermission and revokePermission carry whenNotPaused, and pause() is gated on MAINTAINER_ROLE, held by a second 3-of-7 Safe (0xe6a285b08e2745ec75ed70e4fe41e61b390bbb86) that shares five of its seven signers with the admin Safe. All eight core contracts were unpaused at the time of reading. Read on Vana L1 (chainId 1480) via rpc.vana.org, 2026-08-16. For each of the eight core proxies: EIP-1967 implementation and admin slots (admin slot zero on all eight, so UUPS rather than transparent); RoleGranted logs from deployment via the Vanascan Blockscout API to enumerate candidate role holders, each then confirmed live with hasRole(DEFAULT_ADMIN_ROLE) and hasRole(MAINTAINER_ROLE) rather than trusted from the log; every holder classified by codesize plus getThreshold()/getOwners()/VERSION(). Ingestion only, verdict human-set.
Overstated on-chain The engineering is good and the narrow owner-gating claim above holds; what fails is the absolute. A central party does control what the chain enforces, and has exercised that control repeatedly. The Vana L1 docs page carrying the claim does not mention upgradeability, the admin role or the pause path at all. Path to match: put DEFAULT_ADMIN_ROLE behind a timelock with a meaningful delay so users get an exit window before the permission logic changes, then narrow the multisig to emergency scope. Freedom data_sovereignty is scored 13/15 on design-level evidence; flagged for the 2026-09-01 monthly review.
Open source Verified
Vana develops its protocol and contracts in the open under permissive licences. source →
Confirmed. The github.com/vana-com org carries 99 public repositories, permissively licensed and actively developed: vana-smart-contracts is Apache-2.0 (19 stars), personal-server is MIT (115 stars), vana-sdk is ISC, all pushed on the assessment date. The data-DAO contracts, SDK and personal-server stack are public. Direct GitHub org/repo metadata reads. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: 99-repo org, Apache-2.0/MIT/ISC across the stack, active. Supply reconciliation stays deferred: VANA's canonical supply is on the Vana L1 (the Ethereum contract holds only ~74K of 120M, a bridge/liquidity wrapper - the L1-wrapper trap), so it needs a Vana-L1 reader.
Revenue Established
Gas paid on the Vana L1. Our own framing; Vana publishes no fee-revenue figure and this is not protocol revenue.
$2,348 in L1 gas fees over the trailing year, against $24,557 cumulative since launch and $145 in the trailing 30 days. DeFiLlama summary/fees/vana (dailyFees), refreshed into meta.primary_data.
Established Cross-checked The definitional point is the whole point of this row. DeFiLlama has no bespoke Vana adapter; the `vana` entry is a chain module, so what it reports is validator-bound gas on the L1, not a take rate on data-DAO activity. Anyone reading it as Vana revenue would be off by a category, not a margin. The figure itself is tiny in absolute terms, which is consistent with a chain whose product runs mostly off it. Basis corrected 2026-08-17: this was banded on the cumulative all-time total, which only ever rises, so the band could register growth but was structurally incapable of registering decline. Rebased on the trailing year from the same stored response, which can fall.
Thesis verdicts 1 check
Vana's value proposition is user-owned data: consent recorded and exercised on-chain rather than in a provider's database. source →
The consent rail carries real traffic. permissionsCount() on 0xD54523048AdD05b4d734aFaE7C68324Ebb7373eF returns 136,856 grants, and revocation is used rather than merely available (at least 1,000 PermissionRevoked events; the explorer API caps the result set, so this is a floor and not a count). For scale context, the Vana L1 itself reports 1,605,807 addresses and 72,141,399 transactions. Live contract read for the grant count; PermissionRevoked topic filter over the contract's full history for the revocation floor. The revocation figure is deliberately stated as a floor because the explorer caps results at 1,000; an exact count needs either a paginated pull or a per-permission status read across all 136,856 records. Verdict human-set.
Established on-chain A confirming positive on the thesis. This is the counterweight to the two control-layer findings: the mechanism is not a demo, it is in use at six figures of grants. It also sharpens why the upgrade authority matters, since 136,856 live grants sit under logic that three signatures can replace.
Measured facts & caveats 1 note
The 1.3M user figure is not fully independently verifiable; on-chain DeFi TVL on the Vana chain is ~$238K (DeFiLlama, 2026-06-25), thin relative to the claimed user base.
Olas 7 claims 1 corrected 2026-06-25
Governance Overstated
Olas is governed by veOLAS holders, with critical decisions executed on-chain through GovernorOLAS and a Timelock. source →
The Timelock is real and the Governor is not in the path. The OLAS token's owner() is the Timelock (0x3C1f...95fE, verified source, named Timelock), which is the good part. But the Timelock's only current PROPOSER and EXECUTOR is a 5-of-9 Gnosis Safe (0x04c0...2570); both GovernorOLAS deployments (0x8e84...b401 and the earlier 0x34c8...3dd5) hold no roles at all, having been granted and later revoked. getMinDelay() returns 0, so anything the Safe proposes can execute immediately. The Timelock is its own admin and the deployer has renounced, so no EOA sits in the path. Traced the token's ownership to the Timelock, enumerated all 17 role grants from genesis, then tested current membership for each role and resolved each surviving holder's contract type. Ingestion only, verdict human-set.
Overstated on-chain Stage G0 on the governance ladder: five signatures out of nine can execute against the token contract with no delay. The documented Governor-through-Timelock route exists in code but carries no live permissions, so veOLAS voting is advisory in practice at this layer. Scope note: this covers the OLAS token's ownership path, not every Olas registry or staking contract. Path to a match: restore PROPOSER to GovernorOLAS, set a non-zero minimum delay, and reduce the Safe to a canceller or emergency role.
Distribution Established
No published concentration claim. source →
14,153 holders. The top 10 hold 75.39% raw and 55.67% excluding labelled infrastructure, with the two largest positions being protocol contracts: the governance Timelock at 14.14% and the buOLAS team-lock contract at 10.42%. Pulled the top holders with contract flags and public labels, classified each as holder/infra/insider, and computed raw and infrastructure-excluded top-10 concentration. Ingestion only, verdict human-set.
Established on-chain Concentrated even after excluding infrastructure: 55.67% in ten addresses puts this in the insider-heavy band on the distribution ladder. Much of it is protocol-owned (the DAO Timelock and the team lock), which is better than ten anonymous whales, though the Timelock position is controlled by the same 5-of-9 Safe in the governance finding. Freshness wired 2026-08-17. The refresher reproduced this verdict's hand-authored figures, which is the check that made wiring safe rather than merely convenient. Caveat carried from the index: the infra-excluded figure rests partly on addresses Blockscout does not label, and a change in how many of those sit in the top ten is a signal to re-trace by hand, not a new measurement.
Open source Verified· 2 checks
Olas maintains an on-chain component registry so software is composable and attributable. source →
328 components registered on the Ethereum L1 Component Registry NFT. Direct totalSupply read of the component registry contract, refreshed into meta.primary_data.
Established on-chain The composability layer the architecture rests on, and it is small: a few hundred components against thousands of registered services. That ratio is the honest read on how much of the stack is genuinely shared code versus services registered against a thin common base.
All core Olas code is open source and the contracts are verified. source →
Confirmed at the contract layer: the OLAS token, the Timelock and both GovernorOLAS deployments all return verified source on Etherscan, which is what let us enumerate the governance roles above. Requested verified source metadata for each contract in the ownership path. Ingestion only, verdict human-set.
Verified on-chain A confirming positive, and it is the reason the governance finding was checkable at all: verified source is what makes a claim about who controls what testable by anyone. This check covers the contracts in the token's ownership path, not the wider agent framework repositories.
Utility Established
Olas hosts a growing registry of autonomous services across chains. source →
4,994 services registered cumulatively, summed across the ServiceRegistry NFT totalSupply on Ethereum L1 and the L2 registries. Sum of totalSupply on the L1 and L2 service registries, refreshed into meta.primary_data.
Established on-chain Cumulative, so it counts registrations rather than live services and can only rise. Read as a registry footprint, not as activity: nothing here says a registered service ever ran. The registered_agents row is the closer proxy for participation.
Supply Verified
OLAS has a 1,000,000,000 ten-year supply cap, with supply growing through bonded emissions. source →
Cap confirmed and enforced in code. The OLAS contract exposes tenYearSupplyCap() = 1,000,000,000 OLAS, totalSupply() = 528,786,477.77 and inflationRemainder() = 471,213,522.23, which sum exactly to the cap. Minting runs through a dedicated minter contract (0xa0da...0f82) and is bounded by an on-chain inflation schedule (inflationControl, maxMintCapFraction = 2), not by policy. Direct RPC reads of the token's own cap and inflation accounting, checked for internal consistency (supply + remainder = cap). Ingestion only, verdict human-set.
Verified on-chain A confirming positive with the arithmetic to back it: 52.9% of the ten-year cap is emitted and the contract itself tracks the remainder. Bonded emissions mean supply keeps growing, so this is a dated anchor for the schedule rather than a fixed-supply claim. CoinGecko's 473.7M total is lower than the chain's 528.8M and should not be used.
Thesis verdicts 1 check
Olas runs a live autonomous-agent economy: more than 600 daily active agents, 14.5M transactions, and 35% of Safe transactions on Gnosis Chain. source →
On-chain Olas registries (as of 2026-06-25): 115 registered agent blueprints, 328 registered components (Ethereum L1), and ~4,624 cumulative registered services across Ethereum/Gnosis/Base/Polygon/Optimism Sum of totalSupply on the registry NFTs. These are CUMULATIVE registered counts (one NFT per registration, never burned), an upper bound, NOT the marketed daily-active-agent population. Ingestion via refresh:primary, verdict human-set.
Established on-chain Establishes the on-chain registry ceiling (cumulative registrations). The "more than 600 daily active agents" and 14.5M-transaction activity claims describe a different, activity-based population not derivable from the cumulative registry, so they remain self-reported and unverified by this anchor. ATTRIBUTION 2026-08-13: olas.network's live counters now read 598 daily active agents and 14,229,341 A2A transactions, and the Safe share is published as a Gnosis co-founder quote saying agents make 'over 75% of Safe transactions on Gnosis Chain' on many days, not 35%. Our recorded figures ('>600', 14.5M, 35%) are all slightly off the current published set; refresh them at the monthly review. The registry ceiling this verdict measures is unaffected. Freshness wired 2026-08-16: baseline 115 (registered agent blueprints at authoring).
Ora Protocol 7 claims 4 corrected 2026-06-13
Governance Overstated
The ORA token carries governance utility. source →
No Snapshot space exists for ORA. Querying the Snapshot Hub GraphQL API for ora.eth, oraprotocol.eth and ora-io.eth returns an empty result, and a name search surfaces no ORA space. Snapshot is the default venue for off-chain token-holder voting, so its absence is a meaningful negative for a project whose token is documented as having governance utility. Direct API query for the plausible space identifiers plus a name search. No on-chain governance contract is documented to check instead.
Overstated Cross-checked ORA is the project where an audit-absence claim in our record turned out to be wrong, so an absence claim here was worth checking against a named venue rather than restating. It holds: documented governance utility with no venue in which to exercise it. Inflated rather than established, because the gap is between what the token is said to do and what exists, not merely a measurement we took. The limit: Snapshot is the standard venue, not the only conceivable one, and a governance surface we do not know about would not appear in this query.
Distribution Overstated
Community-first TGE (100% float to the community).
Ethereum ORA top-10 holders = 94.7% raw; infra-excluded (the LayerZero OFT adapter) still 81.4% of supply. 50.1% sits in two Gnosis Safe multisigs (0x8Eb8… 27.1% + 0x5e546… 23.0% — team/treasury/foundation); the funding-trace then resolves the third-largest holder, a 26.3% EOA (0x8520…), to Safe-funded (from:SafeProxy), so it too is insider — lifting insider concentration to ~77%. The launch FLOAT may have been community, but the SUPPLY is ~77% insider-controlled (D0). This answers the score's 'where is the other 83%?'. sources/holders.py: top holders + is_contract + labels, classified holder/insider/infra/cex/burn; Safes counted as insider concentration, the OFT bridge adapter excluded as neutral infra. Concentration = raw balance / total_supply. Ethereum is ORA's canonical chain (OFT); a minority is bridged to spokes.
Overstated on-chain Confirms + quantifies the low 7/15 distribution score. The 'community-first' claim describes the initial float, not the supply. The coldstart holder-source's insider/infra split found 50.1% in two team/treasury Safes; the funding-trace (--trace) then resolved the 26.3% EOA to Safe-funded (team/treasury), lifting insider concentration to ~77% — the earlier re-check on that EOA is now answered. Contrast with OriginTrail, where the same-looking top-10 was mostly neutral bridge/staking infra (D1). Attribution 2026-08-13: ORA has no citable published home for this claim. docs.ora.io no longer resolves (NXDOMAIN), and ora.io has pivoted to an agent-managed-funds product whose /token, /tokenomics, /docs and /blog paths all 404. The '100% of float to the community' wording survives only in third-party press, which we will not cite as the project's own claim, and it sits oddly beside the reported ~$20-23M VC raise. Search exhausted 2026-08-13. The '100% of float to the community' wording is real and traces to ORA's own TGE announcement, but that announcement no longer has a reachable home: docs.ora.io does not resolve, ora.io has pivoted away from the token, mirror.xyz/orablog is bot-gated, and the Wayback captures of the Mirror index render as an empty shell. Decrypt's coverage carries the wording but press is not the project speaking. Left unsourced rather than cited to a secondary source. Freshness wired 2026-08-17. The refresher reproduced this verdict's hand-authored figures, which is the check that made wiring safe rather than merely convenient. Caveat carried from the index: the infra-excluded figure rests partly on addresses Blockscout does not label, and a change in how many of those sit in the top ten is a signal to re-trace by hand, not a new measurement.
Censorship Verified
ORA is a permissionless ERC-20 with no privileged control over holders' balances.
Confirmed at the token layer. The verified source contains no blacklist, no pause modifier, no Ownable and no AccessControl, and the deployed contract reverts on every corresponding call. Nobody can freeze, seize or claw back an ORA balance, and nobody can replace the logic that would allow it, because the contract is not upgradeable. This is a narrower finding than network-level censorship resistance: ORA's inference runs off-chain and is not covered by it. Same runtime probe as the supply verdict, read for the freeze question: absence of pause/blacklist in the verified source, corroborated by reverts on the deployed contract, plus zero EIP-1967 slots to rule out a future upgrade adding them. Scope stated deliberately: this covers the token, not the off-chain inference layer, per the verdict spec's scope-matching rule. Verdict human-set.
Verified on-chain Worth recording because the absence of a freeze function is rarely checked and often assumed. ORA's 9/15 on this dimension is reasoned entirely from the opML AnyTrust model and off-chain inference; the token layer itself is cleaner than that score implies, and the two should be scored as separate scopes at review.
Open source Understated· 2 checks
ORA publishes protocol documentation, a whitepaper and research papers at its documentation site. source →
The documentation host no longer exists. docs.ora.io returns NXDOMAIN from Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1) and Quad9 (9.9.9.9), while ora.io resolves normally from the same resolvers, and Chrome fails to load it. Search engines still index docs.ora.io pages, so published links dead-end. What remains reachable is narrower than documentation: the github.com/ora-io org is live and active (the ora-agent-sdk was pushed 2026-06-24), and the blog moved from mirror.xyz/orablog.eth to paragraph.com/@orablog and still serves, though its most recent post is dated 13 January 2025. Neither carries tokenomics: the live www.ora.io homepage states nothing about supply, allocation, staking or governance, and the blog's launch-methodology post describes f(A.I.)r Launch as a product rather than ORA's own distribution. So the Etherscan-verified contract remains the only reachable first-party publication of ORA's supply. Queried three independent public resolvers for an A record and captured the response status, with a known-good hostname on the same domain as the control, then confirmed the failure in a browser. Separately enumerated the GitHub org and walked the blog's post index to establish what first-party publication survives. Verdict human-set.
Out of date Cross-checked Not a new discovery: the score log already recorded the dead host on 2026-08-13. What is new is the verdict form, the three-resolver confirmation, and the scope check that establishes what does survive. The finding still matters because our open-source evidence credits published documentation and research at 10/15 while the host serving it is gone, and because it explains why the ORA TGE claim sits in the permanently-unsourced set. Same class as Golem's dead yagna repo. Re-check at the 2026-09-01 review in case this is a migration.
ORA publishes third-party security audits of its contracts. source →
Confirmed, and it corrects us rather than ORA. The repository ora-io/audit-report-staking contains ORA_staking-contract_audit_report_2024-07-13.pdf: a Salus Security review of ORA's staking contract at version v5, commit f4ddf14, engagement logged across 21 June to 13 July 2024. It reports 2 high-severity, 3 medium-severity and 6 low-severity issues, with 11 findings marked Resolved, 1 Mitigated and 1 Acknowledged. The audited source sits alongside it in ora-io/staking-contract-audit. The scope is the staking contract only: no published audit was found for the opML or OAO core, and the ORA token contract itself needs none, since it is an unmodified OpenZeppelin ERC20Permit/ERC20Burnable with no admin surface. Enumerated the org's repositories, downloaded the report and extracted its text to read the auditor name, date, contract version, commit and per-severity counts, rather than relying on the repository name. The named-firm-plus-public-report bar in the open-source rubric is met. Verdict human-set.
Understated Cross-checked Our own evidence said 'No audits found despite $23M funding' and used it to hold open_source_transparency at 10/15. A named firm with a public, dated report clears the rubric's audit bar, so the clause was wrong and has been corrected in both the research JSON and ora.mdx. The score is held pending the 2026-09-01 review because the audit covers staking rather than the opML core, which is the part carrying the thesis. Found because Rob pointed at the ora-io org; the lesson is that a project's GitHub org is a publication surface, and 'no audits found' should always be checked against it before it is written down.
Supply Verified
ORA has a fixed total supply of 333,333,333 coins.
Confirmed, and stronger than 'fixed' usually means. The runtime checks are independent of the published source: both EIP-1967 slots read zero, so the token is not behind a proxy and its logic cannot be replaced; owner(), getOwner(), hasRole(), DEFAULT_ADMIN_ROLE(), MINTER_ROLE(), minter() and paused() all revert, so there is no owner, no role admin, no minter and no pause; and totalSupply() returns exactly 333,333,333000000000000000000, matching the TOTAL_SUPPLY constant. The verified source carries no mint function at all: ORACoin is ERC20Permit plus ERC20Burnable, and the only _mint calls are the four in the constructor, closed by assert(totalSupply() == TOTAL_SUPPLY). Supply can fall through burns and cannot rise. Probed the deployed contract for every standard control surface (ownership, role admin, minter, pause) and read both EIP-1967 slots directly, so the immutability finding rests on runtime behaviour rather than on reading the project's own source. The source was then read to confirm no mint path exists and to locate the constructor's four _mint calls. Verdict human-set.
Verified on-chain A confirming positive, and the strongest supply posture in the corpus on the code axis: no cap to raise because there is no mint, and no admin to raise it. Note the split this creates with the distribution verdict on the same project: the supply is beyond anyone's control while roughly 77% of it sits with insiders. Those are different questions and both answers stand.
Gensyn 6 claims 1 corrected 2026-08-12
Censorship Established
The AI (Gensyn) token can be frozen or its issuance controlled by a central admin (token-layer custody surface). source →
The GensynToken transfer layer is PERMISSIONLESS: there is NO pause (paused() reverts), NO per-address blacklist, and NO fee/transfer tax in the implementation (plain ERC20 + Burnable + Votes + Permit). It is an ERC20Votes governance token. The ONLY admin lever is UUPS upgradeability: _authorizeUpgrade is gated to DEFAULT_ADMIN_ROLE, which live is held (un-renounced, no RoleRevoked) by an OpenZeppelin TimelockController (0xb041762ee4efca8f9e33e5f67ec0bcdc4cb1a9e9), i.e. upgrades are subject to a mandatory timelock delay rather than an instant multisig/EOA action. So the token cannot be frozen or censored today, and the one path to changing that (a logic upgrade) is delay-gated. Manual read of the verified implementation (no pause/blacklist/fee; UUPS auth) + live role-holder resolution via getLogs + admin-contract classification. Ingestion only, verdict human-set.
Established on-chain An on-chain custody anchor, not a re-grade. The STRONGEST token-layer posture in the campaign so far: permissionless transfers (like ROBO/COOKIE) PLUS the upgrade lever behind a TimelockController rather than a bare EOA (PHA) or an instant multisig (FET/AUKI). Orthogonal to the review's censorship_resistance score (the compute/network layer). Surfaced by the WS3 coldstart evidence run on the canonical L2 leg.
Open source Verified
Gensyn develops its core software in the open under a permissive licence. source →
Confirmed. The github.com/gensyn-ai org carries 37 public repositories, MIT-licensed and actively developed (gensyn-delphi-skills MIT 15 stars pushed 2026-08-03, gensyn-delphi-sdk MIT, ree 24 stars). The on-chain GensynToken implementation is itself MIT (SPDX header on the Blockscout-verified source). So both the protocol stack and the token contract are permissively licensed and public. Direct GitHub org/repo metadata reads (public_repos, licence, stars, pushed_at) + contract source licence. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: the open-source claim holds (37-repo MIT org + MIT on-chain contract). Surfaced by the WS3 coldstart evidence run.
Utility Overstated
$AI is used for Delphi prediction-market stakes. source →
Delphi stakes and settles in BRIDGED USDC (0x5b32...ddF5). TOKEN() returns that same address on both the DynamicParimutuelGateway and DelphiFactory, and the gateway's TOKEN_DECIMAL_SCALER of 1e12 is consistent with a 6-decimal settlement asset. $AI's only live role in Delphi is as the buyback target. Read the settlement token from both Delphi contracts and required them to agree before recording.
Overstated on-chain Our error, not Gensyn's: the review put 'Delphi market stakes' on the live-utility list. The one shipped product does not use the token, so $AI has no live user-facing utility at all, and what looked like utility is accrual. Token Utility is flagged DOWN for September for exactly the amount the wrong entry was propping up. Recorded as `inflated` because the schema has no `contradicted` verdict; the claim is not overstated in magnitude, it is the wrong asset.
Accrual Verified
Delphi collects trading fees with 70% of the protocol cut permanently burned via buy-and-burn. source →
CONFIRMED at the contract and running. BuybackVault burnBps = 7000 (70%) and executorRewardBps = 100 (1%), unpaused. 14 executeBuyback rounds between 2026-05-01 and 2026-08-11 converted $4,024.76 of USDC fees and burned 111,825.57 $AI, 0.0011% of the cap. The trading fee is NOT a flat 2%: the gateway bounds it per market at 0.5% to 5%. Vault config read by eth_call; every executeBuyback transaction enumerated and its token transfers summed. Two assertions gate the total: burns equal cap-minus-supply exactly, and the burned share equals burnBps after the executor cut (69.30% measured against 69.30% expected).
Verified on-chain Discharges an undischarged hedge: the valueAccrual evidence said 'on-chain burn data not yet independently verified', which named a check nobody had run, and the check was cheap. The mechanism is genuine and the scale is trivial, and both halves have to be quoted together. Value Accrual moves up in September; see the quarterly backlog for the derivation.
Supply Verified
AI (Gensyn) has a fixed 10 billion supply (no inflation). source →
Confirmed on the CANONICAL Gensyn L2 leg (now readable via the mapped gensyn chain, chainid 685689). The GensynToken implementation (behind ERC1967 proxy 0x4e74...bad0, impl GensynToken 0xA18f...Ef16, MIT) mints INITIAL_SUPPLY = 10,000,000,000e18 ONCE in its initializer and exposes NO mint function (mint() reverts on-chain; only the init _mint exists). It is ERC20Burnable, so supply can only DECREASE: live L2 totalSupply = 9,999,888,174 AI (~0.001% burned from the 10B init). The Ethereum leg (~436.5M, a LayerZero OFT held by the GensynTokenOFTAdapter) is a bridged component of this canonical 10B, not additional supply. CAVEAT: the token is a UUPS proxy, so the fixed supply is not immutable at the code level - the DEFAULT_ADMIN_ROLE can upgrade the implementation (e.g. add a mint); that admin is an OpenZeppelin TimelockController (0xb041...a9e9), so any such change is delay-gated, not instantaneous. Manual L2 RPC reads via the coldstart --chain gensyn override + implementation source read (INITIAL_SUPPLY constant, no mint path, UUPS _authorizeUpgrade onlyRole(DEFAULT_ADMIN_ROLE)). Ingestion only, verdict human-set.
Verified on-chain The first reconciliation of Gensyn's CANONICAL supply (prior anchor could only read the ~436.5M Ethereum bridge leg). Fixed-at-init 10B with no mint path and burn-only drift = a confirming match, stronger than FET/AUKI (whose live mint is callable) but with the AUKI/Sentient upgradeability caveat softened by a TimelockController delay. Unblocked by the WS3 T1 gensyn chain mapping + --chain override (specs/oym-coldstart-nonevm-source-layer-spec.md). Attribution 2026-08-13: Gensyn publishes the 10,000,000,000 total but never the words 'fixed' or 'no inflation'. Its MiCA whitepaper is explicit the other way: 'There is no automatic adjustment mechanism for supply adjustments. Governance may, by community vote, authorise fee burns or future emission adjustments within pre-defined protocol limits.' Our claim should not be read as a no-inflation guarantee.
Measured facts & caveats 1 note
Compute revenue is zero and the training-network mainnet has not shipped; on-chain burn data is not yet live (only the Delphi prediction market is active). Pre-revenue.
peaq 6 claims 1 corrected 2026-08-12
Infra Overstated· 2 checks
peaq relies on the work of Validators and Delegators for block production; Validators provide a staking deposit for skin in the game, and only those Validators with enough backing are able to produce blocks. source →
The set is small and the selection is not currently a contest. Session.Validators holds 33 active validators, ParachainStaking.CounterForCandidatePool holds 33 candidates, and MaxSelectedCandidates is 42, so every candidate that exists is selected and the 'only those with enough backing' filter does not bind on anyone today. Stake behind those 33 is concentrated: the largest holds 14.2% of total backing, three reach a third, five reach half, and the top ten hold 74.8%. Skin in the game is thin in the literal sense: TotalCollatorStake splits as 2,264,713 PEAQ posted by validators against 1,222,689,348 PEAQ delegated, so validators put up about 0.18% of the stake standing behind them. Read peaq consensus state directly over the public Substrate RPC (peaq.api.onfinality.io, a third-party provider rather than a peaq-operated endpoint) with state_getStorage against keys built from twox128 pallet/item hashes. No @polkadot tooling was available, so twox128 was implemented from the xxhash64 spec and validated against the published vector twox128('System') == 0x26aa394eea5630e07c48ae0c9558cef7 before any key was trusted. Values SCALE-decoded: Session.Validators and ParachainStaking.TopCandidates as compact-prefixed vectors, TotalCollatorStake as two little-endian u128s, the counters as u32. Ingestion only, verdict human-set.
Established on-chain Closes a gap our own record named rather than measured: the freedom evidence says 'Collator set size and distribution not documented'. It is now documented, at 33 validators with five holding half the stake. Two things keep this from being a harder verdict. peaq is a Polkadot parachain, so this layer governs liveness and transaction inclusion rather than settlement security, which the Relay Chain provides; and 33 producers is not unusual for a parachain. The 0.18% self-bond ratio is the number worth carrying forward, because it means the deposit described as skin in the game is not what secures block production here.
Coretime purchase significantly increases peaq's security and censorship resistance and provides peaq with the highest Nakamoto Coefficients in the industry. source →
Not supported on the layer peaq operates. Taking the Nakamoto coefficient in its usual sense, the smallest number of entities that must collude to control a subsystem, peaq's block production sits at 3: three validators hold a third of total backing and five hold half. That is the lowest figure this corpus has measured for a block-production or voting layer. Measured the same way in the same week, Oasis needs seven entities to reach a third of active escrow, and Flux needs eleven distinct producers to reach half its blocks. The claim is defensible only if it is read as being about the Polkadot Relay Chain's validator set, which peaq buys Coretime from and does not itself operate; peaq's own consensus layer is the one measured here. Read peaq consensus state directly over the public Substrate RPC (peaq.api.onfinality.io, a third-party provider rather than a peaq-operated endpoint) with state_getStorage against keys built from twox128 pallet/item hashes. No @polkadot tooling was available, so twox128 was implemented from the xxhash64 spec and validated against the published vector twox128('System') == 0x26aa394eea5630e07c48ae0c9558cef7 before any key was trusted. Values SCALE-decoded: Session.Validators and ParachainStaking.TopCandidates as compact-prefixed vectors, TotalCollatorStake as two little-endian u128s, the counters as u32. Ingestion only, verdict human-set. The comparison set is our own, measured on the same days by the same definition, which is the only reason a superlative like 'highest in the industry' is checkable at all. It is a floor on the counter-example rather than an industry census: two chains beating the claim is enough to refute 'highest', and no wider survey was run.
Overstated on-chain Graded on the sentence as written, which attaches the superlative to peaq rather than to Polkadot. Read strictly it is a claim about a chain whose own producer set has a Nakamoto coefficient of 3, and two projects in this corpus beat it without looking. The constructive fix is wording: attributing the coefficient to the Relay Chain, and publishing peaq's own producer-set figure alongside it, would be both accurate and still favourable. peaq scores 12/20 on infrastructure; flagged for the 2026-09-01 review.
Open source Verified
peaq develops its parachain node in the open under a permissive licence. source →
Confirmed. The github.com/peaqnetwork org carries 100 public repositories; the core peaq-network-node (the Substrate/Polkadot parachain node) is Apache-2.0, 81 stars, not archived, pushed 2026-07-20. The chain node and pallets are public under a permissive licence. Direct GitHub org/repo metadata reads. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: 100-repo org, Apache-2.0 parachain node, active. Supply reconciliation is deferred: peaq's native PEAQ is a Substrate parachain coin (no ERC-20, no Cosmos LCD), so an independent supply read needs a Subscan key or raw Substrate storage decode - not yet wired.
Revenue Established· 2 checks
Our own framing; peaq publishes no split between chain fees and fees earned by applications on it.
MachineX, the busiest application on peaq, bills roughly $62,000 a year at its current run-rate, down from a peak month of $166,363 in October 2025. That is an order of magnitude more than the chain itself earns in gas, and it accrues to MachineX rather than to PEAQ holders. Trailing-30d fees annualised, with the monthly series read to establish the trend. Kept separate from the chain-gas row on purpose: summing an application's revenue into a chain's fee line is the error that produced the retired combined figure.
Established Cross-checked Added 2026-08-17 when the review's single fee figure was split into its two layers. The point of the split is that these two numbers have different owners.
Value locked in DeFi on peaq. Our own framing; the project publishes no chain-TVL claim.
$568,647 total value locked across peaq chains. DeFiLlama chain-TVL sum, refreshed by scripts/refresh-primary.ts into meta.primary_data.
Established Cross-checked Recorded with its limit stated: DeFi capital on peaq, not DePIN device economics. Deliberately kept separate from the gross_fees row, which reconciles a Token Terminal figure against a DeFiLlama one and must not be conflated with this. Well under a million dollars sits on the chain, which bounds any argument that on-chain financial activity could fund the network.
Measured facts & caveats 1 note
DeFiLlama peaq fee adapter reports $114 all-time gross fees; Token Terminal (Fresh, Jun 10 2026) shows ~$99K all-time. DeFiLlama undercounts peaq by ~850x - do not use it for peaq.
Flux 6 claims 1 corrected 2026-06-13
Infra Overstated· 2 checks
The network has over 10,000 nodes distributed across 66+ countries, operated by more than 560 independent infrastructure providers. source →
The node count is overstated by roughly 39%, and Flux's own two surfaces disagree with each other. The deterministic node list returned by the Flux daemon carries 6,093 nodes (CUMULUS 2,810, STRATUS 1,709, NIMBUS 1,574), and getzelnodecount returns the same 6,093 total. The runonflux.com homepage counter, read at the same time, shows 6,623. The documentation's 'over 10,000' matches neither. The providers half of the claim is a different story and is not contradicted: the 6,093 nodes resolve to 880 distinct payment addresses, which is an upper bound on independent operators (one operator may split across addresses), so 'more than 560' sits comfortably inside what the data allows. Pulled the full deterministic node list, counted rows and tiers, and grouped by payment_address to bound the operator count; cross-read getzelnodecount for an independent tally on the same endpoint family and the public homepage counter for the project's own headline. Both legs of the node-count check are Flux's own surfaces (the daemon API and the runonflux.com counter), so this is graded api and framed as an internal inconsistency in the project's own reporting rather than an independent rebuild. That is the honest description and it is also why the finding is strong: the numbers contradicting the documentation are Flux's. The check that would raise this to onchain-reconciled is running our own Flux daemon and reading the deterministic node list from consensus directly; there is no rpc-pool reuse for this chain family, so it is a medium build, not a cheap one.
Overstated Cross-checked Also corrects us. Our own record carries 7,917 nodes dated 2026-03-06, which was already above the live figure and is now five months stale; the network has shrunk about 23% against that reading and much further against the 14,000-plus peak the same record cites. Flux scores 16/20 on this dimension, the strongest infrastructure score outside the flagships, and it was resting on the documentation's figure. Flagged for the 2026-09-01 review. The constructive fix on Flux's side is simply to point the docs at the live counter.
The global spread of user-operated nodes eliminates single points of failure, with no central data centres. source →
No single point of failure, but meaningfully more concentrated than 'thousands of user-operated nodes' suggests, on all three axes measured. Operators: the largest single payment address runs 423 nodes (6.9% of the network), the top 10 run 28.0%, and 50 addresses run 52.2%, so half the network sits behind fifty payout identities while 397 addresses run exactly one node each. Hosting: the 6,093 nodes sit in 571 distinct /16 IP blocks, but the top 10 blocks hold 31.5% of them. RIPE RDAP registers the two largest commercial blocks to Hetzner Online GmbH (65.108.0.0 and 65.109.0.0, 654 nodes between them) and the single largest block to Stofa AS, a Danish ISP (62.107.0.0, 416 nodes). Block production is the healthiest axis: 232 distinct producers over a 2,880-block window, the largest at 14.55%, and 11 producers needed to reach half the blocks. Concentration computed from the node list by payment address and by IP /16. Network operators were resolved through RIPE RDAP rather than inferred from the address prefix, and are attributed to the registry record rather than asserted. Block-producer concentration read from the explorer's 2,880-block window. The RDAP leg is genuinely independent of Flux; the node list is not. Verdict human-set.
Established Cross-checked Recorded as a measurement, not a refutation: the claim is about eliminating single points of failure and nothing here is a single point. What the numbers qualify is our own wording. Our freedom-score evidence says 'no centralised data centres', and 654 nodes in two Hetzner blocks is a commercial data centre by any ordinary reading, even though the operators are independent of Flux. Fix our phrasing at the review rather than Flux's. ATTRIBUTION REFRESHED 2026-08-17: RIPE RDAP now registers the largest block (62.107.0.0) to Norlys Telco A/S, the Danish group Stofa was folded into; the netname is still DK-STOFANET. The substance is unchanged, one national ISP, but the entity named in this row has moved and the index now reads the registrant organisation rather than the netname.
Censorship Verified
No single entity can shut the Flux network down.
No single point of failure, but meaningfully more concentrated than 'thousands of user-operated nodes' suggests, on all three axes measured. Operators: the largest single payment address runs 423 nodes (6.9% of the network), the top 10 run 28.0%, and 50 addresses run 52.2%, so half the network sits behind fifty payout identities while 397 addresses run exactly one node each. Hosting: the 6,093 nodes sit in 571 distinct /16 IP blocks, but the top 10 blocks hold 31.5% of them. RIPE RDAP registers the two largest commercial blocks to Hetzner Online GmbH (65.108.0.0 and 65.109.0.0, 654 nodes between them) and the single largest block to Stofa AS, a Danish ISP (62.107.0.0, 416 nodes). Block production is the healthiest axis: 232 distinct producers over a 2,880-block window, the largest at 14.55%, and 11 producers needed to reach half the blocks. Concentration computed from the node list by payment address and by IP /16. Network operators were resolved through RIPE RDAP rather than inferred from the address prefix, and are attributed to the registry record rather than asserted. Block-producer concentration read from the explorer's 2,880-block window. The RDAP leg is genuinely independent of Flux; the node list is not. Verdict human-set.
Verified on-chain The same operator and hosting index that judges infrastructure decentralisation answers the censorship question too, and it had never been pointed at this dimension. The claim holds on its own terms: no single entity can stop the network. What the numbers add is the size of the door. Fifty payout addresses run half the nodes and 654 sit in two Hetzner blocks, so a determined actor pressuring hosting providers rather than Flux has far fewer parties to approach than 67 countries suggests. Match with a qualification, not a refutation. ATTRIBUTION REFRESHED 2026-08-17: RIPE RDAP now registers the largest block (62.107.0.0) to Norlys Telco A/S, the Danish group Stofa was folded into; the netname is still DK-STOFANET. The substance is unchanged, one national ISP, but the entity named in this row has moved and the index now reads the registrant organisation rather than the netname.
Open source Verified
Flux develops its node and infrastructure in the open under a copyleft licence. source →
Confirmed. The github.com/RunOnFlux org carries 180 public repositories; the core `flux` node repo is AGPL-3.0, 249 stars, not archived, pushed on the assessment date. The daemon, FluxOS and infrastructure tooling are public under a strong copyleft licence. Direct GitHub org/repo metadata reads. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: 180-repo org, AGPL-3.0 core node, active. Complements the existing circulating_supply reconciliation (already sourced from the Flux chain explorer).
Thesis verdicts 1 check
Flux's value proposition is a working decentralised cloud: real applications deployed across independently operated nodes. source →
The marketplace carries far more than our record credits. The global application registry holds 1,074 specifications, of which 1,018 are unexpired at the current block height (2,865,303), requesting 6,354 instances across 556 distinct application owners. The largest single owner accounts for 244 specifications, so the tail is real but the head is concentrated. Pulled every global application specification and filtered to those whose height plus expire exceeds the current block height, so expired registrations do not inflate the count. Counted requested instances and distinct owners. First-party registry, hence api grade. Verdict human-set.
Established Cross-checked A confirming positive that corrects us in the project's favour, which is the counterweight to the node-count finding above. Our own evidence says '~100 deployed apps limits battle-testing' and uses it to hold down censorship_resistance; the live registry is roughly ten times that. Note the definition carefully before reusing the figure: these are unexpired registrations requesting instances, not confirmed running containers, so it measures demand placed on the network rather than delivered uptime.
Oasis Network 6 claims 1 corrected 2026-06-25
Infra Established
The Oasis consensus layer is secured by a permissionless, stake-weighted validator set. source →
264 registered entities, of which 75 are in the active set. Active escrow concentration: top 1 at 11.1%, top 5 at 30.1%, top 10 at 42.7%, top 20 at 64.6%. Seven entities reach a third of active escrow and fourteen reach half. Named entities lead the set (Colossus, BinanceStaking, Mars Staking), so the largest holders are identifiable rather than anonymous. Pulled all 264 registered validators, filtered to the active set, summed active_balance escrow and computed top-N shares plus the entity counts crossing one third and one half. First-party indexer, hence api grade. Verdict human-set.
Established Cross-checked Recorded as a measurement rather than a correction: the set is genuinely stake-weighted and the top holder sits at 11.1%, which is unremarkable for a proof-of-stake network. The number that matters for a confidentiality chain is seven entities to a third, because a third is the Byzantine threshold. Also a correction owed to ourselves: our freedom-score evidence describes a '120 validator cap' as the limit on censorship resistance, and the active set measured here is 75, well under it. This session did not verify where the 120 comes from, so the cap figure is flagged for the monthly review rather than restated.
Governance Understated· 2 checks
Changes to the network are voted on by node operators, with each entity's voting power proportional to its share of staked and delegated tokens. source →
Confirmed, and the mechanism has been used. The consensus governance module has processed five proposals since 2021, all passed; the most recent (handler consensus240) recorded 69 entity votes, all yes. Voting power is escrow-weighted across an active set of 75 validators drawn from 264 registered entities. That escrow is concentrated: the largest single entity (Colossus) holds 11.1% of active escrow, BinanceStaking 8.2%, the top five 30.1% and the top ten 42.7%; seven entities together reach a third of active escrow and fourteen reach half. Pulled the full proposal list, the vote roll for the most recent proposal, and the active validator set with active_balance escrow, then computed the concentration shares and the entity counts crossing the one-third and one-half marks. Graded api rather than onchain-reconciled deliberately: Nexus is Oasis's own indexer, so it is first-party rather than an independent rebuild. The check that would raise this to onchain-reconciled is a direct consensus-layer gRPC read against grpc.oasis.io, which needs the Oasis SDK and is not on the rpc-pool rail. Verdict human-set.
Verified Cross-checked The claim is about the voting mechanism and the mechanism checks out. What the numbers add is the shape of the electorate rather than a contradiction: five proposals in five years, every one passing unanimously, is a governance rail that works but has never been used to resolve a disagreement. Unanimity is not evidence of a healthy check.
The voting process may initially be done off-chain but will eventually become an on-chain process. source →
The chain is ahead of the page. On-chain governance is live and has been for years: the consensus governance module holds five recorded proposals, the earliest a consensus-parameters update in August 2021 and the most recent the consensus240 upgrade, each with an on-chain vote roll (69 entity votes on consensus240). The documented future state describes something that already shipped. Read the governance module's proposal list and per-proposal vote rolls, checked the handler names and states against the dates. Graded api for the same first-party-indexer reason as the verdict above. Verdict human-set.
Understated Cross-checked A correction that runs in the project's favour, which is worth recording precisely because most corrections do not. The governance page is stale rather than overstated. It also corrects us: our own freedom-score evidence says 'Foundation controls protocol upgrades. No documented community governance mechanism for protocol decisions beyond validator voting', and the deployed governance module is more than that. Flagged for the 2026-09-01 monthly review; governance is scored 8/20.
Data Verified
Sapphire contract state is visible only to the contract that wrote it; not even full nodes can read the values, and eth_getStorageAt returns zero for all storage slots except three well-known EIP-1967 proxy slots. source →
Confirmed by direct experiment against both ParaTimes, with a control. On Sapphire (chainId 23294, sapphire.oasis.io), eth_getStorageAt on wROSE 0x8Bc2B030b299964eEfb5e1e0b36991352E56D2D3 returned zero for slots 0 through 5, while the same contract answered symbol() = "wROSE" and totalSupply() = 14,330,145.43 ROSE over eth_call at the same moment, so the endpoint was live and the contract was not empty. On Emerald (chainId 42262, emerald.oasis.io), the same call against wROSE 0x21C718C22D52d0F3a789b752D4c2fD5908a8A733 returned plaintext: slot 0 decodes to the packed string "Wrapped ROSE", slot 1 to "wROSE", slot 2 to 0x12 (18 decimals). Same RPC method, same chain family, opposite results, so the zero return on Sapphire is the confidentiality layer rather than a dead or restricted endpoint. Treatment-and-control read: the same six storage slots on the same nominal contract (wROSE) on the confidential ParaTime and the transparent one, paired with live eth_call getters on the confidential side to rule out an unresponsive node. Ingestion only, verdict human-set.
Verified on-chain A confirming positive on the project's central technical claim, and one of the few privacy claims in the corpus that a plain RPC call can settle. Two limits bound what it proves. It shows the node RPC will not serve raw storage; it does not show the data is encrypted at rest inside the enclave, and it says nothing about SGX side-channel resistance, which is a hardware-trust question no RPC read can answer. And confidentiality here is contract-mediated: a contract's own public getters still return values to any caller, which is why totalSupply() answered freely. Confidential state is the default, not a guarantee against a contract that chooses to publish.
Open source Verified
Oasis develops its protocol in the open under a permissive licence. source →
Confirmed. The github.com/oasisprotocol org carries 102 public repositories; the core node oasis-core is Apache-2.0, 369 stars, not archived, pushed on the assessment date. The confidential-compute (Sapphire/ParaTime) stack is public under a permissive licence. Direct GitHub org/repo metadata reads. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: 102-repo org, Apache-2.0 core node, active. Supply reconciliation stays deferred: ROSE's canonical supply is on the Oasis L1 (not a Cosmos-SDK LCD, not a queryable ERC-20 - the BSC contract is a bridge wrapper), so it needs the Oasis-specific API - not wired.
FLock.io 5 claims 2 corrected 2026-08-10
Governance Overstated
FLock is governed by a DAO with weighted voting, rather than by the core team. source →
Stage G0 on the contract that matters most to holders. The FLOCK token's upgrade path runs through ProxyAdmin 0xb6523d5d33d29a7e6573330310e3f0e6157e9f06 to a single Safe v1.4.1, 0x6052279aa6BF2E145eDafC7042A9BD6b4A80d31f, threshold 2 of 3, with no timelock and no on-chain governance contract in the path. Two of three signers can replace the token implementation, the supply cap and the blacklist logic with no delay and no on-chain notice. Signer identities are not published. Followed the admin slot to the ProxyAdmin, read its owner, and classified that owner by codesize and Safe getters rather than assuming from the address. Scope stated deliberately: this covers the token contract only, so the broader 'FLock is DAO-governed' claim stays open on the training and staking contracts, which were not enumerated this session. Verdict human-set.
Overstated on-chain Graded against the governance ladder in specs/oym-verdict-framework-spec.md 4a. A 2-of-3 threshold is the lowest in the corpus so far, below Venice's 4-of-6, Morpheus's 5-of-9 and Vana's 3-of-7. Consistent with the existing 9/20 score, so no change is proposed; the verdict supplies evidence the score lacked. Path to a better grade is the usual one: a timelock first, then binding on-chain votes executing through it.
Distribution Verified
66.7% community vs 33.3% team/investors — a good ratio; 1-year cliff + 2-year linear team vest. source →
Base FLOCK top-10 holders = 72.9% raw; infra-excluded (a TransparentUpgradeableProxy ~16.9% likely vesting/staking, plus Bybit/Gate/MEXC ~10%) it is ~44% of supply = D1 'moderate', broadly consistent with the claimed 33% team + community whales. No labelled insider (Safe/vesting) contract sits in the top-10. sources/holders.py: top holders + labels, classified holder/insider/infra/cex/burn; the upgradeable proxy + labelled CEX hot wallets excluded as neutral infra. Concentration = raw balance / total_supply.
Verified on-chain Moderate concentration (D1), consistent with the claimed good community/team ratio and the 10/15 score — not the extreme insider concentration seen at ORA/SAHARA. Re-check item (load-bearing): the single largest holder is a 28.95% UNLABELLED EOA (0xF35C…); if it is a team/treasury/foundation wallet rather than a genuine holder, the read shifts toward D0. The tool could not attribute it this run (no label, EOA). Verdict is match at the moderate reading; flag for a funding-trace at review.
Censorship Overstated
FLOCK is a standard ERC-20 on Base with immutable contracts and no privileged control over holders' balances.
Both halves are wrong for the token contract. FLOCK carries an admin-gated blacklist: the verified implementation declares mapping(address => bool) private _blacklist with events Blacklisted and Unblacklisted, exposes addBatchToBlacklist(address[]) and removeBatchFromBlacklist(address[]) both onlyAdmin, and overrides transfer to check it, so an admin can stop a holder moving their tokens. And the contract is not immutable: it is a transparent proxy whose EIP-1967 admin slot points at ProxyAdmin 0xb6523d5d33d29a7e6573330310e3f0e6157e9f06, owned by 0x6052279aa6BF2E145eDafC7042A9BD6b4A80d31f, a Safe v1.4.1 with a threshold of 2 of 3 and no timelock. Two signatures replace the token logic instantly. Read the proxy's implementation and admin slots, resolved the ProxyAdmin's owner and classified it by codesize plus Safe getters, then read the blacklist declarations and their modifiers out of the verified implementation source. Whether the blacklist has ever been used is NOT established: Base log history is not available on our Etherscan plan, so the Blacklisted event history was not retrieved. The capability is the finding; usage is the open check. Scope is the token contract, not FLock's training or staking contracts, which were not enumerated. Verdict human-set.
Overstated on-chain This corrects us, not FLock: 'Base L2 contracts are immutable' is our own sentence and it is false for the token. A blacklist plus an upgradeable proxy is the opposite of the censorship-resistance case that sentence was supporting, and censorship_resistance is scored 8/15 partly on it. Corrected in the research JSON and flock.mdx; score flagged for the 2026-09-01 review. Note the asymmetry worth keeping: FLock's privacy architecture at the training layer (data never leaves the device) is a separate claim and is untouched by this.
Supply Verified
The total supply of FLOCK is capped at 1 billion tokens. source →
Enforced in the deployed code, which is better than most cap claims in this corpus. The implementation behind the proxy (0x22754dad1b54ce707997afce9a78a3413045f784, FlockTokenUpgradeable, verified on BaseScan) gates minting on require(currentMinted + _amount <= maxTotalSupply), and the live contract reads maxTotalSupply() = 1,000,000,000 FLOCK exactly, with currentMinted() = 438,259,822 FLOCK, so 43.8% of the cap has been issued. A per-account dailyMintLimit of 10 FLOCK is also set. The caveat is that none of this is immutable: the token is a transparent proxy, so both the cap value and the mint logic can be replaced (see the governance verdict on the same project). The cap is real in code and revocable by two signatures. Read the three supply-relevant storage getters live, then located the mint gate in the verified source of the implementation the proxy currently points at. Ingestion only, verdict human-set.
Verified on-chain Graded match because the claim is about the cap and the cap is enforced by the code that is running. Compare Aethir, whose '42B hard cap' had no on-chain check at all and graded inflated; FLock's is materially stronger. Read this together with the upgrade authority below rather than on its own.
Measured facts & caveats 1 note
FLock reports protocol fees in TOKENS: 11.9M FLOCK over the 10 months to 31 October 2025 (2025 Earnings Report). Our editorial carried that as "$2.7M protocol revenue" across fourteen surfaces including the meta description and the tldr. That dollar figure is the token total converted at roughly $0.227, the FLOCK price around the reporting date. FLOCK trades near $0.030 on the 2026-08-15 refresher read, so the same 11.9M tokens are worth about $355,000 now, and the headline was a frozen price conversion presented as a revenue fact. Separately, DeFiLlama converts the same on-chain flows at daily prices and reports $1.17M all-time, which is a third measure again. Carry the token figure; it is what the project reported and it does not move with price. Corrected 2026-08-17.
Phala Network 5 claims 1 corrected 2026-06-12
Infra Editorial
On-chain adoption of the Phala Ethereum L2 (chain 2035), measured as cumulative unique addresses.
no independent source exists No source exists to check. The Blockscout instance that served the stats path was replaced by a Conduit-hosted app exposing only a JSON-RPC proxy and hashed endpoints that change every deploy, and no third-party indexer covers chain 2035 (Routescan answers BLOCKCHAIN_NOTFOUND). A cumulative unique-address count is an indexer aggregate, not an RPC call, so the surviving endpoint cannot supply it. Verified absent 2026-08-14.
Editorial Editorial A deliberate null with a reason, not a gap. The last good read was about 3,002 addresses in June 2026 and it is NOT carried forward as current, because a withdrawn source does not freeze into a fact. This matters less than it would elsewhere: Phala's product runs off-chain in TEEs, so the L2 footprint was always a modest side signal. Promote back to a measured row if Phala restores a stats API or an indexer adds chain 2035.
Censorship Established
The PHA token can be frozen by a central admin (token-layer custody surface). source →
The PHAToken ERC-20 is PAUSABLE and this is a strong lever: transfer/approve/increaseAllowance/decreaseAllowance all carry an onlyOwnerOrNotPaused modifier, so when paused EVERY holder except the owner is frozen (the owner retains transfer ability). pause()/unpause() are gated to PauserRole. Live state: paused()=false (not currently paused), owner()=0xb7687a5a3e7b49522705833bf7d5baf18aabdd2d, which is an EXTERNALLY-OWNED ACCOUNT (no code) that is also the original contract deployer, holds the PauserRole (isPauser(owner)=true) and has NOT renounced ownership. There is no per-address blacklist and no fee/transfer tax. So the token-layer lever is a global owner-carve-out pause held by a single un-renounced deployer EOA. Manual RPC reads of owner/pause/pauser state + eth_getCode to classify the owner (EOA vs contract), cross-read against the verified source. Ingestion only, verdict human-set.
Established on-chain An on-chain custody anchor, not a re-grade. Weaker custody posture than FET (whose mint/pause sit behind a 3-of-5 Safe): here the pause power sits with a single un-renounced deployer EOA, and pause freezes all holders except the owner. Orthogonal to the review's censorship_resistance score (which assesses the Phala network/TEE layer, not token custody). Surfaced by the WS3 coldstart evidence run (admin_functions=[ownable, pause]).
Open source Verified
Phala develops its core software in the open under a permissive licence. source →
Confirmed. The Phala-Network GitHub org carries 305 public repositories; the core monorepo Phala-Network/phala-blockchain is Apache-2.0, 371 stars, not archived, and actively maintained (pushed 2026-05-15). The Rust/Substrate node, pRuntime TEE worker and Phat-contract tooling are all public. Direct GitHub org/repo metadata reads (public_repos, licence, stars, pushed_at, archived). Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: the open-source claim holds (305-repo org, permissively-licensed active core monorepo). Surfaced by the WS3 coldstart evidence run (github fields were unresolved by the tool; verified directly against the Phala-Network org).
Supply Verified
PHA has a fixed 1 billion supply (no inflation on the token contract). source →
Confirmed fixed on the canonical Ethereum contract. PHAToken (0x6c5b...2f4e, non-proxy, Solidity 0.5.16) mints its entire supply ONCE in the constructor (_mint(msg.sender, initialSupply)) and exposes NO external/public mint function anywhere (_mint is internal, called only by the constructor). Live on-chain totalSupply = 1,000,000,000e18 exactly, matching the 1B claim and CoinGecko max_supply. The Ethereum ERC-20 carries the full canonical 1B (bridged Phala/Khala parachain PHA is lock-and-mint against Ethereum custody, not additional issuance, consistent with the ~47% infra share on the Ethereum holder list). No dilution path exists on the contract. Manual totalSupply() read + getsourcecode: confirmed constructor is the only issuance and no mint()/cap-raise exists. Ingestion only, verdict human-set.
Verified on-chain A confirming positive (the Heurist/OriginTrail immutable-supply pattern): the fixed-1B claim holds on-chain because the only issuance is the constructor mint and there is no mint path. Unlike FET (uncapped mint behind a Safe), PHA's token supply genuinely cannot be inflated. Surfaced by the WS3 coldstart evidence run.
Measured facts & caveats 1 note
Token Terminal s only Phala revenue data is the legacy Polkadot parachain, frozen at sunset (latest Nov 18 2025). No independent source covers the current Ethereum L2 (DeFiLlama has no Phala adapter either).
Sahara AI 5 claims 1 corrected 2026-06-13
Infra Established
Sahara Chain mainnet is chain ID 3132023, served at https://mainnet.saharalabs.ai. source →
The registered mainnet endpoint does not exist. mainnet.saharalabs.ai returns NXDOMAIN from Cloudflare (1.1.1.1), Google (8.8.8.8) and Quad9 (9.9.9.9), and the registry entry lists an empty explorers array, so there is no public block explorer either. The control condition is decisive: testnet.saharalabs.ai, on the same domain and the same naming pattern, resolves and serves, returning chainId 0x4c7e1 (313313) and block 0xa9ac47 (11,124,807), with testnet-explorer.saharalabs.ai also resolving. So the testnet is live and reachable while the mainnet host is absent; this is not a domain-wide or resolver-side failure. Five months after our March 2026 note that mainnet was 'imminent', the published mainnet endpoint still does not resolve. Queried three independent public resolvers and captured response status, then used a sibling host on the same domain as the control so a domain-level or resolver-level failure would be visible, and confirmed the control host actually serves RPC rather than merely resolving. Verdict human-set.
Established on-chain States exactly what it proves and no more: there is no reachable public RPC at the address Sahara registered, and no explorer in the registry entry. It does not prove no mainnet exists, since a private or unpublished endpoint could be running, and the SAHARA token itself is live and tradeable on Ethereum and BNB Chain regardless. Corroborates rather than corrects the 5/20 infrastructure score, and dates it: the same gap our March 2026 note described is still open in August. The check that would settle it is a mainnet endpoint published by Sahara.
Distribution Overstated
Community-oriented distribution: 64.25% community-weighted (Ecosystem Development 33.93%, Community Incentives 20.75%, Airdrops 8.15%, IDO 1.42%, Liquidity 1%). source →
Ethereum SAHARA (canonical; 10B total, BSC bridged) top-10 holders = ~82% infra-excluded, of which 46.85% sits in three Gnosis Safe multisigs (0xb9d9… 21.3% + 0xc92F… 19.75% + 0xca51… 5.8% — team/treasury/foundation) plus a single 17.2% EOA (0xfD63…). So while the ALLOCATION plan is 64% community-weighted, the current on-chain SUPPLY is concentrated (D0, top-10 non-infra >50%) in insider Safes — most community/ecosystem tokens are still locked or undistributed. sources/holders.py: top holders + labels, classified holder/insider/infra/cex/burn; the three Gnosis Safes counted as insider concentration. Concentration = raw balance / total_supply. Ethereum is the canonical issuance (our supply anchor above); Sahara Chain uses a bridged version.
Overstated on-chain Confirms + quantifies the low 7/15 score. The 64% 'community-weighted' figure describes the allocation PLAN, not the current supply, which is concentrated: 46.85% in three team/treasury Safes + a 17.2% EOA. Same pattern as ORA. Re-check item: the 17.2% EOA (0xfD63…) — a large early-investor or foundation wallet; does not change the D0 conclusion. Note: as community/ecosystem allocations vest and distribute, concentration should fall — re-measure at review. ATTRIBUTION 2026-08-13: two wording fixes against Sahara's own page. Their 64.25% community figure is 33.93 + 20.75 + 8.15 + 1.42 and does NOT include the 1% Liquidity and Market Stability bucket, and they call the 1.42% a 'Buidlpad Community Distribution', not an IDO. Also note saharalabs.ai now redirects to saharaai.com. Freshness wired 2026-08-17. The refresher reproduced this verdict's hand-authored figures, which is the check that made wiring safe rather than merely convenient. Caveat carried from the index: the infra-excluded figure rests partly on addresses Blockscout does not label, and a change in how many of those sit in the top ten is a signal to re-trace by hand, not a new measurement.
Data Editorial
Sahara claims privacy-preserving handling including TEEs, differential privacy and encrypted data.
No attestation surface and no audit exists to check any of it against. CertiK Skynet records no audit; the data itself sits off-chain on infrastructure we cannot inspect; and Sahara publishes no TEE attestation endpoint a third party could verify against, unlike the Verifiable-ClawGuard repo which attests a different system. Looked for an audit report and for any published attestation surface that would let an outsider verify the privacy claims. Found neither.
Editorial Cross-checked Distinct from the published_audit row, which is about whether an audit exists. This one is about whether the privacy claims could be checked at all, and the answer is no: off-chain storage plus no attestation endpoint means a reader has only Sahara's word. Unverifiable is the honest verdict, not a finding against them.
Open source Established
No third-party security audit of Sahara's contracts is published. Our own statement, checked against an independent register.
CertiK Skynet lists Sahara AI and records "Not Audited By CertiK" and "3rd Party Audit: No", with the Audits section reading "Not Available". The Skynet score it does carry (88.71, AA) is continuous monitoring, not an audit with findings, and the two must not be read as the same thing. Read the audit fields on the third-party monitoring page directly, and searched the SaharaLabsAI GitHub organisation for a published report. Neither surfaced one.
Established Cross-checked Authored specifically because this is the ORA shape: an audit-absence claim written once and never checked, where a report sitting in the project's own GitHub org went unnoticed for months. Here the claim survives the check, and now rests on a named third-party register rather than on our failure to find something. The limit is stated: absence from Skynet is strong evidence, not proof, and a private audit could exist unpublished. That would still leave the transparency claim intact, because an unpublished audit is not a transparency artefact.
Measured facts & caveats 1 note
Sahara Chain mainnet was targeted for Q3 2025; it is registered on ChainList with a chain ID and RPC endpoint, but operational status is disputed across sources.
OpenServ 4 claims 1 corrected 2026-08-10
Distribution Verified
Meaningful non-insider distribution via a public Fjord IDO (25%) plus a 12.8% community airdrop; team (22.5%) and treasury (18%) on on-chain Sablier vesting; balanced with fair-launch elements.
On-chain holder distribution is genuinely broad: 6,635 holders; top-10 concentration 40.77% raw but only 9.81% after excluding infrastructure. The infrastructure in the top holders is exactly the claimed structure: SablierV2 Lockup NFTs (13.00% + 10.00% = on-chain team/treasury vesting streams), a TokenBridge (8.65%), and a UniswapV3 pool (2.35%). The largest genuine (non-infra, non-insider) holder is 1.37%; the only Safe is 0.81%. Insider-Safe share is ~0%. coldstart sources/holders.py: top-holder pull, is_contract + public-label tagging, infra/insider/cex classification, raw vs infra-excluded top-10 concentration. Ingestion only, verdict human-set.
Verified on-chain A confirming positive: the fair-launch / broad-distribution claim holds on-chain. The apparent 40.77% top-10 concentration is almost entirely the claimed Sablier vesting streams + bridge + LP; the real free-float distribution is broad (largest genuine holder 1.37%, ~0% in insider Safes). The ~23% Sablier lockup the review cites is visible as the two SablierV2 Lockup positions. Surfaced by the WS3 coldstart evidence run. Search exhausted 2026-08-13. No OpenServ-published page states the 25/12.8/22.5/18 split. Third-party coverage of the Fjord sale is close on the public slice (CryptoRank: 24.71%, 250M tokens, 7-8 November 2024) but says nothing about the team, treasury or Sablier terms. Until an OpenServ source is found this split should be treated as unattributed, and the earlier flag stands: its shape may have been imported from the SERV launchpad template, which specifies team and treasury vesting via Sablier for tokens launched ON the platform rather than for $SERV itself. Freshness wired 2026-08-17. The refresher reproduced this verdict's hand-authored figures, which is the check that made wiring safe rather than merely convenient. Caveat carried from the index: the infra-excluded figure rests partly on addresses Blockscout does not label, and a change in how many of those sit in the top ten is a signal to re-trace by hand, not a new measurement.
Censorship Overstated
The token transfer layer is meaningfully permissionless (the review's prior censorship evidence framed only the hosted product as restrictable). source →
The transfer layer is NOT permissionless: the verified OpenServ contract has an owner-gated blacklist (BlackListAddress(address,bool) external onlyOwner; _transfer reverts 'Address is blacklisted' for a blacklisted recipient), so the owner can freeze any address from receiving SERV. It also charges an ACTIVE 5% buy / 5% sell tax (buyTotalFees = sellTotalFees = 50, i.e. 5.0%, setFees onlyOwner capped at 5%, 100% routed to treasury). owner() is a Gnosis Safe multisig (has contract code), not a single EOA, and the contract is non-upgradeable. getsourcecode (BlackListAddress onlyOwner + isBlackListed transfer gate; buy/sell fee vars + setFees cap); getabi; eth_getCode on owner() (contract = Safe). Ingestion only, verdict human-set.
Overstated on-chain Corrects our own prior evidence: the SERV transfer layer is NOT permissionless. The Safe-owned contract can blacklist any recipient and levies an active 5% buy / 5% sell treasury tax. The already-low censorship_resistance score (3/15) is unchanged (no grade boundary crossed); the review's evidence text was corrected inline this session to remove the inaccurate 'permissionless transfer layer' framing. Surfaced by the WS3 coldstart evidence run.
Open source Established
No third-party security audit of OpenServ's contracts is published. Our own statement, checked against an independent register.
CertiK Skynet lists OpenServ and records "CertiK Audit: No" and "3rd Party Audit: No". Read the audit fields on the third-party monitoring page directly, and searched the openserv-labs GitHub organisation, whose 14 public repos are SDK and tooling code with no audit artefact.
Established Cross-checked The claim survives an independent check and now rests on a named register rather than on our search coming up empty. Worth pairing with the closed BRAID engine: the parts a reader would most want audited are the parts that are neither open nor audited.
Supply Verified
SERV has a fixed 1 billion maximum supply.
On-chain total = max = 1,000,000,000 SERV (CoinGecko + Blockscout + RPC). The verified OpenServ contract has NO mint or _mint function and is NOT a proxy, so supply is fixed by immutable deployed code (no dilution path). The token does carry a transfer-tax mechanism (see the censorship anchor), which does not change max supply. coldstart evidence.py gather() + a manual contract-source read: no mint/_mint present, Proxy flag 0 (non-upgradeable). Ingestion only, verdict human-set.
Verified on-chain 1B fixed supply confirmed and immutable: no mint path and a non-upgradeable contract, so unlike an upgradeable token (e.g. Sentient) the cap cannot be changed by an admin. Ethereum canonical; Base copy bridged. Surfaced by the WS3 coldstart evidence run. ATTRIBUTION 2026-08-13: OpenServ publishes no supply figure for $SERV anywhere we could find (docs, sitemap and blog all checked; Medium and Mirror are bot-gated). TRAP RECORDED: docs.openserv.ai/launch/for-builders says 'Every launch uses a fixed supply of 1,000,000,000 tokens', but that is the template for third-party tokens launched ON the SERV launchpad, not $SERV itself, and must not be cited here. Our claim's shape may have been imported from that template; re-verify it at the monthly review. Search exhausted 2026-08-13. OpenServ publishes no supply figure for $SERV on any surface we can reach: docs, sitemap, every blog post, and the Medium and Mirror accounts (both bot-gated). Third-party sources exist (CryptoRank gives 1.01B total, a public sale of 24.71%/250M on Fjord in November 2024) but none is OpenServ speaking. The on-chain read of exactly 1,000,000,000 stands on its own; only the attribution is missing.
Warden Protocol 4 claims 1 corrected 2026-03-06
Governance Verified
WARD holders govern WardenChain by binding on-chain vote. source →
Five proposals in the x/gov module through March 2026: three upgrade proposals (v0.7.2, v0.7.4, v1.0.0) and a transaction-fee increase passed; proposal 4, "Set Fixed 3% Inflation Rate", was rejected, with opposing stake more than two orders of magnitude above the support. Enumerated the full proposal set via Cosmos REST and read each status and final tally directly.
Verified on-chain Authored to settle a claim our own record had wrong. The score evidence read "No evidence of active on-chain governance proposals" against a module holding five, and the most consequential was a defeat: token holders rejected a fixed 3% inflation rate. A rejected monetary-policy proposal is the single best evidence a governance process is real, and we had recorded its absence. Corrected in the review and the research JSON. The record is still short and the token is young, so the score is flagged for the monthly rather than moved here.
Open source Verified
Warden develops its chain in the open under a permissive licence. source →
Confirmed. The github.com/warden-protocol org carries 38 public repositories; the core chain monorepo warden-protocol/wardenprotocol is Apache-2.0, 2,162 stars, not archived, pushed within days of assessment. The Cosmos-SDK chain, modules and tooling are public under a permissive licence. Direct GitHub org/repo metadata reads (public_repos, licence, stars, pushed_at). Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: 38-repo org, Apache-2.0 chain monorepo (~2.2k stars), active. Surfaced by the WS3 coldstart run. Freshness wired 2026-08-17. Wiring limit, stated so nobody reads more into it than it carries: what is re-measured is the star count, because that is the quantity the verdict states. The failure modes that would actually overturn an open-source verdict are the repo being archived, relicensed, or going quiet, and none of those move stars. They are on the Phase 4 backlog. A star-count band is a prompt to go and look at the repo again, not a check that it is still open.
Supply Established
WARD has an uncapped, inflationary PoS supply (no fixed cap). source →
Confirmed uncapped and actively inflating, on the CANONICAL native leg. WardenChain is a Cosmos-SDK chain (with EVM compatibility), so the base staking denom `award` is read via the Cosmos bank module: onchain_total_supply = 1,052,451,039 WARD (18 decimals) - ALREADY ~5.2% ABOVE the 1B genesis 'total' CoinGecko still reports. The chain's mint module reports 10.0%/yr inflation (/cosmos/mint/v1beta1/inflation = 0.10), so supply grows continuously with no cap. The Base and BSC ERC-20 contracts CoinGecko lists are minority bridge wrappers, not the canonical supply. Manual LCD reads via the coldstart Cosmos source (T3): base-denom supply + mint inflation. Ingestion only, verdict human-set.
Established on-chain Confirms AND quantifies the review's uncapped-inflationary-PoS framing: current native supply ~1.052B, already past the 1B genesis, inflating ~10%/yr - so CoinGecko's '1B total' is a stale genesis figure, not a cap. First reconciliation off the WS3 T3 Cosmos source; the EVM legs are minority wrappers (the multi-leg caveat).
Measured facts & caveats 1 note
The 60.4M 'agent runs' headline is dominated by off-chain activity with no independent analytics coverage; the off-chain portion cannot be independently confirmed.
Giza 7 claims 2026-06-25
Governance Verified
Governance is council-based by design: Giza rejects token-weighted voting, and in Phase 1 a Security Council holds executive authority while stakers give non-binding input through Snapshot. source →
Their disclosure is accurate, and the chain shows what it implies. The GIZA token contract (GizaMainChain, 0x5908...7774) is Ownable by a 2-of-4 Gnosis Safe (0xa87d...6ae0; getThreshold 2, getOwners 4) which holds an uncapped mint(uint256) with no timelock, and no on-chain governance contract sits in the path. That is Stage G0 control, and it is what a Security Council with executive authority looks like in code. Read the token's owner, then read that owner's Safe threshold and signer count on-chain, and enumerated the verified ABI for privileged functions. Ingestion only, verdict human-set.
Verified on-chain VERDICT CORRECTED 2026-08-13, same day it was authored. The first version tested the claim 'GIZA holders govern the protocol through token-weighted voting' and marked it inflated. Giza makes no such claim; its docs explicitly reject token-weighted governance as 'the illusion of direct democracy' and publish council control as the design. Marking a project inflated for a claim it does not make is the error the framework warns about, so the claim has been restated and the verdict is now match: they said a council controls it, and a council controls it. The centralisation is unchanged and still severe, which is what severity carries. Credit where due: Giza discloses this plainly, which many projects do not.
Distribution Established
No published concentration claim.
The raw top-10 number is alarming and the real one is not. Top-10 holders control 97.72% of supply, but 88.53% of that is a single LayerZero OFT adapter (the bridge lock holding supply that circulates on other chains) and the labelled infrastructure share is 88.89%. Excluding infrastructure, the top 10 hold 8.92% across 2,186 holders, with the largest non-infra holder being the team Safe at 8.49%. Pulled the top holders with contract flags and public labels, classified each as holder/infra/insider, and computed both the raw and infrastructure-excluded top-10 concentration. Ingestion only, verdict human-set.
Established on-chain A worked example of why raw concentration numbers mislead. Anyone quoting Giza's 97.72% top-10 figure would be describing a bridge contract, not a whale. On the infrastructure-excluded basis the distribution sits in the fair band; the holder base is thin at 2,186 addresses, which is the more meaningful weakness. Freshness wired 2026-08-17. The refresher reproduced this verdict's hand-authored figures, which is the check that made wiring safe rather than merely convenient. Caveat carried from the index: the infra-excluded figure rests partly on addresses Blockscout does not label, and a change in how many of those sit in the top ten is a signal to re-trace by hand, not a new measurement.
Open source Established
Giza develops its agent and proving stack in the open. source →
Public but stalled. The github.com/gizatechxyz org carries 32 public repositories and none has been pushed since 23 March 2026: giza-hub last moved that day, LuminAIR (the proving library, 57 stars) in September 2025, giza-token in September 2025. The token contract source is verified on Etherscan. Enumerated the org's repositories by last-push date. Ingestion only, verdict human-set.
Established Cross-checked The code is public, which is the claim, so this is not a failed check. The finding is the timeline: development stopped around the same March 2026 date the agent dashboard froze, which corroborates the retirement of ARMA and Pulse rather than a quiet continuation.
Utility Established
Staking GIZA is a live token utility: operators stake to run agents and holders stake for rewards. source →
46,298,698 GIZA staked in the Staker contract (Base) balanceOf via eth_call, scaled 18
Established on-chain The GIZA token-staking layer is live and directly measurable on-chain (~46.3M GIZA), a small but real anchor. Distinct from agent AUA, which is unverifiable. Freshness wired 2026-08-16: baseline 46,298,698 (staked GIZA at authoring; already down ~8.8%, so the band is doing work).
Supply Established
GIZA has a maximum supply of 1,000,000,000 tokens. source →
The number is right today and nothing enforces it. totalSupply() returns exactly 1,000,000,000 GIZA, matching the claim. But the verified contract exposes mint(uint256) to its owner with no cap parameter, and that owner is a 2-of-4 Safe, so the supply is bounded by multisig restraint rather than by code. Direct RPC supply read plus an ABI review of the verified source for cap enforcement. Ingestion only, verdict human-set.
Established on-chain Recorded as measured rather than as a pass, because the claim and the enforcement are different things. Renouncing the minter role or adding a hard cap would turn this into a clean match; until then a supply figure is a statement about intent.
Revenue Established
Giza agents generate transaction fees, a portion of which flows to stakers and the treasury. source →
$127,490 all-time on-chain protocol revenue, of which $83,666 in the trailing year and $2,285 in the trailing 30 days. The trailing 24-hour and 7-day readings are both zero. DeFiLlama summary/fees/giza?dataType=dailyRevenue, refreshed by scripts/refresh-primary.ts into meta.primary_data.
Established Cross-checked The measured anchor behind the F-grade on revenue sustainability. All-time revenue across the whole protocol is smaller than a single month of most projects on this dashboard, and the recent window has gone flat: the trailing 30 days are a fraction of the trailing year, and the last week is zero. This is the on-chain leg only and says nothing about off-chain arrangements, but Giza publishes no off-chain revenue figure either. Because the all-time series only ratchets upward, a resumption of fees would show up as band-crossing growth rather than being lost in a cumulative total. Basis corrected 2026-08-17: this was banded on the cumulative all-time total, which only ever rises, so the band could register growth but was structurally incapable of registering decline. Rebased on the trailing year from the same stored response, which can fall.
Thesis verdicts 1 check
Giza runs autonomous DeFi agents managing real user assets at scale (~$19.48M assets under agency). source →
Unverifiable. DeFiLlama on-chain ~$14K residual (mostly HyperEVM; Base only ~$219) Adapter merges api.arma.xyz + api.gizatech.xyz smart-account lists and sums USDC lending positions, but those endpoints now return 404/301, so the ~$14K is a residual undercount, not a measure of the live agent
Editorial Cross-checked ARMA/Pulse retired Feb-Mar 2026 and funds returned to EOAs; successor agent AUA cannot be confirmed. Homepage figure is a static Framer counter; the app replays a frozen 2026-03-23 snapshot. Neither the self-reported $19.48M nor DeFiLlama's $14K residual is a trustworthy current AUA. GIZA token staking (~46.3M, see giza_staked) is the one live on-chain anchor, separate from AUA.
Measured facts & caveats 1 note
UPDATED 2026-06-25: ARMA and Pulse were retired (announced 26 Feb 2026, migration deadline 26 Mar 2026) and user funds returned; the successor unified agent (Giza World) has no verifiable current AUA. DeFiLlama on-chain TVL has collapsed to ~$14K (mostly residual; the adapter's account-feed endpoints api.arma.xyz/api.gizatech.xyz now 404/301, so even that is an undercount). The homepage ~$19.48M AUA is a static Framer counter and the Giza World app replays a frozen snapshot dated 2026-03-23; both are stale/self-reported. Cumulative 'agentic volume' and agent counts remain off-chain and unverifiable.
Nosana 6 claims 2026-08-12
Distribution Check pending
NOS holders stake into the network, giving the token a participating holder base. source →
— Not checked. NOS staking accounts live on Solana and are enumerable under the Nosana staking program, which would settle the count; we have not enumerated them.
Check pending Editorial A staker count is a participation signal, not a distribution one: it says how many accounts stake, nothing about how concentrated the stake is. Carried as a reported figure so it is not mistaken for a measured one.
Censorship Established
The NOS token can be frozen by a central authority (token-layer custody surface). source →
The NOS SPL mint has freezeAuthority = NULL: no authority can freeze any NOS token account, so there is no token-layer freeze/censorship lever. Combined with the null mint authority, the token is fully immutable at the SPL layer (no mint, no freeze). Manual SPL freeze-authority read via the coldstart Solana source. Ingestion only, verdict human-set.
Established on-chain A positive on-chain custody anchor: no freeze authority = accounts cannot be frozen. Orthogonal to the review's censorship_resistance score (the compute/network layer). The SPL analogue of 'no pause/blacklist'.
Open source Verified
Nosana develops its stack in the open under a permissive/copyleft licence. source →
Confirmed. The github.com/nosana-ci org carries 34 public repositories, actively developed: nosana-dashboard is GPL-3.0 (18 stars), nosana-node and the nosana.com site were pushed within a day of assessment. The core CLI/node/dashboard are public. Direct GitHub org/repo metadata reads (public_repos, licence, pushed_at). Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: 34-repo org, GPL-3.0 dashboard, active. Surfaced by the WS3 coldstart run.
Utility Check pending
Nosana settles GPU compute jobs on-chain, and the cumulative job count measures that activity. source →
— Not checked. The settlement venue is confirmed independently: the GPU market accounts returned by Nosana's API are owned by the Nosana Jobs Solana program nosJhNRqr2bc9g1nfGDcXXTXvYUmxD4cVwy2pMWhrYM, verified by getAccountInfo. That establishes the jobs settle where Nosana says, not how many there have been. Counting them means enumerating job accounts under that program on Solana, which we have not done.
Check pending Editorial The marketplace_activity row beside this one confirms the venue and observed live jobs running; this row carries the cumulative count, which is a different claim and is only as good as Nosana's indexer. Worth noting the count has moved a long way past the 985K figure our earlier research recorded, so any prose quoting that number is stale.
Supply Verified
NOS has a fixed 100M supply (no inflation). source →
Confirmed fixed AND enforced. getTokenSupply on the NOS SPL mint (nosXBVoaCTtYdLvKY6Csb4AC8JCdQKKAaWYtx2ZMoo7, 6 decimals) = 99,999,720.49 NOS, matching the CoinGecko total exactly (just under the 100M max). Critically, getAccountInfo shows mintAuthority = NULL: no further NOS can ever be minted (the SPL analogue of a renounced/dead mint), so the fixed supply is enforced by the token itself, not just policy. Manual SPL reads via the coldstart Solana source (T2): supply reconcile + mintAuthority null-check. Ingestion only, verdict human-set.
Verified on-chain A confirming positive and the cleanest Solana case: mintAuthority null = supply provably cannot inflate (stronger than an EVM 'no mint function', since it is the same guarantee at the SPL layer). First reconciliation off the WS3 T2 Solana source. ATTRIBUTION 2026-08-13: Nosana's old tokenomics page is gone (docs.nosana.io 301s to learn.nosana.com and the token page 404s). The 100,000,000 total is server-rendered on nosana.com/nosana-token as a live stat tile, but nowhere does Nosana state 'fixed', 'max supply' or 'no inflation' - that framing is ours. Their own post 'From Yield to Growth' says the opposite in spirit: 'emissions expand supply even when jobs don't grow'. That is distribution from pre-allocated pools, not minting (our on-chain read found mintAuthority null), but the no-inflation wording overstates what they publish.
Measured facts & caveats 1 note
Nosana DOES take a network_fee_percentage on each on-chain job (visible per-market in /api/markets), so protocol revenue is computable in principle from on-chain job settlements. But it is not tracked by DeFiLlama or Token Terminal and we have not computed it here, so no protocol revenue figure is asserted.
Auki 5 claims 2026-08-12
Distribution Established
No published holder-concentration figure. The whitepaper publishes a genesis allocation table (30.49% insider weight) but says nothing about where supply sits on-chain. source →
The top 10 AUKI addresses hold 83.80% of the 9,989,714,427 on-chain supply, and all eight unlabelled EOAs among them trace by largest inbound transfer to the token deployer. 79.74% sits in those EOAs, 3.01% in the labelled MerkleVester contract and 1.06% at MEXC. No DEX or CEX appears anywhere in the acquisition path of the top nine. Enumerated every inbound ERC-20 transfer for each top holder and followed the LARGEST rather than the first, then repeated that hop to its origin. The distinction is what decides the case here: the first inbound to five of these wallets is a 1 AUKI test transfer, which is what the 2026-08-10 funding trace followed, and why it returned an inconclusive 'from:eoa (chain)'. Ingestion only, verdict human-set.
Established on-chain The 2026-08-10 trace measured the concentration but could not resolve where it came from. The structure is a single distribution tree. All 10,000,000,000 of the genesis mint went from the zero address to the deployer 0xc4f8401c… in one transfer; the deployer split it across five pass-through wallets (2B each, 1.991B for the fifth), each of which forwarded its whole balance to one hub 0xdc0858…; and that hub is the largest-inbound source for holders 2 to 5 directly and for holders 1, 6, 7 and 9 one hop further on. Several of them send onward into a 3-of-5 Gnosis Safe (0xe7a140ba…) that holds none of the token's admin roles and is separate from the 4-of-6 Safe holding mint and upgrade authority. This establishes that none of the top nine acquired on the open market, so the 83.80% is distribution structure rather than market accumulation. It stops short of showing that 83.80% is insider-held today, because an allocation recipient is deployer-funded by construction, and origin alone cannot separate the team from an investor or an ecosystem counterparty sitting on an unsold allocation. Naming the wallets needs an off-chain disclosure Auki has not published. Distribution fairness stays 9/15 pending the monthly review, where the question is whether an unnamed 79.74% concentrated in deployer-seeded EOAs sits comfortably with a published 30.49% insider weight. Freshness wired 2026-08-17. The refresher reproduced this verdict's hand-authored figures, which is the check that made wiring safe rather than merely convenient. Caveat carried from the index: the infra-excluded figure rests partly on addresses Blockscout does not label, and a change in how many of those sit in the top ten is a signal to re-trace by hand, not a new measurement.
Censorship Established
The AUKI token can be frozen, upgraded or its issuance controlled by a central admin (token-layer custody surface). source →
The AukiToken is the deepest admin surface in the campaign so far: (1) it is a UUPS UPGRADEABLE proxy, so the 4-of-6 Safe (UPGRADER_ROLE) can replace the entire token logic, including adding a blacklist or fee; (2) it is PAUSABLE - _beforeTokenTransfer AND _approve both carry whenNotPaused, so a pause (PAUSER_ROLE) freezes all transfers and approvals; (3) it has an uncapped mint (MINTER_ROLE); (4) DEFAULT_ADMIN_ROLE (the same 4-of-6 Safe) can grant MINTER/PAUSER to any address. Live state: paused()=false, and the current implementation has NO per-address blacklist and NO fee/transfer tax. So today the token transfers freely, but the 4-of-6 Safe holds pause (grantable), mint (grantable) and full-logic upgrade powers. Manual read of the verified implementation for the pause/upgrade/mint surface + live paused()/role/Safe-threshold reads. Ingestion only, verdict human-set.
Established on-chain An on-chain custody anchor, not a re-grade. Stronger than FET/PHA/NTX because the token is fully UPGRADEABLE (not just pausable): the 4-of-6 Safe can rewrite the token, including adding censorship logic that does not exist today. Better-governed than a bare EOA (4-of-6 multisig) but a far larger surface. Orthogonal to the review's censorship_resistance score (network/agent layer). Surfaced by the WS3 coldstart evidence run.
Open source Verified
Auki develops its posemesh / spatial-computing stack in the open under a permissive licence. source →
Confirmed for the protocol stack. The github.com/aukilabs org carries 53 public repositories, MIT-licensed and actively developed: posemesh (MIT, 47 stars, pushed 2026-08-11), reconstruction-server (MIT, pushed 2026-08-12), auki-sdk (MIT), hagall (the posemesh network server, MIT). Caveat: the AUKI token contract itself declares no SPDX licence ('None' on BaseScan), so the on-chain token is not itself licensed even though the surrounding protocol code is MIT. Direct GitHub org/repo metadata reads (public_repos, licence, stars, pushed_at) + getsourcecode licence field. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: the open-source claim holds (53-repo MIT org, active posemesh/hagall/SDK). The one nuance is that the token contract is unlicensed while the protocol stack is MIT. Surfaced by the WS3 coldstart evidence run (github fields were unresolved by the tool; verified directly against the aukilabs org).
Supply Established
The posemesh economy begins with an initial mint of 10 billion AUKI, after which supply deflates as services are consumed, asymptotically toward a total supply of 5 billion. source →
The current supply matches (on-chain total 9,989,714,427 AUKI against the 10B initial mint, with ~0.1% burned, consistent with deflation having just begun), BUT nothing about the schedule is enforced by immutable code. AukiToken (Base 0xf956...5df4) is a UUPS UPGRADEABLE proxy (impl 0x408b...dfcf) whose logic can be replaced, and the current implementation exposes an uncapped mint(to, amount) gated to MINTER_ROLE behind a 4-of-6 Safe. Neither the 10B ceiling nor the 5B floor is a code constraint. Manual RPC reads of supply, impl slot, role membership and Safe config, cross-read against the verified implementation (mint has no cap; UUPS _authorizeUpgrade gated to UPGRADER_ROLE). Ingestion only, verdict human-set.
Established on-chain The Sentient upgradeable pattern, but more thoroughly admin-controlled: the supply figure matches yet there is no hard cap (uncapped grantable mint + full UUPS upgradeability) behind a 4-of-6 Safe. Graded established (mint authority + upgradeability are verified facts; nothing over-issued, so not inflated) rather than match (no immutable cap to match). Distribution is deferred separately (the opaque-EOA concentration case). Surfaced by the WS3 coldstart evidence run (pausable=true, contract_name=UUPSProxy). Claim corrected 2026-08-13: we previously recorded 'a fixed 10 billion supply (no inflation)', which mis-states Auki's own design. The whitepaper describes an initial mint of 10B DEFLATING toward 5B, not a fixed cap. The verdict is unchanged (established, not match) because the on-chain finding is the same either way: no immutable cap exists in either direction. Attribution also moved off www.auki.network, which no longer resolves; the live site is auki.com and the whitepaper is on GitBook.
Measured facts & caveats 1 note
On-chain DeFiLlama figure measures only AUKI burned-for-credits and excludes off-chain fiat/USDC paid for Cactus pilots, where the growth narrative sits. The two are not the same revenue base.
Allora Network 5 claims 2026-06-12
Infra Established
The Allora L1 is a Cosmos SDK / CometBFT chain secured by a stake-weighted validator set. source →
17 bonded validators, essentially unchanged from the 16 our record notes at mainnet launch. Voting power within that set is unusually even for a small set: the largest holds 6.7% of bonded stake, six validators reach a third and eight reach half. The number that stands out is not concentration but participation: 10,548,195 ALLO is bonded against a total supply of 787,883,668 ALLO, so roughly 1.34% of the token supply secures the chain, with a further 381,179 ALLO unbonding. Pulled the bonded validator set with token weights, computed top-N shares and the counts crossing one third and one half, then read the staking pool and bank supply for the ratio. The uallo exponent was derived rather than assumed: the bank module's uallo total divided by 1e18 gives 787.9M, consistent with the known sub-1B supply, which fixes the decimals at 18 (a 1e6 reading would imply 7.9e20 tokens). Public third-party node, so api grade rather than our own rebuild. Verdict human-set.
Established Cross-checked The even weighting inside the set is a genuine positive and worth stating, because a 6.7% top validator is better than most chains we have measured. The security question sits elsewhere: 1.34% of supply bonded means the cost of acquiring a third of voting power is small relative to the token's float, which is the finding that should inform the 9/20 score at the 2026-09-01 review rather than the validator count alone.
Governance Verified
ALLO holders govern the chain by binding on-chain vote. source →
17 proposals in the x/gov module through 13 August 2026: twelve passed, one rejected, the remainder failed to reach a vote. Executed changes include max_validators, feemarket gas settings, an IBC light-client recovery, enabling emissions, and six chain upgrades to v0.17.0. Proposal 13 (v0.15.1) was rejected outright before the same upgrade passed as proposal 14. Enumerated the full proposal set via Cosmos REST and read each status and final tally directly.
Verified on-chain Authored to settle a claim our own record had wrong. The score evidence read "No evidence of active governance proposals or meaningful voter turnout" against a chain with 17 of them and a rejection on the record, which is the Oasis-shaped failure this pass exists to find: an absence asserted about the world when nobody had queried the module. Corrected in the review and the research JSON. The narrower point survives: eleven of twelve passing proposals drew zero opposing votes, so the process works and is barely contested. Score held for the monthly review rather than moved here.
Open source Verified· 2 checks
Halborn is auditing the Allora chain code and will provide a comprehensive report on completion. source →
The engagement is published; a completed report is not. Allora's own post (18 July 2024) describes the audit as ongoing and scheduled to complete before mainnet launch, and links no report. No audit report appears in the 15-repository allora-network GitHub org, and a targeted search surfaced the announcement but no published findings. This is recorded as unverified rather than as an absence: a report may exist somewhere not searched, and the ORA case earlier the same day showed exactly that failure mode, where an audit sat in the project's own GitHub org while our record said none existed. Read the announcement for its status wording and date, enumerated the org's repositories looking for audit or security repositories, and searched for a published report by firm name. The concrete check that would settle this: ask Allora, or look for a Halborn-side publication. Verdict human-set.
Check pending Editorial Sharpens our own wording without overturning it. Our evidence says 'No security audit - significant transparency gap'; the accurate statement is that an audit by a named firm was commissioned and announced in July 2024 and no completed report has been found. The rubric bar in the verdict spec is a named firm plus a public report, and only the first half is met, so open_source_transparency 12/15 is not disturbed.
Allora develops its chain in the open under a permissive licence. source →
Confirmed. The github.com/allora-network org carries 15 public repositories; the core chain allora-network/allora-chain is Apache-2.0, 140 stars, not archived, pushed on the assessment date. The Cosmos-SDK L1 and its modules are public under a permissive licence. Direct GitHub org/repo metadata reads (public_repos, licence, stars, pushed_at). Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: 15-repo org, Apache-2.0 chain, active. Complements the existing native total_supply reconciliation (which the WS3 T3 Cosmos source now automates). Surfaced by the WS3 coldstart run.
Measured facts & caveats 1 note
Mainnet-only inference volume is not publicly separated from testnet figures.
AntSeed 5 claims 2026-08-12
Distribution Verified
No pre-mine: the token contract allocates nothing at deployment, so all supply reaches holders through emissions. source →
Confirmed at the contract + holder level: the ANTSToken constructor allocates nothing (no deployer/treasury pre-mint), so all 63.3M outstanding was emission-minted. Holder read (146 holders): top-10 raw 67.72% but ex-infra 33.43% with a 0% insider share — no Safe/deployer/team wallet appears in the top holders; every large non-infra holder traces to `mint` (direct emission receipt). The single largest holder is 0xA065...B261 'AntseedSellerRewardsPool' at 29.58% (infra, the transparent seller-emission reserve, matching the disclosed 50% Provider Pool), not a private allocation. coldstart evidence.py holders leg (raw + infra-excluded top-10, insider classification with funding-trace) + a manual read of the constructor confirming no _mint at deploy. Ingestion only, verdict human-set.
Verified on-chain A confirming positive: the fair-launch, no-pre-mine claim holds on-chain (empty constructor, 0% insider share, largest holder is the transparent emission pool). Caveats, not contradictions: only ~6% is emitted across 146 holders so the picture is early, and forward emission fairness rests on the owner-controlled emissions contract (the record already flags the Provider Pool as treasury-discretionary pending the validation framework). Surfaced by the WS3 coldstart evidence run. CLAIM NARROWED 2026-08-13. We had recorded 'no pre-mine, no team allocation, no VC allocation'. The no-pre-mine half is verified on-chain and stands. The 'no team allocation' half was our overstatement, not AntSeed's: their own docs publish a 15% contributors/team share of emissions plus a 15% Foundation Ecosystem Reserve. No pre-mine and no team allocation are different things and we had run them together. AntSeed also publishes two mutually inconsistent emission splits (the reputation docs vs the seller-pools blog), which is flagged for the monthly review along with the Token Distribution Fairness score.
Censorship Established
ANTS is a non-transferable Phase-1 token; transferability is an admin-gated launch control, separate from the network's censorship-resistance. source →
Verified live: transfersEnabled() returns false on 2026-08-12, so ANTS is currently non-transferable for all non-whitelisted holders (the _update override reverts TransfersNotEnabled for any non-mint, non-whitelisted sender). The owner (0xf733...f8bb) holds three relevant powers: enableTransfers() (flips transfers on GLOBALLY, but ONE-WAY — reverts if already enabled, so it cannot re-freeze), setTransferWhitelist(account,bool) (grant a specific address the right to transfer during the lock, e.g. LP seeding), and setRegistry() (set the minter authority). So today the owner fully gates who can move ANTS and when the global switch opens. Manual read of the transfer-gating logic + eth_call transfersEnabled()/owner(). Ingestion only, verdict human-set.
Established on-chain An on-chain token-admin anchor recording the exact mechanism the review flags as 'a separate concern': at the token layer ANTS is presently non-transferable and the owner unilaterally controls transferability (per-address whitelist + a one-way global enable). The distinguishing nuance from the OpenServ/Sentient findings: this is a one-way launch gate, not a repeatable pause/blacklist, so once enableTransfers() is called the freedom is permanent. Orthogonal to the network-layer censorship score (WebRTC/DHT/GPL), so recorded as an established anchor, not a re-grade. Surfaced by the WS3 coldstart evidence run.
Open source Verified
The AntSeed stack (buyer client, seller setup, channel logic, verifier) is GPL-3.0 open source. source →
antseed org: 9 public repos. The primary `antseed` repo is GPL-3.0, 52 stars, last push 2026-08-12 (actively developed); `antseed-verifier` (GPL-3.0, pushed 2026-08-04) is the validation framework being built in the open, and `openclaw-antseed-stateless-plugin` is GPL-3.0. The token contract is verified on BaseScan ('Exact Match'). Some peripheral repos (pi-antseed, antseed-pay) carry no license file. Direct org/repo reads: license SPDX, stargazers_count, pushed_at; verified-flag from getsourcecode. No independent third-party audit confirmed by this run (recorded as the review's held-below-band reason). Ingestion only, verdict human-set.
Verified Cross-checked Open-source claim holds: GPL-3.0 primary repo, actively pushed, and the verifier framework the roadmap depends on is public. Grade held at api (GitHub metadata + BaseScan verification; no reputable third-party smart-contract audit located). Surfaced by the WS3 coldstart evidence run (org-URL github leg re-run against the resolved antseed org).
Supply Verified· 2 checks
ANTS emits on a disinflationary epoch schedule toward the 1.04 billion cap. source →
71,579,684 ANTS minted, 6.88% of the 1.04 billion cap. The Blockscout series has it rising from 59,225,766 on 2026-08-02, so roughly a fifth of the tokens in existence were minted inside a fortnight. GET total_supply / 1e18, refreshed by scripts/refresh-primary.ts into meta.primary_data with a dated series.
Established on-chain Separated from max_supply_hard_cap deliberately. The cap is a constructor constant and correctly carries drift_policy "static"; what actually moves is how much of it has been issued, and at the current pace that is the number a reader needs. Early-schedule emission is expected to be fast, so this row records the rate rather than judging it; the 10% band will route a human roughly monthly while it stays this steep.
ANTS has a fixed 1.04 billion maximum supply, emitted on a disinflationary epoch schedule with no pre-mine. source →
MAX_SUPPLY = 1_040_000_000e18 is a public constant on the Etherscan/BaseScan-verified ANTSToken contract and is enforced in mint() (reverts MaxSupplyExceeded if totalSupply + amount would exceed it). Live totalSupply 63,313,866 ANTS (~6.09% of cap on 2026-08-12, up from the 40.6M June anchor as emission continues). No pre-mine: the constructor mints nothing (it only sets transfersEnabled=false). mint() is callable ONLY by registry.emissions() (reverts NotEmissionsContract otherwise), so issuance is programmatic, not owner-discretionary. Caveat: the owner (EOA 0xf733...f8bb) can repoint the minter via setRegistry, so the emissions authority is owner-configurable even though the 1.04B ceiling is not. Manual contract-source read (the MAX_SUPPLY constant, the mint() cap guard and emissions-contract gate, the empty constructor) + eth_call MAX_SUPPLY()/totalSupply()/registry() on Base. Ingestion only, verdict human-set.
Verified on-chain The 1.04B fixed-cap + no-pre-mine claim is confirmed at the contract level: the cap is a hard constant enforced in mint(), and nothing is minted at deploy. Emission is minter-gated to the registry's emissions contract; the residual owner power is repointing that registry, not exceeding the cap. Surfaced by the WS3 coldstart evidence run against the manually-supplied Base contract.
Golem Network 4 claims 2026-08-13
Distribution Established
No published concentration claim; GLM came from a 2016 crowdsale with no ongoing emissions. source →
21,315 GLM holders. The top 10 hold 57.7% raw, but 23.83% of supply sits in labelled infrastructure (the largest single holder, at 19.85%, is Octant's RegenStaker contract). Excluding infrastructure the top 10 hold 37.83%, with an identified insider share of 16.59%. Pulled the top holders with contract flags and public labels, classified each as holder/infra/insider, and computed both raw and infrastructure-excluded top-10 concentration. Ingestion only, verdict human-set.
Established on-chain Sits in the middle band once infrastructure is excluded: 37.83% top-10 is neither a fair-launch profile nor an insider-controlled one. The 19.85% in Octant's staking contract is Foundation-directed capital doing public-goods funding, which is a different thing from a whale and should not be read as either. Freshness wired 2026-08-17. The refresher reproduced this verdict's hand-authored figures, which is the check that made wiring safe rather than merely convenient. Caveat carried from the index: the infra-excluded figure rests partly on addresses Blockscout does not label, and a change in how many of those sit in the top ten is a signal to re-trace by hand, not a new measurement.
Open source Verified
Golem is open source, and its node software is published at github.com/golemfactory/yagna. source →
Open source confirmed, with one broken link. The github.com/golemfactory org carries 274 public repositories and core components were pushed within days of this check: ya-service-bus and ya-relay (GPL-3.0) on 2026-08-10, ya-installer on 2026-08-01, golem-stats-backend on 2026-08-12. The GLM contract source is verified on Etherscan under GNU GPLv3. However github.com/golemfactory/yagna, the node repository Golem's own documentation links to, returns 404, and no rename redirect resolves it. Enumerated the org's repositories by push date and by stars, then requested the exact repository URL cited in Golem's installation docs. Ingestion only, verdict human-set.
Verified Cross-checked The open-source claim holds comfortably on the evidence: a large public org, copyleft licences, commits days old, verified contract source. The 404 on the documented yagna repository is a documentation defect rather than a closed-source finding, but it does mean a user following Golem's own install guide lands on a dead page. Worth flagging to them.
Supply Verified
The GNT to GLM migration is supply-conserving: the two tokens together are capped at 1,000,000,000. source →
Confirmed and enforced by the migration invariant. On 2026-08-13 totalSupply() reads 796,565,516.94 GLM and the legacy GNT contract reads 203,434,483.06, which sum to exactly 1,000,000,000.00. GLM has risen ~195,712 since our June 2026 anchor and GNT has fallen by the same amount, so every new GLM is a migrated GNT rather than new issuance. Direct RPC supply reads on both contracts, summed to test the 1B invariant. The GLM contract exposes a minter role (addMinter/renounceMinter/mint) whose only observed use is the migration path; the invariant holding to the cent is the evidence for that. Ingestion only, verdict human-set.
Verified on-chain A confirming positive, and an unusually clean one: the two supplies sum to the 1,000,000,000 cap exactly, so the migration is conserving supply rather than adding to it. Quoting GLM's 796.57M alone understates the GNT+GLM economic total, which is why the 1B is the figure to cite. Freshness wired 2026-08-16: baseline 796,565,517 (migration invariant, should not move at all; tight band).
Revenue Established
The Golem Foundation is funded well enough to develop the network without needing protocol revenue. source →
VERIFIED on-chain: ~11,295 ETH + 50,001,000 GLM in Foundation wallets (token-denominated; ~$25.8M on a 2026-08-17 read). Plus 100,000 ETH staked via Octant (~$189M on the same read) = 3,125 solo validators (Nimbus, public top-20 pool, Foundation Dec-2023 announcement) — beacon-chain-countable, strongly corroborated, exact validator set not yet pinned by us. Total ~$215M against a ~$88M GLM market cap, about 2.4x, on 2026-08-17 Direct on-chain reads for the liquid ETH (auto-refreshed via treasury_eth_liquid = 11,295.637 ETH) + 50M GLM. The 100k is the Octant solo-validator set (~3,136 validators x 32 ETH), a public top-20 pool: CONFIRMED by Octant's own docs AND independent third-party research (OAK Research) at ~3,136 validators / 100k ETH / ~6,470 ETH rewards over 2 years, Nethermind+Nimbus on Qubes OS; beacon-chain-verifiable. (CORRECTS an interim note that wrongly called it unverifiable Diva DVT - that was only a planned transition. Dune could enumerate the validators directly but the independent confirmations make it unnecessary; Dune does NOT cover Nillion's Cosmos chain.)
Established on-chain VERIFIED liquid ~$23M (11,295 ETH + 50M GLM). The 100,000 ETH is the Golem Foundation's Octant project = 3,125 solo validators (Nimbus, public top-20 pool) per the Dec-2023 announcement: a beacon-chain-countable set, strongly corroborated by the announcement + the rewards wallet, exact set not yet pinned by us. Total ~$180M / ~1.85x market cap holds. NOTE on process: two earlier passes mis-stated this (first as fully-verified $180M, then as unverifiable Diva DVT); the accurate position is solo-validator Octant staking, public and beacon-verifiable. Re-read 2026-08-17: the holding is denominated in ETH and GLM, so its dollar value moves with ETH rather than with anything Golem does. The previously carried $180M / 1.85x was frozen at June prices and is now ~$215M / ~2.4x. Editorial restated around the token quantities with the multiple as a dated reading; the direction of the correction favours the project, which is the opposite of the FLOCK case and the reason this defect class is not a bias but an artefact.
Measured facts & caveats 1 note
stats.golem.network rendered empty; active provider count, task count and utilisation are not independently verifiable.
IoTeX 4 claims 2026-06-12
Open source Verified
IoTeX core is open source with active development. source →
iotexproject/iotex-core: Apache-2.0 licensed, not archived, 1,612 stars, 56 open issues, last push 2026-08-10 (active). coldstart github source: repo metadata + SPDX license. Audit presence not confirmed by this run (recorded as a gap).
Verified Cross-checked Open-source claim holds at the code level (Apache-2.0, active development). Not upgraded to onchain-reconciled / O2: the Etherscan-verified contract in the evidence bundle is the ioTube-bridged ERC-20 on Ethereum, not IoTeX L1 core, and a reputable core-contract audit report is unconfirmed here; either would lift the grade. Surfaced by the WS3 coldstart evidence run. Freshness wired 2026-08-17. Wiring limit, stated so nobody reads more into it than it carries: what is re-measured is the star count, because that is the quantity the verdict states. The failure modes that would actually overturn an open-source verdict are the repo being archived, relicensed, or going quiet, and none of those move stars. They are on the Phase 4 backlog. A star-count band is a prompt to go and look at the repo again, not a check that it is still open.
Supply Verified
IOTX has a 10 billion max supply with ~94.4% circulating (capped supply type, minimal future dilution); IoTeX 2.0 adds inflationary staking rewards counterbalanced by EIP-1559 and ioID burns. source →
CoinGecko max_supply 10,000,000,000; circulating 9,441,368,555 (94.4%). Ethereum ERC-20 totalSupply reads 1.0e28 wei (10B); no cap() function present on that contract. coldstart evidence.py gather(): CoinGecko max/circulating supply; RPC totalSupply + Etherscan token supply on the Ethereum representation. NOTE: the on-chain read is the ioTube-bridged ERC-20 on Ethereum, not the IoTeX L1 native token, so it corroborates the aggregate 10B figure but not native L1 emission/cap governance.
Verified Cross-checked The 10B max / 94.4% circulating figures reconcile across the claim and CoinGecko. Grade held at api (aggregate + wrapper corroboration), not onchain-reconciled: IoTeX is an L1 and the queried Ethereum contract is the ioTube bridge representation, not the native chain. The 'capped / minimal dilution' framing carries the IoTeX 2.0 inflationary-staking caveat (net supply effect governance-dependent), which this source does not settle. Surfaced by the WS3 coldstart evidence run.
Revenue Established
Chain-level value locked on IoTeX. Our own framing; IoTeX publishes no TVL claim.
$1,547,785 total value locked across IoTeX chains. DeFiLlama chain-TVL sum for IoTeX, refreshed by scripts/refresh-primary.ts into meta.primary_data.
Established Cross-checked Recorded as a scale anchor with an explicit limit on what it means. Chain TVL measures capital parked in DeFi on IoTeX, not DePIN device activity, so it is not a measure of the thesis this review rates. What it does establish is that almost no capital sits on the chain, which bounds any argument that fee revenue could come from on-chain financial activity rather than from device economics.
NuNet 4 claims 2026-08-12
Censorship Established
The NTX token can be frozen or its issuance controlled by a central admin (token-layer custody surface). source →
The Ethereum NuNetToken is PAUSABLE: PAUSER_ROLE can call pause() and ERC20Pausable's whenNotPaused guard on _beforeTokenTransfer freezes ALL transfers globally (no owner carve-out; currently paused()=false). PAUSER_ROLE and DEFAULT_ADMIN_ROLE are both held by the single deployer EOA 0x863f13e5b505f1eb17803b94ec9d3daf80092165, un-renounced. There is NO per-address blacklist and NO fee/transfer tax (plain ERC20PresetMinterPauser). So the token-layer levers are: global pause (freeze everyone) + uncapped mint + role management, all controllable by one deployer EOA (plus the bridge contract's delegated MINTER_ROLE). Manual read of the verified contract (pause path, no blacklist/fee logic) + live pause/role state + owner classification. Ingestion only, verdict human-set.
Established on-chain An on-chain custody anchor, not a re-grade. Like FET the token is globally pausable and admin-mintable, but the powers sit with a single un-renounced deployer EOA (the PHA custody posture) rather than a multisig. A global pause (freeze all) rather than a per-address blacklist. Orthogonal to the review's censorship_resistance score, which assesses the NuNet compute/network layer, not token custody. Surfaced by the WS3 coldstart evidence run (pausable=true).
Open source Verified
NuNet develops its core software in the open under a permissive licence. source →
Confirmed. NuNet's primary code home is the GitLab group gitlab.com/nunet (group id 6160918, 30+ projects), with a GitHub mirror at github.com/nunet (11 public repos). The flagship Device Management Service (github.com/nunet/device-management-service) is Apache-2.0, not archived, and actively maintained (pushed 2026-07-20). The core platform is public under a permissive licence. Direct GitLab group + GitHub org/repo metadata reads (project count, licence, pushed_at, archived). Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: the open-source claim holds (GitLab-primary 30-project group + Apache-2.0 active DMS). The coldstart tool's GitHub-only heuristic missed it (NuNet is GitLab-primary), so this was verified directly against both hosts - a banked reminder that a GitHub gap is not an absence of open source. Surfaced by the WS3 coldstart evidence run.
Supply Established
NTX has a fixed 1 billion supply across all chains (no inflation). source →
The current 3-chain total matches (~999.8M ~ 1B, confirmed in the total_supply anchor above), BUT the 1B is not enforced by any single contract. The Ethereum NuNetToken (0xf0d3...7935, non-proxy) is an OpenZeppelin ERC20PresetMinterPauser with an UNCAPPED mint(to, amount) gated to MINTER_ROLE and no maximum-supply check. Live role reads: MINTER_ROLE has TWO holders - the deployer EOA 0x863f13e5b505f1eb17803b94ec9d3daf80092165 AND the TokenConversionManager contract 0x6c0d706c75b559549938c0b1de863cf7f042d1cf (the owner-controlled cross-chain burn-and-mint bridge). The deployer EOA also holds DEFAULT_ADMIN_ROLE (can grant/revoke roles) and PAUSER_ROLE; none renounced. So new NTX can be minted on Ethereum by the bridge (expected, should be balanced by burns elsewhere) OR directly by the deployer EOA (unbalanced), and the global 1B relies on off-contract bridge accounting + operator discipline, not a code cap. Manual enumerable-AccessControl role reads + holder classification + source read confirming mint() has no cap guard. Ingestion only, verdict human-set.
Established on-chain Complements the total_supply anchor with the mint-authority dimension (the FET pattern). The total matches, but there is no hard cap: an uncapped mint() is live, held by the bridge conversion contract AND a bare deployer EOA that can mint directly outside the bridge. Graded established (mint authority is a verified fact; nothing has been over-issued, so not inflated) rather than match (no code cap to match). Weaker posture than FET's 3-of-5 Safe - here the admin is a single un-renounced EOA. Surfaced by the WS3 coldstart evidence run (admin_functions=[mint, pause]). ATTRIBUTION 2026-08-13: the multichain-token page is the only one stating the cross-chain constant. Two caveats: its mint split (581.25M NTX-ETH) contradicts the split on NuNet's own token-overview and network-tokenomics pages (631.25M), and every page is stamped 'Last update 15th August 2023'. It is also policy rather than code - our on-chain read found an uncapped mint() with two live MINTER_ROLE holders.
Grass 4 claims 2026-06-25
Censorship Established
The GRASS token can be frozen by a central authority (token-layer custody surface). source →
The GRASS SPL mint has freezeAuthority = NULL, so token accounts cannot be frozen (no token-layer freeze lever). Note the counterpoint on the supply side: the mint authority is live (a Squads multisig, corrected 2026-08-14), so the centralisation risk here is dilution, not transfer-freezing. Manual SPL freeze-authority read via the coldstart Solana source. Ingestion only, verdict human-set.
Established on-chain On-chain custody anchor: no freeze authority (accounts can't be frozen). Orthogonal to the review score. The live MINT authority (a Squads multisig) is the material centralisation, captured in the supply_dynamics verdict.
Open source Established
Grass (Wynd Network) develops its node software in the open. source →
Confirmed CLOSED. The project's GitHub org github.com/Wynd-Network has 0 public repositories, and there is no separate public org (github.com/getgrass 404s). The Grass node runs as a proprietary browser extension / desktop client with no published source, so the network client cannot be audited or independently verified. Direct GitHub org enumeration. Ingestion only, verdict human-set.
Established Cross-checked Confirms the closed-source reality (no open-source claim to match, only the closed reality to verify): 0 public repos, proprietary node client. Surfaced by the WS3 coldstart run.
Supply Established
GRASS has a fixed 1 billion supply. source →
The current supply matches (getTokenSupply on the GRASS SPL mint Grass7B4RdKfBCjTKgSqnXkqjwiGvQyFbuSCUJr3XXjs, 9 decimals = 999,993,124.25 ~ the 1B total/max), BUT the cap is NOT enforced: mintAuthority is SET to 31rYartQwHeBMjAe2MgGpffGV57fQY3kug4BDN8tLGqQ. CORRECTED 2026-08-14: that account is a SQUADS MULTISIG VAULT, not a single keypair. It is System-Program-owned with no data, which is what the original read saw, but it is OFF-CURVE (no private key can exist for it) and Solscan labels it 'Grass Multisig' with a #Squad Vault tag. So the cap is still NOT token-enforced and additional GRASS can still be minted beyond 1B, but doing so requires the multisig's threshold rather than one signature. Manual SPL reads via the coldstart Solana source + authority owner-classification. Ingestion only, verdict human-set.
Established on-chain The supply matches but is admin-mintable: the cap is policy, not code. CORRECTED 2026-08-14, and this one was wrong in our favour of alarm: the authority was called 'a single keypair, the weakest posture in the campaign'; it is a Squads multisig ('Grass Multisig', off-curve). The error came from inferring 'wallet' from System-Program ownership plus zero data, which a Squads vault also satisfies. Flag for the monthly review: the supply_dynamics evidence is materially less damning than recorded. Graded established, not match (no enforced cap) and not inflated (nothing over-issued yet). Surfaced by the WS3 T2 Solana source.
Measured facts & caveats 2 notes
Own-surface interrogation (2026-06-09): Grass publishes NO public operational surface. www.grass.io states only 'over 8.5M users'; the app (app.grass.io) is login-gated; no network-stats/explorer page exists - the opposite of io.net's public explorer and Aethir's public dashboard. The claims are uncheckable by construction: node count, bandwidth and reputation are all measured by Grass's validator, which the docs state is currently 'a singular, centralised entity'. The only on-chain footprint is batched ZK session-proof checkpoints submitted by that one validator (data-provenance proofs, opaque to node/bandwidth/user counts). So '8.5M users / 1M concurrent / 3 PB-day' remain self-attested, off-chain, and uncheckable even via the chain.
Entirely closed-source: zero public repositories on the Wynd-Network GitHub. ZK-proof, traffic-separation, node and validator code claims cannot be independently verified.
ElizaOS 4 claims 2026-06-13
Censorship Established
The ELIZAOS token can be frozen by a central authority (token-layer custody surface). source →
The canonical ELIZAOS SPL mint (DuMb...) has freezeAuthority = NULL, so token accounts cannot be frozen - no token-layer freeze/censor lever. (The mint authority is a live SPL multisig, so the centralisation is on the dilution axis, captured in supply_dynamics, not transfer-freezing.) Manual SPL freeze-authority read via the coldstart Solana source. Ingestion only, verdict human-set.
Established on-chain On-chain custody anchor: no freeze authority on the canonical mint (accounts can't be frozen). Orthogonal to the review score. Read on the DuMb canonical mint, not the retired legacy mint.
Open source Verified
elizaOS develops its agent framework in the open under a permissive licence. source →
Confirmed, emphatically. The github.com/elizaOS org's flagship repo `eliza` is MIT with 19,020 stars and was pushed on the assessment date - one of the most-starred open-source AI-agent frameworks on GitHub. Other org repos (army MIT, knowledge) are active. The framework is fully public under a permissive licence. Direct GitHub org/repo metadata reads (licence, stars, pushed_at). Ingestion only, verdict human-set.
Verified Cross-checked A strong confirming positive: MIT, ~19k stars, actively developed flagship framework. Surfaced by the WS3 coldstart run. Freshness wired 2026-08-17. Wiring limit, stated so nobody reads more into it than it carries: what is re-measured is the star count, because that is the quantity the verdict states. The failure modes that would actually overturn an open-source verdict are the repo being archived, relicensed, or going quiet, and none of those move stars. They are on the Phase 4 backlog. A star-count band is a prompt to go and look at the repo again, not a check that it is still open.
Supply Established
ELIZAOS (ex-ai16z) supply is emission-capped at 11B. source →
Read on the CANONICAL post-rebrand mint DuMbhu7mvQvqQHGcnikDgb4XegXJRyhUBfdU22uELiZA (9 decimals): getTokenSupply = 9,458,494,670.58 ELIZAOS, consistent with the recorded ~9.38-9.45B (continuous emission drift) toward the 11B max. mintAuthority is SET to D4MYCaoyT5XZFBke16JwaNJa6TWDeCTuZMYErukMGerU, an account owned by the SPL Token program, i.e. an SPL MULTISIG - so ELIZAOS is actively minted toward 11B under multisig control, not a fixed supply. THRESHOLD READ 2026-08-13: that multisig is numRequiredSigners=1 of numValidSigners=2, so a SINGLE one of the two signers can mint; 'multisig' overstates the protection, which is one signature, with a spare key rather than a second approver. IMPORTANT: CoinGecko's 'ai16z' id still resolves to the RETIRED legacy HeLp6NuQ... mint (~1.1B); grading must use the DuMb canonical mint. Manual SPL reads via the coldstart Solana source + authority owner-classification (SPL multisig). Ingestion only, verdict human-set.
Established on-chain Adds the mint-AUTHORITY dimension to the existing total_supply match: supply is minted toward 11B under an SPL multisig, not fixed. Banks a Solana stale-mint caveat: CoinGecko still points 'ai16z' at the retired HeLp mint (~1.1B) post-rebrand, so the coldstart auto-resolution grabs the wrong mint - always verify against the project's canonical mint. ATTRIBUTION 2026-08-13: elizaOS frames 11B as the ceiling of a gradual expansion from the old 6.6B ai16z supply ('total supply could expand to up to 11B'), never as a hard-coded cap. Our on-chain read of the null mint authority is the stronger fact. SHARPENED 2026-08-13: the mint authority's threshold was never read, only its type. It is 1-of-2, which is a single-signature control with key redundancy, not shared control. Recorded because the difference between 1-of-2 and (say) 4-of-7 is the whole of what 'multisig' is taken to mean.
Measured facts & caveats 2 notes
ElizaOS is a development framework, not an on-chain protocol; daily/monthly active usage is not tracked publicly and the 50,000+ agents claim is not independently verifiable.
DAO treasury current value is not independently verifiable; estimates range $10M-$25M across sources of varying reliability.
OriginTrail 4 claims 2026-06-25
Distribution Verified
Fair/broad distribution: 50% sold in the ICO, vesting complete, ~23% insider (moderate and fully vested), no overhang. source →
Ethereum TRAC top-10 holders = 51.6% raw, but ~24.8pp is infrastructure — a staking-hub proxy (EternalStorageProxy 12.9%), a bridge/deployment proxy (L1ChugSplashProxy 7.1%), other proxies, and Kraken. Infra-excluded top-10 is ~28% of total (~32% of circulating) = D1 'moderate' under the rubric, consistent with the claimed moderate/vested distribution. The only real-holder concentration is two large unlabelled EOAs (12.0%, 8.2%); it does not reach D0 (>50%). sources/holders.py: top holders + is_contract + public labels, classified holder/infra/cex/burn; concentration = raw balance / total_supply (decimals cancel). Infra-exclusion drops contracts + labelled CEX + burn.
Verified on-chain The raw top-10 (51.6%) reads as high concentration but is ~half infrastructure (staking hub + bridge proxies + Kraken); infra-excluded it is moderate (D1), matching the 'fair/moderate, fully vested' claim and the 11/15 score. First distribution verdict authored with the new coldstart holder-source (infra-exclusion). Re-check item: the two large unlabelled EOAs (12.0% / 8.2%) — if either is an exchange or a founder wallet the read shifts. Attribution 2026-08-13: the TGE structure post on OriginTrail's official Medium, authored by co-founder Tomaz Levak, is the only project-published source for the split (50% presale/crowdsale, 18% founders and preICO, 5% team and advisors, 2-year vesting at 12.5% per quarter). Medium returns 403 to automated requests, so a curl-based link check will flag it as bot-gated; it resolves in a browser. Freshness wired 2026-08-17. The refresher reproduced this verdict's hand-authored figures, which is the check that made wiring safe rather than merely convenient. Caveat carried from the index: the infra-excluded figure rests partly on addresses Blockscout does not label, and a change in how many of those sit in the top ten is a signal to re-trace by hand, not a new measurement.
Open source Verified
OriginTrail core (the DKG node and protocol) is open source under Apache-2.0, with active development. source →
TracToken contract source-verified on Etherscan; github.com/OriginTrail/ot-node Apache-2.0, not archived, 234 stars. Active development in OriginTrail/dkg (V10, 2026). coldstart github source (ot-node: Apache-2.0, last push 2026-03-27) + Etherscan-verified TracToken source. NOTE: the tool sampled ot-node (older V6-era node); the actively-developed repo is OriginTrail/dkg (V10 shipped mid-2026), so 'active development' holds. Audit report not confirmed by this run.
Verified on-chain Open-source claim holds (Apache-2.0 + verified contract). The coldstart run sampled ot-node (V6-era, last push 2026-03); active development lives in OriginTrail/dkg (V10, 2026). A reputable audit report is unconfirmed here (would lift toward O2). Distribution is now graded in a separate verdict (holder-source added 2026-08-10).
Supply Verified
500M fixed cap, zero inflation, no token printing (the cleanest supply profile in DeAI). source →
TRAC (TracToken, Ethereum 0xaa7a…) is a 2018 OZ MintableToken whose mint() is gated by canMint (require !mintingFinished); mintingFinished() reads true on-chain, so minting is permanently disabled and no code path can raise the 500M total. Transfers themselves require mintingFinished, corroborating the flag. eth_call the mintingFinished() getter (selector 0x05d2035b) -> true; read the verified source (mint() has onlyOwner+canMint; transfer requires mintingFinished). Confirms a hard cap enforced in code, not merely a current-total match.
Verified on-chain Verifies the CAP MECHANISM, complementing the total_supply figure-match above. Surfaced by the WS3 coldstart run, whose ABI heuristic flagged a mint function + EOA owner (0xe80d…) as a soft-cap candidate; on-chain verification cleared it — the mint entrypoint is permanently locked, so the EOA owner cannot inflate supply. An honest 'no token printing' claim, confirmed (the honesty bound working in the confirming direction).
Walrus 4 claims 2026-07-02
Open source Verified
Walrus is developed in the open. source →
Confirmed and actively developed. MystenLabs/walrus is Apache-2.0, 407 stars, not archived, with 116 open issues and a push on the day of this check. Direct GitHub repo metadata read. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: permissive licence, same-day commits, open issue tracker. Covers licence and development activity, not audit coverage.
Supply Verified
WAL has a fixed maximum supply of 5,000,000,000 tokens. source →
Confirmed. The WAL coin type on Sui mainnet (0x356a...4f59::wal::WAL, 9 decimals) reports a total supply of 4,999,929,701.36 WAL, which is 70,298.64 below the 5 billion headline, consistent with a fixed mint minus a small burn rather than ongoing issuance. Direct read of the coin's on-chain supply through Sui's GraphQL API, the JSON-RPC method having been deprecated on public fullnodes. Ingestion only, verdict human-set.
Verified on-chain Walrus's first independently verified figure. Everything else we hold on this project is self-reported, so this is the one number a reader can check without taking Mysten's word for it.
Revenue Editorial
Walrus earns storage fees at a fixed $0.023 per GB per month, paid in WAL. source →
no independent source exists Queried api.llama.fi /summary/fees/walrus and /protocol/walrus (both not-found) on 2026-07-02.
Editorial Editorial Feeds Returns Revenue Sustainability (10/25). Real mechanism, unverified scale. revenue_annual_usd left null. Re-check when Walrus is added to DeFiLlama or an on-chain fee index becomes available.
Thesis verdicts 1 check
Walrus stores roughly 467TB of data for real users, making it a working decentralised storage network rather than a testnet. source →
no independent source exists Cross-checked the 2,300TB third-party claim against Walrus's own ~467TB network total; internally inconsistent.
Editorial Editorial Used only with explicit self-reported framing; never as a verified figure. ATTRIBUTION CORRECTED 2026-08-13: the 467TB figure is published by the SUI blog (27 March 2026), not by Walrus, and it is cumulative unencoded data at that date. Walrus's own about page currently states '356TB active data stored', a lower number on a different basis. Both are self-reported; the verdict stays unverifiable and the 467TB should always carry its March-2026 date.
Measured facts & caveats 1 note
Walrus is not tracked on DeFiLlama (verified 2026-07-02: api.llama.fi /summary/fees/walrus and /protocol/walrus both not-found) and no independent storage-fee aggregator covers it. Storage is priced at a self-reported fixed $0.023/GB/month, paid in WAL. No independent USD reconciliation exists.
Fetch.ai / ASI Alliance 4 claims 2026-06-13
Censorship Established
The FET/ASI token can be frozen or its issuance controlled by a central admin (token-layer custody surface). source →
The FetchToken ERC-20 is PAUSABLE: the PAUSER_ROLE holder can call pause(), and _beforeTokenTransfer inherits ERC20Pausable's whenNotPaused guard, so a pause freezes ALL token transfers globally (currently paused()=false, i.e. not paused). PAUSER_ROLE is held by the same 3-of-5 Gnosis Safe (0x8400ac...) that holds MINTER_ROLE and DEFAULT_ADMIN_ROLE. There is NO per-address blacklist and NO fee/transfer tax (plain OZ ERC20PresetMinterPauser; the lone 'fee' mention in the source is an OZ doc comment). So the token-layer levers are: global pause (freeze everyone) + uncapped mint + role management, all behind the 3-of-5 multisig; there is no selective per-account censorship path. Manual read of the verified contract (_beforeTokenTransfer -> ERC20Pausable whenNotPaused; no blacklist/fee logic) plus live paused() and PAUSER_ROLE member reads. Ingestion only, verdict human-set.
Established on-chain An on-chain custody anchor, not a re-grade. Unlike ROBO/COOKIE (no pause, permissionless transfer layer), the ASI token CAN be globally frozen by its 3-of-5 admin Safe — closer to the OpenServ/Sentient admin-surface findings, but via a global pause rather than a per-address blacklist. Orthogonal to the review's censorship_resistance score, which assesses the Fetch network / agent layer, not token custody. Surfaced by the WS3 coldstart evidence run (pausable=true).
Open source Verified
The ASI Alliance (Fetch.ai + SingularityNET) develops its core software in the open under permissive licences. source →
Confirmed. The flagship agent framework fetchai/uAgents is Apache-2.0, 1,636 stars, not archived, pushed 2026-08-11 (one day before assessment) — actively developed. The chain node fetchai/fetchd (Cosmos-SDK based) is public and active (pushed 2026-05-27). On the SingularityNET side of the merger, singnet/snet-cli is Apache-2.0 and active (pushed 2026-07-24). The verified token contract itself is Apache-2.0. So the core agent framework, chain node and marketplace tooling are all public under permissive licences. Direct GitHub repo metadata reads (licence, stars, pushed_at, archived) + getsourcecode licence. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: the open-source claim holds across both merged lineages (Fetch uAgents/fetchd + SingularityNET snet-cli), all permissively licensed and recently active. Surfaced by the WS3 coldstart evidence run. Freshness wired 2026-08-17. Wiring limit, stated so nobody reads more into it than it carries: what is re-measured is the star count, because that is the quantity the verdict states. The failure modes that would actually overturn an open-source verdict are the repo being archived, relicensed, or going quiet, and none of those move stars. They are on the Phase 4 backlog. A star-count band is a prompt to go and look at the repo again, not a check that it is still open.
Supply Established
FET/ASI has a fixed supply of ~2.714 billion (the recorded max supply implies no further issuance). source →
The current supply is real and matches (on-chain total 2,714,384,546.672 = the recorded figure exactly), BUT the cap is NOT contract-enforced. FetchToken (0xaea4...ad85) is a non-proxy OpenZeppelin ERC20PresetMinterPauser: it exposes an UNCAPPED mint(to, amount) gated only to MINTER_ROLE, with no maximum-supply check anywhere in the code. The MINTER_ROLE, PAUSER_ROLE and DEFAULT_ADMIN_ROLE are all held by a single address (0x8400ac235ed4f139a3e05670a9a3c724e448129b), which is a Gnosis Safe with a 3-of-5 threshold (getThreshold()=3, 5 owners); none of the roles have been renounced. So the ~2.714B figure is a matter of multisig POLICY, not code: the 3-of-5 Safe can mint arbitrary additional FET at any time. The token is also ERC20Burnable (holder-initiated burns). Manual RPC reads of the enumerable AccessControl role sets + Safe config, cross-read against the verified contract source (confirmed mint() has no cap guard and the contract is not a proxy). Ingestion only, verdict human-set.
Established on-chain QUALIFIES our own prior data_sources note, which called the on-chain read a confirmation of the 'fixed cap'. The supply figure matches, but there is no hard cap: an uncapped mint() is live behind a 3-of-5 Gnosis Safe that also holds the pause and role-admin powers. Materially weaker than the immutable hard caps confirmed for Heurist/OriginTrail/OpenServ (mint dead or capped) — here issuance is ongoing multisig discretion. Graded established (the mint authority is a verified fact; nothing has been over-issued, so not inflated) rather than match (there is no code cap to match). Surfaced by the WS3 coldstart evidence run, which flagged admin_functions=[mint, pause] and pausable=true. ATTRIBUTION 2026-08-13: the ASI token page publishes the supply figure but never states it is capped, and the Alliance docs give a different target ('The total token supply will be set to 2.63055 billion $ASI tokens'). The no-further-issuance half of our claim is our inference from the contract, not their assertion.
Nillion 3 claims 2026-08-13
Governance Established
The NIL token's logic and supply can be changed by a central authority (token-layer control surface). source →
Stage G0: instant unilateral control. NIL is a UUPS-upgradeable ERC-1967 proxy (implementation 0x0a53...b8f1) whose DEFAULT_ADMIN, UPGRADER and MINTER roles are all held by a single 3-of-5 Gnosis Safe (0x9d80...0742, getThreshold 3, getOwners 5). Three signatures can replace the token's logic outright or mint new NIL, with no timelock anywhere in the path. MINTER is additionally held by an EmissionsController contract (0x6316...2f46), the routine issuance path. The deployer has renounced every role, which is the right hygiene. Read the proxy's implementation slot, enumerated all 15 RoleGranted events from genesis, tested current role membership for each grantee, then resolved the surviving holders' contract types. Ingestion only, verdict human-set.
Established on-chain Recorded as measured rather than as a failed claim, because Nillion publishes nothing about these roles either way. The reader-facing point stands on its own: an upgradeable token with mint authority behind a 3-of-5 multisig is a trust assumption, and it is not disclosed. A timelock on the UPGRADER role would be the cheapest meaningful fix.
Utility Editorial
Blacklight node operators must stake a minimum of 70,000 NIL against their node to be assigned verification work by Nillion's Ethereum L2, and are rewarded from a pool equal to 0.5% inflation of the 1B total supply. source →
Not independently re-summed. There is no public staking-statistics endpoint for the L2 Blacklight set, and the previous target (a nillion-1 Cosmos LCD) no longer exists to query. Previously we attempted a nillion-1 LCD re-sum. That target is gone: per Nillion's own migration guide the Cosmos chain was scheduled to halt on 23 March 2026 at 13:00 UTC, with distribution continuing through a Merkle-claim contract on Ethereum. Any future check must target the Ethereum L2 staking contracts, not a Cosmos endpoint.
Editorial Editorial VERDICT RE-AUTHORED 2026-08-13. The previous version described ~13.8M NIL staked across 41 nodes on the nillion-1 Cosmos chain and recorded the re-sum as blocked because every public nillion-1 endpoint was unreachable. The endpoints were not flaky, the chain was being shut down: Nillion migrated NIL to Ethereum and halted nilChain on 23 March 2026, roughly five months before we noticed. We had been treating a decommissioned network as a temporarily broken one. The telco operators are real but run PetNet enterprise nodes, not nillion-1 validators, which our earlier wording conflated. Still unverifiable, now for an honest reason: no public endpoint publishes the L2 Blacklight staking set. Also note the 0.5% reward-pool inflation, which sits against the 'total supply 1B' figure our supply verdict anchors on.
Supply Verified
NIL has a total supply of 1,000,000,000 tokens. source →
1,010,060,031.59 NIL on-chain total (2026-08-13), up from 1,009,194,647 in June 2026 as the EmissionsController continues to mint Direct RPC totalSupply() read (6 decimals), cross-read against Blockscout. Ingestion only, verdict human-set.
Verified on-chain On-chain total confirms the recorded ~1B within 1.0%, and the drift since June is emissions, not a discrepancy. The liquid NIL is the Ethereum ERC-20 (CoinGecko lists NIL on Ethereum only); Nillion's Cosmos chain uses a separate unil staking denom. Note there is no on-chain cap: see token_control for who can mint.
Measured facts & caveats 1 note
112K+ users / 641M+ documents / 1.4M inferences are off-chain node-application metrics on nilDB/nilAI; no public stats API; not derivable on-chain. Phase 2 credits burn NIL for nilDB/nilCC (no public burn figure; Ethereum NIL fixed at 1B) and nilAI revenue runs through Stripe (off-chain), so paid usage and revenue are also unverifiable.
Openmind 3 claims 2026-08-12
Censorship Established
The ROBO ERC-20 is a standard, permissionless transfer token (no freeze / blacklist / transfer tax). source →
Confirmed permissionless at the token-transfer layer: the Etherscan-verified ROBO contract is a plain OpenZeppelin ERC-20 + ERC20Permit + Ownable with NO pause, NO blacklist/allowlist, and NO fee-on-transfer / tax hook; the full function set is name/symbol, EIP-712 permit plumbing, burn (holder self-burn), restoreSupply (owner re-mint to cap), updateNameAndSymbol (one-time), and view getters. Transfers cannot be frozen or censored by the owner. The residual owner powers are supply-side (restoreSupply) and cosmetic (already-spent name change), and the owner has NOT renounced (still EOA 0x3f68...8135). Full manual read of the verified main contract (function enumeration + confirmation that no _update/_beforeTokenTransfer override, blacklist mapping, or fee logic exists) cross-checked against the coldstart admin_functions/pausable facts. Ingestion only, verdict human-set.
Established on-chain An on-chain custody fact, the OPPOSITE of the OpenServ/Sentient token-admin findings: ROBO's transfer layer carries no censorship surface (no pause/blacklist/tax), so at the token level it is permissionless. This is orthogonal to the review's censorship_resistance score, which is driven by the runtime/FABRIC stack rather than the ERC-20; recorded as an established anchor, not a re-grade. The one caveat is supply-side (owner restoreSupply), captured under supply_dynamics. Surfaced by the WS3 coldstart evidence run.
Open source Verified
OM1, Openmind's robot runtime, is MIT-licensed open source with an active contributor base. source →
OpenMind/OM1 (the flagship runtime, 'Modular AI HAL for Robots') is MIT-licensed, 2,894 stars, 992 forks, NOT archived, last push 2026-08-12 (actively developed). The OpenMind org carries 16 non-fork repos; the OM1 family (OM1, OM1-modules, OM1-avatar, OM1-sim) is uniformly MIT and recently pushed. Context, not a downgrade: the FABRIC coordination-layer / veROBO contracts the token thesis rests on are only partly public (fabric-nft exists; the coordination contracts are forward-dated), so the OPEN part is the runtime, not yet the token's on-chain economic layer. Direct repo/org reads: license SPDX (MIT), stargazers_count, forks_count, archived flag, pushed_at; org non-fork repo enumeration. Contributor-count and audit presence not re-counted by this run (recorded as gaps). Ingestion only, verdict human-set.
Verified Cross-checked Open-source claim holds for the runtime: OM1 is genuinely MIT-licensed, high-star, and pushed the day of assessment. The star count grew since research (2,787 -> 2,894), consistent with active development. Grade held at api (GitHub metadata; no reputable third-party audit confirmed here, and BscScan notes none submitted for the BNB deployment). Surfaced by the WS3 coldstart evidence run (org-URL github leg re-run against the resolved OpenMind/OM1 repo). Freshness wired 2026-08-17. Wiring limit, stated so nobody reads more into it than it carries: what is re-measured is the star count, because that is the quantity the verdict states. The failure modes that would actually overturn an open-source verdict are the repo being archived, relicensed, or going quiet, and none of those move stars. They are on the Phase 4 backlog. A star-count band is a prompt to go and look at the repo again, not a check that it is still open.
Supply Verified
ROBO has a fixed 10 billion maximum supply; capped, no further dilution. source →
TOTAL_SUPPLY = 10_000_000_000e18 is a public constant in the Etherscan-verified contract, minted once to the deployer in the constructor; on-chain totalSupply already equals 10,000,000,000 (RPC + Blockscout + Etherscan agree). There is no mint path that can exceed the cap: the only re-mint function, restoreSupply(to) onlyOwner, reverts once totalSupply >= TOTAL_SUPPLY, so the 10B ceiling is enforced. Caveat, not a cap breach: the contract is a plain non-upgradeable OZ ERC-20 + Ownable whose owner is still an EOA (0x3f68...8135, not renounced), and restoreSupply lets that owner RE-MINT previously-burned supply back up to the cap to an address it chooses, so the public burn() is owner-reversible rather than permanently deflationary. updateNameAndSymbol is a one-time owner power already spent (the token's on-chain name is 'Fabric Protocol'). coldstart evidence.py gather() (bs_total_supply, onchain_total_supply, token_supply_raw all 1e28 wei = 10B) + getsourcecode: read the TOTAL_SUPPLY constant, the constructor _mint, and the restoreSupply cap guard (require(currentSupply < TOTAL_SUPPLY)); owner() via eth_call 0x8da5cb5b. Ingestion only, verdict human-set.
Verified on-chain The 10B fixed-cap claim is confirmed at the contract level: the cap is a hard-coded constant, supply is already at it, and no function can exceed it. Ethereum is the LayerZero-OFT hub holding the full mint; the Base/BSC OFT spokes are minted against locked hub supply, not additional tokens. The honesty nuance surfaced by reading the source: an owner EOA retains restoreSupply (re-mint burned tokens up to the cap) so the 'buyback/deflation' narrative is owner-reversible, not a one-way burn. Surfaced by the WS3 coldstart evidence run. ATTRIBUTION CORRECTED 2026-08-13: the $ROBO token is issued by FABRIC FOUNDATION, not OpenMind, and OpenMind's own whitepaper disclaims it: 'OpenMind is not the issuer of the $ROBO token... No representations or statements by OpenMind should be attributed to or relied upon as statements of Fabric Protocol Ltd.' Our source of record for ROBO token claims is fabric.foundation. The cap is fixed at 10,000,000,000 but an emission controller keeps releasing tokens up to it, so circulating supply still grows.
Theta Network 3 claims 2026-06-25
Open source Verified
Theta develops its protocol in the open under a permissive/copyleft licence. source →
Confirmed. The github.com/thetatoken org carries 57 public repositories; the core node theta-protocol-ledger is GPL-3.0, 363 stars, not archived, pushed on the assessment date. The Go reference client and protocol are public. Direct GitHub org/repo metadata reads. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: 57-repo org, GPL-3.0 reference client, active.
Supply Verified
THETA has a fixed 1 billion supply (non-inflationary). source →
Confirmed fixed. The Theta chain explorer API (explorer-api.thetatoken.org/api/supply/theta) returns total_supply = 1,000,000,000 and circulation_supply = 1,000,000,000, corroborated by CoinGecko (total 1B / max 1B / circulating 1B). THETA is non-inflationary by protocol design: it is the fixed-supply governance/staking token minted in full at genesis, while TFUEL is the separate, inflationary gas token. So there is no THETA issuance mechanism. Direct read of the chain explorer supply endpoint, cross-checked against CoinGecko and the protocol's fixed-supply design. Ingestion only, verdict human-set.
Verified Cross-checked A confirming positive: THETA is a fixed-1B genesis token with no issuance path (TFUEL is the inflationary gas token, a separate denom). Two agreeing sources (chain explorer + CoinGecko). THETA is a bucket-D own-chain (no ERC-20, no Cosmos LCD) authored via a direct explorer-API read.
Ocean Protocol 3 claims 2026-06-13
Open source Verified
Ocean Protocol is open source (Compute-to-Data, contracts, libraries) under Apache-2.0, over seven years of development. source →
OceanToken contract source-verified on Etherscan (0x967d…); github.com/oceanprotocol Apache-2.0, not archived, 220 stars, last push 2026-04-04. coldstart github source (Apache-2.0, active) + Etherscan-verified OceanToken source. The 'multiple audits' element is an editorial claim, not independently re-verified this run.
Verified on-chain Grounds Ocean's genuine open-source strength (its 'technology outperforms the tokenomics' thesis). Supply/distribution stay deferred this run: after the 2024 merger 81% of OCEAN converted to FET, so supply is merger-shaped (already covered by the total_supply anchor above) and the raw top-10 90.99% reflects conversion-locked tokens, not live holder concentration (needs infra-exclusion). token_utility is authored below. Surfaced by the WS3 coldstart run.
Utility Established
OCEAN is a decentralized, community-usable token: the Foundation renounced contract control in mid-2023, giving the community full autonomy to use OCEAN for staking, governance, payment or any purpose. (Separately, the Foundation's docs state OCEAN 'has no intended utility value'.) source →
On-chain owner() = 0x0: the OCEAN contract's ownership is renounced, independently confirming the about-us 'Foundation renounced all control (mid-2023)' claim and making mint/pause (onlyOwner) permanently uncallable — OCEAN is immutable and permissionless. Two coexisting official framings: about-us says the community may use OCEAN for any purpose; docs say OCEAN 'has no intended utility value... not a staking, governance or payment token'. In practice protocol-native utility is thin: the flagship Ocean Network (GPU compute, Mar 2026) settles in USDC not OCEAN; a buyback-and-burn (Predictoor revenue) reduces the ~268M capped supply. Ocean exited the ASI Alliance in Oct 2025 and governs independently. eth_call owner() (0x8da5cb5b) = 0x0 confirms the renouncement on-chain; combined with reading both official token pages and the flagship product's settlement currency. The load-bearing renounced/permissionless leg is on-chain; the thin-practical-utility qualifier is editorial.
Established on-chain Corrects a WS3 mischaracterization (thanks to Rob's flag): OCEAN is NOT a deprecated residual. Ocean exited the ASI Alliance (Oct 2025) and is an active independent project; the token is Foundation-renounced (mid-2023) and permissionless. The docs 'no intended utility value' line is a legal/regulatory disclaimer, not a statement that the token is useless, and coexists with the community-usable autonomy on the about-us page. Functional protocol-native utility is nonetheless thin today (Ocean Network settles in USDC). The Token Utility (10/20) and Value Accrual (5/20) scores and the editorial's face-value 'no utility' framing are routed to the review queue for reconsideration in this light.
Measured facts & caveats 1 note
Ocean Market activity and data-NFT adoption metrics are not publicly disclosed; cannot independently verify how many datasets are published or consumed.
Heurist 2 claims 2026-08-10
Open source Verified
Heurist's stack (miner client, agent framework, mesh tooling) is open-source. source →
heurist-network org: 35 public repos, actively developed. Active components carry permissive licenses (heurist-mesh-mcp-server, heurist-finance, gpt-search-web, heurist-skills-cli MIT; x402 Apache-2.0); the flagship heurist-agent-framework (820 stars, last push 2026-07-26) carries a custom/unrecognised license. The miner-release GPU-mining client (72 stars) is public and not archived but frozen since 2025-02-26, ~1 month after mining was paused (Jan 2025). coldstart github source + direct org/repo metadata reads (license SPDX, archived flag, last push). Audit presence not confirmed by this run (recorded as a gap).
Verified Cross-checked Open-source claim holds: extensive public repos, permissive licenses on the active tooling, recent commits. Context, not a downgrade: development has pivoted from the GPU-mining/inference layer (miner-release frozen Feb 2025) to the agent framework + mesh tooling, so the mining client the token's original inference thesis rests on is no longer maintained. Grade held at api (GitHub metadata; no reputable audit confirmed here). Surfaced by the WS3 coldstart evidence run.
Supply Verified
HEU has a fixed 1 billion maximum supply with no further dilution; the token contract is a plain non-upgradeable ERC-20. source →
MAXIMUM_SUPPLY = 1_000_000_000e18 hard-coded in the verified HEU contract and enforced in mint() (reverts HEU__CanNotExceedMaximumSupply past the cap); on-chain totalSupply already equals 1B, so mint() can never emit another token. Contract is a plain OpenZeppelin ERC-20 + Ownable (not a proxy); owner() = the deployer EOA 0xfb93...cd33f, but its only live powers are mint (dead at cap) and transferOwnership. No pause, blacklist, fee, or upgrade functions exist; renounceOwnership() is overridden to revert (permanent but powerless owner). coldstart evidence.py gather() + a manual contract-source read: getsourcecode returned the mint() cap check and the constant MAXIMUM_SUPPLY = 1_000_000_000e18; owner() via eth_call 0x8da5cb5b; function enumeration confirmed no pause/blacklist/upgrade. Ingestion only, verdict human-set.
Verified on-chain The 1B fixed-cap claim is confirmed at the contract level: the cap is hard-coded and enforced, and supply has already reached it, so no dilution is possible regardless of the owner EOA. The coldstart bundle's mint+ownable admin flag looked like a soft-cap risk (the Aethir pattern); rigorous verification CLEARED it (the OriginTrail confirming pattern): an honest fixed supply. Canonical Ethereum is the full 1B mint; the Base address 0xEF22 is an OptimismMintableERC20 bridge holding only the ~193.1M bridged-to-Base portion. Surfaced by the WS3 coldstart evidence run. Attribution 2026-08-13: the tokenomics page states the 1,000,000,000 maximum plainly. It does not state non-upgradeability, and the same page publishes a staking emission of '50% APR from protocol emissions' with 500M in a mining-and-staking bucket vesting over 120 months, so circulating supply keeps growing under a fixed cap.
Measured facts & caveats 1 note
The TGE figures are frozen: mining has been paused since January 2025, so the self-reported usage is stale and does not reflect current activity.
Sentient 2 claims 2026-08-10
Censorship Established
Independent anchor: the token-contract-level custody/censorship surface of the SENT ERC-20 (distinct from the editorial's model-layer OML censorship assessment). source →
The SENT ERC-20 is a PAUSABLE, UUPS-UPGRADEABLE contract. Implementation SentientTokenV1 exposes pause()/unpause() and _authorizeUpgrade gated by DEFAULT_ADMIN_ROLE; the admin role can freeze all transfers and replace the logic with arbitrary code (add minting, a blacklist, or balance seizure). Currently paused() = false (not paused). EIP-1967 admin slot is empty (UUPS pattern); upgrade/pause authority sits in AccessControl roles, whose current holders (top holders are multisig Safes) are not further attributed here. getsourcecode on the implementation (pause + _authorizeUpgrade onlyRole(DEFAULT_ADMIN_ROLE)); eth_getStorageAt on the EIP-1967 impl + admin slots; eth_call paused(). Ingestion only, verdict human-set.
Established on-chain A token-layer custody fact the model-layer censorship score does not capture: SENT holders' transferability and balances are subject to an upgradeable, pausable contract under admin-role control. Not graded against the 8/15 censorship score (that score assesses model censorship, a different axis) and not a re-grade; recorded as an independent medium-severity anchor for custody risk. Distribution note (deferred, not graded): the same run measured ~69.64% of supply in insider multisig Safes and ~21% circulating on Ethereum, consistent with the review's overhang note; a firm token_distribution_fairness verdict is deferred pending per-Safe attribution and multi-chain (Base/Polygon/Arbitrum) holder data. Surfaced by the WS3 coldstart evidence run.
Supply Verified
SENT has a fixed 34,359,738,368 (2^35) maximum supply. source →
On-chain total = max = 34,359,738,368 (2^35), confirmed via CoinGecko + Blockscout + RPC totalSupply. The current implementation SentientTokenV1 has NO public mint function (supply is set once at initialisation), so the figure is fixed by the deployed code. IMPORTANT: the token is an ERC1967 UUPS proxy, so this fixed-supply property is code-level, not immutable: DEFAULT_ADMIN_ROLE can replace the implementation (a future version could add minting). coldstart evidence.py gather() (CoinGecko/Blockscout/RPC totalSupply) + a manual read of the verified implementation source: no public mint(); _authorizeUpgrade gated by DEFAULT_ADMIN_ROLE; EIP-1967 admin slot empty (UUPS). Ingestion only, verdict human-set.
Verified on-chain The 34.36B (2^35) fixed-supply figure is confirmed on-chain and the live code has no mint path. Unlike an immutable ERC-20 (e.g. Heurist), the cap here is not tamper-proof: the UUPS proxy lets the admin role upgrade the logic, so 'fixed supply' holds only for the current implementation. Corrects a fossilised 'pre-token' label; SENT has a live Ethereum ERC-20. Surfaced by the WS3 coldstart evidence run. ATTRIBUTION 2026-08-13: the canonical page is the Sentient Foundation tokenomics post; sentient.xyz/blog/tokenomics 301s to it, and docs.sentient.xyz never states a supply figure at all. Their own wording is exact: 'The total supply is 34,359,738,368 SENT, exactly 2^35.'
Reconciliation ledger
2 checks across 2 projects not yet on the full spine. Each is one claim tested against an independent source. Projects sit here when the spine cannot be run on them yet, which for a pre-token project means there is no token contract, supply or distribution to check. Search and filter arrive in the Explore tab.
Intelligent Internet 1 check
token supply
checked: No live tradeable supply on any production chain; CoinGecko returns no coin for the II token (confirmed 2026-06-25). A Solana address exists but carries no circulating supply.
why?
- source:
- CoinGecko /search (empty coins array) + settlement-chain status
- method:
- CoinGecko /search query returned an empty coins array (2026-06-25). The settlement chain is a custom L0 still marked "Planned" (Bitcoin Core v25 base); nothing to index until emission begins.
- note:
- Pre-token: nothing to reconcile until emission begins. Recorded as unverifiable, not a pass; promote to a supply anchor once the token is live and circulating.
Nous Research 1 check
token supply
checked: No circulating/total supply on any chain; CoinGecko returns no coin for nous-research (confirmed 2026-06-25). On-chain Solana addresses are Psyche coordination/research programs, not an SPL token mint.
why?
- source:
- CoinGecko /search (empty coins array) + on-chain address inspection
- method:
- CoinGecko /search returned an empty coins array (2026-06-25). No TGE has occurred; the Psyche 40B training claim is self-reported with no settleable independent measure.
- note:
- Pre-token by necessity until TGE. Recorded as unverifiable, not a pass; promote to a supply anchor on token launch.
The Verdict Matrix
Every spined project, scored on the same 11 dimensions. Colour is our verdict. Read down a column to compare one dimension across all projects, or across a row for one project's whole profile.
| Project | Freedom | Returns | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Infra | Gov | Distrib | Cens | Data | Open | Util | Accrual | Supply | Rev | Liq | ||
| Morpheus 7.8/5.8 | ✓ | ↑ | ✓ | ◔ | ◔ | ✓ | ↓ | ◆ | ✓ | ↑ | ◆ | |
| Venice 5.7/6.9 | ◔ | ↑ | ✓ | ✓ | ◔ | ↑ | ◆ | ✓ | ✓ | ✓ | ✓ | |
| Bittensor 5.6/6.3 | ↺ | ↑ | ↑ | ✓ | ✓ | ✓ | ◆ | ◆ | ✓ | ↑ | ✓ | |
| Virtuals Protocol 4.2/6.9 | ✓ | ↑ | ✓ | ✓ | ◔ | ✓ | ◆ | ◆ | ✓ | ✓ | ✓ | |
| Aethir 3/6.4 | ◔ | ↑ | ↑ | ✓ | ◔ | ↑ | ◆ | ◆ | ↑ | ↑ | ✓ | |
| Akash Network 6.6/6.8 | ◆ | ✓ | ✓ | ✓ | ↺ | ✓ | ||||||
| NEAR Protocol 6.3/7.3 | ↺ | ○ | ✓ | ◆ | ↑ | ✓ | ||||||
| io.net 3.9/5.4 | ↑ | ◆ | ◆ | ↑ | ◔ | ◔ | ||||||
| Render Network 3.2/7.2 | ○ | ◆ | ◆ | ◆ | ↑ | |||||||
| Vana 5.9/5.5 | ↑ | ◆ | ↑ | ✓ | ◆ | |||||||
| Olas 6.2/3.5 | ↑ | ◆ | ✓ | ◆ | ✓ | |||||||
| Ora Protocol 4.8/4.2 | ↑ | ↑ | ✓ | ↓ | ✓ | |||||||
| Gensyn 5.2/3.4 | ◆ | ✓ | ↑ | ✓ | ✓ | |||||||
| peaq 5.3/4.8 | ↑ | ✓ | ◆ | |||||||||
| Flux 7.6/5.7 | ↑ | ✓ | ✓ | |||||||||
| Oasis Network 6.2/4.6 | ◆ | ↓ | ✓ | ✓ | ||||||||
| FLock.io 5.5/5.8 | ↑ | ✓ | ↑ | ✓ | ||||||||
| Phala Network 5.5/5 | ○ | ◆ | ✓ | ✓ | ||||||||
| Sahara AI 3.3/4.5 | ◆ | ↑ | ○ | ◆ | ||||||||
| OpenServ 2.4/3.4 | ✓ | ↑ | ◆ | ✓ | ||||||||
| Warden Protocol 4.7/4.8 | ✓ | ✓ | ◆ | |||||||||
| Giza 4.2/3.4 | ✓ | ◆ | ◆ | ◆ | ◆ | ◆ | ||||||
| Nosana 5.8/4.6 | ◔ | ◆ | ✓ | ◔ | ✓ | |||||||
| Auki 4.9/3.6 | ◆ | ◆ | ✓ | ◆ | ||||||||
| Allora Network 5.2/4.7 | ◆ | ✓ | ✓ | |||||||||
| AntSeed 6.6/3.2 | ✓ | ◆ | ✓ | ✓ | ||||||||
| Golem Network 6.9/4.6 | ◆ | ✓ | ✓ | ◆ | ||||||||
| IoTeX 6.4/5 | ✓ | ✓ | ◆ | |||||||||
| NuNet 4.7/3.3 | ◆ | ✓ | ◆ | |||||||||
| Grass 3.7/5.5 | ◆ | ◆ | ◆ | |||||||||
| ElizaOS 5.2/2.7 | ◆ | ✓ | ◆ | |||||||||
| OriginTrail 6/6.6 | ✓ | ✓ | ✓ | |||||||||
| Walrus 6.2/5.5 | ✓ | ✓ | ○ | |||||||||
| Fetch.ai / ASI Alliance 5/5.5 | ◆ | ✓ | ◆ | |||||||||
| Cookie DAO 2.2/5 | ◆ | ◆ | ✓ | |||||||||
| Nillion 5.6/4.2 | ◆ | ○ | ✓ | |||||||||
| Openmind 5.6/3.7 | ◆ | ✓ | ✓ | |||||||||
| Theta Network 5.9/5.3 | ✓ | ✓ | ||||||||||
| Ocean Protocol 5.5/3.9 | ✓ | ◆ | ||||||||||
| Heurist 3.8/2.5 | ✓ | ✓ | ||||||||||
| Sentient 4.9/5 | ◆ | ✓ | ||||||||||
Hover a cell for the finding; click it to open that project's receipt back in Overview. 5 of 41 spined projects are checked on all 11 measures so far; the rest fill in over time. A faint outline means not assessed — shown honestly, never passed off as a pass.
Explore
Every receipt in one searchable ledger. Filter by project, dimension, verdict or free text; click a row to open its signed receipt back in Overview.
314 of 314 receipts
Methodology
How we check every claim, what each verdict means, and how the dataset is signed: the full method →
Verdicts
- We checked this claim against independent on-chain data and it holds up.
- We measured this independently on-chain. The project made no self-reported figure to check, so this is a dated independent anchor, not a verification of a claim.
- The reported figure is higher than independent data shows. Treat the headline number with caution.
- The reported figure is lower than independent data shows.
- Accurate when first reported, but on-chain data has since moved. Do not cite the old figure as current.
- This is independently verifiable, we just have not run the check yet. A to-do on our side, never a mark against the project. Distinct from "unconfirmed", where no independent source exists.
- We checked but there is no independent source that could confirm this (genuinely private or off-chain). Distinct from "unverified": this is a permanent limit, not a to-do. Not disproven, just unconfirmable - lean on what is confirmed.
Independence of the check
- We independently reconstructed the figures from on-chain data - the deepest check we do.
- Checked against an independent third-party data source (e.g. DeFiLlama, Messari).
- Reviewed editorially and figures flagged, but not independently reconstructed from chain data.
- We have not run an independent check on this project yet. This is NOT a clean result - it just means unchecked.
For agents
The machine-readable twin of this page. Everything a human reads here is derivable from the same signed substrate a machine can pull, so the two surfaces cannot drift.
- /api/scores.json → CORS-open JSON feed: every project's dual scores and integrity reconciliations, dated to the signed substrate.
- /llms-full.txt → The full corpus in the llms.txt format for AI ingestion (/llms.txt for the index).
- Substrate MCP → Read-only Model Context Protocol endpoint over the signed substrate, for agent tooling.
A dated snapshot, not a live feed. Raw figures refresh on a schedule; a verdict only changes when a person re-checks it. Read the date. This is not financial advice. Compare projects.