Rust Gambling Support Evidence Checklist

First decide which system holds the record

A Rust skin transaction can cross at least two systems. Steam records the item transfer and trade-offer state. The gambling site records an internal deposit, balance adjustment or withdrawal request. Cryptocurrency adds a wallet and network transaction; card or payment services add their own reference.

A screenshot of site balance alone does not show where an item moved. A Steam offer ID alone does not show how the operator credited it. The useful packet connects both identifiers on one timeline without assuming that either party caused the issue.

Evidence packet table

Copyable support-evidence template

Issue summary:
Operator domain:
Operator account/user ID:
Timezone used below: UTC

Expected result:
Observed result:
Requested resolution:

Chronology
- YYYY-MM-DD HH:MM: action — observed result — reference ID
- YYYY-MM-DD HH:MM: action — observed result — reference ID

Operator transaction
- Transaction ID:
- Status shown:
- Asset/item and displayed value:

Steam or payment record
- Steam offer ID / network transaction hash / provider reference:
- Sender and recipient (Steam only):
- Exact items moving each direction (Steam only):

Attachments
- Original screenshot filenames:
- Saved terms/help-page URL and capture time:

Redactions made:
- Passwords, authentication codes, API keys, wallet seed phrases,
  full payment details and unrelated identity information removed.

Save original files before annotating copies. A crop can remove the timestamp, domain or item direction that makes the image useful. When a page is dynamic, record the URL and capture time beside the screenshot.

Build the chronology before writing the conclusion

Use neutral verbs: “offer created,” “offer cancelled,” “balance unchanged,” “withdrawal marked pending.” Avoid “stolen” or “refused” until the evidence establishes that interpretation. A completed Steam trade and a missing site credit is a different problem from an operator withdrawal that never created a Steam offer.

For a skin deposit, the minimum useful sequence is:

1. Site transaction created with its displayed item and credit.
2. Steam offer created with sender, recipient and item direction.
3. Mobile or email confirmation completed, declined or not received.
4. Steam offer reached a final status.
5. Operator balance changed—or did not change—with a timestamp.

The missing-skins decision guide helps classify those states before a duplicate transaction is attempted.

Security and privacy boundary

Support does not need a Steam password, mobile authentication code, wallet seed phrase or private key. Do not upload identity documents to a generic chat because a stranger asks. If an operator's published terms require verification, confirm the official domain and documented upload route, then provide only the fields legitimately required for that process.

An API key is also sensitive. Steam's trade-redirection guidance says a key should not be shared and can be revoked if exposed. If offers were replaced or redirected, use official Steam account-recovery and security routes before signing into the gambling site again.

Escalation record

Add the date the complaint was opened, the promised response window, every response and the final position. Then identify the applicable dispute route from the operator's current terms and your jurisdiction. The UK Gambling Commission complaint page is useful for understanding that complaints have different destinations; it is not evidence that a Rust-skin site is licensed by that regulator or that it can resolve every dispute.

Read the Steam trade-offer safety guide before approving a changed offer and the skin cashier guide for the fields to save before a transaction.

The withdrawal documentation comparison shows which public fields our operator reviews record; it is not evidence that a specific transaction will complete.