# Shipyard: the work-backed launchpad

*Working title. Alternates worth checking for domains: Slipway, Drydock, Berth, Batchwork. Rename is a find-and-replace.*

**One line:** a permissionless launchpad where every raise is backed by deliverables, not tokens. Contributions sit in on-chain escrow and stream to the builder only as work ships. First category: software, built in batches.

**Category name:** work-backed raises, a hybrid, not a service marketplace. Backers back a **project that is bootstrapping itself**, and unlike a token launch they receive something real (the deliverable) before the project is even fully established. What a backer buys is a **slot**: a unit of the builder's output. Tokens and points may exist as side perks; they are never the principal.

---

## Why this exists

- Token launchpads sell exposure to a price. Most backers lose to unlock schedules, thin liquidity, and mercenary flippers. The product is a chart.
- The actually scarce thing is shipped work. Builders need capital up front; people need software; nobody needs another chart.
- Programmable escrow makes it possible to sell *future work* with bounded downside: money moves only as fast as the work.

The pitch to a backer, in one sentence: **if the token goes to zero you still got the thing you paid for, and if the work never ships, you get your money back.**

## The invariant (the whole protocol in one line)

> **Beyond the mobilization tranche, every dollar is either delivered against or still withdrawable. There is no third state.**

This covers all three release triggers at once, and it's honest about the single at-risk portion: the mobilization tranche (15% for a new builder) is the bounded, disclosed cost of a builder starting work. That is the entire downside. On a token launchpad the downside is everything.

Note where the floor works differently by trigger, worth understanding rather than glossing:
- **Instant and delivery** deliverables hold their floor by *delivery*: the app gets built, the tutorials exist, and they keep their value whatever happens to the project afterward.
- **Milestone** deliverables (hub residency, launch perks) are contingent on the project reaching that milestone. They hold their floor by *refund instead*: no milestone, no release, money still withdrawable.

## Why this isn't a launchpad

**It de-risks the project, and it de-pressures the founder.** A token launchpad sells a claim on the project succeeding, which makes honesty expensive: you cannot pivot without betraying holders, cannot admit a dead end, cannot wind down gracefully. It manufactures zombie projects, ventures that should die but can't, because dying became a broken promise.

Work-backed raises move the certainty to the part that *can* be certain (the work) and leave the venture honestly uncertain. A founder can pivot, or fail outright, having fully discharged what they owed. **Failure stops being fraud and goes back to being failure.** That is backer protection and founder protection in the same mechanism.

**Disclosure is deliberately asymmetric, and that's correct.** Two kinds of disclosure get two treatments:
- **Scope box, mandatory.** What one slot buys, in testable language. Non-negotiable, because it is the text confirmation is judged against.
- **Project narrative, optional.** Vision, roadmap, the why. A founder may write ten pages or three lines; both are legitimate raises.

The speculative disclosure is the optional one; the enforceable one is required. The market handles the rest, founders who disclose more raise more. So disclosure becomes a competitive advantage instead of a compliance burden nobody can police.

## Core mechanics

### 1. Raises (permissionless)
Anyone deploys a raise. A raise defines: the offering (what one slot redeems for, in plain testable language), slot supply, pricing curve, delivery cadence, and escrow terms. No listing committee. Trust comes from terms + track record, not gatekeeping.

### 2. Slots (units of work, and they're liquid)
Slots are ERC-1155 tokens, **built as of v0.4**: each serial is a token id with a supply of one, and transferring it moves everything attached to that slot, including the right to confirm or send back the delivery, the right to withdraw, and any unclaimed token bonus. The vault's own accounting *is* the balance, so there is no second ledger to drift. 1 slot ≈ one focused build; bigger scope combines slots (a 3-slot app). Because slots are tokens, they are **transferable**: if you no longer want your build, sell the slot. Work itself becomes a liquid asset with price discovery, which no launchpad does.

