# Treasury Updates

## Deposit Events

| Event | Fired when |
| --- | --- |
| `deposit.quote_created` | Route planning is complete; execution steps are created with exchange rate info |
| `deposit.updated` | General notification that a field on the deposit has been updated |
| `deposit.expired` | The deposit reached its expiration date-time and is no longer actively processing |

## Withdrawal Events

| Event | Fired when |
| --- | --- |
| `withdrawal.quote_created` | Route planning is complete; execution steps are created with exchange rate info |
| `withdrawal.balance_updated` | Balance check result is available (`reserved` or `awaiting_funds`) |
| `withdrawal.updated` | General notification that a field on the withdrawal has been updated |
| `withdrawal.expired` | The withdrawal reached its expiration date-time and is no longer actively processing |


## Rebalance Events

| Event | Fired when |
| --- | --- |
| `rebalance.quote_created` | Route planning is complete; execution steps are created with exchange rate info |
| `rebalance.balance_updated` | Balance check result is available (`reserved` or `awaiting_funds`) |
| `rebalance.updated` | General notification that a field on the rebalance has been updated |
| `rebalance.expired` | The rebalance reached its expiration date-time and is no longer actively processing |


## Step Events

All other lifecycle updates for a deposit, withdrawal, or rebalance fire at the step level as each step progresses:

| Event | Fired when |
| --- | --- |
| `step.signature_requested` | Tesser has prepared an unsigned transaction and is waiting for your signature. The payload carries it as `unsigned_transaction` |
| `step.signed` | Step has been cryptographically signed |
| `step.submitted` | Step has been submitted for execution |
| `step.confirmed` | Step execution is confirmed on-chain or by the partner |
| `step.completed` | Step finished successfully |
| `step.failed` | Step encountered an error and could not complete |
| `step.updated` | General notification that a field on the step has been updated |

The `data.object` for step events is a [DepositStep](/api/~schemas#deposit-step), [WithdrawalStep](/api/~schemas#withdrawal-step), or [RebalanceStep](/api/~schemas#rebalance-step), depending on the resource the step belongs to. The three differ in three ways only:

- **The parent-resource id** — `deposit_id`, `withdrawal_id`, or `rebalance_id`.
- **`unsigned_transaction`** — defined on withdrawal and rebalance steps; deposit steps have no such field. Where it exists it is populated only while a step your organization signs is sitting in `signature_requested` status; on every other step and status it is `null`.
- **`provider_key`** — `circle_mint`, `openfx`, or `turnkey` on deposit and withdrawal steps, but only `circle_mint` or `turnkey` on rebalance steps. A rebalance moves funds between your own accounts, so it never routes through a liquidity provider.

Signing applies only to steps your organization signs — on-chain steps out of a self-custodial wallet, where `provider_key` is `turnkey`. Deposits are never signed by you, so `step.signature_requested` and `step.signed` do not fire on a deposit. To sign a withdrawal or rebalance step, see [Sign a Wallet Step](/how-tos/sign-a-wallet-step).

## Expiration

When a deposit, withdrawal, or rebalance reaches `expires_at` before completing, its unfinished steps are resolved and two kinds of event fire:

- `step.failed`, one per step still in `created` or `signature_requested` — the only two statuses expiration fails. Each carries `failed_at` and a `status_reasons` entry with `error_code` [`transfers-9204`](/overviews/errors#transfers) ("The transfer expired before it could be executed"). A step that has reached `signed`, `submitted`, or `confirmed` is in flight on-chain, so expiration leaves it to resolve on its own outcome instead of failing it.
- `<resource>.expired` — `deposit.expired`, `withdrawal.expired`, or `rebalance.expired` — carrying the final state of the resource.

No `<resource>.updated` follows `<resource>.expired` — the expiration event itself carries the final top-level values, including whatever the `actual` overlay settled to. Steps never emit an event of their own for expiration; it is a property of the parent resource, and a failed step's outcome surfaces as `step.failed`.

For how the resource's fields look at expiration, see [Expiration](/overviews/funds-movement-lifecycle-and-data-model#expiration).

## Payload

The `data.object` for each top-level Treasury event contains the full resource. See [General](./general#example-payloads) for the envelope shape and example payloads, and the [Deposit schema](/api/~schemas#deposit), [Withdrawal schema](/api/~schemas#withdrawal), and [Rebalance schema](/api/~schemas#rebalance) for the full field reference.

Unlike payments, Treasury resources carry no compliance arrays — there is no `risk_status`, `risk_status_reasons[]`, `participants[]`, or `provider_metadata[]` on a deposit, withdrawal, or rebalance. Withdrawals and rebalances do carry `balance_status`; deposits do not.