Deposit lifecycle

A deposit is a state machine. It is driven by Steam's own trade state and by what LootFi can re-prove at each step — never by a wall clock alone.

The states

                     ┌──────────────┐
                     │  OFFER_SENT  │  offer created, waiting for you
                     └──────┬───────┘
             you accept     │      you decline / it expires
          ┌─────────────────┴──────────────────┐
          ▼                                    ▼
  ┌────────────────┐                     ┌──────────┐
  │ RECEIVED_LOCKED│                     │  FAILED  │ (terminal)
  └───────┬────────┘                     └──────────┘
          │  received asset identified
          │
   ┌──────┴────────────────────────┐
   │ no escrow / authenticator hold│  escrow or authenticator hold
   ▼                               ▼
┌────────────────────┐    ┌──────────────┐
│ PENDING_PROTECTION │    │ HELD_ESCROW  │
└─────────┬──────────┘    └──────┬───────┘
          │                      │
          └──────────┬───────────┘
                     │  unlock time reached (+ safety margin)
                     ▼
           ┌───────────────────┐
           │ ELIGIBLE_TO_MINT  │
           └─────────┬─────────┘
                     │  mint gate passes, transaction confirms
                     ▼
              ┌──────────┐
              │  MINTED  │ (terminal)
              └──────────┘

  At any point after receipt, a confirmed trade reversal on the depositing
  Steam account routes the deposit to:

              ┌──────────┐
              │ REVERSED │ (terminal)
              └──────────┘

What triggers each transition

OFFER_SENT

LootFi has created a Steam trade offer requesting the items you selected. The offer is in your Steam client and nothing has moved yet.

• You accept → the offer's acceptance is reconciled and the deposit moves on.
• You decline, it expires, it is cancelled, or Steam marks the items invalid → FAILED. Nothing was received, nothing is owed. Start a new deposit.

What you see: "waiting for you to accept" with a link to the offer.

RECEIVED_LOCKED

The offer was accepted. LootFi now reads Steam's exchange details for that offer to learn three things:

1. Receipt time — Steam's own tradeInitTime, not the moment our server noticed.
2. Escrow — whether Steam applied a trade hold, and for how many days. The accepted offer is authoritative here; a hold can only ever be revised upward from what was known at send time, never downward.
3. Asset identity — the post-trade asset the custody account will hold.

A deposit stays in RECEIVED_LOCKED while any of those is unresolved. The common case is entirely normal: Steam does not assign the post-trade asset id until the protection window ends. A deposit sitting here with its item correctly in limbo is healthy, not stuck. LootFi retries the read once the window has actually closed rather than hammering Steam with a question it cannot answer yet.

What you see: "received — waiting for Steam to release the item", with the unlock time once it is known.

PENDING_PROTECTION and HELD_ESCROW

Two names for the same countdown, distinguished by why it is running:

• PENDING_PROTECTION — only Steam's ordinary trade-protection window applies.
• HELD_ESCROW — an escrow/trade hold or a recent-authenticator hold also applies, so the wait may be longer than the ordinary window.

Both compute the same unlock time, and both compute it the same way: the maximum of the applicable windows measured from the receipt time. Never the sum. The full formula, with worked examples, is on Hold calculation.

Throughout this phase the item is in neither inventory — not yours, not the custody account's. That is Steam's behaviour, not a LootFi bug, and it is why custody is judged from the trade record rather than from an inventory check. See Custody model.

While the countdown runs, LootFi periodically re-reads the trade record:

Trade record	Result
Still held	Countdown continues. If Steam has by now published the post-trade asset id, it is picked up.
Reversed	Every open deposit on that Steam account is frozen and re-verified. Confirmed-missing items become REVERSED.
Rollback started, not completed	The deposit is held for human review. Never auto-destroyed.

What you see: a countdown to the unlock time, and the reason the wait is what it is.

ELIGIBLE_TO_MINT

The unlock time has passed (plus a small safety margin) and the received asset is fully identified. The deposit is queued for the mint gate.

This state means "allowed to attempt a mint", not "will definitely mint". The gate itself does a fresh custody re-verification under a row lock and can still send the deposit to review. See Minting.

What you see: "minting".

MINTED

The mint transaction confirmed. A token exists on chain, owned by the wallet you specified at deposit time, and its metadata record is written.

What you see: the token in your portfolio, with its id, and a link to the transaction.

REVERSED (terminal)

