Lifinity holders can prepare, submit, and verify a wind-down token claim

Set the stop boundary before opening the claim

Record three inputs before continuing: the public wallet address that controls the position, the Lifinity token form associated with that address, and the next action shown for that token form. The eventual claim output is USDC. Stop if the connected address differs from your record or the interface finds no expected position.

A useful starting record contains the public address, visible LFNTY and xLFNTY balances, the starting USDC balance, any veLFNTY balance reported by the application, and the displayed claim amount. A screenshot can preserve the interface state, but it does not replace the transaction record. Never enter a recovery phrase, private key, or exported signing key into a claim page.

Separate durable rules from live parameters. The eligible token forms, Solana transaction model, USDC output, and published deadline define the task. The wallet balance, displayed entitlement, network fee, recent block data, and transaction instructions belong to the live session. An older screenshot cannot establish those changing values for a later transaction.

The reversible part ends when the wallet signs and submits the transaction. Before that point, you can disconnect, close the page, change the selected account, or investigate an unexplained difference without altering the on-chain position. An unfamiliar request, missing balance, or unexpected destination is a reason to stop at that boundary.

Token form determines what the first record should contain

LFNTY, veLFNTY, and xLFNTY should remain separate entries in the starting record. They represent different account states, so a wallet token list alone may not reveal every eligible position. Compare the connected address with both the wallet display and the claim interface before accepting the amount offered for conversion.

LFNTY in the wallet

LFNTY is the governance token and appears as a transferable Solana token when the connected wallet holds it. Record its balance without assuming that the full visible amount automatically equals the claim entitlement. Use the live interface to identify any required conversion and the amount attached to the next transaction before signing.

veLFNTY in the application

veLFNTY is not a standard SPL token, so ordinary wallet token lists do not display it. Its state belongs to the Lifinity account linked to the wallet. A zero wallet display therefore does not settle whether the address has a veLFNTY position; the account view and claim interface must supply that part of the inventory.

xLFNTY as a transferable token

xLFNTY is a standard SPL token that represents four-year locked veLFNTY. It can appear in the wallet independently of the application-only veLFNTY state. Keep its balance on a separate line, then compare that record with the claim interface rather than merging the two forms into a single estimated total.

What counts as a ready wallet?

A ready wallet controls the address with the eligible position, can review and sign a Solana transaction, and can cover any network fee shown for that transaction. Readiness is an observable account state, not a wallet brand or a promise that the claim will succeed.

• The connected public address matches the address in the starting record.
• The expected token form appears in the wallet or the application account view.
• The claim interface displays an eligible USDC output for that address.
• The transaction preview corresponds to the selected claim rather than an unrelated transfer.
• The wallet can cover any SOL network fee that its preview shows.

Lifinity directs holders of LFNTY, xLFNTY, and veLFNTY to convert eligible positions to USDC before the deadline. The displayed entitlement remains a live input even though the output asset is established. If the interface cannot connect that entitlement to the recorded wallet and token form, do not infer an amount from an old token price or treasury estimate.

Inspect the transaction before signing

The wallet preview is the last practical checkpoint before the claim changes on-chain state. Compare it with the public address, token form, and USDC output already recorded. Do not rely on the button label alone, because the signature applies to the transaction instructions that the wallet receives.

Asset movement and destination

The requested action should correspond to the eligible Lifinity position and the expected USDC result. Stop if the preview introduces unrelated assets, an unexplained transfer, or a different connected account. If the wallet cannot present enough detail to relate the request to the claim, preserve the current state and investigate before signing.

Authority and network fee

A normal wallet interaction asks for transaction approval through the wallet; it does not require a recovery phrase or private key. Treat the fee as a live Solana parameter shown for that submission. Record it if needed for reconciliation, but do not turn one observed fee into a fixed Lifinity charge or a permanent network value.

Approve one request at a time. Multiple open prompts make it harder to match a signature with the reviewed transaction, especially after an account switch or page refresh. Close stale prompts, confirm the selected public address again, and proceed only when one preview represents the intended claim.

Did the claim actually complete?

A confirmed Solana transaction and the expected USDC balance change provide the completion evidence. A success message on the page is helpful, but it should agree with the transaction record and wallet state before the task reaches its stop point.

The transaction signature

Save the signature immediately after submission and check its status through a Solana transaction viewer that you already trust. A signature identifies the submitted request, while its status distinguishes confirmation from failure or continued processing. Without that identifier, a delayed interface message is difficult to separate from a transaction that never left the wallet.

The balance reconciliation

Compare the post-claim USDC balance with the recorded starting balance and the output shown before signing. Wallet interfaces can refresh slowly, so a temporary display delay does not justify an immediate second submission. Refresh the account state and reconcile the same transaction signature before deciding that the first attempt failed.

Completion does not depend on a promised market outcome. It depends on agreement among the reviewed claim, the confirmed transaction, and the observable USDC balance change. If those records disagree, keep the signature and both balance snapshots while resolving the discrepancy.

Treat a failure as a state to diagnose

A closed or rejected wallet prompt means no claim was authorized, while a submitted transaction may remain pending, fail on-chain, or confirm before the page refreshes. Check whether a signature exists and inspect that exact transaction before trying again. Repeating a pending request can create overlapping records without making Solana process the original transaction faster.

View full-size image

Finish before support closes

Lifinity set December 31, 2026 as the deadline to claim remaining assets. The published date is an outer boundary, not a reason to wait until the final session. Wallet access, interface availability, transaction troubleshooting, and account reconciliation all take time if an unexpected state appears.

The published deadline does not supply a local-time assumption in the date itself. Do not build a last-minute plan around an unverified end-of-day interpretation. Completing the first bounded claim earlier leaves time to investigate a missing position without treating the support cutoff as flexible.

A completed token claim does not prove that every Lifinity-related asset has been handled. Flares use a separate claim path, so holders of both token positions and Flares should inventory them separately. Keep each transaction, balance change, and completion record attached to the wallet and asset class that produced it.

Preserve the public address, before-and-after balances, displayed entitlement, transaction signature, and confirmation state. Keep secret credentials out of that record. Once those items agree for the selected position, stop; the answer changes only if another eligible wallet, token form, or separate Flare position remains.