A vesting wallet can restrict when its token balance becomes releasable under its coded schedule. It does not prove token value, project legitimacy, recipient behavior, fair distribution, or future price. The legacy Lester factory is compromised and new schedule creation, deployment fees, and token approvals to it are disabled. The immutable replacement is active only through chain/runtime/target/spender/fee checks. Existing children remain separate contracts. Their schedule has no factory-owner clawback, but the VestingWallet owner can transfer ownership, so the eventual recipient is not necessarily immutable.
The vesting schedule cannot be cancelled or clawed back, but the initial beneficiary is the VestingWallet owner and can transfer ownership. Choose the initial owner and schedule carefully.
Before setting up vesting, understand the two parameters that matter most: Cliff: A period at the start where no tokens are released. If you set a 6-month cliff, beneficiaries receive nothing for the first 6 months, then all cliff tokens vest at once. Linear release: Tokens unlock continuously after the cliff. 12-month linear means 1/365th of the vested amount unlocks every day after the cliff ends.
Navigate independently to lester-labs.com/vesting and select only a child discovered through a source-pinned legacy factory with a reviewed child-runtime hash.
Read the current VestingWallet owner rather than assuming the initial beneficiary still controls it. Confirm that the intended recipient controls that address.
Read the token address, current balance, released amount, start, cliff, duration, and `releasable(token)` value from the exact child. A copied interface or matching name is insufficient provenance.
The recovery transaction must be zero-value `release(token)` to the exact child wallet. Anyone may trigger it, but tokens go to the child’s current owner.
Sign only after every target and parameter check succeeds, then verify the token transfer and updated released amount through an independently selected RPC or explorer. Do not approve or deposit new tokens into the legacy factory.
A visible schedule is only one data point. Verify current ownership, token controls, all material allocations, and the exact runtime; do not treat vesting as an endorsement or safety certificate.
The historical child follows the OpenZeppelin VestingWallet release model: anyone may trigger `release(token)`, and the releasable amount goes to the child’s current owner. The frontend exposes that only as authenticated recovery. New schedules use the immutable replacement factory and attested child runtime after chain, target, spender, fee, token, and schedule checks.