Auction settlement cron: wat er gebeurt wanneer de bel gaat

De auction timer expires. Het platform wacht niet tot iemand maandagmorgen inlogt om uit te zoeken wat er gebeurde. Een cron-backed RPC draait binnen een minuut en doet de volledige settlement deterministically.

De steps

1. Determine the winner: hoogste bid boven reserve. Als reserve niet gehaald wordt, gaat het lot naar de no-sale flow (zie no-sale-relist article).

2. Capture the deposit: de deposit-on-file van de winning bidder wordt toegepast op de H2 escrow die de cron aanmaakt. De escrow opent meteen in held state als de deposit de volledige lot value dekt, of in pending_deposit als de buyer moet top up doen.

3. Transfer the inventory in Core: de onderliggende assets krijgen een status flip van "auction-listed" naar "sold-pending-shipment" en worden gelinkt aan de outbound order van de winner (auto-created).

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

5. Write the settlement row: de seller payout, platform fee en side-fees worden berekend door de H6 fees engine en gesnapshot op een settlement row die aan de deal hangt.

6. Notify both parties: realtime + email digest, afhankelijk van preferences.

Wat als de deposit niet genoeg is?

De escrow opent pending_deposit en de buyer heeft 7 days om aan te vullen. Doet hij dat niet, dan vuurt de cancel_stale_pending_deposits cron, de escrow auto-cancelt, een strike wordt geregistreerd tegen de buyer (zie three-strikes article), en het lot wordt unpublished — waarna de F5 auction-no-sale flow het op de market kan relisten.

Waarom een cron, geen webhook

Auctions kunnen honderden bids hebben in hun final seconds. Een webhook-per-bid model is moeilijk atomic te maken; een cron-per-lot is eenvoudiger. De cron draait elke minute, pakt elk lot op waarvan de end time voorbij is (en dat nog niet settled is), en draait de deterministic flow. Tegen maandagmorgen staat er een row in de database die exact zegt wat er gebeurde.