Hold calculation

The wait between depositing a skin and receiving a token is the most common surprise on this platform, so here is the exact arithmetic. No rounding, no "typically", no marketing.

The formula

unlockAt = receiptTime + MAX(
             protectionSeconds,
             escrowDays × 86400,
             authenticatorSeconds
           )

MAX. Never SUM.

Why MAX and not SUM

All three windows are concurrent un-tradeable periods measured from the same receipt time. They overlap; they do not queue up behind one another.

receipt
  │
  ├──────────── protection (7 days) ────────────┤
  ├──── escrow (3 days) ────┤
  ├────────────────── authenticator (15 days) ───────────────────────┤
  │                                                                  │
  └──────────────────────► item is free here (the longest window) ◄──┘

Summing them would produce 7 + 3 + 15 = 25 days for an item Steam releases after 15. That would not be "extra safe" — it would just be wrong, and it would make the protocol unusable for anyone with a hold.

The safety argument runs the other way, and it is worth stating precisely:

• Being late is safe. The item is still in custody; waiting longer costs the depositor time and nothing else.
• Being early is the only unsafe direction. Minting before Steam has actually released the item means minting a token that could still be invalidated by a reversal.
• MAX is greater than or equal to every individual window, so MAX can never be early. That is the whole justification.

The three windows

Trade protection — 7 days

Steam's standard protection window on a freshly traded CS2 item. It applies to essentially every deposit and is why "about a week" is the honest headline answer.

During this window the item is in neither inventory. See Trade protection.

Recent-authenticator hold — 15 days

If the receiving side's mobile authenticator was added or moved recently, Steam applies a longer hold. When that condition applies to the account receiving your deposit, 15 days enters the MAX and, being longer than 7, wins.

This one is easy to miss precisely because it is invisible in the ordinary case and dominant when it applies.

Escrow / trade hold — as Steam reports it, per offer

Steam reports escrowDays on the offer itself, based on the depositor's account state — mobile authenticator age, recent password changes, and Valve's own rules. It varies per user and per offer.

Two properties of how LootFi handles it:

It is measured from receipt, which is deliberately conservative. In Steam's own model, escrow delays delivery — the item arrives later. LootFi instead counts the escrow window from the receipt time it already has. That can only push the unlock later than strictly necessary, never earlier. The protocol over-waits by construction.

It can only be revised upward. The value known when the offer is sent may be zero; the accepted offer carries the authoritative figure. LootFi takes the larger of the two. A hold can grow with better information. It never shrinks.

Escrow is set by Steam, not by LootFi

Nothing on the LootFi side shortens an escrow hold. It is a property of the depositing account. If your account triggers escrow, the deposit waits — see Escrow & holds for the account conditions that cause it and how to avoid them next time.

Worked examples

Receipt at 2026-01-01 12:00 UTC in every row.

Situation	protection	escrow	authenticator	MAX applied	Unlock
No holds at all	7 d	—	—	7 d	Jan 8, 12:00
3-day escrow	7 d	3 d	—	7 d	Jan 8, 12:00
15-day escrow	7 d	15 d	—	15 d	Jan 16, 12:00
Recent-authenticator hold	7 d	—	15 d	15 d	Jan 16, 12:00
3-day escrow and authenticator hold	7 d	3 d	15 d	15 d	Jan 16, 12:00

Read the second row carefully, because it is the one people expect to be wrong: a 3-day escrow changes nothing. It is shorter than the 7-day protection window that was going to run anyway, so it never becomes the maximum. A hold only matters when it is longer than everything else.

In code

const DAY = 86_400;

function computeUnlock(input: {
  receiptTime: Date;
  escrowDays?: number;          // as reported by Steam on the accepted offer
  authenticatorHold?: boolean;  // recent-authenticator condition
}): Date {
  const protectionSeconds = 7 * DAY;
  const authenticatorSeconds = input.authenticatorHold ? 15 * DAY : 0;
  const escrowSeconds = Math.max(0, Math.floor(input.escrowDays ?? 0)) * DAY;

  const applied = Math.max(protectionSeconds, escrowSeconds, authenticatorSeconds);
  return new Date(input.receiptTime.getTime() + applied * 1000);
}

The function is pure and deterministic: same inputs, same unlock, every time. The breakdown is stored alongside the deposit, so the reason for a given wait is recoverable after the fact rather than being an opaque timestamp.

The safety margin past unlock

Reaching unlockAt makes a deposit eligible to mint. Minting does not begin at that instant.

A small additional margin is applied past the unlock before the mint gate will consider the deposit. The reasoning is the same asymmetry as everywhere else: clock skew between Steam and our own timekeeping is real but bounded, so a margin costs a depositor a short additional wait and removes an entire class of "minted a few minutes too early" failures.

The margin is a fraction of the hold itself, not a meaningful part of the wait.

What the unlock time is not

• Not the mint time. It is the earliest moment a mint may be attempted. The mint gate then re-verifies custody from scratch and can still hold the deposit for review. See Minting.
• Not a guarantee from Steam. LootFi computes this from what Steam reports. If Steam extends a hold, the recomputed unlock moves with it.
• Not negotiable. There is no expedited path, no fee that shortens it, and no account tier that skips it. The window belongs to Valve.

For a batch

A batch deposit shows the latest unlock across its items — the point at which the whole batch is free, not the point at which the first item is. Items still mint individually as each becomes eligible; the displayed countdown just does not pretend the batch is finished early. See Deposit lifecycle.

Related

• Escrow & holds — what causes a hold on your account.
• Account requirements — how to avoid triggering one.
• Deposit lifecycle — where this countdown sits in the wider flow.