Which address should you inspect when an agent looks unfunded?

Inspect the execution account for funds and positions, and inspect the approved agent key for trading authority. Those are different questions. A zero balance at the signing address can be entirely consistent with a funded account, so we would establish the address roles before diagnosing missing funds.

The current agent-wallet reference describes a separate Hyperliquid key authorized to place and cancel orders. The selected account holds the balance, positions, and orders. This is the Hyperliquid alpha workflow inspected October 3, 2026. Our wallet permission analysis gives the broader authorization context.

A false alarm with two addresses

Illustrative scenario: an owner sees 500 USDC in the selected Hyperliquid account. A block explorer or account lookup for the agent signing address shows zero. They conclude the agent never received the money and consider funding that second address.

The useful next observation is the selected account's state, rather than another transfer. Write down the account address associated with the agent, the approved signing address, and the surface supplying each balance. If the 500 USDC belongs to the selected execution account and the authorization belongs to the expected key, the zero signer balance has a different meaning from failed funding.

This worksheet also catches an actual account-selection mistake. Perhaps the owner funded their main account while the agent targets an eligible subaccount. Both addresses may be legitimate, but the balance belongs to a different trading context. Confirm the selected account shown in setup against the account whose positions you inspect.

Three observations to keep separate

First, identity: which account is selected? Second, readiness: does that account have the required balance and completed setup approvals? Third, authority: is the expected agent wallet authorized to trade it? A successful sign-in answers none of the latter two by itself.

Trading approval and fee approval are separate setup steps in the connection guide. Record which step remains pending rather than collapsing every failure into “wallet broken.” A wallet action can require a later status review before the application reflects readiness.

If activity shows an authorization failure, inspect that failure and the venue's key approval. If activity shows a policy rejection, account funding may be irrelevant. If an order was submitted, inspect execution state before changing authorization. Our trace guide explains why these stages belong in distinct records.

Revocation answers a narrower question

Revoking the relevant key removes its trading authority. Existing positions and resting orders require separate review. An account can therefore have revoked authorization and continuing exposure at the same time.

The owner-facing diagnosis ends with two plain statements: “This is where the capital and exposure are,” and “This is the key permitted to act on them.” Keep private identifiers in private support context. Public examples need only role labels. That preserves enough structure to explain the problem without publishing someone's account details.