Legacy
Historical referenceLegacy airdrop
Historical allocations and vesting claims.
Historical vesting
Snapshot
Wallet + allocation
Legacy
Historical referenceHistorical allocations and vesting claims.
Historical vesting
Snapshot
Wallet + allocation
Vest
180-day linear schedule
Claim
Newly vested tokens
This page describes historical vesting and allocation plans. Topups do not create airdrop rights. Existing allocations and claims remain available through Legacy claims. The material below is a historical reference, not a topup benefit.
The historical plan reserved 100,000,000 project tokens for pass holders, or 10% of a proposed 1,000,000,000 token supply. Mainnet allocation and token launch are not live. The configured testnet uses a mock token.
The airdrop uses a Merkle root and linear vesting over 180 days.
The snapshot is taken when mint closes. Allocation is based on pass weight.
allocation = 100,000,000 * holderWeight / totalWeight
Rounding is down. The remaining dust stays in the vesting contract.
| Membership | Weight | Relative share |
|---|---|---|
| Each new pass | 10,000 | 1.0x |
| Existing NFTs | Original weight preserved | 1.0x or 2.5x |
Sum every pass owned by a wallet before building its snapshot row. A wallet appears once with its aggregate weight. Additional mints do not change an airdrop root that has already been finalized.
Example with two holders:
Each allocation is a leaf:
The tree is built with OpenZeppelin StandardMerkleTree and the types ["address", "uint256"].
The root is set on-chain before the start. The proof is tied to the wallet and the allocation amount.
Vesting is linear over 180 days.
Open Legacy claims from the workspace sidebar using the wallet in the historical snapshot. Topup totals and API usage do not change its allocation.
The airdrop card shows:
Click the airdrop claim button and confirm the transaction. The button shows the token symbol for the active network. The contract transfers only the newly vested amount.
If the card says No allocation, the wallet is not in the snapshot.
The airdrop is live on testnet with a mock token.
Mainnet airdrop is not live. The final allocation depends on the mint close snapshot and the token launch.
The airdrop token is a four.meme TaxToken. If the token taxes ordinary transfers from AirdropVesting, users receive less than their allocation while the contract records the gross amount.
This is the highest unresolved risk in the self-audit. Before mainnet, the team must verify the token's transfer behavior, whitelist the vesting contract, or use a non-tax token for the airdrop.
| Item | Address |
|---|---|
| AirdropVesting | 0x506d8182b65c9cb74113f62a1db7ae6584242209 |
| Airdrop token | 0xFc7d29a29f01a8e08E3eb1df32f9D4Cb51100442 |
| Root | 0xec6d9d0c720c7e65ec213f51649d40faeed7afc6a624ebc51a820f533a1893d7 |
| Start | 1793549536 |
The testnet token and allocation have no real value.
Alice = 100,000,000 * 10,000 / 35,000 = 28,571,428.57 tokens
Bob = 100,000,000 * 25,000 / 35,000 = 71,428,571.43 tokens
keccak256(bytes.concat(keccak256(abi.encode(account, amount))))
vested = allocation if elapsed >= 180 days
vested = allocation * elapsed / 180 days if elapsed < 180 days