Lifinity moved from oracle-based market making to a final asset-claim process on Solana

Oracle pricing, concentrated liquidity, and delayed rebalancing

The DEX combined several mechanisms to quote trades, concentrate capital, and manage the assets held in its pools. Those mechanisms explain its former market-making model. The separate token forms came from Lifinity’s governance and locking system and now require different wind-down steps.

Oracle-led pricing

Pool balances did not serve as the primary price source. A custom oracle supplied the reference price, and the DEX traded only when that oracle had updated during the current Solana slot and reported a sufficiently narrow confidence interval. This design reduced the need for arbitrage trades to pull pool prices back toward the wider market.

Concentrated liquidity

Lifinity applied a concentration factor to its constant-product curve. That placed more liquidity within the useful trading range than an unconcentrated curve could provide with the same capital. The factor was a configurable pool parameter, not a universal constant that applied equally to every market or period.

Delayed pool rebalancing

Rebalancing adjusted available liquidity as trades or oracle prices changed. Under the v2 model, a pool targeted its initially deposited amount of the base asset until price movement crossed a configured threshold. It then reset its target around a balanced value at the new price. The delay aimed to avoid continuously trading inventory back to an equal-value split after every small movement.

The wind-down changed the relevant account actions

Trading mechanics now provide historical context, while claims and withdrawals determine the remaining user actions. Account handling separates token conversion, previously accrued rewards, and the claim route for Flares, Lifinity’s collectible series. A completed action in one category does not establish completion in another.

The current task is therefore account-specific. A wallet may contain a transferable token, a protocol-recorded vote-escrowed position, an unclaimed reward balance, a collectible position, or several of these states. Each state must appear in the matching interface before its transaction can be evaluated.

Token forms determine the available exit path

LFNTY, veLFNTY, and xLFNTY represented different forms of exposure and did not share the same transfer behavior. Treating them as interchangeable wallet balances can hide a position or direct a holder toward the wrong transaction.

LFNTY

LFNTY was the governance token and the basic entry or exit unit in the original token model. During the wind-down, holders should rely on the live claim flow for the conversion that applies to their balance. Historical locking instructions do not establish the current claimable amount.

veLFNTY

veLFNTY was a non-transferable account state rather than a standard SPL token. It represented locked LFNTY, carried voting power, and previously provided access to protocol revenue. Its balance could remain invisible in a normal wallet token list because the application tracked it through a dedicated account.

xLFNTY

xLFNTY was the transferable SPL-token representation of a four-year locked veLFNTY position. The original system allowed conversion between those forms at a one-to-one token ratio. In the wind-down, the USDC redemption program used xLFNTY as its input. LFNTY and veLFNTY holders had to use the live conversion route for their positions before redemption.

What should a holder establish before claiming?

A holder should establish the controlled address, the type of position, and the exact transaction outcome before providing authorization. The website’s label alone cannot replace the details shown by the connected wallet.

• Identify every controlled Solana address that may contain a Lifinity position.
• Distinguish LFNTY, xLFNTY, veLFNTY, reward balances, and Flares.
• Read the claimable output and recipient shown for that specific account.
• Check the fee payer and every authority requested by the transaction.
• Leave enough time to resolve a failed or pending transaction before the deadline.

Old screenshots, estimated redemption values, and another wallet’s result do not determine the connected account’s entitlement. The claim interface and the resulting Solana transaction supply the relevant live state.

Four stages from account review to confirmed exit

Keep the process reversible through account review and route selection. Before authorization, compare the expected account state with what the interface and blockchain show. Move to the next stage only when those views describe the same address, position, and intended output.

Table: Four stages from account review to confirmed exit

Stage	Expected state	Completion evidence	Security significance
1. Account discovery	The wallet controlling the intended Solana address is connected.	The address and displayed positions match the wallet under the holder’s control.	Inspection should not authorize an asset transfer.
2. Route selection	The interface recognizes the relevant token, reward, or collectible position.	The displayed route names the position and its available claim action.	The route must correspond to the asset being surrendered or withdrawn.
3. Transaction authorization	The wallet presents the intended claim or conversion.	The transaction summary shows the recipient, assets, authorities, and network fee.	A signature authorizes the listed on-chain instructions, not the surrounding webpage text.
4. Confirmation	The submitted transaction reaches a final on-chain state.	The transaction reaches finalized status, the source position changes as expected, and the output appears at the intended address.	On-chain state provides stronger completion evidence than a success message alone.
The exit is complete only when the confirmed transaction and the post-claim balances match the intended conversion or withdrawal.

View full-size image

Verification belongs at the transaction boundary

A wallet connection identifies an address, while a transaction signature can authorize an actual state change. Read the wallet prompt at that boundary. The intended transaction should involve the expected Lifinity position, the stated output, and no broader authority than the action requires. Reject a prompt if the assets, recipient, or permission differs from the claim being attempted.

After submission, preserve the transaction signature and inspect its status. A page-level confirmation can disappear after a refresh, but the signature ties the action to a particular Solana transaction. Compare the post-transaction source balance with the received USDC or other stated output. An unchanged position, missing output, or failed transaction means the intended exit has not yet completed.

What happens after the December 31, 2026 deadline?

The claim notice sets December 31, 2026 as the deadline for all asset claims. It also states that support and the website will end after that date. A visible token balance after the cutoff therefore does not establish that the provided conversion interface will remain available.

The deadline should be treated as an operational limit, not merely a reminder. Waiting until the final hours leaves little room for wallet compatibility problems, network delays, failed transactions, or uncertainty about a non-standard position. Completing the claim earlier also allows time to reconcile the received balance against the confirmed transaction.

Reconciling balances and incomplete states

Different account views can disagree without proving that an asset disappeared. The discrepancy must be narrowed to the wallet view, the application account, or the transaction record.

Wallet balances

Standard SPL tokens such as LFNTY and xLFNTY can appear in wallet token accounts. veLFNTY used a different account model, so its absence from that list was expected. A holder should also confirm that the connected address is the one that originally held or controlled the position.

Application state

The interface determines which actions it currently exposes for the connected account. A reward balance belongs to the rewards flow, while wind-down redemption belongs to the claim flow. If a state appears stale after a confirmed transaction, refresh the account data before signing another transaction.

Transaction records

A pending transaction does not provide the same evidence as a finalized transaction. A failed transaction may leave the original position unchanged, while a confirmed transaction should show the relevant account changes. Checking the signature first avoids treating a slow display update as a reason to submit an unnecessary duplicate.

The remaining decision is time-sensitive

Lifinity’s former DEX functions explain the origin of its pool assets and token structure, but they no longer define the holder’s next action. The practical decision is whether every controlled position has reached a confirmed exit state while the claim services remain available.

Record the signature of each successful transaction and compare the final wallet state with the claim that was authorized. Any unresolved LFNTY form, reward balance, or eligible collectible needs attention before December 31, 2026. After support ends, the presence of an asset in a wallet may no longer come with a maintained interface for recovering its wind-down allocation.