Web3 Token Sale Landing Page: Where Quota Accounting and Access Break Down
The public stage of a token sale does not break on the page itself—it is static and predictable.
Failures come from another direction: participants arrive in a batch during the first minutes, and the web3 token sale landing page begins checking quotas and access in a mode the interface is not prepared for. What exactly breaks here is visible across three nodes.
First—quota accounting. A user opens two tabs, the wallet signs two transactions with the same nonce, and one replaces the other. The interface has already rendered success upon signature, while only one purchase is credited on-chain.
The same effect is caused by a retry on timeout: the network node did not respond, the client sent the request again—and the per-address limit is deducted twice or not deducted at all.
Second—the access list. While it lives in a spreadsheet, it is edited by hand: addresses are appended, quota levels are changed, and duplicates in different letter cases are caught.
Manual moderation cannot withstand the flow, and an edit after the Merkle root is published invalidates the proof—the participant gets "you are not on the list" with a formally correct address. The error is silent: no email, no line in the log.
Third—simultaneous requests to a shared quota pool. The remaining balance is read from several sources, the cache lives its own life, and the number in the interface diverges from the contract state. Below we examine how this is fixed at the level of checks, not cosmetics.
What Changes After Implementation: Timelines, Load, Failure Class
While the participant list lives in a spreadsheet, launching a token sale means manually reconciling addresses and deploying overnight at the moment of opening.
After switching to a Merkle tree, it is enough to record the root in the contract: the landing page gives each wallet an inclusion proof, and edits to the list no longer require rebuilding and redeploying.
Launch preparation shrinks from weeks to several days, and the start no longer depends on whether someone managed to upload the current version of the file.
The peak is thousands of wallets in the first minutes. Transaction signing happens client-side; the landing page only forms data and monitors confirmation on the Ethereum network via event subscription.
The load profile changes: the infrastructure serves reads and a stream of statuses rather than mass writes, so the page does not degrade at peak, and the per-address limit and time window are checked by the contract itself.
The main thing is that a whole class of failures disappears: double crediting, editing an already opened list, losing a request when the connection drops, racing for the limit. An atomic check rejects an incorrect transaction entirely, leaving no partially executed state.
If the configuration needs to be reverted, rollback takes minutes: a parameter or pointer is changed, without restoring from backups.
For the team, this means predictability: clear metrics by stage, alerts on contract events, the same scenario on testnet and mainnet.
Landing Page Implementation Options: What We Take Ready-Made, What We Write
A token sale page has two parts: the landing page itself (wallet, request, status) and the access logic.
Access is most often built on a Merkle tree: the full list of addresses is fixed by a single root, the participant presents a branch—the check in the contract does not get more expensive as the list grows. How freely this logic can be rewritten depends on the build approach.
A ready-made builder handles typical sales quickly, but dictates both the form of access verification and when status is updated. A custom build removes these constraints—at the cost of support, monitoring, and re-auditing the contract with every rule change.
Three Paths and Their Cost
| Option | When It Fits | Limitations |
|---|---|---|
| Ready-made builder | Sale according to a standard scheme, fixed access list, launch within tight deadlines | Access verification and limits are as in the template; status updates with a delay; the interface cannot be rewritten; support only through the vendor |
| Open template with customization | You need your own design, no non-standard distribution rules | We maintain the fork ourselves: security updates arrive rarely, and part of the access checks is rewritten manually |
| Custom build of the page and contract | Non-standard rounds, dynamic limits, live status, multiple access sources | Longer to launch; contract audit, monitoring, and regression tests are needed for every change |
A mixed option is a frequent compromise: your own page, distribution on an audited contract.
Work Stages: From Distribution Model Analysis to Handover
The order of work here matters more than speed: the landing page frontend and the smart contract ship in one release, and if you build the interface first and then change the distribution model, both layers have to be rewritten.
That is why we go from placement economics to code, recording at each step exactly what we are checking.
- Distribution model analysis. We consolidate rounds, per-wallet limits, vesting, and refund rules into a single state table—it becomes the source of truth for both the contract and the frontend.
- Access scheme. We determine who buys and under what conditions: a Merkle tree for lists, a server signature for open windows, separate phases for different groups.
- Contract setup. We transfer the table into parameters: phase duration, caps, pause, and the events the frontend subscribes to. Each event has exactly one consumer in the interface.
- Real-time frontend assembly. Subscription to network events, handling intermediate transaction states and rare block reorgs—the sold counter does not "jitter" or roll back in front of the buyer.
- Load testing. We run a simultaneous buyout scenario: hundreds of addresses in one window, competition for the limit, behavior when a round overflows. We look at where the queue grows and what a person sees at that moment.
- Handover of control. We distribute roles via multisig, revoke excess rights, hand over access, the deployment scheme, and emergency action instructions—the client's team can change parameters without us.
This order removes the main launch risk: a discrepancy between what the landing page shows and what actually lies on-chain.
Handover Package: Access Schemes, Rules, Procedures
After delivery, the client's team is left not with an archive of source code, but with a working package: with it, the token sale landing page can be run independently—change round conditions, add participants, update the contract, and understand what is happening during peak load. Below is exactly what is included in the handover and why each artifact is needed in practice.
- Access scheme — how the address list is formed, who includes a participant and on what basis, where proof of the right to purchase is stored, and how it is verified on each request.
- Distribution rules — limits per participant and per stage, issuance order under network congestion, behavior during partial filling and early round closure.
- Environment configuration — network parameters, deployed contract addresses, access keys to nodes and monitoring services, separated into test and production environments.
- Update procedure — the order of edits: who prepares, who approves, how it is tested on the test environment, and how rollback is performed if verification fails.
- Contract documentation — the purpose of methods, list of events, known limitations and assumptions, so a new developer can join the project without contacting us.
- Incident instructions — signs of typical failures, control points, the procedure for each scenario, and the boundary beyond which our engineer is engaged.
- Access register — accounts, roles, and rights indicating the owner of each item, so access is not lost when an employee changes.
Separately, we hand over load test logs: they show at what number of simultaneous requests the landing page starts to slow down and where the safeguards trigger.
Case Study: Peak Load Without Manual Participant Moderation
On the Aurum Launchpad project, before launch, whitelist access relied on manual moderation.
A coordinator checked wallet addresses against a spreadsheet and added them to the contract via separate calls—at peak, the request flow reached several thousand calls per minute, processing could not keep up, the access queue grew, and some participants saw an error and simply closed the page.
Every edit required human intervention: the risk of adding someone else's address, leaving a duplicate, or letting a bot through, while resolving disputed requests took up to a day.
What Exactly Was Changed
Access was switched to automatic verification. The wallet signs a message and confirms ownership of the address, the service returns a signed permit in response, and the contract verifies it when issuing tokens—no human is involved in the chain anymore.
The allowlist is assembled into a tree in advance, and only its root goes on-chain, so mass edits no longer require transactions.
The queue limits processing speed at peak, duplicate requests are suppressed by request key, and addresses without on-chain history are filtered out at the entrance.
Metrics Before and After
A peak of eleven thousand requests in the first ten minutes passed without failures: all valid requests were confirmed automatically, with zero manual edits.
Median time from signature to access dropped from four minutes to three seconds, and support requests phrased "I can't get on the list" fell sixfold. Access errors (someone else's address, a duplicate, a bot that passed the filter) disappeared as a class.
The contract remains immutable after launch, while the permit issuance key is moved to a separate service with a log: during an incident, access can be reissued without code changes.
We deploy the same architecture for request collection, share distribution, and token unlock schedules—describe your task, and we will return with an estimate and plan.
What to Do If the Contract Is Already Deployed and Cannot Be Changed
Code at a deployed address cannot be changed: bytecode on-chain is immutable, and if a proxy layer was not included at deployment, there is nothing to edit.
The limitation applies only to the address, not the system—logic can be moved to a separate contract, leaving the old one as a state store and entry point. Then updating logic becomes a new deployment and switching calls, not rewriting history.
The main risk here is storage compatibility. The order and types of fields are fixed at deployment: if you insert a variable in the middle of a structure, old values will be read as different ones, and accounting will break.
Therefore, we add new fields only at the end, and access existing ones through explicit getters: this way an edit does not affect already recorded balances and statuses.
Data migration starts with a snapshot: we capture state from contract events, compare it with direct storage reads, and record checksums.
For the whitelist, this is a separate step—rights are moved into a Merkle root, we publish it, and let participants verify their proofs before the sale starts, not at the moment of purchase.
The procedure is then as follows: audit the current state, move the logic, rerun scenarios on a network fork, then switch the landing page and indexer.
During the transition, we count operations in both contracts and reconcile totals line by line—any discrepancy is visible immediately, not after issuance. Rollback to the previous scheme remains possible until the old contract is decommissioned.
Common Technical Questions: Access, Load, Updates
Participant access, load resilience, and rule updates are the three questions that most often cause a token sale landing page to be reworked after sales have already started.
Below is how each is addressed at the level of the contract and configuration, rather than through manual actions during the rush.
How is access verified if the whitelist is assembled manually?
The allowlist of addresses is stored in a file, a hash tree is calculated from it, and only the root remains on the contract.
The participant presents a short proof, and the contract compares it with the root—the check costs the same for a hundred addresses and for tens of thousands. Adding to the list means recalculating the root and updating one variable.
Will the page withstand thousands of participants arriving simultaneously?
The sale start is a spike: the page opens for everyone in the same minute, while only a few make a purchase. Static files are served from edge cache, writes occur only at the moment of purchase, so visits do not turn into a transaction queue.
Fundraising progress and participant status are pulled from the indexer; if a node fails, the request goes to a backup.
Will we be able to change the sale rules ourselves?
Yes, if the parameters are moved into the contract constructor: stage duration, distribution ranges, limits, and pauses are changed by an administrative role without rebuilding.
The boundaries of edits are defined in advance—what can be changed, until when, and what is fixed after the first purchase. The administrator role can be held on a multisig or under a timelock.
Let's Discuss the Task: We'll Return with an Estimate and Work Plan
To return with an estimate and plan, rather than clarifying questions, we need the initial data for the task.
Below is what usually determines the scope of work for a web3 token sale landing page: from the distribution model to the smart contract's behavior in the first minutes after a round opens.
If some items are not yet resolved, that is fine—we will go through them together and record them in the plan.
- Fundraising goal and distribution model: shares, limits per wallet, who gets access and in what order.
- Round rules: fixed price or range, start and close time, what happens if the target is not met.
- Allowlist of addresses: how many there are, where they come from, whether a Merkle root is needed, and how often it is updated.
- Network and assets: where the token is issued, whether you accept a native asset or stablecoin, and whether refunds are needed.
- What we show in real time: fundraising progress, participant counter, timer, connected wallet status.
- Access and management: who signs the deployment, whether multisig and a pause are needed in case of an incident.
- Expected load: how many people will arrive in the first minutes, whether rate limits on contract requests are needed.
- What is already ready: mockups, domain, analytics, legal wording on the page.
Send what you have—a draft of the rules, an address export, links to mockups. We will discuss the task, return with an estimate and a stage-by-stage work plan, and immediately name the next step.