Hyperlock rewards: Why Records and Exit Outcomes Matter

Existing paths create different reward records

The reward path attached to an older position determines which record matters during reconciliation. Hyperlock displays LPs, staked hyperTHRUST, hyperTHRUST LPs, yield positions, and points positions as distinct categories. A value in one category does not establish a balance or claim in another.

Hyperlock's application currently presents the protocol as withdraw-only following Thruster's closure announcement. That operating state supports the removal of existing positions rather than a new reward strategy. Historical earning descriptions should therefore be read as context for old records, not as evidence that a new deposit or lock remains available.

Before that change, LP staking was associated with HYPER and THRUST rewards plus Blast points. HYPER locking used a 16-week term for voting participation, while delegated votes were associated with weekly USDC rewards. Depositing THRUST minted hyperTHRUST, which had its own staking and liquidity uses. Each path created a different relationship between the qualifying position and its possible output.

The table below identifies the current boundaries for checking those records. These entries do not assign a live value to a position or promise that every historical reward remains claimable.

Which evidence establishes a reward record?

A reward record is established by the qualifying position and the state stored for the same account, not by a quoted rate or a wallet notification. The account, position category, and recorded amount need to describe the same participation path. If one of those elements belongs to another address or category, it cannot complete the chain of evidence.

Eligibility evidence

Eligibility comes before the claimable amount. An LP deposit, HYPER lock, delegated vote, or hyperTHRUST position mattered only within the terms of its respective program. The relevant evidence is the qualifying state actually attached to the address. A past interface estimate, screenshot, or campaign description may explain an expectation, but it does not replace the account record.

Recorded value and settlement

Interface record

The interface can identify a position category and display a related value. That view is useful for locating the record, although it may lag after a transaction or represent a non-token entry such as points. Refreshing the view can resolve stale display data, but it cannot create eligibility that the underlying account lacks.

Onchain record

A published Hyperlock reward contract exposes an earned amount separately from the staked balance. This separation matters because the contract exposes staked principal and accrued rewards separately, while a paid reward may instead appear in an event or token balance. A transaction receipt, relevant event, token transfer, and post-transaction balance show different parts of the outcome. No single field should be treated as a substitute for all the others.

Eligibility and payout records serve different jobs

Eligibility explains why an address could accrue a reward, while the payout record shows whether value left the reward mechanism. A position can have historical eligibility without a remaining claimable amount. Conversely, a token transfer may be visible even after an interface clears the claimable display. Reconciliation connects the qualifying record, the amount immediately before the action, and the resulting state without assuming that one screen contains the full history.

How should a missing state change be handled?

A missing state change should stop reconciliation at the first unsupported prerequisite, before another claim or withdrawal is attempted. Start with the account, Blast network selection, position category, and transaction status. This order separates a missing record from a failed execution and avoids letting another transaction obscure the original problem.

A failed EVM transaction does not commit its attempted state changes. It may still consume a network fee, so the wallet's ETH balance can change even though the reward or position record does not. That fee movement is not evidence that a claim or exit succeeded.

View full-size image

If no successful transaction exists, the smallest reversible response is to reload the same address and category, then inspect the wallet request again. A new submission is justified only after confirming that the intended record remains unchanged and no earlier transaction is pending. Switching accounts, categories, or assets would create a different test and make the first outcome harder to trace.

A successful receipt paired with no expected state change needs a different response. Compare the contract called, the function recorded, any reward or withdrawal event, and the resulting token balances. Repeating the same call without resolving that mismatch can add fees while leaving the underlying uncertainty untouched. The earlier transaction remains unresolved until its recorded effect matches the action that was requested.

Claims and position exits close separate records

A claim addresses accrued rewards, while a withdrawal addresses the position or staking balance that qualified for them. One published Hyperlock reward contract reflects that distinction by giving its withdrawal function separate options related to claiming and locking. That implementation applies only to its contract path and does not establish the same options for every application category.

Reward completion normally requires evidence of the relevant reward payment, credited token balance, or updated earned amount. Position completion requires the old position to decrease or disappear and the expected asset state to appear. If a points entry remains after an asset exit, its presence needs to be interpreted as a separate record rather than counted automatically as an unpaid token reward.

When is the reward exit fully reconciled?

A reward exit is fully reconciled when every relevant position and reward record has a matching outcome. The qualifying record identifies what existed, the transaction shows what action executed, and the post-transaction state shows what changed. Any surviving lock, points entry, earned amount, or position category remains a separate open item until its own status is understood.

The order matters. First identify the record owned by the address, then compare its pre-action state with the successful transaction and its outputs. A token transfer can confirm payment, while a reduced staking balance can confirm principal movement. When both actions were intended, both changes need evidence; success in one does not fill the gap in the other.

Reconciliation ends at the boundary of what the records demonstrate. An interface message cannot prove a transfer that never settled, and a successful receipt cannot prove that the user selected the intended position. If a relevant record has no matching outcome, the exit remains partial even when the wallet labels the transaction successful.