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)
• 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)