### 3. The non-custodial vault (nobody holds the money)
Contributions go into a smart-contract vault that **no one controls**: not the builder, not the platform. Shipyard cannot touch, freeze, or redirect funds; withdrawals are permissionless functions backers call themselves. This is the answer to "escrow without a custodian": the escrow *is* the contract. At close, the builder can claim only the **mobilization tranche** (15% for a new builder). Everything else stays in the vault, **attributed backer-by-backer to their own slots**: not pooled.

### 4. Handshake settlement (per-backer, no committees)
Every backer's deal is bilateral: *my money, my slot, my delivery, my release.* There are no quorums, no councils, no arbitration courts, replaced by a receipt and a button:

- The builder posts a delivery with evidence (repo, live URL, content hash) against the written scope box.
- Its backer **confirms it**, or it **auto-accepts after 7 quiet days** (silence can't grief the builder).
- If it misses the scope, the backer sends it back for **one revision round**.
- Still unhappy after the revision? **No-fault exit:** the backer takes their unreleased money and walks. No justification needed, no tribunal. The outcome is recorded in both parties' on-chain history, a bad delivery costs the builder their Score, which is worth more than any single slot.

Confirmed delivery → that slot's tranche releases to the builder. Disputes aren't adjudicated; they're **priced and exited**.

### 4b. What "delivery" actually means: evidence first, handover on confirm
The obvious attack on any escrow for digital goods: **the backer takes the code and then refuses to release the funds.** You cannot un-send a repo. Left unaddressed this is fatal, because the only exploitable path in the settlement flow is *deliver → request revision → redeliver → no-fault exit*, which would hand a backer both the app and their money.

So delivery is deliberately two-phase, and the phases are separated by the confirmation:

| Phase | Builder provides | Backer can | Backer cannot |
|---|---|---|---|
| **1. Evidence** | live demo on **builder-controlled** hosting, screenshots, walkthrough, commit hash | use the app fully, judge it against the scope box, request one revision, exit | fork, deploy, own, or keep it |
| **2. Handover** *(fires on confirm / auto-accept)* | repo access transferred, deployment handed over, domain + env vars released | everything | — |

**You inspect the car before buying; you don't drive it off the lot until you pay.** The evidence is genuinely sufficient to judge, a running app at a URL, exercised by the backer, while the transferable asset stays with the builder until the tranche releases. Exit during phase 1 and you never received anything transferable: the builder keeps the code and can resell that slot's work outright.

This also makes the exploit path pointless rather than merely punished, which is the right kind of fix. The remaining penalties are secondary but real: exiting forfeits your share of the already-released mobilization tranche, the slot token, the token bonus, and your Shipyard Points, and it records against your **backer** Score. (Builders aren't the only side with a reputation; serial post-delivery exiters are visible.)

**Honest residual risk.** A client-side web app served to a backer's browser can be partly copied from the demo. That's physics, not a design flaw, and no escrow removes it. What the two-phase flow guarantees is that source, deployment, ownership, and support never transfer without release. Mitigations that shrink it further: demos behind a login, watermarked builds, backend logic staying server-side.

**v2 makes it cryptographic.** Encrypt the deliverable, publish the ciphertext, and gate the decryption key on the on-chain `Confirmed` state (Lit Protocol-style conditional decryption). Then handover isn't a process anyone has to honor, it's enforced by the same contract that releases the money.

### 5. Self-serve exits (the protection is a withdraw button)
- **Before close:** withdraw any time, in full, instantly.
- **After close, before your build begins:** still yours, withdraw. The builder's funding certainty comes from the mobilization tranche plus everything already delivered, and grows with every confirmed build.
- **Your delivery runs 14+ days past its slot's scheduled date:** your withdraw button simply reopens. Lateness isn't a claim you file; it's a timer that gives you your money back.
- **Any time:** sell the slot (transferable token).

Worst realistic case for a Batch 001 backer at 100 USDC: the builder vanishes the day after close → 15 released, 85 self-withdrawable → maximum loss 15% plus gas. On a token launchpad, −90% is a Tuesday. And the founder's own stated ethic, "if I find out I can't build it, I return the money", is exactly what the vault turns from a personal virtue into a structural guarantee for every raise.

### 6. Earned terms (the trust ladder)
Permissionless entry, earned trust. Escrow terms are set by on-chain track record, not by an application form:

| Builder score | Upfront at close | Auto-accept window | Late reopens exits at |
|---|---|---|---|
| **New** (0 deliveries) | 15% | 7 days | 14 days |
| **Proven** (10+ slots delivered, ≥95% confirmed) | 25% | 5 days | 21 days |
| **Veteran** (50+ slots, ≥97% confirmed) | 40% | 3 days | 30 days |

New builders get the most conservative terms; every confirmed delivery mints history in a soulbound score contract. This resolves the permissionless-vs-trust paradox: we don't gate *entry*, we gate *terms*.

### 7. Token bonus: the bonus that follows the work
Founders may attach a token, like any launchpad, but under house rules that keep it a bonus, not the deal:

- **Utility on the funded project, declared at creation.** The wizard makes the founder pick what holding unlocks, fee discounts, Pro access/credits, governance, on *their* product.
- **Delivery-gated unlocks.** Bonus tokens unlock **per confirmed delivery**, pro-rata, the same rhythm as the escrow. Money follows the work; so does the token. No cliff dumps, no pre-delivery flips, and the bonus rewards backers of builders who actually ship. **Built and enforced by `BonusDistributor`:** a slot's allocation is claimable only once the vault reports that slot Confirmed, so a raise that never delivers distributes nothing, a backer who exits forfeits that slot's allocation, and the founder cannot accelerate anyone including themselves. There is no owner, no pause, and no mint function after deploy.
- **Never priced.** The UI displays token bonuses with no dollar value, ever, receipts literally print "unpriced." No implied valuations.
- **The worth-zero test.** Deploying a token raise requires an attestation: *this raise still makes sense for backers if the token is worth $0.* The raise page repeats the test publicly.
- Non-token perks (badges, points, priority queues) follow the same "bonus, never the principal" labeling.

Demo state: **Raise 002 (@relaylabs, $RELAY)** is the reference token raise, an automation startup funding its launch by building integrations for backers, with $RELAY utility (Pro access, fee discounts, roadmap votes) unlocking per confirmed delivery. Distribution philosophy for token bonuses: broad and fair, no founder-hoarded supply; fair-launch or milestone-based schedules both supported (exact per-raise schedule is a wizard choice, to be designed with the first real token raise). Batch 001 deliberately stays tokenless: the flagship proves the deal works on work alone.

### 8. Release triggers: three, not one
Not every raise is 40 identical apps. A raise that funds a *thing* (a hub, a house, a launch) needs capital at a moment, not a trickle. So money is attributed to **the deliverable that earns it**, and each deliverable component declares one of three release triggers:

| Trigger | Releases when | Use for |
|---|---|---|
| **Instant** | the backer is granted access | already-built digital goods: app access, courses, docs, memberships |
| **Delivery** | that backer confirms their build (or 7-day auto-accept) | bespoke work, the Batch 001 default |
| **Milestone** | the project posts milestone evidence and the exit window passes | capital events: property secured, hub opened, launch shipped |

**Deliverables are code and only code, at launch.** Web apps, dapps, integrations, contracts. Not tutorials, access passes, memberships, or physical perks. The reason is verification: a repo either runs at the stated URL or it doesn't, so confirmation stays objective, the revision round stays decidable, and nobody has to argue about whether a tutorial was "good." Fuzzy deliverables would quietly reintroduce the judgment calls that handshake settlement exists to eliminate. Other categories come later, once the rail has a track record, and each one has to answer the same question: *can a stranger tell whether this was delivered?*

Keep two things separate that are easy to conflate:
- **What the backer receives**: code, always.
- **What the raise funds**: anything at all. A house, a launch, runway. That's the founder's business, disclosed as narrative, and it's why milestone releases exist at all.

A backer does not buy a share of the house. They buy an app, and the founder's proceeds fund the house.

**Milestone share is gated by Score.** A milestone release is fundamentally *"trust me with a lump,"* which is precisely what the trust ladder exists to ration. So the share of a raise that may be milestone-gated scales with track record:

| Builder score | Max milestone share |
|---|---|
| **New** | 0%, delivery-gated only |
| **Proven** | up to 30% |
| **Veteran** | up to 50% |

A first-time founder asking backers to fund a lump-sum purchase is the exact silhouette of the launchpads this replaces. Earn it first.

**Milestone release is the same primitive as delivery release, scaled from one backer to the whole raise:** the founder posts evidence against a milestone description written at raise creation, an exit window opens (default 10 days), and **any backer who dislikes it withdraws their unreleased share during the window instead of voting**. Silence releases. Exit is the veto, no quorum, no committee, consistent with handshake settlement.

One safeguard milestones need that per-slot deliveries don't: a **funding floor**. You cannot un-buy a house. If withdrawals during the window drop the milestone pool below its stated amount, the milestone *fails to fund* and the whole amount reverts to withdrawable. Nobody ends up half-funding a purchase.

**The declared split.** At creation the founder declares how each contributed dollar divides across mobilization / delivery / milestones. It renders on the raise page as a single bar. A backer can always answer "where does my money physically go, and what has to happen before it moves?"

### 9. Queue position is disclosed, not policed
The number-one way a work-backed raise fails is a builder over-selling their own hours, not fraud, just optimism. The wrong fix is a wizard that blocks deploy: founders must stay free to price however they want, including aggressively, and "I couldn't deliver so backers withdrew" is a survivable outcome the vault already handles.

The right fix is that **the schedule is already a contract term, so publish it.** Every slot's scheduled date is `serial ÷ cadence`, the same date the late-trigger uses to reopen withdrawals. Show it at the moment of purchase:

> *Slot #12, scheduled ≈3 weeks after close.*
> *Slot #400, scheduled ≈80 weeks after close.*

Nobody has to be protected from themselves; they just have to be told. Backers pick their own queue position with the wait attached, and demand thins out naturally where the promise stops being credible. Underpricing is still permitted. It is simply **visibly self-defeating**, because the cost of cutting price is a longer queue, and the queue is public.

The wizard still runs the arithmetic and warns loudly at creation (`4,000 slots ÷ 5 per week = 800 weeks`), but it deploys if you insist. Disclosure, not paternalism.

**This is why price-per-app is the wrong unit of competition.** Ten apps delivered over two years is worth less than five delivered next month. The real unit is *price per app per week of wait*, and publishing queue position is what makes that legible, the race to the bottom becomes expensive and visible, because the currency being spent is time, not promises.

### 10. No AI judge: ever
AI is a **scribe, never a judge**. An AI arbiter would reintroduce exactly what this design removes: a centralized oracle whose decisions need an appeals process, which needs a committee. Nothing decides a release except the backer or the clock.

Where AI legitimately helps, all pre-decision and non-authoritative:
- **Scope drafting**: turning "I'll build you an app" into a testable scope box at creation
- **Evidence packaging**: assembling the delivery receipt (diff summary, screenshots, content hash)
- **Reminders and digests**: "your build auto-accepts in 2 days; here's what changed"

The Score's role is likewise *terms, not verdicts*: it sets upfront %, auto-accept window, and late trigger before the raise opens. It never touches an individual release.

### 10a. The honeypot, and the ceiling that bounds it

Escrow does not make scams impossible, and it is worth being precise about what it does and does not cover.

**What escrow already handles.** A builder who takes money and never delivers cannot keep it. Backers withdraw the unreleased balance themselves, and the failure is recorded against the builder's Score forever.

**What it does not handle.** The **mobilization tranche is the only money in the system that is not refundable**. A scammer can open a raise, collect the 15% at close, and vanish. Backers recover the other 85%, but the skim is real and, because entry is permissionless, repeatable with a fresh wallet every time.

So the raise ceiling is set by Score alongside every other term:

| Tier | Max raise | Worst-case skim |
|---|---|---|
| **New** | 5,000 USDC | 750 |
| **Proven** | 50,000 USDC | 7,500 |
| **Veteran** | uncapped | — |

The ceiling is checked against the **worst case, not an optimistic tier mix**: `maxSlots × highest unit price`. Reaching a bigger target costs **ten real confirmed deliveries**, and delivering ten real builds costs far more than 750 USDC. The attack stops paying.

Two scam vectors escrow cannot touch at all, and which need the product rather than the contract:
- **Phishing inside listing copy.** A malicious link in a raise description loses money entirely off-platform. Needs moderation and reporting.
- **Auto-accept exploitation.** Deliver something worthless and hope the backer never looks; after seven quiet days it releases. Escrow is working exactly as designed here, which is why **notification is a safety requirement, not a convenience.**

### 10b. What stops a race to the bottom
If one founder offers 5 apps for 100 USDC, someone will offer 10 for 100. Why would anyone still back the first? Four answers, in ascending order of durability:

1. **Queue speed.** The cheaper offer has a longer queue, and the queue is published per slot. Ten apps arriving through 2029 lose to five arriving next month.
2. **Scope quality.** "10 apps" of *what*? The scope box is where offers are actually comparable, and vague scope is a weak deliverable no matter how many units it promises.
3. **Score.** A New builder promising 10-for-100 is a red flag; a Veteran with a 97% confirmed rate promising 5-for-100 is a credible bargain. Reputation is the only thing here that can't be conjured on day one, which is exactly why it's the moat.
4. **The cause.** Mission-aligned backers pay a premium to fund something they want to exist. This is the one differentiator that never commoditizes, and it's why narrative, optional as it is, earns its place on the page.

The structural point: on a token launchpad the race to the bottom is a race on *promises*, which are free to make and invisible until too late. Here it's a race on *delivery time*, which is finite, public, and self-punishing. **The deliverable is the floor; the cause is the premium.** Backers pay somewhere at or above the work's market value, protected by the fact that they got the work.

### 11. Referrals: growth without cannibalization
Backers can bring backers, rewarded from a **declared referral pool** the founder reserves out of the token bonus at creation (e.g. 10% of the bonus allocation). Declared upfront, so every backer sees the dilution before contributing. It never comes out of another backer's pocket, and it costs the founder no cash.

Three rules make it sybil-resistant and honest:
1. **Credit only vests on money that stays.** A referral counts when the referred contribution survives to a confirmed release. Referred backer withdraws → the credit reverses.
2. **The referrer's reward unlocks on the schedule of the person they brought in.** Your referral tokens unlock as *their* builds get confirmed. This rewards bringing in real, durable backers rather than signup volume.
3. **Per-referrer cap**, declared at creation, so no single affiliate can absorb the pool.

**Built, and the interesting part is where the attribution lives.** The obvious design is a list of who referred whom, submitted by whoever is paying out. That design has a hole in the middle of it: the person with the most reason to redirect a referral is the one holding the pen. So attribution is recorded by the vault, in the backer's own deposit transaction (`deposit(tier, referrer)`), stamped onto each slot and never writable again. Payout reads it back and pays that address and no other. `claimReferral(serial)` takes no recipient argument at all, and anyone may call it. There is no function a founder could use to pay themselves, which is a stronger claim than a policy saying they shouldn't.

Rule 1 falls out for free rather than needing a reversal mechanism: an exited slot never reads Confirmed, so the reward simply never unlocks. Rule 3 is the pool itself, a hard ceiling in token units. Self-referral and builder-referral are rejected at the vault. Beyond that, farming means buying slots with real USDC into an escrow you do not control and having the work actually delivered: expensive, public and bounded, which is the honest answer rather than pretending sybils are solved.

**Cash referrals, for the raises that have no token.** A pool carved out of a token bonus only rewards referrers on raises that launched one, and most will not. So a builder can also set a **referral share of their own release**, in USDC, fixed at creation and capped at 10% by the factory. When a slot that referrer brought is confirmed, that share of what the *builder* receives is credited to them.

The important property is what it does not touch. It comes out of the builder's margin, never out of escrow, so a referred backer's deposit, refund, exit rights and withdrawal amounts are identical to an unreferred one. It is the builder buying growth with their own money, on the only terms this protocol recognises: paid on work that actually shipped.

It is credited rather than sent, and that is a safety property rather than a convenience. The referrer is an address the *backer* chose. Paying them inside the release would put that address on the critical path of the builder getting paid, and USDC can freeze an address: name a frozen one and the transfer reverts, so the slot could never confirm and could never auto-accept either. Accruing a balance the referrer pulls themselves keeps every possible failure their own.

Two things follow that were not in the original sketch. Transferring a slot does **not** move the referral, because the credit was earned when the slot was bought rather than by whoever holds it now. And referrals accrue **Shipyard Points** at 0.25 per USDC of a confirmed slot brought, so bringing people to the many raises with no token attached is still worth something.

**On "hastening TGE": no extra machinery needed, TGE fires on fill, not on the deadline.** A raise that fills in two weeks generates its token in two weeks instead of waiting out a six-week clock. Referrals accelerate the token event by simply doing their job, and the incentive is honest because it's the same event everyone was already waiting for.

### 12. Shipyard Points: the protocol's own growth engine
Separate layer from project tokens, and they stack: **the protocol rewards protocol behavior; a project rewards backing that project.** A referrer on a token raise earns Shipyard Points *and* that project's referral allocation.

Points are **soulbound** (non-transferable), carry no promise of conversion, and are framed exactly as the prototype already says: *if Shipyard ever tokenizes, early participants are first.*

| Action | Points | Why weighted this way |
|---|---|---|
| **Back** | 1 per USDC that reaches a confirmed release | rewards money that actually funded work |
| **Build** | 2 per USDC released to you | supply side is the scarce side |
| **Confirm** | 25 flat, per delivery you confirm yourself before auto-accept | keeps the machine moving; rewards the active behavior |
| **Refer** | 0.25 per USDC referred that reaches a confirmed release | growth, priced below participation |
| **Complete** | 1.25× multiplier on a raise that delivers 100% of its slots | both sides win by finishing |

**Implementation note (built, Aug 2026).** Points are **derived, not minted**. There is no Points contract and no balance anyone can write: a scheduled job replays chain history and computes the table, so anyone can rerun the same arithmetic and get the same answer. That also means the formula can be retuned without a migration.

All five components are counted, including the 25-point manual-confirm bonus, which reads the `Confirmed` event's `autoAccepted` flag out of the event index rather than the RPC.

**The sybil defense is structural, not a filter:** points mint only on *released* money, and releasing money requires delivering confirmed work. Wash-farming a raise with yourself means actually building the apps, which costs far more than points that carry no guaranteed value. Volume alone earns nothing.

Who's in the flywheel: **backers** (capital), **builders** (deliverables), **referrers** (either of the above, plus affiliates and KOLs who never back at all), and **confirmers**: the underrated fourth group, since prompt confirmation is what makes the rail feel fast.

---

## Batch 001: the first raise (the founder dogfoods the protocol)

- **Creator:** @ulogger, platform founder, deliberately the first raiser, on the *worst* terms (New tier). The founder's money unlocks the same way everyone else's will.
- **Offer:** focused web apps, built in public, delivered in backing order.
- **One slot buys:** one focused app, up to ~3 screens / one core flow, deployed, source handed over. Bigger apps combine 2–3 slots. Excluded: native mobile, heavy custom backends, ongoing maintenance (those become future "retainer raises").
- **Cadence target:** 5 builds/week once the batch closes.
- **Supply:** 40 slots.

### Pricing

> Note on the original sketch (100 USDC → 1 app, 500 → 3, 1000 → 5): that curve is inverted. It charges *more* per app as you buy more (167/app at the 500 tier vs 100/app solo). Bulk must always be cheaper per unit, or the tiers punish your best backers.

| Tier | Slots | Price | Per build | Save |
|---|---|---|---|---|
| Solo | 1 | 100 USDC | 100 | — |
| Trio | 3 | 270 USDC | 90 | 10% |
| Batch Five | 5 | 400 USDC | 80 | 20% |
| Studio | 10 | 700 USDC | 70 | 30% |

Fully claimed, the raise lands ≈ 2,800–4,000 USDC depending on tier mix. **Intentionally small.** Batch 001 exists to prove the delivery rail on-chain and mint the first Builder Score, not to maximize the raise. Batch 002 prices against demonstrated demand and a Proven-tier track record.

**Perks (side, never the principal):** backer badge NFT, 2× protocol points, priority queue for Batch 002. No token promise required for the deal to make sense.

### Pricing rationale
- **Anchor:** a freelance/agency MVP runs $2k–10k+. AI-accelerated batch production compresses the cost; pricing 10–30× under the anchor makes backing feel obviously positive-expected-value in *goods*, not in token hopium.
- **Slots-as-work-units** keeps pricing honest as scope varies, a bigger app just costs more slots.
- Declining unit price rewards commitment; a hard cap per batch creates real (not fake) scarcity because cadence is finite.

---

## Protocol economics (how Shipyard earns)

- **Listing: free, permissionless.** No application fee, no token allocation taken from raises, both would corrupt the trust ladder.
- **2.5% fee on released funds only.** Nothing on refunds, the protocol earns only when work actually delivers. Shipyard is paid on proof-of-delivery, exactly like builders. Incentive-aligned by construction, and stated openly in the wizard, receipts, and FAQ.
- **1% on secondary slot transfers** once the marketplace exists.
- Deliberately rejected: paid listings and boosted placement (pay-to-win discovery would poison earned terms), and upfront token allocations (turns the platform into a bagholder with a conflict of interest). Future revenue candidates that stay aligned: retainer-raise fees, and premium builder tooling.

## Architecture

- **v0 (this repo):** high-fidelity product prototype, mocked state, no chain code. The spec you can click.
- **v0.2 (testnet):** Base Sepolia. Contracts: `RaiseFactory`; `RaiseVault` (USDC vault + slot registry + handshake settlement + self-serve exits, draft in [`contracts/RaiseVault.sol`](../contracts/RaiseVault.sol), compiles clean); `Score` (soulbound builder track record). All USDC-denominated.
- **v1 (mainnet, Base):** real Batch 001. Evidence = URI + content hash per delivery. Adds milestone releases + referral registry for the first capital raise.
- **Later:** secondary slot marketplace, Shipyard Points contract, categories beyond software (design, audits, content), retainer raises, fiat on-ramp via account abstraction.

## Posture

Deliberately **non-custodial**: the platform never holds user funds, which removes the heaviest operational and regulatory burden by construction. Clear parameters, plain-language terms, and disclaimers on every raise page (the scope box, the release schedule, and the worth-zero test *are* the disclosure). Token bonuses are utility-first with broad distribution; the market, not the platform, decides whether they trade.

## Open questions

- **Serial-withdrawal games:** a backer withdrawing right before their build starts costs the builder queue time. Mitigation already in the design: the mobilization share released at close is not refundable after close, which prices the exit fairly.
- **Quality bar:** confirmation = "matches the written scope box." One revision round, then no-fault exit. Keeps outcomes decidable without judges.
- **Naming + domain.**