Supply allocation and vesting

An allocation pie can sum to 100% while obscuring immediate team control or a vesting schedule that starts before funds are deposited.

Specify total raw supply, decimal precision and allocation denominator before displaying percentages. Every allocation needs a purpose, recipient/authority label, amount, immediate availability and release conditions. Do not confuse a planned schedule with an enforced deployed contract. The source documentation describes a vesting mechanism; the exercise below defines its own hypothetical schedule.

For linear vesting, state start, duration, cliff if any, total allocation and released-to-date. Calculate vested entitlement separately from currently claimable amount: previous releases reduce what remains claimable. If deposits can arrive after the schedule starts, the implementation may make a portion immediately releasable; disclose that dependency rather than assuming a fresh lock for each deposit. Beneficiary transfer and administrative paths also matter.

An allocation disclosure does not independently verify all wallets or prevent another mint path. A total-supply design must be reconciled with actual supply/authority evidence before a live claim is possible. Here all amounts and recipients remain fictional, with no contract deployment or funding.

Allocation denominator: stated total used for percentage calculations.

Vested entitlement: amount earned by the stipulated schedule.

Claimable: vested minus already released.

Enforced vesting: schedule implemented by inspectable controls, not a prose promise.

ILLUSTRATIVE Cedar supply=1,000,000 whole-unit equivalents: community 500,000; treasury 250,000; team 200,000; testing reserve 50,000. Team schedule is stipulated linear over24 months from month 0, no cliff; at month 6,20,000 have already been released. This is a paper schedule, not a real escrow.

Holder distribution plus unlock timeline:50/25/20/5 allocation shares; team month 6 vested 50,000, released 20,000, claimable 30,000, unvested 150,000. Label every figure illustrative and distinguish schedule from enforcement.

Caption: Fictional allocation and paper unlock schedule; no deposited or locked asset.

SPECIFICATION_ONLY — the rendered visual has not been produced or independently reviewed.

The fictional allocations sum to 1,000,000 and 100%. At month 6 the stipulated team entitlement is50,000; claimable is30,000 after the stated prior release.

It proves no locked funds, real custody, beneficiary independence, cap enforcement or future execution. A100% allocation pie cannot establish100% of supply is actually controlled by these labels.

Showing vested amount as claimable; omitting prior releases; calling a paper promise a lock; ignoring late-deposit or beneficiary-transfer behavior.

Calculate all percentages, month 6 team entitlement and claimable balance. Write a disclosure explaining the difference between this schedule and a verified vesting implementation.

• Reconcile units and total allocation.
• State start, duration, cliff and prior releases.
• Separate vested, claimable and unvested amounts.
• Do not label a paper schedule as enforced lock.

Allocation arithmetic is reproducible when its denominator and release assumptions remain explicit; enforcement requires separate records.

• Vested is not the same as claimable.
• A schedule promise is not an observed lock.
• Supply and authority evidence must accompany live allocation claims.

P12-L03

Use the named ZECOIN tool only as an evidence-reading context. This lesson creates no tool output, account session or entitlement. Offline exercise; do not sign, deploy, approve or fund anything.

• ERC20: ERC-20 standard — Token interface and allowance semantics; the standard does not establish issuer identity or safe permissions. Boundary: Mechanism documentation only; original illustrative values are stipulated, not observations. Historical records have separately frozen provenance and explicit collection gaps.
• VEST: OpenZeppelin Contracts 5.x finance — VestingWallet mechanism; actual schedule and beneficiary control require specific implementation evidence. Boundary: Mechanism documentation only; original illustrative values are stipulated, not observations. Historical records have separately frozen provenance and explicit collection gaps.

ILLUSTRATIVE — entirely fictional offline inputs; no current observation.

null — no real observation

1

null

needs_review