Hyperliquid Flagged Address Case Study: Transaction Reconstruction

Published: November 3, 2025 | Reading time: 10 minutes | Author: Carlos Vendrell

Incident Overview

The account was flagged by a third-party screening signal, which restricted normal UI access. The case also had multiple open positions, active execution steps, and a final destination-chain receipt that needed to be tied back to the affected account.

Public case facts are limited to client-approved, anonymized information. Full wallet addresses and raw transaction hashes are retained internally, but not shown on this public page.

The useful part of the case is the workflow: separate the frontend warning, position activity, Hyperliquid ledger withdrawals, destination-chain receipts, and fee accounting. Without that separation, a reader can easily mistake a final receipt for the whole story.

The main review question was narrower than "was money received?" The review had to connect the final USDC receipt to the affected account through position-close fills, ledger withdrawals, token-transfer logs, and fee entries.

Evidence Used

The internal case file includes the original wallet, final receiving wallet, Arbitrum receipt transaction, Hyperliquid withdrawal ledger entries, and position-conversion transactions. Because this public version is anonymized, the evidence is summarized rather than displayed verbatim.

The evidence review used transaction order rather than explorer display time alone. Hyperliquid and Arbiscan can present timestamps differently depending on display settings and local timezone assumptions, so the case was normalized around UTC and confirmed by matching the transaction sequence. This prevents a common investigation error: treating two explorer clocks as contradictory when the underlying transaction order is still consistent.

The internal review used this sequence:

1. Match the final receiving wallet against the client-approved destination.
2. Confirm the final receipt transaction on Arbiscan.
3. Reconcile gross received amount against fee deductions.
4. Preserve the sequence of Hyperliquid position-close and withdrawal transactions.
5. Aggregate fills by hash, coin, direction, fee, and closed PnL.

Frontend-State Evidence

A flagged-address case can include a separate frontend-state evidence category: the warning screenshot, UTC capture time, affected public address, and Hyperliquid legal-check response. This category records whether the official frontend currently allows the address, but it does not replace on-chain evidence.

In this case study, frontend-state evidence is treated as context for the incident window. The transaction reconstruction still depends on the sequence of Hyperliquid ledger entries, Arbitrum receipt data, and fee reconciliation.

Public redaction boundary

The public page uses evidence summaries, not raw identifiers. This keeps the case useful while avoiding unnecessary address-linkage exposure.

UTC Timeline

Execution Path

The operational review focused on asset visibility, position conversion, fee settlement, and final withdrawal. This public version intentionally omits access-method details and should be read as a reconstruction example, not an implementation guide.

For future incidents, the safer pattern is to start with read-only checks: confirm balances, identify open positions, map withdrawal dependencies, and document which assets are immediately movable versus locked or dependent on market actions. Only after the state is understood should any execution path be considered. This reduces the risk of signing the wrong action, closing the wrong position, or relying on an incomplete balance snapshot. For a reusable classification framework, compare the incident with the smart contract recovery boundary guide and the block explorer evidence workflow.

Observed sequence

1. Account state was assessed after the flag warning.
2. Open perp exposure was reduced through a series of position-close fills.
3. USDC withdrawal entries were recorded on Hyperliquid.
4. The Arbitrum transaction distributed USDC to multiple destinations, including the client-approved receiving wallet.
5. Final receipt was confirmed on Arbitrum and reconciled against the Hyperliquid ledger entries.

Transaction Reconstruction

The deepest part of this review was not the final receipt alone. The important question was what happened between the flagged-address warning and the Arbitrum receipt. Using the owner-provided transaction hashes, Hyperliquid API fills, and Arbitrum RPC receipt data, the sequence can be reconstructed at a transaction-group level without publishing wallet or hash details.

The reconstruction grouped fills by execution cluster rather than presenting all 248 rows. Each row below represents a set of fills with the same asset and close direction during the reviewed window. This makes the public table auditable at a summary level while avoiding a raw dump that would be difficult to read and easier to misuse.

Position-close batch

The Hyperliquid fills show that the account did not simply withdraw an idle USDC balance. A series of open positions were closed first. Across the verified execution window, the API returned 248 fills, with total trading fees of 249.714176 USDC and total closed PnL of -44,653.465322 USDC. The negative PnL is not treated as a service fee; it is the realized result of closing existing market exposure.

This batch shows why a flagged-account incident can be more complex than a simple withdrawal problem. If the account contains open perps, the execution path has to account for market exposure, realized PnL, trading fees, and the timing gap between close fills and the final withdrawal.

