RADAR Token Vesting: What Unlocking Means

Unlocking vested RADAR means a portion of tokens that was restricted by a vesting arrangement has become eligible for release. It does not necessarily mean the tokens have already appeared in your wallet, and it does not guarantee that you can sell them immediately.

Vesting is commonly used to distribute tokens over time rather than making an entire allocation accessible at once. The arrangement may apply to a team member, contributor, investor, community allocation, or another named beneficiary. The token label alone does not tell you which arrangement applies to your RADAR.

Keep these three stages separate:

• Vested: the allocation is subject to a time-based or other release condition.
• Unlocked: some or all of the restricted amount is now eligible to be released.
• Claimed or transferred: tokens have actually been moved to the receiving wallet, if the arrangement requires a transaction.

Before acting, identify the exact RADAR allocation and its governing schedule. The cliff, release dates, claim process, and contract can differ between allocations. Do not assume that one holder’s unlock date applies to yours.

A vesting schedule sets when an allocation becomes accessible. Some schedules include a cliff: an initial period when nothing is released, followed by a first release. Others release portions periodically, such as monthly, or make the allocation available on a single date. These are common patterns, not confirmation of RADAR’s specific terms.

A schedule may describe a total allocation and a percentage or quantity released at each step. It may also specify whether the release is automatic or whether the beneficiary must claim. Read the original grant terms or the relevant vesting contract, rather than relying on a token tracker’s summary alone.

To check your schedule, look for:

1. The beneficiary address and the total allocation.
2. The start date and any cliff period.
3. The quantity or percentage released at each interval.
4. Whether past, unclaimed releases remain claimable.
5. Any end date, transfer restriction, or other condition.

RADAR’s exact schedule cannot be inferred from the ticker. If you cannot match the terms to your wallet address and allocation, pause and seek confirmation through an official project channel before signing a transaction.

First confirm whether your RADAR is actually vested. A token balance shown in a dashboard, allocation notice, or spreadsheet is not proof that tokens are in your wallet or currently claimable. Compare the beneficiary address and amount with the original grant or the vesting contract’s on-chain records, where applicable.

Then check whether the release requires a claim. In some arrangements, tokens transfer automatically when they unlock. In others, the beneficiary must connect the correct wallet and submit a transaction. If a claim is required, verify the network, contract address, wallet account, and amount in the wallet’s transaction preview before approving it.

A cautious check looks like this:

• Confirm the terms from the organization or agreement that granted the allocation.
• Match the beneficiary address exactly; a similar-looking address is not enough.
• Inspect the contract details using a trusted block explorer or wallet interface.
• Check the transaction’s destination and permissions before signing.
• Keep the transaction record after a successful claim.

Never reveal your seed phrase or private key to claim tokens. A legitimate vesting process should not require you to hand over wallet recovery credentials.

“Unlocked” can mean that a scheduled amount is available to claim, not that it has already been transferred. Check the contract or grant interface for separate figures such as total allocation, released amount, claimed amount, and remaining locked amount. If those categories are not clear, avoid treating a displayed total as your spendable wallet balance.

If the tokens are already in your wallet, check that the wallet is connected to the correct network and that you are viewing the genuine RADAR token contract. Wallets can display unfamiliar tokens or similarly named assets; a matching ticker is not enough to establish that a token is authentic.

After a claim, verify the transaction status and the resulting token balance. If the transaction fails, do not repeatedly approve new requests without understanding the error. Failed transactions can still consume network fees, and repeated attempts can expose you to malicious prompts if you are using an unverified site.

A claimable balance is also different from a guaranteed sale. You may need to find a market with sufficient liquidity, and a sale can incur trading fees, slippage, and network costs. Unlocking is an access event, not a promise about price or a recommendation to trade.

The cost depends on how the vesting arrangement works. If a transaction is required, you may have to pay the network’s transaction fee in its native asset. That fee can change with network activity. If you later transfer or trade the tokens, those actions may require additional fees. The specific fee for claiming RADAR is not universal, so check the transaction preview before signing.

There may also be costs that are not obvious from the claim screen. A swap can include a trading fee and slippage, while a withdrawal through a centralized service may have its own rules. Do not assume that a token’s unlock itself creates a fee, or that a displayed estimate covers every later action.

Before you proceed, confirm:

Check	Why it matters
Network fee and fee currency	You may need the network’s native token to submit a claim.
Amount and destination	Confirms what the transaction will release and where it will go.
Approvals or permissions	A claim should not require broad, unexplained access to unrelated assets.
Later transfer or trade costs	Claiming and selling are separate transactions.

If the transaction requests an unexpectedly large payment or an unlimited token approval, stop and verify the request independently.

The main risk is signing a transaction that is not the claim you intended. Fake unlock announcements and impersonated support accounts may direct you to counterfeit claim pages, request a wallet connection, or ask for your recovery phrase. A wallet connection by itself does not prove a site is safe, and a familiar logo is not proof of authenticity.

Check the project’s official communication channels by navigating to them yourself, not by following an unsolicited direct message. Confirm the contract address independently, and read the wallet prompt carefully. If the transaction is difficult to understand, do not sign it just because a countdown or warning says your allocation will expire.

Also consider vesting and market risks. The schedule may not match what you expected, a claim transaction can fail, and an unlocked amount may be difficult to trade at a quoted price if liquidity is limited. A token’s price can move independently of its vesting status.

Protect yourself by using a wallet you control, keeping its recovery phrase offline, and never sharing private credentials. If you already signed a suspicious transaction, stop interacting with the site and review wallet permissions and transaction history using trusted tools. For substantial holdings, consider getting help from a qualified security professional.

Avoid these common mistakes when you see a RADAR unlock notice:

• Treating “vested” as “in my wallet.” An allocation may still be locked or require a separate claim.
• Assuming one schedule covers everyone. Different grants or allocations can have different terms.
• Trusting a ticker or screenshot. Confirm the wallet address, token contract, and vesting arrangement.
• Signing in a hurry. A deadline or urgent message is not a reason to skip transaction checks.
• Confusing unlock with profit. Release timing says nothing certain about market price, liquidity, or sale proceeds.
• Sharing a recovery phrase. No legitimate claim should require your seed phrase or private key.
• Ignoring costs after the claim. A transfer or swap is a separate action and can carry its own fees and risks.

A sensible order is: verify the source of the allocation, match its beneficiary address, read the release terms, confirm whether a claim is needed, inspect the transaction, and only then decide whether to proceed. If a key detail cannot be confirmed, waiting is safer than signing an unexplained transaction. You do not need to claim immediately just because someone sent you an unlock announcement.

Use this short checklist before acting on a RADAR vesting notice:

1. Identify the allocation. Know who granted it and which wallet address is the beneficiary.
2. Read the actual terms. Confirm the cliff, release dates, claim rules, and any restrictions.
3. Verify the contract and network. Do not rely on a ticker, copied address, or unsolicited link.
4. Check the wallet prompt. Make sure the recipient, amount, and permissions match the claim you expect.
5. Budget for the transaction. Confirm the fee currency and estimate, then account separately for later transfers or trades.
6. Save the record. Keep the grant terms and transaction confirmation for your own records.

If you cannot verify the allocation, do not connect your wallet or sign a transaction. Ask the grant issuer through a channel you independently know is genuine, and avoid sharing sensitive wallet information. For tax treatment, rules depend on where you live and the circumstances of the grant and receipt; consult a qualified local tax professional if the amount is material.

The practical takeaway is simple: unlocking is a change in access under a particular schedule. Confirm that schedule and the claim transaction before treating any RADAR amount as available.