Auction Settlement Cron: was passiert, wenn die Glocke schlaegt

Der Auction Timer läuft ab. Die Plattform wartet nicht, bis sich Montagmorgen jemand einloggt, um herauszufinden, was passiert ist. Eine cron-backed RPC läuft innerhalb einer Minute und erledigt das gesamte Settlement deterministisch.

Die Steps

1. Determine the winner: Highest Bid above Reserve. Wenn Reserve nicht erreicht ist, geht das Lot in den No-sale Flow (siehe No-sale-relist Article).

2. Capture the deposit: Der Deposit-on-file des Winning Bidders wird auf das H2 Escrow angewendet, das der Cron erstellt. Das Escrow öffnet sofort im held state, wenn der Deposit den vollen Lot Value abdeckt, oder in pending_deposit, wenn der Buyer top up machen muss.

3. Transfer the inventory in Core: Die zugrunde liegenden Assets bekommen einen Status Flip von "auction-listed" zu "sold-pending-shipment" und werden mit der Outbound Order des Winners verknüpft (auto-created).

4. Close the lot: lot.state = closed, end timestamp recorded, audit row written.

5. Write the settlement row: Seller Payout, Platform Fee und Side-fees werden vom H6 Fees Engine berechnet und auf eine Settlement Row am Deal gesnapshot.

6. Notify both parties: Realtime + Email Digest, je nach Preferences.

Was, wenn der Deposit nicht reicht?

Das Escrow öffnet pending_deposit und der Buyer hat 7 days zum Top up. Tut er das nicht, feuert der cancel_stale_pending_deposits Cron, das Escrow auto-cancels, ein Strike wird gegen den Buyer recorded (siehe Three-strikes Article), und das Lot wird unpublished — dann kann der F5 Auction-no-sale Flow es auf dem Market relisten.

Warum ein Cron, kein Webhook

Auctions können in ihren final seconds hunderte Bids haben. Ein Webhook-per-bid Model ist schwer atomic zu machen; ein Cron-per-lot ist einfacher. Der Cron läuft jede Minute, greift jedes Lot auf, dessen End Time vergangen ist (und das noch nicht settled ist), und führt den deterministischen Flow aus. Montagmorgen steht eine Row in der Database, die genau sagt, was passiert ist.