After capital flows into escrow, the project's progress is public. Four classes of events produce on-chain artifacts that any participant can observe: milestone completions, quarterly KPI re-attestations, material change disclosures, and tranche releases. Each emits a public proof page with five standard sections. Participants do not depend on the team's communications to know what is happening.
Real-timeEvery event emits an on-chain artifact
Quarterly KPIRe-attestation cadence on the dossier
Proof pagesPublic, shareable, audit-survivable
Information asymmetry is structurally addressed
The default information dynamic in token launches is asymmetric: the team knows what is actually happening, the participants depend on the team's communications. The team controls the marketing surface, the Discord, the X account, the AMA narrative. When operating reality diverges from communicated narrative, participants are the last to know. The collapse pattern documented in no KPI evidence (81% of 2017 ICOs defunct within a year; 84.7% of 2025 institutional TGEs below TGE) is partly a consequence of this asymmetry.
The Launchpad inverts the default. The project's progress is recorded on-chain through events of four classes: milestone completions, quarterly KPI re-attestations, material change disclosures, and tranche releases from escrow. Each event emits a public proof page. The team does not control whether participants see the events; the events are recorded by the protocol independent of the team's communications. Participants observing the chain see exactly what the protocol verified, who attested, and what changed.
FOUR EVENT CLASSES VISIBLE TO PARTICIPANTSAfter capital flows into escrow, the project's progress is public. Four classes of events produce on-chain artifacts that any participant can observe: milestone completions, quarterly KPI re-attestations, material-change disclosures, and tranche releases from escrow. Each emits a public proof page; participants do not depend on the team's communications to know what is happening.
E1MILESTONES
Project completes a milestone, attestor co-signstriggers tranche release
What participants seeThe team declares the milestone complete with operating evidence (deployed contracts, audit reports, revenue audit, throughput data, regulatory approval, asset commissioning). The Attestor Registry party designated in B5 of the dossier reviews and signs. The proof page shows the milestone, the evidence hash, the attestor signatures, and the tranche release that follows.
Why it matters for capital observationEach milestone completion is paired with a tranche release. The capital release page documents the mechanism; from the participant's side, what is visible is the chain of milestone-attestation-release pairs that demonstrates the project is delivering against its dossier commitments.
E2QUARTERLY KPI
Re-attestation cadence, every 90 daysupdated metrics, attestor-signed
What participants seeEvery 90 days, the team posts updated KPI evidence for the operational metrics declared at admission (revenue, throughput, user count, route-specific measurables). The attestors designated in B5 co-sign. The proof page shows the updated metric values, the evidence hash for the current quarter, the attestor signatures, and the change from the prior quarter.
Why it mattersThe quarterly cadence keeps the on-chain dossier aligned with current operating reality. If a project's revenue dropped 60% between Q2 and Q3, the participant sees that change in the proof page chain; the team cannot continue to claim Q2 metrics on the listing surface while the on-chain dossier shows the Q3 update.
E3MATERIAL CHANGE
48-hour disclosure window for substantive changestrigger-based, not calendar-based
What participants seeWithin 48 hours of internal awareness of a material change (founder departure, custody change, operating-model pivot, legal status change), the team posts the disclosure. The proof page shows the change category, the disclosure timestamp, the team's explanation, the attestor review status, and the impact assessment (does this trigger a tier reassessment, milestone revision, or revocation review).
Why it mattersMaterial changes are the most common source of post-admission risk for participants. The 48-hour window keeps participants informed in real time; the on-chain disclosure record is durable and auditable. If the team fails to disclose within the window, the protocol-detected or community-reported discovery itself becomes the trigger for revocation review.
E4TRANCHE RELEASE
Escrow capital flows to team treasurypermissionless once quorum is met
What participants seeEach tranche release is a separate on-chain event. The proof page shows the milestone the release is paired with, the attestor signatures that triggered the release, the exact tranche amount released, the team treasury address that received the capital, and the cumulative status of the escrow (how much remains locked, how much has been released, how many milestones remain).
Why it mattersThe tranche release record is the cash-flow side of the milestone-completion record. Participants observing the chain can track not only whether the project is delivering against milestones but also how much capital has actually flowed to the team versus how much is still held in escrow against future delivery.
Four classes of events visible to participants after commit. Each emits a public proof page with the standard anatomy documented in the diagram below. The classes overlap; a single material change disclosure may trigger an attestor review that updates a milestone schedule, which in turn affects the next tranche release.
The proof page is the central artifact
Every event of every class emits a proof page with the same five-section structure. The standardisation matters: a participant who knows how to read one proof page knows how to read every proof page across every Launchpad listing. The same applies to auditors, regulators, and new participants joining a project two years after the initial commit. Proof page format is part of the protocol, not a per-project design choice.
The proof page is also the unit of cross-reference for the protocol. When a milestone completion triggers a tranche release, the milestone's proof page links to the tranche release's proof page. When a quarterly KPI update affects the listing tier classification, the KPI proof page links to the tier reassessment. When a material change disclosure triggers an attestor review, the disclosure's proof page links to the review's resolution. The cross-reference graph makes the listing's history navigable.
PROOF PAGE ANATOMY, FIVE STANDARD SECTIONSEvery observable event (milestone completion, quarterly KPI, material change, tranche release) emits a public proof page with the same structure. The proof page is the participant's source of truth; the team's marketing communications are not.
What it containsEvent class (milestone, KPI, material change, tranche), event timestamp (block-level precision), project identifier (the listing's dossier hash anchor), and a one-line human-readable summary of what happened ('M2 revenue threshold reached', 'Q3 KPI re-attestation', 'Material change: founder departure', 'Tranche 3 release of $4.2M').
P2ATTESTOR SIGNATURES
Quorum proof, who signed and what they signedcryptographically verifiable
What it containsEach attestor's Registry identifier, their role (AUDITOR, METER_OP, INSPECTOR, etc.), the specific component they attested (some attestors sign the financial audit, others sign the operating-asset attestation), the signature timestamp, and a verification link the participant can click to verify the signature cryptographically against the Attestor Registry.
What it containsThe dossier hash before the event, the canonical-JSON evidence hash for the event itself, and the resulting updated dossier hash if the event updates the dossier (quarterly KPI events update; material change events update; milestone events typically reference but do not modify). The hash chain is append-only; participants can reconstruct the dossier's evolution.
P4CAPITAL OR STATE RECORD
Tranche release amount, escrow status, token state changeson-chain cash and token impact
What it containsFor tranche releases: the exact amount released, the recipient treasury address, the escrow's cumulative state (how much locked, released, remaining). For milestone events with a tranche pair: the linked tranche release record. For material changes or KPI events: any state changes to participant-held tokens (e.g., if the disclosure triggers a tier review that reclassifies the listing).
P5CROSS-REFERENCES
Linked events, dossier sections, related proof pagesnavigable history
What it containsLinks to the related dossier section in B5 (for milestone events, the milestone declaration; for KPI events, the metric definitions), the prior event of the same class (the previous quarterly KPI, the previous material disclosure), and any downstream events triggered by this one (a milestone event linking forward to its tranche release record).
Five-section anatomy of every Launchpad proof page. The standardisation makes proof pages shareable and audit-survivable: a regulator reviewing a 2026 event in 2028 can read the proof page without prior protocol familiarity and understand exactly what happened.
What this changes for participants
The structural change is the elimination of trust as a participation prerequisite. The default 'do you trust this team' question becomes 'has this team delivered against their dossier commitments' which is observable on-chain. The participant does not need to assess team character; they can read the proof page chain and see whether milestones are being delivered, whether KPIs are being re-attested on cadence, whether material changes are being disclosed within window.
This does not mean character or trust is irrelevant; project quality, vision, and execution still matter for outcomes. What changes is that the participant's information access does not depend on the team's communication. The participant has the same factual basis as the team itself for assessing the project's progress against its commitments. The team can choose to communicate or not, can choose to emphasise or downplay, can choose to lead with vision or lead with metrics; the on-chain record stays the same regardless.
The pages adjacent to this one document the structural mechanism this observability supports: custody and compliance documents what holding tokens means across the lifecycle; investor protection documents the protection layers that connect the observed events to the participant's capital. Together, the three pages describe the post-commit relationship between protocol, project, and participant.
Continue the For Investors series
The final page of the series, investor protection, documents the four protection layers (capital escrow, milestone-gated release, milestone-aligned vesting, revocation framework) and the four recovery scenarios that protect the participant's capital across the lifecycle. The protection mechanisms connect to the observable events documented on this page: protection runs when triggers in the observable record fire.
