The Launchpad embeds investor protection at the contract level, not as policy. Four protection layers compose: capital escrow under the One-Claim Ledger, milestone-gated tranche release, milestone-aligned insider vesting, and the graduated revocation framework. The protocol enforces all four mechanically; recovery scenarios for the substantive cases follow a graduated framework. The protocol protects capital, not price.
≈ 4 min read · 4 sections
100% escrowedCapital held in protocol escrow at presale open
Milestone-gatedTranches release on delivery, not the calendar
4 scenariosGraduated recovery for substantive triggers
Protection is mechanical, not advisory
The default investor-protection paradigm in token launches is advisory: warnings on landing pages, qualified-investor disclaimers, jurisdiction-blocking text. None of this protects capital. What protects capital is the structural mechanism that determines where capital sits, when it releases, and what conditions must be met. The Launchpad embeds investor protection at the contract level, not in disclosure text.
Four protection layers compose. The capital escrow layer determines where committed capital sits (under the One-Claim Ledger, not under the team's keys). The milestone-gated release layer determines when capital flows to the team (only on attestor-signed milestone completion). The vesting-alignment layer determines when insider tokens unlock (with operating milestones, not calendar dates). The revocation framework layer determines what happens when obligations are missed (graduated consequences with remediation pathways). The four layers are documented in the diagram below.
FOUR PROTECTION LAYERS, EMBEDDED AT THE CONTRACT LEVELInvestor protection on the Launchpad is mechanical, not advisory. Four layers compose: capital escrow under the One-Claim Ledger, milestone-gated tranche release, milestone-aligned insider vesting, and the graduated revocation framework. Each layer is enforced by smart contracts; none depend on a Launchpad operator's discretion.
L1CAPITAL ESCROW
Capital sits in protocol escrow under One-Claim Ledgerteam has no transfer authority
What it preventsThe upfront-transfer pattern that produced the 84.7% below-TGE failure rate across the 2025 institutional dataset (Memento Research). Presale capital does not transfer to the team treasury at TGE; it sits in a project-specific escrow contract under the protocol governance's keys, not the team's keys.
What it does not preventThe token's market price moving below the participant's entry price. The protocol protects the capital that has not yet released to the team; it does not protect the token's secondary market valuation. See 'what protection does not cover' below.
L2MILESTONE-GATED RELEASE
Tranches release only on attestor-signed milestone completionPoV-verified delivery required
What it preventsLump-sum capital transfer regardless of delivery. The escrow tranche release mechanism (documented in capital release) requires the attestor designated in B5 of the dossier to sign the milestone completion. If the milestone is missed (deadline passes without attestor sign-off), the tranche stays locked and the project enters revocation review.
How participants observeEach tranche release is a public event with the milestone evidence, attestor signatures, and the exact amount released. Participants observing the chain can track delivery rate; if a project goes three quarters without a milestone completion, the visible record shows that no tranches have released since milestone N.
L3MILESTONE-ALIGNED VESTING
Team and insider tokens vest with delivery, not calendarno calendar-cliff dumps
What it preventsThe cliff-dump pattern that drove the 71.1% median FDV decline across the 2025 cohort. Team and investor vesting in Block B4 of the dossier is linked to operating milestones from Block B5, not unconditional calendar dates. A team that fails to deliver M2 cannot vest the M2 tranche of team tokens, even if twelve months have passed since TGE.
How it changes the dynamicThe Token Unlocks dashboards that track calendar-based vesting cliffs across the industry show predictable sell pressure on cliff dates. For a Launchpad listing, the unlock dates are conditional on delivery; the pre-unlock sell pressure that drives the cliff-dump dynamic does not have the same coordination point.
L4REVOCATION FRAMEWORK
Graduated consequences when obligations are missedtranche freeze, listing flag, remediation pathways
What it preventsThe 'admission is the end of accountability' pattern. The revocation framework (documented in governance) freezes escrow tranches when triggers fire (missed quarterly KPI, undisclosed material change, attestor revocation, sustained behavior inconsistent with the dossier). Tokens move to frozen state pending review; the listing surface updates with the trigger.
Recovery pathwaysMost revocation reviews resolve at remediation (the team posts the missed evidence, replaces the attestor, discloses the material change). Permanent revocation is reserved for sustained non-compliance, fraud determination, or refusal to engage with remediation. The four-stage recovery scenarios are documented in the diagram below.
Four protection layers, mechanically enforced. None depend on a Launchpad operator's discretion. The composition is what produces the structural protection; no single layer is sufficient, but all four together address the substantive failure modes documented in the diagnostic series (upfront capital, no KPI evidence, unverified mints).
What revocation looks like for participants in practice
The graduated revocation framework runs when triggers fire (missed quarterly KPI, undisclosed material change, attestor revocation, sustained behavior inconsistent with the dossier). The framework is designed for recoverable circumstances; most reviews resolve at remediation. The substantive cases that participants might observe fall into four recovery scenarios documented below.
Critically, the framework's first action is always graduated: tranches freeze, the listing surface updates with the trigger and review status, team token vesting linked to affected milestones pauses. Token trading on third-party venues is not halted; the protocol is not a securities suspension authority. The Launchpad's endorsement withdraws while review is open; capital that has not yet released to the team stays locked. The participant continues to see the holding and its current state.
FOUR RECOVERY SCENARIOS, GRADUATED OUTCOMESWhen obligations are missed or triggers fire, the revocation framework runs. Most reviews resolve at remediation. Permanent revocation is rare and reserved for sustained non-compliance or fraud. The four scenarios below cover the substantive outcomes a participant might observe.
R1REMEDIATED TRIGGER
Common scenario, recovery within review windowtranches unfreeze, listing returns to active
TriggerMissed quarterly KPI deadline (30 days past due) or rejected KPI evidence on first submission.
OutcomeThe team posts the corrected or supplementary evidence with attestor co-signing. The review concludes at remediation; the tranche unfreezes and team token vesting for the affected milestone resumes. The listing surface returns to active. The full event is preserved in the proof page chain (the miss, the remediation, the resolution).
Participant impactFrozen tokens return to their prior state (Active or Restricted as applicable). The participant sees the full sequence of events in the listing's proof page history; potential new participants see the remediation record.
R2ATTESTOR REPLACEMENT
Common scenario, attestor changes during the listingreplacement attestor onboarded and re-signs
TriggerAn attestor on the dossier loses Registry credentials (the audit firm's certifications lapse, the inspector firm changes ownership, the METER_OP attestor's license expires). The team is given the standard window to onboard a replacement.
OutcomeThe team identifies a replacement Attestor Registry party with the appropriate role; the new attestor reviews the dossier components the prior attestor signed and re-signs them. The B5 milestone schedule remains in force with the new attestor designation. The tranche schedule resumes; team vesting resumes.
Participant impactThe transition is reflected in the audit trail; the original attestor's signatures remain in the historical record but are flagged as superseded. The new attestor's signatures take effect from the replacement date forward.
R3DISCLOSED PIVOT
Project changes substantive direction with proper disclosureattestor review, possible tier reassessment
TriggerThe team discloses a material change to operating model (B2 asset class shift, business pivot, methodology change) within the 48-hour disclosure window. The change is substantive and may invalidate prior evidence.
OutcomeThe attestors conduct an evidence-first review: are the new operating model's evidence requirements satisfied by the existing dossier (likely re-attestation with addenda) or do they require fresh evidence? Depending on the magnitude of the change, the listing tier may be reassessed (e.g., a Retail Open listing that pivots to pre-revenue concepts may route down to Qualified).
Participant impactThe participant sees the disclosure, the attestor review, and the resulting tier or dossier changes. If the participant disagrees with the new direction, secondary market trading (where applicable) and the future milestone schedule provide the options. Holdings are not seized or refunded; the protocol respects the original commitment as the participant's exposure to the project's success or failure.
R4PERMANENT REVOCATION
Rare scenario, fraud or sustained non-compliancelisting endorsement withdrawn permanently
TriggerSustained non-compliance across multiple review cycles, fraud determination by attestor consensus with on-chain evidence, or refusal to engage with the remediation pathway over the review period.
OutcomeThe listing surface marks the project as permanently revoked with the full on-chain history preserved (every dossier version, every disclosure or missed disclosure, every attestor signature, every milestone completion and miss). The historical record is auditable by any participant.
Escrow dispositionUnreleased escrow tranches remain locked. Distribution back to participants follows the protocol's standard distribution mechanism; the exact mechanism depends on the size of the remaining escrow, the number of participants, and any applicable regulatory direction. The protocol cannot recover capital that has already released to the team in prior tranches.
Token stateThe token remains tradeable on any third-party venue that chooses to list it. The protocol's Launchpad endorsement is withdrawn permanently; tokens held by participants move to a state that reflects the revocation but does not destroy the participant's holding.
Four recovery scenarios, ranging from common (remediated trigger, attestor replacement) to substantive (disclosed pivot) to rare (permanent revocation). The protocol's design optimises for the common cases (low-friction remediation) while preserving substantive review for genuine pivots and permanent revocation for genuine bad-faith outcomes.
What protection does not cover
Three categories of risk sit outside the protocol's protection mechanism. First, market price risk: the protocol protects capital that has not yet released to the team, but it does not protect the token's secondary market valuation. A token can trade below the participant's entry price even if every milestone is delivered on schedule; market dynamics, macro conditions, and project-specific demand all affect price independent of operational delivery.
Second, capital that has already released to the team in prior tranches: when an irrecoverable trigger fires (R4 permanent revocation), the unreleased escrow stays in the protocol's distribution mechanism, but capital that has already flowed to the team in prior tranches cannot be clawed back through protocol mechanism. This is by design; the milestone-gated release implies that capital paired with a delivered milestone has compensated for that delivery. The integrity of the milestone-attestation chain matters here; if a milestone was attested fraudulently, the attestor faces Registry consequences.
Third, regulatory and legal risk specific to the participant's jurisdiction: the protocol enforces compliance with the jurisdiction-bound rules (Reg D, Reg S, MiCA, FCA, etc.) but does not represent or guarantee that a participant's regulatory position is sound. The participant's tax exposure, reporting obligations, and any jurisdiction-specific regulatory action are the participant's responsibility under their professional advisory arrangement.
The protocol's commitment is precise: capital is escrowed, releases are milestone-gated, insider vesting is delivery-aligned, and the revocation framework runs mechanically. The commitment is not that participation in any specific Launchpad listing will produce a positive financial outcome. The commitment is that the structural mechanism that protects participants from the failure modes documented in the diagnostic series runs at the smart-contract level.
The For Investors series complete
This page closes the four-part For Investors section. Each page covered one component of the investor-side protocol mechanism:
Verified profile. The six-step profile build and the five-component active profile that the protocol checks at every participation event.
Custody and compliance. The three custody options and the four token lifecycle states with state-specific rules.
Visible progress. The four classes of observable events and the proof page anatomy that makes each event audit-survivable.
Investor protection (this page). The four protection layers and the four recovery scenarios that protect capital across the lifecycle.
Together with the For Issuers series and the Why it's broken diagnostic series, these twelve pages describe one cohesive protocol design: what failure modes the Launchpad addresses (diagnostic), what the issuer commits to deliver (issuer-side), and what protections the participant relies on (investor-side). For the protocol-level primitives the Launchpad reuses, see Proof-of-Verification, the PoV Gate, the Attestor Registry, and the One-Claim Ledger.
