How the private auction works.

The initial model is an invitation-only, time-bounded RFQ auction. Makers price independently; the institution compares eligible responses after the cut-off and explicitly selects an offer. It is a single selected quote, not a public order book or a continuous matching engine.

Walk through an auction

Freeze the trade before inviting makers

The request fixes the chain, exact token addresses, sell amount, taker, external executor, quote cut-off, minimum acceptable quote expiry and ranking-rule version. The institution chooses eligible counterparties before price comparison. Business minimum proceeds may remain private to the institution and platform.

All invited makers receive the same required execution terms. Changing them creates a new request version and invalidates the previous comparison. A platform request ID and auction ID are application identifiers, not native signed-order fields.

Timing and response eligibility

Agree quoting deadlines and timeout/retry rules with the desk. The prototype’s five-minute quote is a local fixture, not a platform SLA or a maker commitment.

Ranking and selection

1. Validate participant eligibility, signature, domain and exact request mapping.
2. Exclude late, expired, indicative, declined, out-of-policy and superseded responses.
3. Compare net proceeds for the same full sell amount. Show gross output, separate platform charges and estimated gas. Unknown charges must remain explicit.
4. Break equal-net ties by earlier valid server receipt, then stable quote ID.
5. Recommend the highest eligible result and record any client selection override.
6. Release an executable envelope only for the selected quote, then revalidate and simulate before wallet approval.

Selection does not lock inventory. A single response is labeled single-maker; it cannot demonstrate competitive best execution. Benchmarks must match size, chain, timing and fee assumptions; an indicative reference price is not an executable route.

One selection is an application rule

The native order does not encode auction close, ranking or a one-winner constraint across makers. Keep losing signatures server-side. After disclosing an executable quote, do not disclose another winner until the earlier order is filled, expired or effectively cancelled and pending transactions are reconciled.

This prevents ordinary workflow mistakes within the application. It does not create a protocol-level prohibition against a malicious client using multiple signed offers it has obtained.

Failure and lifecycle

Auction states are draft → open → closed → selected, with no-valid-quotes, expired and cancelled branches. Execution separately progresses through awaiting authorization → submitted → mined → confirmed, or reverted/reorged outcomes.

No eligible quote means no execution. A failed selected quote requires a fresh review; never silently switch makers. A pending transaction needs chain reconciliation even after its signed order expires.

Who sees what