Dutch auction: where the price mechanics break
A Dutch auction sells tokens at a decreasing price: the starting price is set above the market benchmark and drops on a schedule until someone accepts the current level. The first to agree to that price takes part of the volume — or all of it if they are the only one. The mechanics look simple, but it is in the bid calculation that they most often break.
The difficulty is that bids arrive constantly while the price changes between them.
The minimum price step is small, participants submit bids within one second, and recalculating the outcome turns into manual work: a spreadsheet, exports, and checking the submission time across time zones.
As soon as two participants claim the same level, the result starts being disputed — and there is nothing to confirm it with.
Refunds add another failure point. Some bids do not make it into the volume allocation: the auction closed below their price or the volume has already been placed.
Funds for them must be returned, but without automation this means manual payouts — addresses get lost, transfers get stuck when the network is congested, and the participant waits weeks for their own funds, losing trust in the placement.
And most importantly, there is no verifiable transaction history. The log lives with the organizer: the order of bids, the moment the price drops, and the volume allocation cannot be reconstructed from the outside.
The final price in the report looks justified, but is not independently confirmed, and the token sale turns into a matter of trust in the platform. We break down how this is closed by a contract with a deterministic decreasing curve.
What changes after implementing contract-based token sale
Automating the sale removes manual operations from the process: bids are accepted by the contract throughout the auction window, the price is recalculated along a predefined curve at each step, and the result is fixed once — at the moment of closing. The team no longer needs to compile spreadsheets and manually reconcile incoming transfers.
The first measurable change is the bid collection time. Previously the window was opened and closed by agreement between people; now the boundaries are set in the contract and are observed regardless of staff workload.
The auction duration is planned in advance rather than adjusted to the availability of the person on duty.
Calculating the final price stops being a separate operation.
The price is determined at closing based on actual demand, and the token allocation is calculated by the same contract call — the result appears immediately and does not diverge between participants and internal accounting.
Refunding overpayment closes an entire class of failures: if a participant sent more than follows from the final price, the difference is automatically returned to the sending address.
Disputed operations due to "stuck" balances and manual top-ups disappear, and the share of support requests for such cases drops to zero.
The load on the support team also decreases. Typical status questions are replaced by the public state of the auction, and reporting is assembled from contract events. Engineers focus on developing the sale rather than sorting through correspondence.
Dutch auction formats: decreasing price and sealed bids
The mode sets two independent parameters: how the price changes over time and whether participants see others' bids before closing.
This produces different load profiles — with a decreasing price, bids come in waves following each drop step; with sealed bids, the peak shifts to the reveal stage, and it is for that stage that the contract throughput is calculated.
A uniform price is the third mode: bids are collected within the window, a single clearing price is calculated, and tokens are distributed among everyone who passed the threshold. Early buyers do not overpay, but some bids are cut off by price.
| Mode | When it fits | Behavior under load | Limitations |
|---|---|---|---|
| Decreasing price | public sale with a fast start and a clear minimum | steady flow of bids, peak at the first drop steps | early participants pay more than later ones; a well-calibrated drop schedule is needed |
| Sealed bids | large rounds where allocation volume and protection against bid copying matter | peak at reveal, a reveal window and a security deposit are needed | those who do not reveal their bid lose the deposit; harder for individual participants |
| Uniform price | distribution at a common price among those who passed the threshold | load is spread across the bid collection window | some bids are cut off by price; shares require careful rounding |
In practice, modes are combined: collecting sealed bids, calculating a uniform price, and decreasing the price within the window.
This is how the batch auction Gnosis Auction is structured — a single clearing price removes the bidding race and makes the result predictable for all participants.
Implementation stages: from distribution scheme to system handover
A Dutch auction is a parameterizable mechanism: the price starts at the maximum and decreases on a schedule until participants buy out the entire volume.
An error in the drop step or in the order of processing bids within a single block distorts the result for all buyers at once, so implementation proceeds in stages with recalculation checks at each one.
- Requirements analysis. We fix the issuance volume, starting price and drop step, round duration, per-participant limits, and admission rules — by wallet list or by balance snapshot.
- Distribution scheme design. We determine how bids are recorded, at what single price the round is executed, what happens to unsold volume, and on what schedule tokens are unlocked after the auction.
- Contract development. We assemble the auction contract, token, escrow of funds until settlement, administrator roles, and emergency trading halt.
- Environment setup. We deploy a test environment, connect wallets and the participation interface, and configure reporting on bids and final settlements.
- Scenario testing. We run full and partial filling, no bids, simultaneous bids in one block, round cancellation, and unavailability of an external price source.
- Acceptance. We reconcile the contract results with the calculation model on historical datasets and check repeatability and separation of rights.
- System handover. We provide documentation, access, and a change procedure, support the first real round, and transfer control to your team.
What we hand over: parameters, schemes, procedures
What is handed over is not only a working contract but also a set of documentation that allows the system to be launched and run without us.
Sale parameters are described so that they are changed by the operator, not the developer: where the value is read, what boundaries are allowed, and what happens at zero or overflow.
- Sale parameter description — starting price, drop step, recalculation interval, round duration, minimum volume: value, allowed range, place of verification.
- Bid flow scheme — the path from participant signature to settlement: where the balance and spending allowance are checked, at what moment the price is fixed.
- Refund scheme — how the unselected reserve is withdrawn, what the participant sees if the round does not take place, which events are written to the log.
- Access matrix — roles: sale administrator, operator, auditor, treasury wallet; which functions each calls and where multi-signature confirmation is required.
- Operator instructions — starting a round, pausing, early completion, publishing results: step by step, with the expected result at each step.
- Support procedure — frequency of checks, who responds to events and how, where notifications go, how parameter edits are recorded.
- Failure procedure — network halt, parameter error, key compromise: order of actions and the boundary up to which intervention is possible without restarting the contract.
Case: token sale at a decreasing price without manual support
The client was bringing a token to market through a decreasing-price sale: a window lasting several hours, a start above expected demand, and a decrease until bids close the entire volume.
The scheme is convenient for the buyer but heavy to support: the price changes constantly, and everything calculated manually turns into a queue and disputes.
What was the bottleneck
The price was recalculated by the operator on duty and published in a spreadsheet — up to fifteen minutes passed between steps.
Bids came through a form and were compiled manually: at a peak of 400 requests per minute, five people could not keep up, and some purchases were confirmed only after the price had dropped. Every discrepancy meant correspondence, recalculation, and risk of disputing the sale results.
What was changed in the sale setup
The price was moved into a smart contract: it is recalculated from time and bought-out volume, a bid is executed at the price of the current step, and a per-wallet limit cuts off buying by a single address.
The contract is deployed on the public Ethereum network, so the participant verifies settlements and purchase history independently, without statements from the platform. We added an emergency sale halt and a bid acceptance queue — peaks no longer bring execution down.
The share of bids with manual confirmation fell from 80% to zero, and there were no disputed settlements with participants. A report that previously took a week of work by several people is assembled from contract events in a couple of hours.
The duty shift was reduced to one observer: price, volume, and remaining lot are visible on the monitoring panel.
The sale went through without stops, and the client's team focused on communication rather than reconciling numbers. The same setup is reused for subsequent launches — only the price curve parameters change.
What to do if the sale is already launched at a fixed price?
There is no need to stop an active sale: obligations to participants are fixed at the moment of purchase and apply regardless of the mechanics by which the remainder is sold. A practical transition scenario is not to rewrite the working contract, but to split the issuance.
The sold part remains under the control of the current contract, while the unsold volume is transferred to a new one — with a decreasing price. Participants who bought earlier retain their shares, unlock schedules, and right to receive without changes.
The question of those who already bought at a higher price is handled separately.
Retroactive recalculation breaks both accounting and trust, so a best-price guarantee is applied: at the end of the auction, the final price is fixed, and the difference is closed by an additional token accrual.
The calculation is based on a state snapshot: the distribution is fixed at a specific block, the right to compensation is calculated for each participant, and they claim it themselves by presenting proof.
Such a sale transfer does not affect already collected bids — limits, individual terms, and the claim queue are preserved.
If the price decrease does not lead to buying out the remainder, a pre-described scenario of returning to the fixed price is activated — participants see no difference in the interface.
Every step is reversible: at any stage, you can return to the previous scheme without breaking obligations.
Technical doubts: calculations, refunds, access rights
Before the auction starts, we fix five technical questions, and the answers determine the contract architecture: how price and allocation calculations are verified, what is visible in other participants' bids, how unused funds are returned, what happens during network congestion, and whether parameters can be changed after launch.
How can we be sure that the price and allocation are calculated correctly?
The calculation logic follows from open parameters: starting price, drop step, bid submission window. Any participant can recalculate the outcome independently of us — the same input data produces the same result for everyone.
Before launch, we run scenarios on a network copy: full filling, cancellation of a large bid, an auction with no bids.
Are other participants' bids visible?
In open mode, amounts and addresses are visible — this is part of the auction mechanics. If volumes need to be hidden until closing, the bid is submitted as a hash and revealed at the settlement stage; unrevealed bids do not participate in the allocation.
How are unused funds returned?
The remainder after settlement is returned to the sender's address in the same settlement transaction or by a separate call if settlement is split into stages. The refund does not depend on administrator actions — the rights to it are built into the logic.
What happens during network congestion?
Some bids may not make it into a block, and then the execution order shifts. That is why we take the submission window with a margin, limit the number of attempts from one address, and describe in advance which bids are considered accepted.
Can parameters be changed after launch?
The starting price, drop step, duration, and limits are fixed before launch and do not change on the fly — otherwise participants cannot verify the calculation in advance. Changes are possible only through a halt and restart according to an announced procedure.
Let's discuss the task: what to send and how we will start
To come back with an estimate and a plan rather than with clarifying questions a week later, one email describing the task is enough. Below is what to cover in it; some points may not be worked out, and that is fine: we will fix assumptions and estimate based on them.
- Distribution task. Who receives tokens, how much and at what step the price decreases, where the lower bound is, and what happens to the undistributed remainder.
- Restrictions. Per-participant limits, open sale or a list of admitted addresses, identity verification, regions, protection against sharp demand spikes.
- Tokenomics. Issuance volume, team and investor shares, unlock schedules and waiting periods, refund mechanics if the threshold is not reached.
- Network and assets. Where the auction is launched, in what funds are accepted, whether a market price source is needed, how transfer fees are accounted for.
- Current sale state. What has already been done: deployed contracts, completed security audits, test runs, ready wallet integrations.
- Integrations and reporting. Wallets and custody solutions, analytics during the auction, exports for accounting and regulator requests.
- Timelines and roles. Desired launch window, hard dates, composition of participants on both sides, and the procedure for approving changes during the work.
After the email, we analyze the problem statement, name the risks, and come back with an estimate and a stage-by-stage plan. To discuss the task substantively, it is enough to describe the outline — we will clarify the details under a non-disclosure agreement on a call.