Once tokens release from milestone tranches, the participant holds them under one of three custody arrangements: self-custody by default, EDMA-integrated qualified custodian, or bring-your-own institutional custodian. Each token sits in one of four lifecycle states (Active, Restricted, Frozen, Retired); the protocol enforces state-specific rules at the contract level regardless of where custody sits.
KYC-boundCustody choice does not bypass compliance
Custody is your choice, compliance is automatic
Once a milestone completes and the linked tranche releases tokens to participant addresses, the participant holds those tokens. Where the tokens sit (which wallet, which custodian, which arrangement) is the participant's choice. What rules apply to the tokens (whether they can be sold, transferred, retired, used as collateral) is the protocol's enforcement. The two are independent: a participant in self-custody and a participant using a qualified custodian face the same rule-enforcement, just from different operational positions.
The protocol enforces token state rules at the contract level. A restricted token does not become transferable because its custodian wishes it were; an attestation-revoked token does not become tradeable because the participant moves it to a different wallet. Custody is operational; compliance is structural. The two pages following this one in the series document what participants observe about the project's progress and what protection mechanisms protect the capital under all four token states.
THREE CUSTODY OPTIONS, INVESTOR CHOICEOnce capital has flowed into a Launchpad escrow and the team has begun delivering against milestones, the participant receives tokens at each milestone-linked unlock. Where those tokens are held is the participant's choice. The protocol supports three custody arrangements; proofs follow tokens regardless of custody location.
O1SELF-CUSTODY
Default, full control of keysbest for crypto-native participants
How it worksTokens are held in the participant's own wallet bound at C4 of the verified profile. The participant controls the keys. The EDMA dashboard displays balances, proof links, and per-asset action buttons (sell, retire, transfer where rules allow). Hardware-wallet integration and 2FA are supported.
What it requiresSelf-managed key security. The participant accepts responsibility for the wallet's seed phrase, hardware key, or multi-sig configuration. The protocol cannot recover tokens held under lost keys.
What it does not changeRestricted-asset rules still apply. Frozen-token state still applies (if an attestation is revoked). Vesting schedules from the dossier still apply. Custody is where the token sits; the protocol's rules about what can be done with the token are enforced regardless.
O2EDMA CUSTODY
Qualified custodian, named segregated accountinstitutional-grade security
How it worksFor participants who prefer not to manage keys, EDMA integrates with a qualified custodian. The participant receives a named, segregated account; tokens are held under MPC (multi-party computation) or multi-sig security with the participant as the controlling party. The participant operates through the EDMA dashboard with the same UX as self-custody; the difference is who holds the keys.
What it requiresKYB completion if the participant is an entity. Acceptance of the custodian's terms of service. The custody arrangement is contractual between the participant and the custodian; EDMA facilitates the integration but is not the custodian itself.
What it providesRecovery pathways if the participant loses access (subject to the custodian's standard recovery procedures). Insurance coverage per the custodian's policy. Audit trail integration with the EDMA proof page system.
O3BRING-YOUR-OWN
Existing institutional custodian via APIfor participants with established custody
How it worksInstitutional participants with existing custodian relationships (Fireblocks, Anchorage, BitGo, Coinbase Custody, and other qualified providers) connect through API integration. Works with both segregated and omnibus custody structures. Tokens retain their Proof of Verification and One-Claim links regardless of where they sit; the custodian sees the proofs through the integration.
What it requiresThe custodian must support the integration (most major institutional custodians do). The connection is established through the EDMA admin interface with the custodian's API credentials. The institutional participant's existing operational workflow (approvals, treasury management, reporting) continues as it would with any other asset class.
What it preservesExisting compliance and audit infrastructure. The institutional participant can maintain its current reporting systems, internal controls, and regulator-facing reporting; the Launchpad-purchased tokens appear in the same custody account as the rest of the institutional portfolio.
Three custody arrangements supported by EDMA. The choice can be different per holding. Proofs follow tokens regardless of custody location; attestation revocation flags propagate to all custody arrangements; restricted-asset rules apply equally.
Token states and lifecycle transitions
A token's state is observable in the participant's dashboard and through the proof page system. The standard transitions are: Active to Restricted (when a vesting schedule moves to a restricted lockup), Restricted to Active (when legal unlock dates pass and counsel clears the lot for resale), Active to Frozen (when an attestation backing the token is revoked or expired), Frozen back to its prior state (when the underlying issue is remediated), or any state to Retired for tokens that represent retirable claims (carbon credits, energy claims).
The protocol does not introduce its own state types beyond these four. Active is the default; Restricted reflects legal compliance rules; Frozen reflects evidence-revocation events; Retired is the terminal state for retirable-claim tokens. The participant always has visibility into the current state, the trigger that caused it, and the path back to Active where applicable. The transitions are recorded in the audit trail of the participant's profile (C5) and in the proof pages of the listing.
TOKEN STATES, FOUR LIFECYCLE PHASESA Launchpad-purchased token moves through up to four states across its lifecycle. The state determines what actions are available; the protocol enforces state-specific rules at the contract level regardless of custody location.
S1ACTIVE
Vested, unrestricted, freely tradable per route rulesthe default operating state
What is allowedTrading on EDMA marketplaces and connected venues, transfer to other addresses, retire (where the route applies, e.g., carbon credits), use as collateral in EDMA DeFi where permitted. All actions are gated by the standard route rules (some routes prohibit certain destinations; the dashboard disables disallowed buttons with explanations).
Common transitionsActive to retired (participant chooses to retire). Active to frozen (an attestation backing the token's underlying evidence is revoked). Active typically remains active for the lifetime of the holding.
S2RESTRICTED
Held under legal transfer limitsvests into Active on legal unlock
What is allowedThe token is credited to the participant's account per the vesting schedule but public resale is blocked. The participant can see the holding in the dashboard with its unlock date. Use as DeFi collateral may be restricted depending on the route. Transfer to other accounts within the same legal owner is typically permitted (e.g., between an investor's controlling wallet and their custodian's account).
Why it appliesUS participants typically hold Reg D-restricted tokens with 12-month lockups for non-affiliates. Other jurisdictions have analogous rules. The restriction is a legal one, not a protocol policy; the protocol enforces it at the contract level to ensure compliance.
Transition to ActiveWhen the legal unlock date passes (typically 12 months for US Reg D non-affiliates), counsel clears the lot and the protocol changes the status from Restricted to Active. The dashboard notifies the participant; the resale buttons unlock.
S3FROZEN
Attestation revoked or expired, held but not actionablevisibility preserved, actions paused
What is allowedThe participant continues to see the holding in the dashboard. Transfer, sale, and retirement actions are paused with a clear explanation of the trigger. The holding is not destroyed or seized; it is held in a state where the proof backing it is no longer valid, and actions wait until proof is restored.
Why it appliesIf an attestor on the dossier loses their Registry credentials, if the project enters revocation review (see governance), if an evidence component is found to be invalid: the affected tokens move to Frozen state. The freeze is graduated and recoverable in most cases.
Transition outIf the underlying issue is remediated (replacement attestor, restored evidence, completed quarterly KPI), the protocol unfreezes the token and it returns to its prior state (Active or Restricted, as applicable). If the issue cannot be remediated, see investor protection.
S4RETIRED
Claim locked permanently, certificate issuedterminal state for the holding
What it meansFor tokens that represent claimable environmental impact (carbon credits, energy retirement, etc.), retirement is a participant action that permanently locks the claim. The participant receives a time-stamped retirement receipt and a public proof page with the serial number, claim details, and full PoV trail. Retired tokens remain visible in the participant's account for audit and ESG reporting.
What it does not apply toTokens that do not represent claimable impact (governance tokens, native protocol tokens, treasury holdings) typically do not have a Retired state. They remain Active or Restricted until disposed.
Four lifecycle states. The state determines what actions are available; the protocol enforces state-specific rules regardless of custody location. Transitions emit on-chain events with the trigger, observable through the proof page system.
Where the participant's exposure sits across the lifecycle
Across the lifecycle, the participant's exposure sits in different places. Pre-commit, the participant has no exposure (the verified profile exists but no commitment has been made). At commit, capital is in the project's escrow (under the One-Claim Ledger, not under the team's control). Through milestone tranches, tokens release to the participant's address but may be Restricted (subject to legal lockups) or Active (freely tradable per route rules). Through quarterly KPI cycles, the dossier's evidence is re-attested but the participant's tokens do not change state unless something material changes.
The participant's exposure can also move sideways: Active to Frozen if the project enters revocation review, Frozen back to Active or Restricted if the trigger is remediated. The 'what is at risk at any given moment' question has a precise answer at the smart-contract level: the dashboard shows the current state of every holding, the unlock dates for restricted holdings, and the freeze status for any flagged holding. There is no ambiguity about what the participant owns and what actions are available to them.
For the substantive cases where the project misses obligations or the protocol's revocation framework runs, see investor protection, page 4 of this series. For the day-to-day observability of project progress that affects whether obligations are being met, see visible progress, page 3 of this series.
Continue the For Investors series
Page 3 of the series, visible progress, documents what the participant can observe about the project after commit: the four classes of on-chain events (milestone completions, quarterly KPI re-attestations, material change disclosures, tranche releases) and the proof page anatomy that makes each event audit-survivable.
Page 4, investor protection, documents the four protection layers and the four recovery scenarios that protect the participant's capital across the lifecycle.
