Methodology.

How every number on the platform is calculated: the ledger, the live feed, every listing sort, and the aggregates.

Source: /ledger · Data sourced directly from the Supabase Postgres mirror of on-chain events.

Router scoping

Every ledger query is filtered by the router addresses of the chains this deployment serves: one on Base (chain ID 8453, NEXT_PUBLIC_VIBES_ROUTER) and one on Robinhood Chain (chain ID 4663, NEXT_PUBLIC_VIBES_ROUTER_4663). Each environment is configured with its own, so production and staging (which runs mainnet test contracts) each show only the raises their routers deployed. Records with no router address or a mismatched router are hidden (fail-closed).

Event taxonomy

The ledger surfaces 24 first-class post-raise event types across 6 categories: lifecycle, tranches, challenges, treasury, progress, refunds. Each Challenge.resolution variant (APPROVED_FULL, APPROVED_PARTIAL, RAISE_FROZEN, REJECTED, UNRESOLVED) is a distinct event type. Same for each TreasuryProposalRecord.challengeResolution variant. Pre-raise events (launches, contributions) are not surfaced; those belong to the home page and /raises.

The register

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, and raises refunding their holders after a freeze; Releasing = FUNDED; Complete = every tranche paid; Frozen = stopped by an upheld challenge, or wound down, its holders refunded; 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.

Event counts

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.

Refunds

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.

Data freshness

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.

What the ledger intentionally does not show

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)

The live activity feed (/feed)

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

Listing sorts (every basis, exactly as computed)

The raise listing (/raises) defaults 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.

The one exception is the home page, which shows the raises in one order it states beside them, the same in its slices and its grid (see "The home page" below).

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.

Platform figures (/api/stats)

The home page, the ledger, /api/stats and the MCP get_platform_stats tool state these figures from one computation over every raise this deployment lists, on Base and Robinhood Chain (each chain's own figures are in figures.byChain). The home page shows the first five and, in Liquidity's place, the raises funded (fundedCount, below):

Raised (totalRaised): ETH raised by live and funded raises. Failed raises and raises refunding their backers are left out; a pro-rata raise counts its cap, not what came in above it. With it, the ETH backed in the last 24 hours (inflow24h).
Backers (totalBackers): distinct wallets with a backing that was not refunded, across live and funded raises. A wallet that backed two raises counts once. With it, those whose first backing on Vibestarter came in the last 24 hours (firstTimeBackers24h).
Live raises (totalCampaigns): raises taking backings now, a paused raise included.
In escrow (totalInEscrow): what the escrows still hold to release. That is 85% of each live raise (the rest pairs into liquidity when it funds), and each funded raise's releases not yet paid, a frozen raise's included. The next release to unlock is dated from the raise's funding, as its escrow unlocks it.
Released (totalDisbursed): what the releases paid out, as each escrow recorded it (the on-chain amountPaid), with the schedule's figure standing in where a payout was indexed without an amount. With it, the releases paid (releasesPaid).
Liquidity (liquidityLocked): the ETH each funded raise paired into its pool, 15% of its effective raise, locked for good.

The answer also carries the median funded raise (avgRaiseSize, a name older than the figure), the raises that reached funding (fundedCount: those releasing, those with every release paid and those frozen since; the home's Raises funded), the tokens trading (tokensLaunched) and every raise listed (campaignCount).

Two limits. The 24-hour figures count a backing from when Vibestarter recorded it, since a backing's block time is not stored, so a backing recorded late reads as new once. A frozen raise counts in escrow what it held to release when it froze: the refunds its holders have claimed since are not indexed yet, so that figure does not fall as they claim.

The home page (/)

The home page shows the six platform figures above, then the raises it lists, as the slices beside the founder panel and as cards below, in one order it states: live raises (a paused one included), closing soonest; upcoming raises with a confirmed date, opening soonest; raises with refunds open, latest deadline first; then funded raises still releasing, most recently funded first. A raise still being finalized sits with its outcome. A failed raise leaves once every backing is refunded, a frozen raise once its holders can no longer claim, and a raise whose every release is paid stays on /raises. The cards below stand in groups, each in its own order: upcoming (opening soonest), live (closing soonest) and funded (most recently funded, a raise refunding after a freeze among them), six to a group; a raise that met its target and is still being finalized reads Finalizing in a group of its own (latest close first), and a failed raise refunding its backers has one too, each while one is. Nothing is featured: every raise uses the same template. While no raise is scheduled, the upcoming group holds the next raise’s open slot and the founders approved to raise who have not opened one yet, newest application first, by category and application day only: a founder is named when their raise is announced.

Its activity column lists, newest first: backings, buys and sells of 0.05 ETH or more, token claims, a raise opening, funding and its pool, an unsuccessful close, a freeze after an upheld challenge, release requests and payouts, challenges filed and ruled, founder updates, and $VIBES stakes and unstakes. A backer is named (else a short wallet); a buyer, claimer or staker is a short wallet; a seller is never named (the wallet a sell shows is the pool's router). The counts above the rows are the true counts for the last 24 hours, not filters. A backing reads its time from when Vibestarter recorded it, since its block time is not stored.

← back to ledger