HyperPad has two independent vesting systems. They’re easy to mix up, so here’s the clean split.
Buyer vesting — in the app
Controls how the tokens buyers purchased unlock after the sale.
| Field | Meaning |
|---|
tgeBps | % unlocked immediately when claims open (0–100%) |
cliffDuration | Delay before any linear unlock begins |
vestingDuration | Linear unlock window after the cliff |
Vested or not, buyer tokens are held in a segregated claim vault — separate from the raise — so
there’s no way for an unlock schedule to put your buyers’ tokens at risk.
Team vesting — contract only
Vests your allocation (the team remainder) on its own schedule via a dedicated TokenVesting
wallet, with its own clock (independent of the sale, so a failed raise can’t lock your tokens).
| Field | Meaning |
|---|
teamTgeBps | % of the remainder unlocked at start |
teamStart | Vesting origin (0 = launch) |
teamCliff | Cliff in seconds |
teamVesting | Linear seconds after the cliff |
teamBeneficiary | Recipient (0 = you) |
The create form doesn’t expose team vesting yet — through the UI, your team remainder is sent to
your wallet instantly. To vest it, call createSaleWithNewToken directly with the team params
set. A self-imposed team lock is a strong trust signal; if that matters to your raise, reach out and
we’ll help you wire it.
| Buyer vesting | Team vesting |
|---|
| Vests | What buyers bought | Your team remainder |
| Clock | Claims-open time | Your teamStart |
| Held in | Claim vault | TokenVesting wallet |
| In the app? | ✅ Yes | ❌ Contract only |
