How the bidding engine works

The four bid types

Every bid recorded by the platform is one of four kinds.

Type	What it is
Static	A single bid at a stated amount. It stands until someone bids higher.
Proxy	A maximum. The bidder states the most they will pay; the engine bids on their behalf, in increments, only as far as it must, and never past the maximum.
Sealed	Hidden from other bidders until the lot closes. Used for pre-bidding on live sales and for closed-tender formats.
Buy now	Acceptance of a fixed price rather than a competitive bid. Available on post-auction lots.

A lot also records the origin of each bid — placed on the website, from the mobile app, by an in-room paddle at a live sale, entered by staff on behalf of a telephone bidder, or generated by the engine resolving a proxy. Origin is kept for the full audit trail and is visible to the auction house on every bid.

Bid increments

Increments are not a single fixed step. Each auction is assigned a bid range: a table of price brackets, each with its own increment. A lot inherits its auction’s range and can override it individually.

The next valid bid is always the current high bid plus the increment for the bracket that bid falls into. Because brackets change as the price climbs, the increment climbs with it — a lot at €200 might step by €25 and the same lot at €2,000 by €200.

The next valid step is shown to bidders on the lot page, and every lot carries its current increment through the API, so a custom front end can display or enforce it. It is not hardcoded anywhere: an auction house changes its own increment structure without a release.

Proxy bidding, precisely

A proxy bid is a maximum, not an amount. When a bidder sets one:

1. The engine raises their bid to the minimum needed to lead — one increment above the standing high bid, not their maximum.
2. When someone else bids, the engine responds automatically, still in increments, still only as far as needed.
3. It stops at their maximum. If a competing bid exceeds it, they are outbid and notified.

A bidder’s maximum is never disclosed — not to other bidders, and not on the lot record. Maxima are held against the individual bid, not against the lot, so the current price never reveals how much headroom the leading bidder has.

The observable consequence: a lot can jump several increments the moment a new bid arrives, because the engine is resolving an existing proxy. That is expected behaviour, not a fault, and it is worth explaining to bidders in your own terms.

Reserve prices

A reserve is the minimum a consignor will accept, and it is separate from the starting bid. Bidding proceeds normally below it; the lot simply does not sell.

Three outcomes follow from that:

• Reserve met — the highest bidder wins on the hammer.
• Reserve not met — the lot goes unsold, and the highest bidder is recorded as a provisional winner rather than a winner.
• Awarded below reserve — the auction house can accept a below-reserve bid after consulting the consignor. The lot is then granted to that bidder and proceeds to invoicing exactly as a sold lot does.

A reserve is never disclosed to bidders. Whether the site shows any indication of how bidding stands relative to the reserve — a percentage, for instance — is a per-auction-house setting; the amount itself is never shown.

The close

Timed lots close on their own schedule rather than all at once, so a bidder following several lots can act on each in turn.

A bid arriving near the close extends that lot. The extension applies to the single lot, not the auction, and re-triggers on each further late bid — bidding continues until a period passes with no new bid. This is what stops a lot being won purely on the clock, and it is why a timed auction can end materially later than its published end time.

How close a bid must land to trigger an extension, and how much time each extension adds, are configured for each auction rather than fixed platform-wide. There is no hidden default: the numbers your bidders see are the ones you chose.

Deliberately not documented: how the engine orders bids that arrive in the same instant, and how it behaves under peak load at a simultaneous close. Those are implementation, they are the part with twenty-five years of auction-specific work behind them, and publishing them would help nobody who is evaluating the platform.

Live auctions

During a live sale the auctioneer drives a console and each lot moves through a defined sequence of states: waiting, current, going once, going twice, going three times, closing, closed. Remote bidders see the same state the room sees, in step with the auctioneer.

Bids from the floor, from remote bidders, from staff entering telephone bids, and from previously-placed absentee and sealed bids all arrive in the same view, in one order, with their origin recorded. The auctioneer is never reconciling two sources by hand.

A lot can also be paused and resumed without ending the sale.

Every outcome a bid can have

The engine returns a specific, named result for every bid — accepted or rejected. This is the full set. Publishing it is deliberate: an auction house should be able to see exactly how the platform will behave before it commits, and an integrator should be able to handle every case rather than discovering them in production.

Accepted

Outcome	Meaning
Winner	The bid leads and the lot closed in this bidder’s favour.
ProxyWinner	A proxy resolved in this bidder’s favour.
SharedWinner	Two bidders finished level; both are recorded.
WinnerBelowMinimum	Highest bid, but under the reserve — provisional, pending the consignor.
BoughtNowWinner	The lot was taken at the fixed price.
BuyNowProxy	A proxy reached the buy-now threshold.
MultiBid	A bid across a grouped or multi-unit lot.
Overbid	Accepted, but since surpassed.
Loser	Valid, did not prevail.

Rejected

Outcome	Meaning
UnderStartBid	Below the lot’s opening price.
UnderCurrent	Below the standing high bid.
UnderMinimum	Below the minimum acceptable for this lot.
NotInBidRanges	Not a valid increment for the current bracket.
AboveMaximumBidFactor	Implausibly high — a guard against a mistyped amount.
AlreadyHighestBidder	This bidder already leads.
BidLimitExceeded	Beyond a limit set for this bidder.
BidCannotBuyOwnLot	A consignor cannot bid on their own lot.
RegistrationRequired	The auction or lot requires prior registration.
NotAllowed	The bidder is not approved to bid.
Closed	The lot had already closed.
BidNeutralized	Withdrawn by the auction house — see below.

Sealed bids and offers carry their own outcomes: a sealed bid is recorded, then resolved when the lot closes; an offer on a post-auction lot is received, and then either rejected or granted by the auction house.

AboveMaximumBidFactor deserves a sentence of its own: it catches the bidder who types €50,000 meaning €5,000, before it becomes an argument.

Withdrawing a bid

An auction house can neutralise a bid — a fraudulent bid, a duplicate, a bidder who has been suspended. The lot recalculates from the remaining valid bids, and the neutralised bid stays on the record marked as withdrawn rather than being deleted. Nothing disappears from the audit trail.

Lot outcomes

At any moment a lot resolves to one of: not started, no bids, provisional winner, winner, reserve not met, awarded, or unsold. Those are the states an auction house reports on.

What this page does not cover

The engine’s internal architecture, its concurrency and closing implementation, its performance characteristics under load, and the thresholds behind fraud and validation guards are not published. That is not evasion — those are the controls that keep the rules above true, and describing them precisely would make them easier to work around.

If you are evaluating the platform and need more than this, ask. Under NDA there is a great deal more to say.