Methodology.

Four columns across the top of the ledger, all time, every enabled chain. Nothing in them changes with the page filters.

• Raises — Funded = raises with status FUNDED, COMPLETED or FROZEN; Releasing = FUNDED; Complete = every tranche paid; Frozen = stopped by an upheld challenge; Unsuccessful = FAILED. Liquidity locked = 15% of the effective amount raised, for every raise with a pool, locked forever.
• Challenges — every tranche challenge by its ruling: upheld in full, upheld in part, raise frozen, dismissed, expired unruled, pending. Upheld rate = the three upheld outcomes over every ruled challenge.
• Treasury — every treasury proposal by its outcome: executed, blocked for rework, blocked as bad faith, challenge dismissed, challenge expired, pending. Execution rate = executed over every proposal with an outcome.
• Tranches — Immediate = paid without a request (the 10% that releases at funding); Requested = ever requested; Paid; Blocked = frozen by a ruling; Pending = requested or challenged now. ETH released = the on-chain amountPaid of every paid tranche, summed, the schedule figure standing in where a payout was indexed without an amount. Average lag = request to payout, over paid tranches that were requested.

The command bar's counts ("17 events", "Challenges 0") are taken with the same predicates the log's own queries use, for the selected window, per chain and per category, so the bar and the list agree. Refund waves count as one event per raise per UTC day, as they appear in the log.

Schema caveat: raises that failed or froze, and tranches that were blocked, carry no timestamp of their own for that transition; the log dates them by the row's last update. Treasury blocks and challenges sort by the proposal's createdAt. Per-transition timestamps are a pending schema change.

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.

Unsuccessful and frozen raises surface REFUND_WAVE events in the log, aggregated by raise and day, giving backers and observers a view of when users actually claimed.

The cells are cached for 5 minutes (edge + KV) keyed by router address and window. The log shows the last 30 days by default and 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, a table of funded raises or a queue of open items (the ledger is event-first; each raise page and /raises carry those)
• All-time governance outcomes as a scoreboard (every challenge and proposal outcome is in the log and its counts; a dedicated page is planned)

/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:

The one exception is the Wave 1 cohort on the homepage, a fixed set of raises rather than an open listing: it is shown in Ending Soon order (raise deadline ascending; raises that have already finalised sit after every running one, most recently closed first). The basis is the same comparator, applied server-side in apps/web/src/lib/wave1-showcase.ts.

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