Methodology

• Funded = campaigns with status=FUNDED. Includes raises that are shipping AND raises that completed all tranches.
• Shipping = status=FUNDED AND at least one tranche was paid in the trailing 90 days. A "delivery" metric, not a "this is a good investment" metric.
• Frozen = status=FROZEN. Raises that were stopped by governance (upheld challenge with RAISE_FROZEN resolution).
• Failed = status=FAILED. Raises that did not reach their goal by the deadline.

All-time counts, broken down by every Challenge.resolution variant. Counts are not filtered by the page window — trust signals should not be cherry-picked by the viewer.

Upheld rate = (upheld full + upheld partial + raise frozen) / (resolved challenges). Excludes pending challenges from the denominator. If no challenges have resolved yet, displays 0%.

All-time counts, broken down by status and challenge resolution. Proposals can enter eight distinct states:PROPOSED, CHALLENGED,EXECUTED, CHALLENGE_REJECTED,CHALLENGE_EXPIRED, BLOCKED_REWORK,BLOCKED_MALICIOUS, TERMINATED.

Exec rate = executed / (executed + blocked·rework + blocked·malicious + challenge·rejected + challenge·expired). A high exec rate means most proposals clear the governance pipeline; a low one means founders are being held accountable.

Schema caveat: TreasuryProposalRecord has createdAt and executedAt but no per-state-transition timestamp. BLOCKED and CHALLENGED events in the ledger log sort by createdAt (when the proposal was filed) rather than when the state change occurred. This understates recency for non-executed outcomes. A follow-up schema change would add per-transition timestamps.

All-time counts of tranche state transitions, plus aggregate ETH released and average request-to-pay lag.

ETH released = sum of Tranche.amountPaid across all paid tranches.

Avg lag = mean of (Tranche.paidAt − Tranche.requestedAt) across all paid tranches that have both timestamps. A low number means tranches clear quickly; a high number means either governance challenges or resolver backlog.

We deliberately do NOT report a "claim rate" or "on-schedule percentage" because any threshold choice would be arbitrary. Raw average lag in days is more honest.

LP locked ETH is approximated as 15% of Campaign.totalRaised summed across all raises with lpPoolAddress set. 15% is the share of raised funds that Vibestarter seeds into the Aerodrome LP pool at finalization per protocol rules.

This is an approximation — the actual LP value drifts with token price. The number should be read as "ETH that was committed to LP at finalization and is now locked indefinitely per protocol rules", not as current LP TVL.

We do not report a "refund discipline" percentage. Refunds are claimed by users, not pushed by the platform. A low claim rate reflects user behavior, not platform accountability — so the metric would be meaningless.

Instead, the ledger reports a binary statement: whether the refund mechanism is available on all failed raises. Failed raises surface REFUND_WAVE events in the log aggregated by raise and day, giving backers and observers a view of when users actually claimed.

Velocity counts respect the page-level window filter (default 30 days). Shows tranches paid, ETH released, milestones verified, challenges filed, and treasury executed/blocked in the trailing window. Unlike the health panels, velocity changes with the filter — it's a measure of recent activity, not a trust metric.

Stats are cached for 5 minutes (edge + KV) keyed by router address and window. The event log polls every 60 seconds while the tab is visible. Pause the live updates with the[ Pause ] button in the filter bar if you need a stable snapshot for screenshots or review.

The indexer populates these records from on-chain event logs. End-to-end freshness from tx confirmation to ledger visibility is typically 30–90 seconds depending on indexer queue depth.

• Pre-raise events (launches, raise-started, individual contributions) — those live on the live activity feed
• Per-user refund clicks (aggregated into refund waves)
• Quest or staking events
• Market price, FDV, volume, or any performance data (that belongs to /raises and each raise detail page)
• A trust score or composite governance grade (too gameable)
• A directory of raises (the ledger is event-first, not raise-first — use /raises to browse)

/feed is the everything-stream: 12 event types merged into one chronological firehose — LAUNCH, RAISE_STARTED, CONTRIBUTION, TRANCHE_REQUESTED, TRANCHE_PAID, CHALLENGE_FILED, CHALLENGE_RESOLVED, TREASURY_PROPOSED, TREASURY_EXECUTED, FOUNDER_UPDATE, FUNDED, FAILED. Every event derives from the Postgres mirror of on-chain activity, ordered strictly by timestamp (newest first). The stream is identical for every viewer: no personalization, no ranking, no operator selection.

Contributions below 0.01 ETH (the protocol minimum) are excluded as dust. The page polls every 30 seconds; the server caches the merged stream for 15 seconds, so what you see is at most ~45 seconds behind the indexer.

All raise-listing surfaces (homepage, /raises) default to chronological order (newest launch first). Every other ordering is a user-selected sort over an objective, stated basis. The comparators live in one module (apps/web/src/lib/raise-metrics.ts) and are:

• Newest — launch record creation time (DB timestamp; launch block number as fallback), descending.
• Most Raised — on-chain totalRaised (wei), descending.
• Most Backers — on-chain unique backer count, descending.
• 24h Inflow — sum of contribution amounts with timestamps in the trailing 24 hours, descending.
• Ending Soon — raise deadline ascending; already-ended raises sink to the bottom.
• Highest Reputation — founder Ethos score (third-party), descending.
• Provenance Quality — attestation-capsule completeness tier (deterministic, completeness-based), descending.
• Token Performance — 24h price change from DEX market data (funded raises only), descending.
• Stage — founder-declared project stage (Concept → Growth), either direction.

There is no composite or velocity-based ranking(no "trending"/"hot" score) anywhere — a formula blending multiple signals into an opaque rank was removed in July 2026 and is prohibited by the platform's presentation-neutrality rules. Test for any ordering here: could a block explorer compute it from public data? If not, it doesn't ship.

The homepage metrics band and the MCP get_platform_stats tool share one computation. Definitions:

• Total Raised — sum of effective raised wei across all visible raises (Pro-Rata raises count their goal, not oversubscription).
• 24h Inflow — sum of all contribution amounts in the trailing 24 hours across visible raises.
• Backers — sum of per-raise on-chain contributor counts (a wallet backing two raises counts twice).
• Disbursed — modeled: 85% of each funded raise's effective raise (the tranche escrow share) × the paid tranches' release percentages.
• In Escrow — modeled: live raises' full balances + funded raises' unpaid tranche escrow (85% share minus disbursed).
• Median Raise — median of non-zero effective raises, in ETH.

Honesty note: "Disbursed" and "In Escrow" are an accounting model over the indexed schedule (the protocol's fixed 85/15 escrow/liquidity split and tranche percentages), not per-block chain reads. Per-raise treasury and escrow balances shown on cards and detail pages are live on-chain reads. The model and the chain agree except transiently around fee claims and refund events.