Technical architecture.
Where enforcement lives, how the two engine paths differ, and what must be proven.
In this guide
Keep enforcement on the authoritative side
| Component | Responsibility |
|---|---|
| Launch / curve program | Create the token, enforce supply and trading accounting, and control migration. |
| Reward controller | Validate reserve commitment, campaign state, winner entitlements, vesting and claims. |
| Curve adapter / shared SDK | Read exact configuration, quote with engine rules and construct transactions. |
| Eligibility / settlement service | Produce reproducible evidence only where the selected policy delegates calculation. |
| Indexer / API | Reconcile chain events into useful views; it cannot authorize a transfer by changing a row. |
| Application | Present terms and state, obtain consent and signatures, and reconcile results. |
Native account design
| Account | Stored obligation |
|---|---|
| Launch PDA | Creator, mint, initial supply, complete allocation and fixed configuration version. |
| Curve PDA + trading vault | Virtual reserves, accounted real quote assets, sale inventory and lifecycle. |
| Sale / liquidity / rewards token vaults | Distinct minted inventory for trading, pool creation and rewards. |
| Fee vault / migration budget | Disclosed costs separate from trading and reward obligations. |
| Campaign / team accounts | Frozen rules, bounded roster, deadlines, scores and result. |
| Registration / claim record | Campaign, wallet, selected team, award and cumulative amount claimed. |
The controlling program signs for its PDAs through cross-program invocation when calling the Token Program or a migration dependency. Account owners, signers, mints, token programs, PDA seeds and allowed CPI targets must all be checked. A client-provided address is not evidence that an account belongs to the intended launch.
Existing engine or native curve
The research recommends first proving a LaunchLab integration that assigns the complete reserve to a RalliPad PDA, then collects it for member distribution. If protocol constraints cannot preserve the required commitment, the alternative is a native RalliPad virtual curve. Neither route returns to mandatory creator-funded trading liquidity.
LaunchLab configuration bounds supply, permitted lock/sale/migration rates, fees and quote assets. Read the selected on-chain configuration rather than hard-coding documentation examples. The integration remains unselected until custody, composition and release behavior are proven.
Meteora DBC and Metaplex Genesis were also researched. DBC’s new configurations target DAMM v2; leftover supply is a post-migration accounting result and must not be assumed to equal a guaranteed reward reserve. Genesis documents a bonding curve and separate project-vesting functionality; their safe composition and authority policies require verification for RalliPad.
Proofs and integer accounting
The bounded registration design can store each wallet’s team and cumulative claims on chain. For a Merkle-based eligibility or award design, leaves and verification must bind the relevant campaign, mint, wallet and amount. Preserve the dataset, rule version and evidence so the result can be reproduced.
Keep token base units and lamports as integers, with wider checked intermediates and integer strings across APIs. The reward controller must prove aggregate awards never exceed the secured allocation and cumulative claims never exceed the applicable vesting schedule.
A Merkle root authenticates a commitment, not the honesty of its publisher. Who can set or replace that commitment and what review process applies must be part of the authority model.
Prove the complete lifecycle
- Create a mint and virtual curve without seeded trading SOL; secure the complete reserve before activation.
- Verify the fixed beneficiary and authority state; attempt omitted or redirected allocation records.
- Execute buys and sells with real program instructions, including slippage, dust and boundary failures.
- Complete the curve and perform the actual supported migration.
- Collect the full reserve where an external escrow is used.
- Register participants, settle the result and transfer a winning member’s claim.
- Prove wrong-wallet, wrong-mint, duplicate-claim, repeated-settlement and withdrawal-bypass attempts fail.
Local arithmetic tests and UI walkthroughs cannot establish compatibility with a deployed financial program. The selected deployment needs integration evidence and independent security review before handling live funds.