Hyperliquid Signed Actions API

SignedActions is the lowest-level Hyperliquid cube: signed user actions as the L1 consensus recorded them, with the key that signed each one. It holds every rejected action (with the error) and every accepted action except order placements and cancels (order, cancel, cancelByCloid) and noop — placements and cancels appear with more structure in Orders and Trades. Modifies, leverage updates, scheduled cancels, transfers, agent approvals, TWAP orders and the rest stay here.

API history goes back about 7 days. For older data, ask about a Data Store export. The query and the subscription serve this filtered view; the Kafka topic hyperliquidcore.messages.proto carries every signed action, accepted orders and cancels included.

API Key Required

To query or stream data outside the Bitquery IDE, you need an API access token.

Follow the steps here: How to generate Bitquery API token ➤

Latest signed actions

Run it in the IDE: Hyperliquid Signed Actions ➤

query {
  Hyperliquid {
    SignedActions(
      limit: {count: 50}
      orderBy: {descending: Block_Time}
      where: {Block: {Time: {since_relative: {minutes_ago: 10}}}}
    ) {
      Block { Number Time }
      ActionType Status User Signer Nonce VaultAddress
      Bundle { Hash Broadcaster ActionIndex }
      Leverage { Asset Value IsCross }
    }
  }
}

Field notes:

• ActionType — the action name as submitted: batchModify, modify, scheduleCancel, updateLeverage, updateIsolatedMargin, twapOrder, approveAgent, spotSend, evmRawTx and other Hyperliquid exchange actions. order and cancel appear only when rejected.
• User vs Signer — User is the account the action applies to; Signer is the key that signed it, which differs when an agent / API wallet acts for the account. VaultAddress is set for vault-scoped actions.
• Bundle — actions arrive in broadcast bundles; Hash is the bundle hash, Broadcaster the node that broadcast it, ActionIndex the action's position in the bundle.
• Status — ok for accepted actions, err for rejected ones; Response (raw string field) carries the node response — the error text when Status is err, for example "Invalid leverage value".
• Action — the raw action payload as a JSON string, when you need parameters beyond the typed fields.
• Leverage { Asset Value IsCross } is populated for accepted updateLeverage actions; Asset is Hyperliquid's numeric asset index (0 is BTC).

Filter examples:

• One account's activity: where: {User: {is: "0x..."}}
• Only leverage updates: where: {ActionType: {is: "updateLeverage"}}
• Failed actions: where: {Status: {is: "err"}}

As with the other Hyperliquid event cubes, changing query to subscription (and dropping limit/orderBy) turns this into a real-time WebSocket stream — useful for monitoring an account's or broadcaster's full action flow live.

Related

• Track Order Flow by Wallet — the order lifecycle behind a wallet's actions
• TWAP Orders & Child Fills — what a twapOrder action produces
• Funding Payments by Wallet
• Liquidation History by Wallet