Skip to main content
The protocol emits 11 distinct event types across the auction lifecycle, plus a 12th for terminal cancellation. A successful auction produces 11 events across 2 transactions. A rejected-then-settled auction produces ~14 events across 2 transactions. The event design is intentional and reflects the auditability requirements of permissioned finance: every state transition is logged, every compliance decision is logged, every capital movement is logged. The audit trail is the product.

Lifecycle order

A failed-only flow emits 1, 2, then (3, 4, 5, 6) per rejection attempt, then 12 at cancellation. A successful flow emits 1, 2, then (3, 4, 5) for the winner, then 7, 8, 8, 9, 10, 11.

Event schemas

Rejection reasons

BidRejected.reason is a bytes32 identifier: The pattern is forward-compatible: indexers should treat unknown reasons as “rejection, reason X” rather than as protocol errors.

Why so many events

Three things must be auditable:
  • Every state transition. No invisible state changes.
  • Every compliance decision. Both passes and rejections produce on-chain records.
  • Every capital movement. Lender proceeds, fee, and collateral push all have distinct events.
This produces a small per-auction gas overhead. We treat that as a feature, not a cost.