---
title: "Get user wallet activity (deposits, withdrawals, transfers)"
method: GET
path: "/v1/users/{wallet_address}/activity"
tags: ["Users"]
---

# Get user wallet activity (deposits, withdrawals, transfers)

`GET /v1/users/{wallet_address}/activity`

Immutable log of on-chain events that affected the wallet's vault position. Each row is a frozen-in-time record; rows never mutate after emission. 

`?vault_id=` narrows to one vault; omitted = activity across every vault the wallet has touched. Each row echoes its `vault_id` so wallet-wide consumers can distinguish per-vault activity. 

Async deposit/redeem lifecycles emit multiple rows (one at request time with `status=pending`, a later one with `status=settled` or `refunded`). Consumers correlate them via `request_hash` to follow a single action across rows. Sync flows emit one row directly in the settled state. 

Pagination is cursor-only. Default order is `desc` (newest first). Default page size 100, max 1000.

## Path parameters

- `wallet_address` string, required

## Query parameters

- `vault_id` string
- `next` string
- `limit` integer
- `order` string

## Response `200`

User wallet activity

- UserActivityResponse
  - `data` UserActivity[], required
    - `assets_delta` AssetDelta, required — Asset-delta envelope on user activity rows. `native` is always present; `token` is present when the indexer knows the row's asset token. The struct shape is kept stable so derived denominations (usd, numeraire token) can be added later without breaking integrators.
      - `native` string, required
      - `token` TokenRef
        - `address` string, required
        - `symbol` string, nullable
    - `block_hash` string, required — Block hash — 1:1 identifier for the block this event was mined in. Consumers needing to detect reorgs should key off this rather than `block_number` (multiple blocks can share a number across a reorg).
    - `block_number` integer, required — Block number — kept alongside `block_timestamp` for on-chain reconciliation / explorer linking.
    - `block_timestamp` integer, required — Unix seconds, block time (`block.timestamp` from the chain).
    - `request_hash` string, nullable — Aera async-flow correlation hash. Links a `*_pending` row to its later terminal row (bare `deposit`/`withdraw` for settled, or `*_refunded`) of the same lifecycle. Emitted only on rows that participate in an async flow; omitted on sync rows and on secondary-market transfers.
    - `shares_delta` string, required — Signed share delta in 18-decimal units, reported at the event where the shares actually moved. Conventions by row type: - `deposit` — positive (shares minted to the wallet). - `deposit_pending` / `deposit_refunded` — `0` (no share movement; deposit requests touch assets only). - `withdraw_pending` — negative for Aera async redeems (shares leave the wallet at request time, escrowed to the Provisioner). - `withdraw` — negative for sync (Morpho) withdraws (shares burn on the same row that pays out assets); `0` for Aera async redeems (the share movement is recorded on the paired `withdraw_pending` row). - `withdraw_refunded` — positive (escrowed shares return). - `transfer_in` — positive; `transfer_out` — negative. Summing across rows for a single async lifecycle gives the net share movement of that lifecycle — there is no double-counting.
    - `tx_hash` string, required — Transaction hash of the on-chain event.
    - `type` string, required — What happened. One of: - `deposit` — settled deposit (sync vault flow or async terminal solve). - `deposit_pending` — async deposit request submitted; awaiting solver. - `deposit_refunded` — async deposit returned without settling; assets bounced back. - `withdraw` — settled withdrawal (sync vault flow or async terminal solve). - `withdraw_pending` — async redeem request submitted; awaiting solver. - `withdraw_refunded` — async redeem returned without settling; shares bounced back. - `transfer_in` — vault shares received from another EOA (secondary market). - `transfer_out` — vault shares sent to another EOA. Async deposit/redeem lifecycles emit two rows (a `*_pending` at request time, then a separate terminal row — bare `deposit` or `_refunded` — at solve time). Rows are immutable; the pending row never mutates. Correlate the pair via `request_hash`.
    - `vault_id` string, required — CAIP-10 vault identifier this row belongs to. Always emitted.
  - `meta` TimeseriesMeta, required
    - `count` integer, required — Number of points in this response.
    - `end` string, date-time, nullable
    - `limit` integer, required — Page-size cap actually applied.
    - `next_cursor` string, nullable — Set when more pages exist; pass back as `?next=`.
    - `refreshed_at` string, date-time, required
    - `request_id` string, required
    - `start` string, date-time, nullable — Window bounds the response covers (echoes the request when set).

## Other responses

- `401` — Missing or invalid auth
- `422` — Invalid cursor

---

[API](https://skmtc.net/gauntlet/apis/gauntlet-api.md) · [All operations](https://skmtc.net/gauntlet/apis/gauntlet-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/gauntlet/gauntlet-api/revisions/bd6a0a40d4fc/schema)