> For the complete documentation index, see [llms.txt](https://docs.reya.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reya.xyz/developers/devnet/executions-and-settlement/transfer-history.md). # Transfer History (Account Ledger) `GET /v2/wallet/{address}/transfers` and the `/v2/wallet/{address}/transfers` WebSocket channel expose every movement of collateral into, out of, or between a wallet's accounts as it settles on-chain: deposits, withdrawals, transfers between your own accounts, pool stakes and unstakes, the token legs of spot trades and auto-exchanges, perp fees and rebates, and liquidation penalties. It is the history behind `accountBalances` — and the place to see where a perp fee went (API `3.4.1`, additive). {% hint style="info" %} **This is a ledger of net deposits (cash), not of `realBalance`.** Realized PnL, funding and ADL cashflows change `realBalance` without moving collateral, so they never appear here. Closing a profitable position shows only its fee entry; a funding payment does not show at all. Read `realBalance` from `accountBalances` and per-position PnL from `positions` / `perpExecutions`. {% endhint %} ## Reading an entry One entry per **account side** of an on-chain transfer, from that account's point of view. Moving 100 rUSD between two of your accounts therefore produces two entries: `-100` on the paying account and `+100` on the receiving one. ```json { "sequenceNumber": 273183852, "accountId": 12345, "asset": "RUSD", "amount": "-1.00", "netDepositsAfter": "999.00", "type": "PERP_TAKER_FEE", "counterpartyAccountId": 1, "symbol": "BTCRUSDPERP", "fillId": "42", "timestamp": 1747927089946, "transactionHash": "0x1dfdfed33589363842c4d8e5cfa1b3a9782ec07cb9a5ab5236ad1e1c224b64ea" } ``` | Field | Meaning | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `sequenceNumber` | Unique id of the entry, increasing in chain order and never reused. Use it to merge REST history and live updates. | | `accountId` | The account this entry belongs to. | | `asset` | Asset symbol (`RUSD`, `SRUSD`, …). | | `amount` | Signed from this account's view: negative when collateral left the account, positive when it arrived. The two entries of one leg sum to zero. | | `netDepositsAfter` | The account's net deposits in `asset` right after this entry — the same basis as `AccountBalance.balanceDEPRECATED`, **not** `realBalance`. In a complete history, consecutive entries of one account and asset satisfy `previous netDepositsAfter + amount = netDepositsAfter`; use this to reconcile amounts in chronological order. | | `type` | What the movement was (table below). It names the purpose of the leg, never its direction — direction is the sign of `amount`. | | `counterpartyAccountId` | The other account involved in the transfer. Absent for deposits, withdrawals, stakes and unstakes. | | `symbol` | The market of the execution that caused the entry: the perp market for fee and rebate entries, the spot market for spot and auto-exchange entries. Absent otherwise; historical perp fee entries may omit both `symbol` and `fillId`. | | `spotExecutionSequenceNumber` | `SpotExecution.sequenceNumber` of the spot trade or auto-exchange that caused the entry. Spot entries only. | | `fillId` | Fill identifier linking the entry to `PerpExecution.fillId` or `SpotExecution.fillId`. Optional: deposits, liquidations, auto-exchanges and dust conversions have no fill identifier, and historical perp fee entries may also omit it. | | `timestamp` | Block timestamp, milliseconds. | | `transactionHash` | The settling transaction. | ### Entry types | `type` | Movement | | -------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | `DEPOSIT` / `WITHDRAWAL` | Collateral entering or leaving the protocol. | | `TRANSFER` | Between two margin accounts of the same owner. | | `POOL_STAKE` / `POOL_UNSTAKE` | The asset leg and the share-token leg of a passive-pool stake or unstake (two entries, one per token). | | `PERP_TAKER_FEE` | The gross fee a taker paid on a perp fill. Its debit amount equals `PerpExecution.takerFee`. | | `PERP_REFERRER_REBATE` | The part of that fee forwarded to the taker's referrer, on the referrer's spot account. | | `PERP_TAKER_REBATE` | The part of that fee returned to the taker. Equals `PerpExecution.takerRebateCredit`. | | `PERP_POOL_REBATE` | The part of that fee credited to the passive pool. Equals `PerpExecution.poolFeeCredit`. | | `PERP_FEE` | A perp fee in historical entries from before Fee v3. | | `SPOT_EXECUTION` | The two token legs of a spot trade (one entry per token, per account). | | `AUTO_EXCHANGE` / `AUTO_EXCHANGE_INSURANCE_FEE` | The legs of an auto-exchange; the second is the insurance-fund fee. | | `LIQUIDATION_INSURANCE_FEE`, `LIQUIDATION_BACKSTOP_FEE`, `LIQUIDATION_LIQUIDATOR_REWARD`, `LIQUIDATION_KEEPER_REWARD`, `LIQUIDATION_BID_FEE` | The penalty legs of a liquidation and the bid fee of a ranked liquidation. | | `INSURANCE_FUND_COVERAGE`, `POOL_MERGE` | Insurance coverage and pool consolidation transfers on protocol accounts. | | `OTHER` | A leg the API does not recognise. Amounts are still exact. | New transfer types may be added; treat an unfamiliar value as `OTHER` rather than failing. ### Reconciling a perp fee A Fee v3 fill with a 1.00 rUSD gross fee and a 0.15 rUSD taker rebate produces these entries in the taker's ledger: | `type` | `amount` | | ------------------- | -------- | | `PERP_TAKER_FEE` | `-1.00` | | `PERP_TAKER_REBATE` | `+0.15` | Join the entries to the execution using `fillId` when present. Their signed sum is `-0.85` rUSD, so the taker's **net fee cost** is `0.85` rUSD. `PerpExecution.takerFee` remains the gross debit of `1.00` rUSD. Referrer and pool rebates appear on the recipients' accounts. Makers have no fee or rebate entries for a Fee v3 fill. See the execution's [Fee v3 fields](/developers/devnet/executions-and-settlement/executions-and-trade-history.md#fee-v3-fields) for the fee breakdown. ## Pagination — opaque cursor Entries are returned newest first by `sequenceNumber`, at most `limit` per page (default and maximum 100). Pass `meta.nextCursor` back as `cursor` to get the next page; when it is absent you have reached the end. Walking to the end visits every entry exactly once — no duplicates and no gaps, even when thousands of entries share one block. Keep the same filters throughout the walk. Cursors are opaque: pass back the returned value unchanged. `startTime` and `endTime` (millisecond timestamps, inclusive) are optional **filters** on the block timestamp; they narrow the walk but are not the paging mechanism. `type` takes a comma-separated list of entry types (for example `type=DEPOSIT,WITHDRAWAL`, or `type=PERP_TAKER_REBATE` for a rebates view). Zero-amount entries are never returned by REST or WebSocket history. A `limit` that is not a positive integer, a `type` list with a label the server does not know, or a `cursor` the server did not issue is rejected with `400`. ``` GET /v2/wallet/0x6c51…6df2/transfers?limit=100 GET /v2/wallet/0x6c51…6df2/transfers?limit=100&cursor=djEuNTQ2MzY3NzA2LjA GET /v2/wallet/0x6c51…6df2/transfers?type=PERP_TAKER_FEE,PERP_TAKER_REBATE&startTime=1756733379000 ``` Entries never change once returned. Historical coverage varies by environment; the endpoint may not include movements from before the available history begins. ## Live updates Subscribe to the `/v2/wallet/{address}/transfers` channel of the [WebSocket Info API](/developers/devnet/api-reference/websocket-api-reference.md). The `subscribed` acknowledgement carries the most recent entries in `contents.data`, newest first (at most 30 for the whole wallet, however many accounts it has; zero-amount entries are not pushed); every later `channel_data` frame carries one new settled entry. To rebuild a local ledger, subscribe first and buffer live updates, page the available REST history, then merge the snapshot, REST entries and live updates by `sequenceNumber`.