What you have to prove before retail capital changes hands
Every Launchpad listing posts a canonical-JSON evidence dossier on-chain before the presale opens. The dossier contains five blocks: identity, asset declaration, operating evidence, vesting and cap-table design, milestone and audit attestations. The marketing surface renders directly from the dossier; the team cannot publish claims that diverge from the on-chain document.
Canonical JSONSame facts produce the same hash, every time
On-chain anchoredBefore presale opens, before capital moves
4 route classesEnergy, trade and RWA, software and protocol, pre-revenue
The dossier is the application
Stage 3 of admission (see how to apply) produces the canonical-JSON evidence dossier. The dossier is the operational artifact that the protocol validates, attestors co-sign, and the listing surface renders from. Once anchored at S06, the dossier hash is the single source of truth about what the project claims and what the protocol has verified.
The choice of canonical-JSON (RFC 8785 inspired) is deliberate. Canonical serialisation means the same facts always produce the same byte string and therefore the same hash. Two teams with identical operating realities produce identical evidence packets; one team cannot stylistically rephrase the dossier to alter the hash. The hash is the cryptographic anchor; the readable surface is downstream of it.
The marketing site that participants see for a Launchpad listing is generated from the dossier. The team does not run a separate marketing site that says one thing while the dossier says another. The protocol-level alignment between claim and evidence is structural, not policy.
CANONICAL-JSON EVIDENCE DOSSIER, FIVE BLOCKSThe dossier is a single canonical-JSON document (RFC 8785 inspired). The same facts always serialise to the same byte string and produce the same hash. The hash anchors on-chain when the presale opens; the marketing page renders directly from the dossier, not from a separate site.
B1IDENTITY
Founders, key contributors, role bindingsno anonymous launches
ContentsVerified identities for each founder and key contributor (KYC completed at admission), role bindings to the Attestor Registry (FOUNDER, OPERATOR, AUDITOR, and route-specific roles), legal entity registration where applicable, jurisdiction declarations, communications addresses for protocol interactions.
Why it mattersThe anonymous-team pattern that recurs across documented presale failures (Lightchain, Moonshot MAGAX, AlleyCat) cannot route past B1. The identities are durable; subsequent material changes to identity trigger the Governance disclosure requirements.
B2ASSET
Underlying operating asset declarationdrives the route-specific requirements at B3
ContentsThe specific operating asset the token represents: installation IDs and capacity attestations for energy projects, counterparty list and settlement record for trade and RWA, deployed contract addresses and repository for software, treasury composition for stablecoins, custody arrangement for held assets. The asset class also determines which Attestor Registry roles must sign at B3.
Why it mattersThe Bitcoin Pepe pattern (raise $20M against vague meme-coin branding, deploy $4,800 of liquidity, walk away) cannot route past B2 because there is no operating asset to declare. The asset must be specific, verifiable, and bound to the Attestor Registry parties who can sign for it.
B3OPERATING EVIDENCE
Route-specific operating evidencethe substantive bulk of the dossier
ContentsOperating evidence appropriate to the asset class declared at B2: meter records for energy, settlement history for trade, deployed product and repository activity for software, audited reserves for stablecoins. The evidence must be ex-post-verifiable; claims of future performance live in B5 (milestones), not here.
Why it mattersThis is the block that turns "claimed working product with hundreds of thousands of users" (the RCO Finance marketing claim) into either verified or rejected. Operating evidence is hard to fabricate at the level the Attestor Registry verifies.
B4VESTING
Token supply, allocation, vesting designmilestone-aligned, not calendar-cliff
ContentsTotal token supply, allocation breakdown (public sale, team, advisors, investors, ecosystem fund, treasury), and the vesting schedule per allocation. Critical constraint: team and investor vesting must reference operating milestones from B5, not unconditional calendar dates.
Why it mattersThe 84.7% below-TGE pattern across institutional 2025 launches (Memento Research dataset) was driven by calendar-based vesting cliffs that triggered insider dumping regardless of whether operating milestones were met. B4 structurally blocks this by requiring the milestone-vesting link at admission.
B5MILESTONES + AUDITS
Operating milestones, audit attestations, designated attestorsthe commitment and the verifier
ContentsThe operating milestones the team commits to deliver (product shipped, revenue thresholds, regulatory approvals, throughput targets), with each milestone bound to an objective measurement, a deadline, and a designated Attestor Registry party that will sign on completion. Plus audit attestations for any deployed code, referenced to specific commit hashes.
Why it mattersB5 is the contract between issuer and capital. The Capital Release page documents how attestor-signed milestone completions trigger tranche releases from escrow; B5 is where the milestones get declared and the verifying parties get bound.
Five blocks compose the canonical-JSON evidence dossier. Each block is required; the dossier validation at admission rejects partial dossiers. The block sequence flows from identity (who) to asset (what) to evidence (verified record) to vesting (token economics) to commitment (milestones and audits).
Route-specific evidence by asset class
Block B3 (operating evidence) is the substantive bulk of the dossier and is route-specific. The Attestor Registry roles that must sign, the specific operating evidence required, and the verification cadence all depend on what the token represents. The protocol distinguishes four broad route classes; the dossier validation matches the asset class declared at B2 against the operating evidence in B3.
Energy and ESG-side projects (Routes 1 through 12 of the ESG marketplace) require METER_OP attestation and route-specific factor declarations. Trade and real-world-asset projects require counterparty lists, settlement records, and where applicable regulatory filings. Software and protocol projects require public repository activity, deployed contracts, and audit reports referenced to specific commit hashes. Pre-revenue concepts route to qualified or private tiers by default; the dossier acknowledges the pre-revenue status rather than pretending operating evidence exists where it does not.
ROUTE-SPECIFIC EVIDENCE BY ASSET CLASSBlock B3 of the dossier (operating evidence) is route-specific. The Attestor Registry roles that must sign, the specific evidence required, and the verification cadence all depend on what the token represents.
R-AENERGY
Renewable energy and ESG-side projects (R1 through R12 route family)cross-references the EDMA ESG marketplace
Operating evidence requiredMetered production history (where the asset is operating), installation registration to the Attestor Registry, capacity rating attestation, route-specific factor declarations (carbon, thermal, methane GWP, diesel emission factor for R9), grid connection credentials where applicable.
Attestor roles requiredMETER_OP for production data, INSTALLER or O&M_PROVIDER for capacity attestation, AUDITOR for the integrity of the operating record. For carbon routes, additional registry attestations (Verra, ICVCM-aligned methodology bodies).
Cross-protocol referencesThe route-specific math, evidence schemas, and methodology references are documented per route at Energy Flow, Carbon Flow, and Complex Flow.
R-BTRADE + RWA
Trade finance, real-world asset, structured-credit projectscross-references the EDMA Global Trade marketplace
Operating evidence requiredCounterparty list with verified business identities, settlement record from prior trades where available, regulatory filings where applicable (registration with the relevant authority for the trade type), custody arrangement for any held assets, off-chain audit of the underlying portfolio composition.
Attestor roles requiredAUDITOR for portfolio audit, CUSTODIAN for asset custody attestation, INSPECTOR for physical or operational verification (where applicable), plus the trade-finance-specific roles documented at the Settlement section.
Cross-protocol referencesThe trade settlement primitive that releases milestone tranches is the same one used by the Global Trade Marketplace; see the 6 milestone gates and EMT milestone tokens.
R-CSOFTWARE + PROTOCOL
Pure software, protocol, infrastructure, application-layer projectsaudit attestation cannot be a marketing badge
Operating evidence requiredPublic repository with committed development activity (a working address, not a stale snapshot), deployed contracts on testnet or mainnet with verifiable addresses, audit reports that reference specific commit hashes (not generic claims), working product demonstration, where applicable a usage record from a deployed environment.
Attestor roles requiredAUDITOR with a verifiable identity on the Attestor Registry (the audit firm is on-chain, not just its logo on a marketing page). For deployed contracts, the audit attestation references the specific contract addresses and commit hashes.
Cross-protocol referencesThe audit-as-marketing-badge failure mode that recurs in industry rug pulls (27% of 2024 cases featured fabricated or unverified audits) is structurally blocked here; see the Unverified Mints diagnostic page.
R-DPRE-REVENUE
Concepts and early-stage projects with no operating record yetroutes to T2 or T3 by default
Operating evidence requiredFounder identity verified, team credentials documented, business plan with measurable milestones (B5 in the dossier), IP and patent status, capital plan with declared use of presale proceeds. The dossier acknowledges the pre-revenue status; the Launchpad does not pretend pre-revenue projects have operating evidence they don't have.
Attestor roles requiredAUDITOR for capital-plan attestation; specialised roles depending on the project category. Identity verification is the minimum bar that all pre-revenue projects must clear.
Tier consequencePre-revenue projects route to T2 (qualified investor) or T3 (private placement) by default. Retail Open access requires demonstrated operating substance; the dossier is honest about what it does and does not show.
Four route classes with their evidence requirements. The classes are not mutually exclusive in scope; a complex project (e.g., an RWA platform with a software product) declares the dominant asset class and supplies evidence per that class, with addenda for the other components. The Attestor Registry roles required are the determinative constraint.
What changes once the dossier is on-chain
The moment the dossier hash anchors at S06, three things become structurally true about the listing. First, the marketing surface renders from the dossier; if the dossier says revenue is $400K annualised and the audit attestation supports it, the listing page says $400K annualised. The team cannot publish a $4 million claim elsewhere while the dossier holds the $400K figure.
Second, the team's vesting and cap-table are publicly observable. Block B4 of the dossier includes the full allocation breakdown and the milestone-aligned vesting schedule. Participants can see, before they commit capital, exactly what insiders hold, when those tokens unlock, and on what conditions. The undisclosed 90%-insider-allocation pattern that produced the $HAWK collapse is structurally blocked because the allocation is in the dossier.
Third, the protocol has a verifiable record of the team's milestones and the attestors who will sign on completion. When the team declares M1 (product shipped) is complete, the attestor named in B5 reviews and signs. Participants observing the chain can see the milestone declaration, the attestor signature, and the corresponding tranche release from escrow. The release is permissionless once the signature quorum is met; no human Launchpad operator approval is required.
These properties are not policy promises. They are structural consequences of how the protocol enforces the dossier-to-listing relationship. The protocol does not need to certify that the team is honest; it certifies that the dossier hash is anchored and that the listing surface renders from it.
Continue the For Issuers series
This page covered what the team has to prove. The next page covers what happens to the capital once participants commit it: capital release. Presale capital sits in protocol escrow under the One-Claim Ledger; tranches release as milestones complete with attestor-verified delivery evidence.
For the admission flow that produces the dossier in the first place, see how to apply. For the governance obligations that survive admission and run for the lifetime of the listing, see governance.
