Anti-Gaming and Three Strikes: How the Auction Fights Back

The instinct, when you read “anti-gaming,” is to imagine a sophisticated machine-learning model classifying bidders into “honest” and “fraudulent.” That’s not what’s running. What’s running is two simpler things, both of which work better than they look on paper.

Continuous detection at bid time

Every bid that comes in goes through a check before it’s accepted. The check looks at the bidding company’s recent activity and computes four signals: rapid bursts inside a 60-second window, the total number of retracted bids, retractions clustering inside a 30-minute pattern window, and raw bid volume over the last 24 hours. Each signal carries a platform-tunable weight; the weighted sum lands on a low / medium / high level. With the shipped defaults, a score of 2 is medium and a score of 4 is high.

If the level is high, the bid is rejected with the reason bidder_high_suspicion. If it is medium, the bid is accepted but the bidder shows up for review on /auction/anti-gaming. The signals stay cached on the bidder’s company row, so the next bid from the same company doesn’t re-run the full window query — fast enough not to slow down the bidding feed, accurate enough to catch the worst patterns.

The review page is a work queue, not a monitor. It states which policy is active, who owns follow-up, when the recent bid sample was analyzed and what the next steps are. Tenant users get Review participants and Review bids; platform staff get the risk settings, the bidder register and a blocklist action with a mandatory reason. An empty page means nobody in the recent sample crossed the thresholds — it is not an audit of every bid ever placed.

The thresholds and weights are tuned by ReVend platform admins on /admin/auction/risk-settings. They are calibrated platform-wide; a seller cannot relax them when publishing a lot.

Before the ban: the strike threshold

Strikes bite before the ban does. The bidder-deposit policy carries an active-strike threshold (default 2). A company with that many active strikes is refused at the eligibility check with the reason strike_threshold — no bid, no buy-now — long before the third strike ever lands. Two strikes is a warning you can’t ignore. Three is the door closing.

Three-strikes auto-ban

Continuous detection catches in-the-moment misbehavior. Three-strikes catches the pattern that’s only visible across multiple auctions. There are two strike types. escrow_deposit_timeout: a bidder won a lot, the platform created an escrow waiting for the deposit, and the buyer never wired the funds within the 7-day window. A daily job (02:00 UTC) cancels those escrows, at most 25 per run, and records the strike against the buyer’s company. buyer_cancel_after_win: the buyer walked away from a won lot.

The strikes table is purpose-built. It records the strike type, the source context (escrow, deal or lot, depending on the strike), the recorded date, a details column for whatever the source flow wants to attach, and a clearance trio (cleared at, cleared by, cleared reason) for compliance pardons. Cleared strikes stay in the table for audit; they just no longer count.

The threshold is hard-coded at three active strikes in 180 days. When the third one lands, a database trigger flips the company to blocklisted with a system-generated reason, and the bid guard rejects every subsequent attempt before it reaches the bidding logic. The bidder is, effectively, removed from the auction without anybody having to remember to remove them.

Pardons and audit

Platform staff can pardon individual strikes from /admin/auction/strikes/[companyId]. The pardon requires a reason of at least 5 characters, written into the cleared-reason column. Staff can also lift the blocklist itself, and manage verification tiers and blocklist state on /admin/auction/bidders. Either way, the audit row stays — the pardon is documented, not erased. Because the next time somebody asks “why is this bidder back?”, the answer is in a column, not in somebody’s memory.