Custody model

A LootFi token is a claim on one specific CS2 asset, not on "an AK-47 | Redline (Field-Tested)". Two physically identical skins with the same wear and the same stickers are still two different assets, and each backs its own token.

This page describes how that binding is created, how it is proved, and why it cannot be created twice for the same item.

What identifies an item

Steam does not give an item a permanent global identifier. What it gives is an asset id that is unique within an inventory context, plus class and instance ids that describe the item type. LootFi combines them into a fingerprint:

appid : contextid : assetid : classid : instanceid

• appid — the game. CS2 is 730.
• contextid — the inventory context. CS2 items are 2.
• assetid — this individual asset. Unique within the context.
• classid / instanceid — the item class: which skin, which wear tier, which sticker layout template. Not unique per asset; two identical Field-Tested Redlines share them.

classid and instanceid are folded in as a defensive tiebreaker. The identifying part is assetid.

classid/instanceid identify a type, not an item

Any logic that matches items by class alone can bind a token to the wrong physical skin when two indistinguishable items are in the same place. LootFi treats a class match as strictly weaker evidence than an asset match and refuses to act on it whenever more than one candidate exists.

Uniqueness: one item, one token

The fingerprint is unique across the whole protocol, and that uniqueness is enforced structurally rather than by a check some code path could skip or race. Two deposits cannot both claim the same physical item: the second is rejected outright, not merely warned about.

This is what makes double-tokenizing the same physical asset impossible rather than merely unlikely. There is no code path that checks "has this been tokenized?" and then, moments later, writes the row; the write itself is the check.

Note where uniqueness lives and where it does not:

• Item uniqueness is enforced off-chain, on the fingerprint.
• Token id uniqueness is enforced on-chain — _mint reverts on a duplicate id, regardless of what any database believes. See Minting.

Both must hold. Neither substitutes for the other.

Custody is judged from the trade record, not from inventory

This is the single most counter-intuitive property of the system, and getting it wrong in either direction is expensive.

When you accept a trade offer, Steam's trade protection applies. During that window the item is in neither inventory. It has left yours and has not arrived in the custody account's. Ask "does the custody account hold this asset?" during that window and the honest answer is no — for a completely healthy deposit.

So LootFi does not ask that question during protection. It reads Steam's trade record, which is available throughout the window and states what actually happened to the trade:

Trade record says	LootFi does
Trade completed and holds	Continue the countdown normally.
Trade was rolled back / reversed	Treat every open deposit on that Steam account as compromised, freeze them all, and re-verify each one before anything can mint.
Rollback started but did not complete	Hold for human review. Never auto-destroy the deposit on an ambiguous signal.
Nothing known (aged out of the window)	Leave the deposit alone.

Reading "not in inventory" as "reversed" would mark good deposits as failed seconds after they succeed. Reading a real reversal as "probably fine" would mint a token backed by nothing. The trade record is the only source that distinguishes them.

Reversal blast radius

A Steam reversal is not scoped to one trade. A depositor who reverses can unwind all of their protected trades at once. LootFi therefore treats any reversal signal as an account-level event: every open deposit for that Steam account is frozen together and each must independently re-prove custody before it can resume. Deposits whose item is confirmed gone are marked reversed; deposits still held return to their normal countdown.

Asset ids change — the token binds to the post-trade asset

When Steam's protection window ends, the item lands in the receiving inventory with a new asset id. The id the depositor saw before the trade is not the id the item has afterwards.

  before trade            during protection             after protection
  ────────────            ─────────────────             ────────────────
  assetid 1234            (in neither inventory)        assetid 9876
  in your inventory       Steam has not yet             in custody
                          assigned the new id

LootFi always fingerprints the received, post-trade asset. Consequences worth understanding:

• A deposit that has been accepted but whose post-trade id Steam has not yet assigned is parked, not advanced. Fingerprinting a placeholder would key the token to an id that will never exist.
• The token id itself does not encode the asset id. Asset ids change; token ids never do. See Token IDs.
• The asset id appears in metadata as steamAssetId. It is descriptive. Do not build anything that assumes it is stable for the life of the item — it is stable only while the item sits still.

What redemption routes on

Burning a token starts a return offer. That offer is sent from the account that actually holds that specific asset, to the trade URL on file for the burner.

Before the burn is even enabled, the preflight confirms a healthy custody account holds the underlying item. If no account holds it, the burn is not offered — the protocol declines to hand out an irreversible action it cannot honour. See Withdrawal lifecycle.

What this model does and does not protect you from

Protected against:

• The same skin being tokenized twice.
• A token being created for an item that was never received.
• A reversal on one deposit silently letting an unrelated deposit mint.
• A withdrawal being routed to an account that does not hold the item.
• Two identical items being confused for one another (the protocol refuses rather than guesses).

Not protected against, and no protocol design can be:

• The custody accounts being compromised, or the operator acting dishonestly. Custody is a trust assumption. It is stated plainly in Trust & security and in Risks & limitations.
• Valve acting on the underlying item — bans, restrictions, or changes to how CS2 items work. Steam's rules govern the item at all times. See Steam rules & limits.

Related

• Deposit lifecycle — the states an item passes through on the way in.
• Trade protection — Valve's rules, in plain terms.
• Trade reversals — what a reversal means for you.