Retik vesting: presale unlocks and token claims

Are unlocked RETIK tokens ready to claim?

Unlocked RETIK requires an enabled claim, an eligible address, and a contract token balance covering that address's entire remaining allocation for the selected stage before a transfer can succeed. Elapsed vesting time answers only the timing part.

The deployed presale contract's claimableAmount reading reports the outstanding allocation. Its claimAmount transaction separately applies release rules. A positive reading does not establish that the whole amount can transfer immediately.

Initial release and accumulated installments

The claim history affects which release calculation the contract uses, including when the first claim occurs late.

First claim

The first claim applies the stage's configured initial percentage. That branch does not calculate every accumulated weekly installment.

Later claims

Later claims calculate elapsed release cycles and subtract previously collected vesting amounts when the remaining balance exceeds the configured installment. A remaining balance no larger than that installment can transfer only when the elapsed whole-cycle count exceeds the configured total by more than one.

The 2024 weekly release plan

The original presale plan specified 20 weekly releases, with no presale allocation unlocked at the token generation event. It described a one-week cliff after that event, an initial waiting period before release. The announced presale schedule began weekly unlocks on May 29, 2024.

Each release represented 5% of the original presale allocation. The presale bucket contained 400,000,000 RETIK, equivalent to 40% of the original total supply. Its scheduled weekly release was therefore 20,000,000 RETIK across the entire presale bucket. That aggregate quantity was separate from any individual participant's entitlement.

The participant's weekly share used their own original allocation as its basis, rather than the balance left after earlier claims. The announced terms also allowed schedule adjustments.

Release terms for the other allocations

The 2024 allocation plan assigned different release terms to the non-presale buckets. Liquidity and listing reserves had a scheduled 100% unlock at the token generation event. The market-making, incentives, and key opinion leader allocation had a 25% initial release, followed by a six-month cliff and quarterly releases.

Team tokens had a 12-month cliff, then releases of 25% of that allocation every three months. Marketing, acquisitions, and partnerships had a six-month cliff and releases of 25% every three months. Partners and advisors followed the same cliff, percentage, and release frequency for their own allocation.

Ecosystem releases followed a one-month cliff and the project's needs. The cashback reserve followed a six-month cliff and cashback needs. These demand-based buckets had no fixed release cadence. Their reserve terms did not determine when a presale participant could collect tokens.

ETH fees and unsuccessful claim attempts

The Ethereum claim required ETH for gas, the charge for executing the contract transaction. Its cost followed the gas consumed and the effective price per unit of gas. Network demand and transaction execution affected the fee; the scheduled RETIK release percentage did not specify a fixed dollar cost.

A claim that reverted during execution could consume gas while reversing its token transfer and state changes. Rejecting a wallet request before submission did not execute an on-chain claim.

Repeated failed submissions could therefore spend ETH without delivering RETIK. A restriction on the address or the stage's claim permission needed resolution before further execution could succeed.

What confirms that a RETIK claim completed?

A completed distribution has a successful transaction result and a RETIK transfer to the intended receiving address. The transferred quantity identifies the installment actually delivered.

A transaction hash identifies a transaction, which may still be pending. Ethereum does not provide a transaction receipt while that transaction remains pending. Inclusion and a successful receipt establish execution; finality gives stronger assurance that the recorded result will remain unchanged.

The receipt's success status alone does not describe how many tokens arrived. The token transfer record supplies the amount and recipient. A distribution also differs from token swaps, which exchange existing holdings.

Adding RETIK to a wallet's token display changes visibility. It does not execute a claim or release another installment.

View image file

Restricted wallets and replacement claim addresses

The 2024 claim procedure described blocking reported compromised wallets and using replacement claim addresses. The presale contract provided an owner-controlled address-change operation. Connecting a newly created address alone did not reassign the purchase allocation.

A claim-address change concerns the presale record; recovering wallet access concerns control of the account's keys. Those operations have different purposes. A recovery phrase gives access to the wallet's assets and must remain private. Disclosing it to someone offering claim assistance exposes those assets without establishing claim eligibility.

Weekly collection and accumulated releases

The 2024 claim terms allowed collecting unlocked installments later without a claim deadline. This historical term does not confirm that a working claim route remains available today. Current claim access and an address's outstanding allocation remain separate from the original calendar.

Frequent collection transferred eligible tokens out of the presale contract sooner and required more fee-bearing transactions. Delayed collection allowed installments to accumulate and could reduce the number of paid claims. Until collection succeeded, the unclaimed tokens remained dependent on the claim mechanism.