# Vibestarter: Full public documentation > Time-released crowdfunding for vibecoded apps on Base and Robinhood Chain. Generated from docs/public/; do not edit this file by hand; run `pnpm --filter web gen:llms`. --- # Vibestarter: Overview Vibestarter is a crowdfunding platform on **Base** and **Robinhood Chain** for **vibecoded apps**: software built collaboratively by humans and AI coding agents. Backers fund a project up front; the funds are released to the founder gradually over time, and backers can challenge a release if a project goes off the rails. ## What makes it different - **Funds release by time, not milestones.** A funded raise pays out **10% immediately**, then **15% each month for six months**. There is no milestone-gating: the schedule is fixed and on-chain. - **72-hour challenge windows.** Before each monthly tranche is released, backers have a 72-hour window to challenge it. Challenges are resolved on-chain. - **Liquidity is locked indefinitely.** When a raise finalizes, its LP position is created and permanently locked in a soulbound contract. - **Verifiable AI provenance.** Every token launched through Vibestarter carries an **Origin Capsule**: an on-chain record proving the founder's identity and which AI agent/tooling built the project. ## Key concepts - **Raise**: a crowdfunding campaign for one project. Raise types: `FIXED_GOAL`, `OPEN_ENDED`, `PRO_RATA`. States move `ACTIVE → FUNDED → COMPLETED` (or `FAILED`). - **Founder**: the person (or team) running a raise. - **Backer / Contributor**: someone who funds a raise. - **Tranche**: one time-released disbursement of funds to the founder. - **Challenge window**: the 72-hour dispute period before a tranche releases. - **Provenance / Origin Capsule**: the on-chain attestation of founder identity and AI-agent authorship. - **VIBES**: the protocol token. Fixed supply of 1,000,000,000, live on Base (`0xefFC8815487084a97edfdfF968b56Ea123421Acb`, the canonical supply) and on Robinhood Chain (`0x9A73D60b9c8C2d330EB6D885E69fCc1399c33C18`, the same token contract with the same full supply). A LayerZero OFT bridge at `/bridge` connects them: an adapter on Base (`0x408021Cb4ef1033675C70CF97788F3E03f45A381`) holds the $VIBES that has been sent across, and an adapter on Robinhood Chain (`0x37F26e3025b3DC50e0EE9f610D386803B42D0685`) holds the unbridged part of that chain's supply as a reserve, so the amount locked on Base always equals the amount in circulation on Robinhood Chain (total supply minus the reserve). Limit 10,000,000 VIBES per hour per direction; approval needed in both directions. Staking accepts the Base token only. ## The architecture, briefly - A launch router deploys a per-raise **escrow** contract that holds funds and enforces the tranche schedule and challenge windows. - Reading raise data is **permissionless**: anyone (including an autonomous agent) can enumerate raises and read their state directly on-chain or via the public API. - See **For agents & integrators** for how to read the platform programmatically. --- # How funding works Vibestarter uses a **time-released** funding model. This page explains the mechanics a backer or an agent needs to reason about a raise. ## The tranche schedule When a raise reaches its goal and finalizes, funds are released to the founder on a fixed schedule: - **10% kickstart**: released immediately on finalization. - **15% per month for six months**: six monthly tranches. The schedule is enforced on-chain by the raise's escrow contract. It is **not** milestone-gated: the founder does not need to prove milestones to unlock the next tranche. Instead, backers police releases through challenges. ## Challenge windows Before each monthly tranche is released, there is a **72-hour challenge window**. During that window: - A token holder meeting the raise's holdings threshold, and its eligibility gate (an on-chain eligibility credential on new raises), can **raise a challenge** against the upcoming tranche, posting a token bond. - Other eligible token holders can **support** or **oppose** the challenge. - The challenge is resolved on-chain. If it succeeds, the tranche is withheld per protocol rules. Challenge windows are the core accountability mechanism, replacing milestone approvals. ## Liquidity When a raise finalizes, a portion is used to create a liquidity position (LP). That LP is **locked indefinitely** in a soulbound locker contract; it is not released after a fixed period. Trading fees from the locked LP accrue to a fee claimer. ## Raise types - **`FIXED_GOAL`**: a single funding target; contributions are accepted up to a hard cap. - **`OPEN_ENDED`**: a soft cap defines the minimum to keep funds; contributions continue past it. - **`PRO_RATA`**: contributions are committed and then allocated pro-rata. ## Reading a raise's numbers Every raise exposes, both on-chain and via the public API: - goal / soft cap / hard cap - total raised and contributor count - deadline and raise-start time - the tranche schedule and each tranche's unlock time - the current challenge (if any) and the challenge threshold See **For agents & integrators** for the exact endpoints and on-chain view functions. --- # For agents & integrators Vibestarter is designed to be **read by autonomous agents**. This page is the quick-start for reading the platform programmatically. Vibestarter is *permissioned-write, permissionless-read*: reading raises and platform data needs no account, no key, and no wallet. ## Read via the public API All of these endpoints are public, unauthenticated, JSON (unless noted), and CDN-cached. The machine-readable contract is the OpenAPI spec: - **OpenAPI 3.1 spec:** `/api/openapi.json` - List raises: `GET /api/campaigns` - Read one raise (by launch tx hash or the `vibes` slug): `GET /api/campaigns/by-tx/{txHash}` - Platform stats: `GET /api/stats` - Global activity feed: `GET /api/feed` - Recent contributions: `GET /api/backings/recent` - Curated event ledger: `GET /api/ledger` - Circulating VIBES supply (plain text): `GET /api/supply/circulating` - Staking stats: `GET /api/staking/stats` - A raise's AI build-activity feed: `GET /api/mcp/activity?campaignId=...` Reads are rate-limited per IP but generously; responses are cache-friendly. ## Read directly on-chain You do not need the backend at all. On Base mainnet: - Enumerate raises via the escrow **factory**'s `getAllEscrows()` (or watch its `EscrowCreated` events). - For each escrow, call `getCampaign()` for founder, token, goal, soft cap, deadline, `totalRaised`, and state; plus tranche and challenge view functions. - Read AI provenance from the registry contract (`isRegistered`, attestation lookups). Contract addresses and **verified deployed ABIs** are published as a versioned bundle at `/api/contracts.json` (Base mainnet). These are the ABIs actually deployed on-chain, so they never drift. ## Backing a raise Agent backing is **built and switched off for now**. The rails: registration via on-chain ERC-8004 agent identity, explicit agent terms, sanctions screening, per-agent contribution caps, and two payment paths: the agent's own ETH via a signed `contribute()`, or **USDC over x402** (one 402-negotiated HTTP request; the platform converts and lands the contribution on-chain attributed to the paying agent). While it is off, `contribute()` requires a terms-acceptance signature and agent signature requests are refused. When it is switched on, `/llms.txt`, the OpenAPI spec, and `/docs/agents` will advertise the endpoints automatically. ## Connect via MCP A remote, read-only **MCP server** (Streamable HTTP) is available at `/mcp`. Point any MCP-capable agent host at it. Tools: `list_raises`, `get_raise`, `search_raises`, `get_platform_stats`, `how_it_works`. No authentication is required. ## Discovery surfaces - `/llms.txt`: concise index for language models (links to this content, the API, the MCP server, and the contract bundle). - `/llms-full.txt`: the full public documentation in one file, for ingestion. - `/.well-known/ai-plugin.json`: agent manifest pointing at the OpenAPI spec and MCP server. - `/api/openapi.json`: the OpenAPI 3.1 description of the public API. - `/mcp`: the remote MCP endpoint (Streamable HTTP). --- # Connect your agent (MCP) Vibestarter runs a **remote, read-only MCP server** so any MCP-capable agent host can discover and read raises without writing a line of integration code. It speaks the **Streamable HTTP** transport. - **Endpoint:** `https://app.vibestarter.xyz/mcp` - **Auth:** none. All data is public and read-only. - **Environment:** the endpoint serves whichever environment it runs in (production = Base mainnet). ## Tools | Tool | Arguments | Returns | |---|---|---| | `list_raises` | `status?` (ACTIVE·FUNDED·COMPLETED·FAILED), `search?`, `limit?` (1–100), `offset?` | Array of raise summaries, newest first | | `get_raise` | `idOrSlug` (launch tx hash, or `vibes`) | One raise's detail, or a not-found message | | `search_raises` | `query`, `limit?` (1–50) | Raise summaries matching the keyword | | `get_platform_stats` | — | Totals: raised, disbursed, backers, funded count, average raise size | | `how_it_works` | — | Plain-text explainer of the funding model | A raise summary includes: `slug`, `title`, `tagline`, `status`, `fundingModel`, `goalWei`, `totalRaisedWei`, `contributorCount`, `deadline`, `tokenSymbol`, `tokenAddress`. `get_raise` adds `description`, `raiseType`, and `softCapWei`. ## Configure your host **Claude Code** (`claude mcp add`): ```bash claude mcp add --transport http vibestarter https://app.vibestarter.xyz/mcp ``` **Cursor / Windsurf / generic** (`mcp.json`): ```json { "mcpServers": { "vibestarter": { "url": "https://app.vibestarter.xyz/mcp" } } } ``` **Programmatic** (`@modelcontextprotocol/sdk`): connect a `StreamableHTTPClientTransport` to the endpoint URL, then `listTools()` / `callTool()`. ## Notes - **Read-only.** There are no write or backing tools in the MCP. Agent backing is built and arrives when raises go live on the platform; until launch it is not available (see the for-agents doc). - **Rate limits** apply per IP; keep polling reasonable. - The endpoint previously lived at `/api/mcp/mcp`; that path continues to work, but `/mcp` is the canonical URL. - Prefer this MCP for conversational agents; for raw HTTP integrations, the same data is available via the REST API described in `/api/openapi.json`, and on-chain via the contract bundle at `/api/contracts.json`. --- # Launch Admission & Moderation Policy This page states the criteria under which Vibestarter grants launch access and moderates listings. It exists so that every admission and moderation decision can be checked against a published rule. Every decision described here is recorded in an internal audit log (screening results, review decisions with reasons, and moderation actions with before/after snapshots). *Version 1.3 · 2026-10 (adds §4.1, posts in a raise's Community; 1.2 added the §2.2 founder withdrawal right; 1.1 added the §2.2 decision bands). Changes to this policy are versioned in the repository alongside the code that enforces it. Human-facing render: `/docs/admission` on the app; this file is also served to agents via llms.txt.* ## 1. How launch access works Launching a raise on mainnet requires a platform-issued launch signature. The signature is issued when **all** of the following hold. Checks 1–5 are automatic: no human judgment is involved, and no wallet meeting them is refused on any other unstated ground. Check 6 is the criteria-bound review, described in §2. 1. **Authenticated wallet.** You control the wallet (Sign-In-With-Ethereum session). 2. **Completed signup.** The Starter Card signup has been completed for the wallet. 3. **Sanctions screening.** The wallet is screened against a bundled snapshot of the OFAC SDN ETH-address list on every request; an exact match is refused. On Base mainnet a Chainalysis on-chain oracle runs as an additional screen when deployed; if the oracle is unavailable or errors after the SDN list has passed, the request is allowed (the SDN list is the authoritative screen) and the outcome is audit-logged either way. 4. **Geographic restrictions.** Launch signing is not available from the United States, Cuba, Iran, North Korea, Syria, Russia, or China (geo-IP at the network edge, mainnet only). 5. **Founder Raise Terms.** You have accepted the Founder Raise Terms with a wallet signature (verified server-side against the versioned terms text). 6. **Approved founder application** (current review phase; see §2). A wallet that is banned under §4 is refused all platform signatures for the duration of the ban. ## 2. Founder application review (current review phase) During the current review phase, founder applications are reviewed by the platform operator against the rubric below. The review is a **safety and quality screen**: it is not an endorsement of any project, and approval is not investment advice or a recommendation. ### 2.1 Rubric Each application is scored 0–3 on four dimensions; the score and the decision reason are recorded: | Dimension | What is assessed | |---|---| | **Provenance** | Is the build genuinely the applicant's work? AI-tooling provenance detail, repo/commit history consistency, originality vs. an unmodified template or clone. | | **Substance** | Does the project exist beyond a landing page? Working demo or live URL (at least one is required), coherent description of what is built. | | **Traction / proof** | Verifiable signals the project is real: users, activity, published artifacts. | | **Founder credibility** | Consistency of the founder's identity signals (linked X account, Ethos reputation, wallet history) with the application's claims. | There are no quotas, no category preferences, and no assessment of a project's commercial merit or token value. Two applications with the same facts get the same outcome. ### 2.2 Process and service level - Applications receive a first review within **5 business days** of submission. - Possible outcomes: **approved**, **needs info** (what is missing is stated; edit and resubmit returns you to the queue), **shortlisted** (awaiting final review), or **rejected** (with the reason). - Decisions follow published bands tied to the rubric (§2.1): - **Approved**: total score of at least 8/12 with no dimension at 0. - **Needs info**: the default for fixable gaps (thin proof, missing detail). The gap is stated; editing and resubmitting returns you to the queue and consumes nothing. - **Rejected**: reserved for integrity failures: a 0 on **provenance** (the build is not credibly the applicant's work) or a 0 on **founder credibility** (identity signals contradict the application), or an appeal re-review that still fails the bands above. A weak-but-honest application receives *needs info*, not rejection. - Rejections and needs-info decisions always state their reason (enforced at the review API; a decision without a stated reason is refused). - You are notified of every status change. - **You may withdraw your application at any time** before a rejection, including after shortlisting or approval, from your application page. Withdrawal is self-service, takes effect immediately, is confirmed in writing, and is recorded in the audit log like any other status change. A withdrawn application can be edited and resubmitted later, which returns it to the queue for a fresh review under the same reference code. Withdrawal is never held against a future application. ### 2.3 Appeal A rejected applicant may request re-review once by resubmitting with new information addressing the stated rejection reason. The re-review is conducted fresh against the same rubric, and its outcome and reason are recorded. Rejection does not affect your ability to use the platform as a backer. ## 3. What the platform does and does not do with listings - Every listed raise renders on the **same neutral template**. Differences in how much a listing shows reflect only what the founder has provided and what is verifiable on-chain (reputation signals, provenance, funding facts). - Ranking and ordering surfaces use **objective, stated bases only** (e.g. funding volume, recency). There are no editorial picks, no "featured" placements, and no paid placement. - The platform does not market, promote, or recommend any specific raise, and nothing on the platform is investment advice. - Raise pages may carry an **AI-generated analysis** of the founder's product, written by a language model from the founder's own submission and their live app, on the same criteria for every listing. It is labelled as machine-generated wherever it appears. It is **not an endorsement, does not reflect the opinion of the platform, and is not investment advice**: a raise's inclusion, ordering and treatment are unaffected by what it says. - Per-raise economics are uniform. The community-allocation mechanism that exists in the router (`setCommunityAllocationForLaunch`) is **not available to third-party raises**; no third-party founder receives bespoke launch terms. ## 4. Moderation and removal Listings can be hidden or removed, and wallets banned, **only** for: 1. **Fraud or materially false claims**: fabricated metadata, fake team members, false provenance, impersonation of a person, project, or brand. 2. **Illegal content** or content that creates legal exposure in the jurisdictions we operate. 3. **Sanctions risk**: a wallet or project connected to a sanctioned party. 4. **Platform abuse**: sybil operations, exploitation of platform mechanics, attacks on other users. Rules: - Every moderation action requires a stated reason citing one of the grounds above and is audit-logged with before/after snapshots. - **The platform renders issuer-supplied content; it never rewrites it.** Moderation acts on visibility only (hide, remove): administrators cannot edit a founder's title, description, or other authored content. Content corrections come from the founder, as a new version the founder submits (and, where applicable, signs) themselves. - **Removal refunds the founder's launch deposit.** The platform never profits from its own moderation decisions. (The deposit is returned on-chain; a removed founder whose wallet is sanctions-flagged has interaction refused rather than funds seized.) - Hidden/removed listings and bans can be reversed; reversal is also audit-logged with a reason. - A banned founder may contest the ban once by contacting support with evidence addressing the stated ground; the outcome and reason are recorded. ### 4.1 Posts in a raise's Community A raise's Community is where its founder, backers and holders talk. Before a raise funds, anyone signed in can ask its founder a question, and only the founder answers. §4's grounds and rules apply to every post there, with these specifics. **What can't be posted.** These are refused as they're written, and the writer is told why: - A post too short to say anything: a title under 10 characters, a reply under 10, a topic's words under 20, or anything without at least three different letters or numbers. - A hate slur. - Crypto-scam bait: asking for a seed phrase or a private key, moving help to a private chat, offers to multiply crypto, or wallet "validation". - A link from a wallet that has never backed or held the raise, more than two links in a post, or a link shortener or chat invite. Invisible characters are removed from what is stored. **Who can hide a post.** Only Vibestarter. Founders, backers and holders can report a post, but none of them can hide, edit or remove anyone else's. Authors can edit or remove their own posts. **Why a post is hidden.** Only for one of these reasons, each citing a ground in §4. Where the last column says yes, anyone can still open the post's words with "Show". Where it says no, the words are withheld from every reader. | Reason | Ground (§4) | Words can be shown | |---|---|---| | Promotion | Platform abuse | Yes | | Not civil | Platform abuse | Yes | | Spam | Platform abuse | Yes | | Undisclosed paid promotion | Illegal content | Yes | | Financial advice | Illegal content | Yes | | False claim or impersonation | Fraud or materially false claims | Yes | | Scam link | Fraud or materially false claims | No | | Private information | Illegal content | No | | Illegal content | Illegal content | No | | Sanctions risk | Sanctions risk | No | **What a hidden post shows.** - A hidden post keeps its author, its time and its place in the conversation. It reads "Hidden by Vibestarter", with the reason and when. - A hidden topic leaves the topic list. One line at the list's foot shows how many are hidden, and opening it puts them back in place, each with its note. - Hidden posts count in no total and match no search. **Reports.** - Reporting a post needs a signed-in wallet, once per wallet per post, with a reason from the table and an optional note. - A reported post stays up until Vibestarter decides. The decision is to hide it, or to dismiss the reports. **Logged, explained and reversible.** - Every hide, every restore and every dismissal of reports is audit-logged, with the post before and after and a note for the log. - The author is told in the app when their post is hidden, with the reason, and when it is restored. - A hidden post can be restored. The restore is logged with its reason too. **No rewriting.** As in §4, Vibestarter never edits a post. When an author edits their own post, its earlier versions stay readable to everyone, each with its time. **What posts are.** - Posts are their authors' own. Vibestarter doesn't check or endorse them. - Nothing in them is investment advice. - Anyone paid to promote a raise must say so in their post. **Bans.** - A wallet banned under §4 can't post, reply, vote or report. - It can still sign in, to claim its tokens and refunds. ## 5. What this policy does not change On-chain protections are not subject to operator discretion and apply identically to every raise: escrowed funds with the fixed time-release schedule, the ≥50% backer allocation floor, the permanent LP lock, the 72-hour challenge windows, and pro-rata refunds on freeze. The platform's emergency powers (global pause, per-raise freeze) exist for incident response and challenge adjudication under `docs/challenge-standards.md`; they are not admission tools. --- # Automatic Signature Policy **Version 1.0 · July 2026.** This page explains when and how the platform's backend issues the cryptographic signatures that gated on-chain actions require. It is a companion to the [Launch Admission & Moderation Policy](/docs/admission). ## What the signature is Participating in gated on-chain actions (backing a raise, launching a raise, filing or supporting a challenge) requires a short-lived signature from the platform's backend (an EIP-712 `TermsAcceptance` or `LaunchAuthorization` message). The signature is a **compliance permit**: it attests that the wallet passed the checks below at the moment of issuance. It authorizes; it cannot execute. The transaction itself is always constructed, signed, and broadcast by the user's own wallet. ## How issuance works: automatically, against fixed checks Signature issuance is **fully automatic: no human reviews, approves, or delays any individual signature request.** The backend signs for any wallet that passes, and refuses for any wallet that fails, exactly these checks, in this order: **For every signature (backing, challenges, launches):** 1. **Authenticated session**: the wallet holder is signed in (SIWE). 2. **No platform ban**: the wallet is not banned. Bans are issued only on the published moderation grounds (fraud or materially false claims, illegal content, sanctions risk, platform abuse; see the [moderation policy](/docs/admission)), each with a recorded reason and audit log. 3. **Sanctions screening**: the wallet is screened against the OFAC SDN list (and the Chainalysis sanctions oracle where deployed) on every request. Sanctioned wallets are refused. 4. **Signup completion**: the wallet has completed the one-time Starter Card signup, which includes accepting the platform terms. 5. **Geographic restriction**: requests from restricted jurisdictions (US, CU, IR, KP, SY, RU, CN) are refused at the network edge. **Additionally, for launch signatures (pilot capacity, mechanical):** During the initial third-party phase the platform runs a **capped pilot cohort**. Admission into the cohort is **curated**: Wave-1 raises are shortlisted from the pilot pipeline and direct applications, reviewed against the published rubric and criteria of the [admission policy](/docs/admission), with its scoring bands, review SLA, and appeal path. Once admitted, the capacity cap itself operates mechanically: when the configured maximum number of non-settled raises is live, launch signatures are refused with a capacity message (code VS-S009) until a slot frees; slots reopen automatically as raises settle, first-come among admitted founders, with no per-request discretion. **Additionally, for launch signatures (current review phase):** 6. **An approved founder application**, reviewed against the published rubric: the one human-judgment step in the system, governed by the [admission policy](/docs/admission) with its published criteria, scoring bands, review SLA, and appeal path. 7. **Launch clearance**: third-party launches open only once the platform's incorporation requirements are complete, and each approved founder is individually cleared for launch. Until both hold, launch signatures are refused with a non-personal gating message (code VS-S010); approval status is unaffected. 8. **Founder Raise Terms accepted**. 9. **The launch uses the raise window we confirmed.** The platform will not sign for a launch that falls outside the confirmed raise window, and the authorization is minted only for the **founder** themselves (or the receiving wallet they declared in their own draft). Deploying opens 48 hours before the confirmed start and closes shortly before it, so a raise cannot open early or run to a different date than the one backers were shown. Everything else about the raise (ticker, goal, soft cap, supply, raise type, allocation split and all copy) remains the founder's to set, and they may change it up to the moment they deploy; **the raise page and its cards therefore show the terms actually deployed onchain**, read from the escrow, not the terms as first submitted. Timing refusals carry the confirmed window (codes VS-S015, VS-S016, VS-S017). This is a limit on what the platform will authorize, not a claim that a launch outside that window is impossible: the authorization is scoped to the founder, so the check binds the request rather than the transaction. ## What this means - **No discretion per request.** The backend cannot favor, deprioritize, or selectively delay individual wallets: identical inputs produce identical outcomes. There is no queue a human works through and no per-request judgment call. - **Refusals are rule-shaped.** Every refusal maps to a numbered check above, and each check's grounds are published. - **Signatures are short-lived and scoped.** Each signature expires within minutes, is bound to one wallet, and (for participation signatures) to one raise contract. It contains no amounts and no transaction data. ## Planned evolution The stated end-state is that check 6 (application review) is retired in favor of mechanical, published, objective criteria, including mandatory founder identity verification through an independent provider (the platform receives a pass/fail status only, never identity documents). When that ships, every check in the issuance path will be objective and automatically applied, and this page will be updated to match exactly what runs.