Auction settlement cron: ce qui se passe au coup de cloche

Le timer de l'auction expire. La plateforme n'attend pas que quelqu'un se connecte lundi matin pour comprendre ce qui s'est passé. Une RPC backed by cron tourne dans la minute et exécute tout le settlement de manière déterministe.

Les steps

1. Determine the winner : highest bid above reserve. Si reserve n'est pas met, le lot entre dans le no-sale flow (voir l'article no-sale-relist).

2. Capture the deposit : le deposit-on-file du winning bidder est appliqué au H2 escrow créé par le cron. L'escrow ouvre immédiatement en held state si le deposit couvre toute la lot value, ou en pending_deposit si le buyer doit top up.

3. Transfer the inventory in Core : les assets sous-jacents passent de "auction-listed" à "sold-pending-shipment" et sont linked à l'outbound order du winner (auto-created).

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

5. Write the settlement row : le seller payout, la platform fee et les side-fees sont calculés par le H6 fees engine et snapshot sur une settlement row attachée au deal.

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

Et si le deposit ne suffit pas ?

L'escrow ouvre en pending_deposit et le buyer a 7 days pour compléter. S'il ne le fait pas, le cron cancel_stale_pending_deposits se déclenche, l'escrow auto-cancels, un strike est enregistré contre le buyer (voir l'article three-strikes), et le lot est unpublished — à ce moment, le flow F5 auction-no-sale peut le relist sur le market.

Pourquoi un cron, pas un webhook

Les auctions peuvent avoir des centaines de bids dans leurs final seconds. Un modèle webhook-per-bid est difficile à rendre atomic ; un cron-per-lot est plus simple. Le cron tourne chaque minute, récupère tout lot dont l'end time est passée (et qui n'est pas encore settled), et exécute le flow déterministe. Le lundi matin, une row dans la database dit exactement ce qui s'est passé.