How the allocation is locked.
Separate custody, wallet-bound entitlements, and claims that cannot redirect another member’s award.
In this guide
The lock is a program rule
The required guarantee is that the promised community allocation cannot be sold by the creator, taken by a KOL or spent as trading liquidity. Its release follows the launch’s published campaign and reward rules. A label in the interface cannot enforce that guarantee.
In the native reference, the Token Program owns the rewards token account and a RalliPad program-derived address is its token authority. A PDA has no private key. RalliPad can authorize transfers through its program only when the required checks pass.
That is different from placing tokens in an ordinary developer wallet and asking the developer not to move them. It is also different from freezing every recipient’s wallet.
Two ways to secure the same commitment
| Path | At token creation | Before member claims |
|---|---|---|
| Native RalliPad curve | The community tokens enter a dedicated rewards vault. | The reward controller verifies settlement, funding and the published release gate. |
| LaunchLab reference integration | Reserved supply remains in the engine vault, with a fully assigned campaign-specific RalliPad PDA entitlement. | The controller collects the available reserve through the beneficiary path into its validated vault, then applies member claims. |
LaunchLab documents reserved vesting tokens outside curve sales and graduation liquidity, with beneficiary records and claims gated by migration. This external entitlement is not a RalliPad vault balance at creation. Its schedule and complete collection path must be tested for the selected configuration.
The RalliPad-specific PDA assignment and atomic finalization remain integration requirements. Public engine documentation alone does not prove that the composed RalliPad launch works.
Bind the award to winning wallets
Record the participant
Bind the campaign, participant wallet and selected team in an authoritative registration. A wallet cannot join twice or count for two teams in the same campaign.
Finalize the winner
Apply the frozen scoring, deadline, eligibility and tie rules. Record the final winner set and entitlement calculation.
Assign each award
Bind each entitlement to the campaign, mint, beneficiary wallet, amount and release schedule. A winner is entitled to a share; they cannot withdraw the entire reserve.
Validate the claim destination
Transfer only newly claimable tokens into a token account for the correct mint whose owner is that beneficiary. A caller-supplied replacement wallet must not redirect payment.
No withdrawal shortcut
- The creator cannot replace the beneficiary or reuse the same reserve for another obligation.
- The KOL cannot sweep member allocations through an organizer withdrawal.
- An administrator cannot use a generic rescue, close-account or emergency path to drain protected rewards.
- Pause and recovery behavior must preserve earned claims; their exact powers must be published.
A PDA is not proof of immutability. If the program can be upgraded, the authority that controls upgrades is a separate trust assumption. Users need the actual deployed program, vault, upgrade controls and security review to assess the lock.