Hyperlock now limits activity to withdrawals while users reconcile older Thruster-linked positions on Blast.

The normal withdrawal path and a missing position

A normal withdrawal begins with the wallet that owns the recorded position. Connect that account on Blast, allow the application to load its position categories, and open only the withdrawal action attached to the intended record. Before signing, compare the account, network, contract interaction, and asset shown by the wallet with the position being closed. Once the transaction settles, the old position should decrease or disappear, while the returned asset should become visible in the expected account.

If no position appears, stop before approving a different action. Recheck the connected address and network, then compare earlier onchain activity with the application's display. An empty interface can reflect the wrong account, the wrong network, or stale application data; it does not prove that a recorded position has vanished.

The protocol roles behind legacy balances

Hyperlock originally combined several related functions rather than a single deposit product. Thruster liquidity-provider positions could be deposited for boosted rewards based on aggregated veTHRUST influence. A separate route allowed THRUST deposits to mint hyperTHRUST, while HYPER could be locked for governance participation. These relationships explain why one wallet may contain several kinds of records. They also explain why one withdrawal control should not be assumed to close every legacy balance.

Position categories determine the return asset

The application separates LPs, staked hyperTHRUST, hyperTHRUST LPs, yield positions, and points positions. Those labels describe different states, so the expected output must come from the selected record rather than from the account's combined value.

Deposited Thruster LP positions

A staking withdrawal may release the liquidity-provider token that was deposited into Hyperlock. Receiving that token is different from receiving the underlying pool assets. Check the asset contract and amount that arrive after settlement. If the wallet receives an LP position, any later attempt to redeem its underlying assets belongs to the pool's own available exit process, not to the completed Hyperlock withdrawal.

Staked hyperTHRUST and hyperTHRUST liquidity

Staked hyperTHRUST and a liquidity position containing hyperTHRUST represent different layers of state. The former concerns a staked protocol asset, while the latter can represent a pool position. A control for one category should not be used as evidence that the other category has also closed. Match the transaction preview to the category shown in the application and check the returned token after confirmation.

Yield and points records

Yield and points entries are separate records rather than ordinary wallet inventory. A visible entry does not establish that it is transferable, currently claimable, or included in a principal withdrawal. Record each displayed balance before acting, then check whether the withdrawal changed it. This prevents a closed principal position from being mistaken for a completed reward or points claim.

Wallet and network compatibility comes first

Hyperlock positions were created on Blast, so the wallet must expose the position-owning address on that network. An address can look identical across several EVM-compatible networks while holding different state on each one. A connection on the wrong network may therefore produce an empty view or a rejected transaction even when the address text appears correct.

Wallet compatibility also includes the ability to display and sign the specific contract call. Hardware-backed and browser-based accounts can use different connection paths, but neither path changes onchain ownership. If a wallet cannot decode the request, do not sign until the target contract and method have been verified for the selected withdrawal.

The account also needs enough of the network's native gas asset to submit a state-changing call. A displayed position balance cannot pay that fee unless it is itself the required gas asset.

Withdraw-only mode narrows valid actions

Hyperlock's application states that the protocol entered a withdraw-only state after Thruster announced its closure. New deposits, reinvestment, and fresh yield positioning do not fit that operating status. A page or wallet request that attempts to create a new deposit should therefore be treated as a mismatch, even if it uses familiar names or token symbols.

Withdraw-only mode does not make every legacy record identical or immediately releasable. A staked position, an LP token, a time-based lock, and a reward record can retain different contract conditions. The available action for each record still depends on its actual state.

Wallet prompts have different effects

A wallet interaction can stop at account disclosure, continue to a message signature, or submit an onchain transaction. These steps have different effects and should not be treated as interchangeable confirmations.

Connection and account selection

Connecting a wallet normally reveals the selected public address to the application without moving an asset. The useful check at this stage is whether the loaded position matches that address. If the application requests a message signature, read the message and origin. A signature can authenticate an account even though it does not itself complete a withdrawal.

Allowance and execution

An ERC-20 approval changes how much a named spender may transfer; it does not return a position to the wallet. A withdrawal is a separate contract call. Do not infer that a new unlimited allowance is required merely because an approval prompt appears. The spender, token, and amount should correspond to a necessary step in the selected exit rather than to a new deposit path.

Confirmation and failure

A submitted transaction changes protocol state only if the network confirms it successfully. A reverted call leaves the intended contract change unapplied, although the account may still spend gas. A pending transaction remains unresolved. Check the final status and resulting balances before repeating the call, because a delayed interface update can otherwise prompt an unnecessary second submission.

Onchain results confirm the withdrawal outcome

A transaction hash proves that a request was broadcast, not that the requested withdrawal succeeded. While it is pending, keep the hash and avoid creating a replacement unless the wallet clearly identifies that action. After confirmation, inspect the status, recipient account, contract, and asset movements.

A successful status should be reconciled with two observations: the source position changed, and the expected asset or position token arrived. If only the interface changed, confirm the onchain balance. If only the chain changed, reconnect or refresh the application before deciding that its display is wrong.

A confirmed call with an unexpected output requires a narrower comparison. Identify what token or record the contract returned, then compare that output with the selected position category. Do not submit a different withdrawal merely to see whether it produces a more familiar asset.

Legacy locks and rewards retain separate conditions

Historical participation included governance locks and reward-related records. The withdrawal-only notice changes the available product activity, but it does not erase conditions already encoded for those positions.

Time-based HYPER locks

Hyperlock described HYPER governance locks with a 16-week term. A withdraw-only interface does not by itself prove that a particular lock has reached its release condition. The position's recorded start, end, and current contract state determine whether an exit can execute. If the application shows a lock without an available action, preserve its identifying transaction details rather than testing unrelated controls.

Rewards, claims, and points

Rewards and points can remain separate from the principal position that generated them. Before withdrawing principal, note any claimable balance or points record shown for the same account. Afterward, check those entries independently. A principal withdrawal event confirms movement of that position; it does not prove that every reward, claim, or points record was included in the same call.

Residual risks remain after a withdrawal

Exiting Hyperlock can remove exposure from its staking contract while leaving another form of exposure in the wallet. An LP token still represents a pool position, and its underlying asset mix may have changed. A token allowance can also remain active after the associated position closes. Review those outputs only after the withdrawal is confirmed, since revoking a permission too early could interfere with a remaining exit or claim. A page inviting a fresh deposit conflicts with the announced withdraw-only state and should not be used as a recovery route.

View full-size image

Transaction records document the final result

Keep the transaction hash, contract address, confirmed status, and the relevant balances before and after the exit. These records distinguish a completed withdrawal from a wallet prompt, a pending broadcast, or a cosmetic application update. They also make later discrepancies easier to isolate without repeating a state-changing call.

The intended withdrawal is complete only when the legacy position has changed as expected and the returned asset is visible under the owning account. On Blast, the settled transaction and changed asset record provide the final proof.