The trade that delivered the item was rolled back by Steam before a token was minted. The item is back with the depositor; nothing is owed and nothing was minted. The mint gate re-verifies custody precisely so a reversal cannot slip past it into a mint.

Steam can also reverse a trade after a token exists — support rollbacks are not confined to the protection window. That does not produce REVERSED, because the deposit really did complete. Instead the token is flagged UNBACKED: it still exists on chain and whoever holds it still owns it, but LootFi stops listing it and withdrawal is refused, because the physical item is no longer in custody. See Reversals.

FAILED (terminal)

The deposit ended before anything was received: declined, expired, cancelled, or rejected by Steam. Nothing left your inventory.

Batching: one offer, one deposit

Depositing five items sends one trade offer, not five. You accept once.

Internally each item still gets its own record. That is deliberate, and it buys three things:

1. Uniqueness per item. The fingerprint is unique per asset, so batching several items into one offer cannot weaken it.
2. Independent minting. Each item mints on its own once it can. One item held for review does not block the other four.
3. Independent identity. Each item's category and asset are pinned separately, from that item's own Steam data.

The batch is presented as a single deposit, so two aggregation rules apply:

• Aggregate state is the least advanced item. If four items are eligible to mint and one is still in protection, the deposit reads as still in protection. It never claims to be further along than its slowest item. Any reversal makes the whole deposit read as reversed; any failure makes it read as failed; it reads as minted only when every item has minted.
• Aggregate unlock is the latest item's unlock. The displayed countdown is when the whole batch is free, not when the first item is.

Both round in the direction of not over-promising.

Receipt time is only ever corrected backwards

The unlock clock starts at the receipt time, so the receipt time directly determines how long you wait.

If the first read of Steam's exchange details fails — Steam returns an error, or is briefly unavailable — LootFi records the moment it observed the acceptance as a provisional receipt. That value is necessarily later than the truth, which would make you wait longer than you should.

When the authoritative tradeInitTime is later obtained, it replaces the provisional value. Because the real value is earlier, the correction always moves the receipt backwards and the unlock earlier.

The receipt is never moved forward. A deposit's wait can shorten when better information arrives; it cannot lengthen because of a retry.

(Escrow is the mirror image: it can only be revised upward, because under-stating a hold is the unsafe direction there. Both rules point the same way — the protocol may over-wait, never under-wait.)

Category is pinned at deposit time

When the offer is created, LootFi reads the item's live Steam type tag and pins its category to the deposit record then and there.

It is pinned early because it must be pinned from real data. The tokenId encodes the category in its top byte, and that is permanent — no upgrade, no admin function, and no re-mint can change a token's category once it exists.

The rules are strict:

• The category comes from the item's actual Steam Type tag. Nothing else.
• An unrecognised or missing tag yields no category, not a guess. The deposit is held for review rather than allocated an id.
• A name-based heuristic is never used to allocate an id. Names are ambiguous — it is exactly the kind of guess that files a graffiti or a capsule as a gun, permanently.

The mint gate re-checks this. If no category was pinned at deposit and the stored tags still do not yield a definite answer, the deposit is held for a human instead of minting something unfixable.

See Token IDs for the encoding and the category table.

Failure branches, collected

Situation	Outcome	Recoverable?
Offer declined / expired / cancelled	FAILED	Yes — nothing moved. Deposit again.
Steam marks items invalid	FAILED	Yes.
Exchange details unreadable at acceptance	Parked in RECEIVED_LOCKED, retried after the window closes; original receipt time preserved	Yes, automatically. No hold time is lost.
Post-trade asset id not yet assigned	Parked in RECEIVED_LOCKED	Yes — this is the normal state during protection.
Received asset cannot be matched to the requested item	Held for review	Yes, by a person. Never auto-resolved by guessing.
Trade reversed	REVERSED	No — the item is back with the depositor.
Rollback started but not completed	Held for review	Yes, by a person.
Category not determinable	Held for review	Yes, by a person. Never minted with a guessed category.
Item not in custody at mint time, trade shows no rollback	Held for review	Yes. Not minted, not destroyed.

The pattern across all of them: the two irreversible actions — minting and declaring a deposit dead — are the two the protocol refuses to take on incomplete information.

Related

• Hold calculation — why the wait is what it is.
• Minting — what the mint gate checks.
• Track your deposit — the same states, from the UI.
• Trade protection — Valve's window explained.