Hyperlock exits can be stopped before broadcast and verified after confirmation.

The account and position must match

Exit readiness starts with the address that owns the recorded position. The wallet must show Blast and the exact account associated with that record. If the interface shows no position, stop before signing and check the selected address, network, and position category. Activity from another account cannot prove ownership of the missing position.

The position label sets the expected outcome. The application separates LPs, staked hyperTHRUST, hyperTHRUST LPs, yield positions, and points positions. Those records represent different states, so a balance change in one category does not reconcile another.

For an account that pays its own gas, network readiness includes enough ETH on Blast to submit a contract transaction. Signing an offchain connection message does not consume gas, while an onchain withdrawal does. If the wallet cannot use Blast or the account cannot authorize the call, resolve that compatibility problem while the position remains unchanged. Substituting another address would create a different account context.

Where does reversibility end?

The wallet can no longer reverse the position change after Blast confirms a successful withdrawal transaction. Before broadcast, the user can decline the wallet request, change the selected amount where the interface permits it, or return to the position without altering onchain state.

A connection signature normally proves control of an address for the application session, but it does not withdraw a position. Rejecting that signature prevents the connection without creating a transaction receipt or spending ETH.

A broadcast transaction enters a less predictable stage while it remains pending. Some wallets offer replacement or cancellation by sending another transaction with the same nonce and a different fee. Network acceptance determines whether that replacement wins, so a pending-state cancellation is an attempt rather than a dependable undo function.

After confirmation, another transaction may move or use the returned asset, but it cannot erase the confirmed history. Withdraw-only mode supplies an exit path for supported existing positions. It does not restore the position after a completed exit or roll the account back to an earlier block.

View full-size image

An exit sequence from position to proof

Hyperlock's application now operates in withdraw-only mode. Start with an existing position, then finish by matching the successful receipt to the resulting state. Each stage has a different failure mode.

An exit sequence from position to proof

Exit stage	Main failure mode
1. Establish the starting record	The wrong account, network, or stale interface state prevents a reliable starting balance.
2. Match the category to the expected output	Treating LP, staked, yield, and points records as interchangeable creates the wrong completion test.
3. Inspect the wallet request	Confusing a connection signature, token approval, and withdrawal call can authorize the wrong action.
4. Broadcast the intended transaction once	A rejected prompt creates no transaction, while duplicate submissions can complicate reconciliation.
5. Read the transaction receipt	A pending or failed receipt does not prove that the exit changed the position.
6. Reconcile the record and returned asset	A hidden token or lagging interface can obscure a successful onchain balance change.

View full-size image

The exit counts as complete only when the successful receipt and relevant balances tell the same story. If they diverge, keep the transaction hash and compare the initiating address, transferred assets, and remaining position before trying another call.

Each wallet prompt changes something different

Wallet prompts deserve separate readings because signing in, granting an allowance, and executing a withdrawal have different effects.

• A network or account switch changes the viewing context without modifying a position.
• A connection signature authenticates the session and normally sends no transaction.
• A successful approval transaction changes a token allowance for a named spender without closing the position.
• A withdrawal transaction calls the relevant contract and can change balances when execution succeeds.

Before authorization, compare the active account, Blast network, target contract, requested function, asset, and amount with the position being closed. Wallets do not always decode every call into a friendly sentence. An unclear summary is a reason to pause, not a reason to infer that the request is harmless. The exit flow requires wallet authorization, never entry of a recovery phrase into the page.

What proves that the exit succeeded?

A successful receipt and the expected state change together prove the exit. A confirmation banner or closed wallet window provides weaker evidence because neither one describes the final contract state.

The transaction hash identifies the submitted call. Its receipt shows whether the top-level execution succeeded or failed, along with the block, initiating address, and contract involved. Match those fields to the intended withdrawal before evaluating any balance changes.

Transfer records then show which tokens moved, between which addresses, and in what amounts. Compare them with the expected output for the selected position. A successful receipt proves that the call completed, but a reader still needs the transfers and post-transaction balances to confirm that the intended position supplied the intended asset.

The application view offers a final reconciliation point. The old record should decrease, disappear, or otherwise show the completed state that applies to its category. If the interface lags, use the confirmed receipt and onchain balances first, then refresh the display. A missing button alone does not establish where the assets went.

Returned assets and surviving records

Returned assets depend on the record selected for withdrawal. A deposited LP position and a staked position represent different claims. If an exit returns an LP token, receiving that token does not mean the pool has also returned its underlying reserve assets. Removing liquidity is a separate interaction from withdrawing the deposited LP representation.

Surviving records require the same category-specific reading. A points entry does not establish what happened to an LP or staked balance, and an unchanged token symbol does not prove that the amount stayed constant. Reconcile each relevant record by address, token contract, and before-and-after amount. This preserves evidence even when interface labels or token displays update later.

Pending, failed, and replaced submissions

Rejected, pending, and failed requests describe different states. Rejecting the prompt before broadcast creates no transaction hash and changes nothing onchain. A pending transaction has a hash but lacks a final receipt, so its outcome remains unresolved.

A replacement transaction may use the same account nonce to supersede a pending call. The original hash can remain visible even when another transaction confirms first. Check both hashes and their nonce relationship before resubmitting. Sending repeated withdrawals without that check can produce confusing failures or an unintended second call if the position still permits one.

A failed receipt means execution reverted and the requested position change did not apply, although the account may still pay network fees. Read the failure in the context of the same account, category, and position state. Correcting a network or compatibility issue is different from retrying a call against a position that another transaction already closed.

Allowances after the exit

An ERC-20 approval sets the amount that a named spender may transfer from an owner's token balance. That allowance exists separately from the Hyperlock position. A withdrawal does not inherently require a fresh approval, and completing an exit does not prove that every earlier allowance has reached zero. Read any approval prompt as its own onchain action.

A successful revocation transaction reduces or removes future delegated spending authority. It does not retrieve a position, reverse a withdrawal, or alter the receipt for the completed exit. Match the token and spender before revoking because an unrelated allowance may authorize a different token workflow. If no wallet or service sponsors gas, the submitting account also needs enough ETH on Blast for the revocation transaction.

Evidence to keep after an exit

A complete exit record combines the transaction hash, initiating address, Blast network, receipt status, block, token transfers, and before-and-after position state. Keep those details together rather than relying on a wallet notification or screenshot alone. They let the account holder distinguish a completed withdrawal from a hidden token, stale interface, failed call, or still-pending transaction without reopening the position.