Two details matter for interpretation. First, the negative closed PnL is market outcome, not an external charge. Second, the trading-fee total comes from fill records and should not be merged with withdrawal fees or owner-provided fee accounting. Combining them would overstate one category and obscure the actual execution path.

Withdrawal reconciliation

The Hyperliquid ledger recorded two withdrawal entries at 2025-09-14 17:33:18 UTC. One entry matched the client receipt of 104,564.85089 USDC. A second smaller withdrawal entry of 571.226298 USDC, plus a 1 USDC withdrawal fee, reconciles with the owner-provided fee figure of approximately 572.226298 USDC. The final Arbitrum transaction was confirmed at 2025-09-14 17:33:10 UTC and included a USDC transfer to the client-approved receiving wallet.

The Arbitrum receipt also showed multiple USDC transfers in the same transaction. The public page does not list the recipient addresses, but the decoded transfer amounts included 104,564.85089 USDC to the destination wallet and a smaller 571.226298 USDC transfer consistent with the fee reconciliation. This is why the case record separates trading fees, withdrawal fees, and owner-provided fee accounting instead of combining them into one vague cost number.

Accounting Review

The accounting review separates four categories: final destination receipt, trading fees from fills, protocol withdrawal fees, and the owner-provided fee figure. The categories answer different questions and should not be collapsed into a single headline number.

Reconciliation formula used for the owner-provided fee figure: 571.226298 USDC + 1.000000 USDC = 572.226298 USDC. The owner-provided value includes additional decimal precision, leaving a residual of less than one-millionth of a USDC. That residual was treated as rounding precision, not a separate transfer category.

Risk Controls

The case was reviewed carefully because one wrong action could have created a second loss. The public article does not provide instructions for repeating the access route. Instead, it highlights controls that are useful in any incident review.

• Preserve the original warning text and affected address before taking any action.
• Use read-only balance and position checks before signing transactions.
• Separate spot balance, open perps, ledger entries, pending withdrawals, and final chain receipts.
• Normalize every timestamp to UTC before comparing Hyperliquid, Arbitrum, and explorer records.
• Do not treat realized PnL, trading fees, withdrawal fees, and external fee accounting as the same cost category.
• Avoid publishing full wallet relationships unless the owner has explicitly approved disclosure.
• Avoid using unverified workflows that cannot explain the action, destination, fee, and expected receipt.

Review Boundary

This article covers one anonymized case file: the flagged-account incident, position-close sequence, withdrawal ledger entries, and destination-chain receipt. Use it as a reconstruction example, then compare your own account state separately.

Several details remain intentionally outside the public record: complete wallet addresses, full transaction hashes, screenshots, access-route specifics, and client communications. Those omissions are deliberate. They reduce address-linkage risk while still allowing the article to explain the chain-state logic behind the case.

The important habit is cross-checking independent categories: Hyperliquid fill aggregation, Hyperliquid withdrawal ledger entries, Arbitrum token-transfer logs, UTC event order, and the owner-provided fee figure. If any one of those categories disagrees materially in a future case, treat the reconstruction as incomplete until the gap is resolved.

Results

The outcome recorded for this public case is that funds were received on the destination chain and the receipt was reconciled against the internal case file. Public disclosure is intentionally limited to reduce unnecessary exposure.

The withheld fields are part of the publication boundary. The internal record preserves the wallet and transaction evidence, while the public article avoids publishing relationships that could expose the client to unwanted attention or social-engineering attempts.

Frequently Asked Questions

Conclusion

This case shows how a Hyperliquid flagged-address incident can be reconstructed from account state, fills, ledger entries, destination-chain receipts, and fee accounting. The useful lesson is the review sequence, not the access method.

Key takeaways:

• Normalize timestamps to UTC before comparing explorers.
• Use on-chain receipts and transaction order as the source of truth.
• Keep access-method details out of public incident reports.
• Separate trading fees, withdrawal fees, realized PnL, and service accounting.
• Keep public case studies anonymized when wallet relationships should not be exposed.

For readers facing a similar warning, start with documentation rather than action. Save the warning text, record the affected address, export relevant transaction history, and verify balances through independent sources. If the account has open positions, write down the exposure and liquidation risk before choosing the next step. That creates a decision record support, a technical reviewer, or an internal security team can actually use.

About the Author: Carlos Vendrell

DeFi Recovery Specialist

Carlos focuses on verifiable incident review, chain-state reconstruction, and risk-controlled recovery documentation.

Twitter/X LinkedIn Medium

Last updated: June 16, 2026

← Back to Case Studies