Wallet claims & vesting.

Open claims only when the conditions hold

Every claim requires a finalized entitlement, sufficient reward custody and satisfaction of the campaign’s release rules. The research also proposes a graduation gate: successful migration plus collection of the complete reserve before member vesting starts. That additional rule is not yet selected for all RalliPad launches.

claims_ready = winner_settled
            AND migration_successful
            AND complete_reserve_available

vesting_start = timestamp when all gates become true

Under that policy, a winning team can have an award while the token still trades on the curve. A token that never graduates can leave the award locked indefinitely. Settlement-only releases would require a separately approved and tested economic design.

If LaunchLab is selected, its beneficiary claim path requires migration and the engine’s vesting schedule must also permit collection. RalliPad cannot promise tokens earlier than its own custody can receive them.

Vesting controls availability, not ownership of the award

A = wallet award; u = initial release basis points
I = floor(A × u / 10,000)

if not claims_ready: vested = 0
else if duration is zero: vested = A
else:
  vested = I + floor((A − I) × elapsed / duration)
  elapsed is clamped between 0 and duration

claimable = vested − cumulative_claimed

For a 200,000-token award, an illustrative 20% initial release unlocks 40,000 tokens at the release gate, with 160,000 vesting over an illustrative 30 days. Fifteen days later, 120,000 total are vested. If 40,000 were already claimed, another 80,000 are claimable. These are teaching values, not universal launch terms.

A claim pays the entitled wallet

1. Verify the award

   Check the campaign, token mint, winning registration or entitlement proof, beneficiary and schedule.

2. Calculate the available delta

   Use the chain clock and stored cumulative claims. The client cannot choose a larger payout amount.

3. Validate the destination

   Use a token account for the right mint controlled by the recorded member wallet. A third-party caller cannot substitute their own destination.

4. Commit and transfer together

   Advance the cumulative claim amount and transfer the newly available tokens atomically. Duplicate calls cannot collect the same units twice.

The proposed participant claim uses the beneficiary wallet’s authorization. A permissionless relayer could be added only with fixed-beneficiary checks and an explicit fee policy. No claim flow ever needs a seed phrase or private key.

After the tokens reach the wallet

Received tokens in an ordinary SPL token account can be held, transferred or sold by that account’s owner. The remaining unvested award stays in custody. Vesting limits the timing of releases; it does not guarantee price stability or that members keep tokens after claiming.

Lost-wallet recovery, claim expiry and beneficiary changes require a separately approved authorization policy. There is no assumed recovery key or operator right to redirect awards.