Token Sale: Lotteries, Tier Systems, and Score-Based Allocation Distribution

Token sale and allocation: where slot distribution breaks

Token sale allocation is first of all a task of correct recording, not handing out slots. While there are few rounds and participants, allocation distribution rests on manual participant lists and a spreadsheet maintained by one person.

As soon as the conditions become composite — participation tiers, wallet weight, activity history — the scheme stops reconciling: two lists diverge, some addresses enter the round twice, and some do not enter at all.

Manual lists produce a separate class of failures — disputed exclusions. A participant who formally meets the conditions fails the filter because of a typo in the address or a confirmation delay, and such a case is reviewed manually and publicly. Any retroactive correction devalues the rules that were announced in advance.

Failures when recording into a round begin where a burst of applications falls into a single point in time.

The recording node becomes overloaded: the queue grows, confirmations arrive late, some transactions are retried, and without an idempotency key a retry turns into a double accrual. The peak lasts only minutes, while the consequences take weeks to sort out.

Then the reputational effect kicks in: the community sees not the mechanics but “someone was skipped, and someone was processed twice.” Restoring trust is harder than rebuilding the distribution from scratch — and usually more expensive than the development itself.

Below we break down how this is addressed: from formalizing selection rules to the resilience of the recording node under peak load.

What transparent slot distribution at launch provides

Slot distribution at launch is not a list of winners but a set of checks performed before the round opens. Controlled participant selection is needed so that the start does not turn into a bot race and the result can be rechecked against a published log.

• Share of real participants. Filtering by address history, activity volume, and wallet age cuts off multi-accounts and empty shells — addresses with genuine activity enter the allocation, not identical clones.
• Transparent round rules. Tier weights, the entry threshold, and the per-address limit are fixed by formula before the start and do not change during it; disputed cases are reviewed according to a published algorithm, not through correspondence.
• Verifiable draw. The lottery pool draw relies on external randomness verification via Chainlink, so the outcome does not depend on our server and can be checked by a third party.
• Resilience under peak demand. Applications pass through a queue with batch recording, and resubmission from the same address updates the same record: there are no duplicate slots or double charges, and the counter does not become a bottleneck.
• Predictable load. We calculate the peak application flow in advance and keep spare throughput — the round does not fall over at the moment of maximum demand.

We run each point through a test round before launch: we feed in a load scenario, reconcile the log, and only then open the real one. The rules remain the same for all participants.

Allocation formats: lottery, Tier system, Score-based

The choice of scheme is determined by two questions: who gets the right to allocation and how much exactly.

Lottery-based selection, the Tier system, and Score-based distribution are three basic answers, and each imposes its own constraints on the project economy and support load. They are rarely chosen in pure form, so it is more convenient to keep the comparison in one table.

In practice, schemes are combined: Tier sets the right to participate, Score determines weight within a tier, and the lottery fills the remainder in the lower one.

Then the calculation runs against a fixed snapshot, and weights and thresholds are published before the round opens — the participant sees why they received exactly that amount.

Implementing distribution in work stages

Allocation distribution is not a one-time setup but a reproducible process: rules, weights, and state snapshots must produce the same result on a repeat run.

An error in weights or in the selected snapshot block is most expensive precisely at the token sale stage — after calculation it can no longer be silently rolled back, and participants will see the discrepancy.

That is why the work proceeds strictly in order: from requirements gathering and the selection scheme to the test run and handover.

1. Requirements gathering and selection model. We fix the number of rounds, who is admitted to them, which participant contribution is counted, and which actions exclude from distribution — this becomes the acceptance criterion.
2. Score weight scheme. We assign a weight to each action and a threshold for a tier in the Tier system; we consolidate the weights into a table so that any rule change reads line by line instead of drowning in code.
3. Preparing state snapshots. We choose the block at which data is captured, collect addresses, remove duplicates, exclude service and contract addresses, and pull activity history for each wallet.
4. Configuring distribution rules. Round parameters, per-participant limits, the order of allocation accrual, and behavior under under-subscription are moved into configuration — this way a rule changes without editing the calculation code.
5. Test run of the round. We calculate on a copy of the data, reconcile totals by tiers and by individual wallets, and separately check edge cases: zero contribution, tier change at the threshold boundary, duplicate addresses.
6. Launch and handover. We run the round, hand over allocation lists, a report on disputed cases, and rule documentation with a recalculation procedure — the result is reproducible by your team.

Artifacts retained by the client’s team

The package is handed over not as a presentation about the scheme but as a working set of documents: using them, the client’s engineer or a new contractor can run the next round independently, without reconstructing the selection logic from correspondence and logs.

• Selection scheme description: tiers, criteria weights, the allocation calculation procedure, and the boundaries beyond which the rule changes.
• Scoring rules: formula, data sources, rounding, cutoff thresholds, and system behavior for addresses with incomplete history.
• Access matrix: operator, analyst, and auditor roles, which actions require threshold signature, and how rights are revoked.
• Round operator instructions: step-by-step scenarios — list preparation, opening the window, pause, recalculation, closing, and exporting results.
• Disputed case policy: response timelines, who makes the decision, reply templates for participants, and a protocol for recording each decision.
• Metrics dictionary and data schema: how address, wallet, and participant record are linked, and where recalculation history is stored.
• Round results report: how many addresses passed selection, distribution by tiers, support request volume, and how they were resolved.

The documents describe an already working system, so they do not diverge from the implementation: every scoring rule and every operator scenario has been tested on a real round.

We transfer the package to your documentation repository and hold a handover session where we go over disputed points and the procedure for making changes.

Case study: transition from lottery to scoring system

A launch platform, Helios, came to us with lottery-based selection: allocation was received by random applications among everyone who managed to submit them.

Formally fair, in practice the distribution went to those holding dozens of wallets, not to those who participated in previous rounds.

In the first minutes of the round, the contract received an avalanche of requests, and support received a stream of identical messages: “I confirmed participation, but there is no allocation.”

We moved selection to a scoring system. Scores are calculated from confirmed wallet history: holding duration, participation in previous rounds, activity on the project network, and completed verification.

The total score forms tiers with a fixed allocation weight, and applications are accepted throughout the round window — there is no longer a race for seconds.

Metrics before and after

The share of confirmed participants who reached allocation receipt grew from 42% to 81%: selection now works with verified wallets instead of cutting people off at the last step.

Support requests in the first day of the round dropped by about five times — the question “why wasn’t I selected” is resolved by the transparent score calculation that the participant sees in their dashboard.

Peak load on the contract fell by an order of magnitude: applications are distributed across the window instead of arriving in a single minute.

The bulk of rejected applications were multi-account wallets, while the live queue remained filled — the round closed with excess demand. The score formula and tier thresholds change through configuration — the next round is prepared for a new audience in hours.

What to choose: Tier system or Score-based allocation?

Both schemes distribute a limited allocation volume, but their selection logic differs. The Tier system ties the right to a share to a threshold: the condition is met — a tier with a fixed weight opens.

Score-based calculates points across a set of actions and divides the volume proportionally to the accumulated total.

Under equal conditions, the schemes diverge most strongly. In the Tier system, the same threshold gives the same weight, so when oversubscribed, an additional rule must be introduced — first-come-first-served or a lottery within the tier.

Score-based solves the same situation with arithmetic: equal points give equal shares, and no disputed slots arise.

Requirements for participant data also differ. The Tier system needs only one verifiable attribute read from network state at the cutoff moment: balance, stake, role presence.

The scoring scheme needs a full action trail resistant to gaming — accruals for volume and holding duration, penalties for withdrawal before the cutoff.

Therefore, the participant checks the threshold themselves, while the formula can only be checked through a calculation preview before launch.

The working option is usually hybrid: a hard threshold cuts off random noise, points rank those who passed, and we publish the snapshot so the share can be recalculated on Ethereum.

Technical doubts before launching a round

Selection rules are verified against data, not promises.

Four questions we address before the round starts: how multi-accounts are filtered out, what happens when a participant changes address, how the score is recalculated when rules are edited, and what happens during a partial failure.

We record the answers in the round configuration — so the decision can be reproduced rather than recalled.

The participant changed address — are points transferred?

Yes, by a signature from the old address. The transfer goes by participant tier, not by wallet: the round limit is tied to it, otherwise one person could collect several quotas. Transfers are closed before the round opens; afterward, only manual review.

Rules were changed — is the score recalculated fairly?

Yes. The score is always rebuilt from an immutable event snapshot, not incrementally. Recalculation produces the same result on the same data, so we reconcile both versions and show the difference by each tier — the participant sees why the score changed.

What to do during a partial round failure?

A failure must not lead to double accrual. Distribution operations are recorded in the log and replayed from it; per-participant and per-round limits are calculated from what has already been issued. We stop the round, reconcile the state, and continue from the checkpoint.

How are the selection rules themselves verified?

The rules audit happens before launch: a test run on a copy of real data, recalculation by an independent implementation, and edge case checks — empty sample, one top-tier participant, quota overflow. The result is a report with discrepancies and configuration edits.

Let’s discuss the distribution task and the format of work

To come back with an estimate for the distribution project, rather than general reasoning, we need a set of input data. The more concrete the initial picture, the more accurate the work plan for selection and distribution and the fewer edits once the round is already open.

• Expected round volumes: how many participants you expect, target volume, the number of tiers in the Tier system, and the shares between them.
• Current scheme: how allocation is calculated now — manually in spreadsheets, by script, or by contract, and where participant records are kept.
• Data constraints: where you take the balance and activity snapshot from, whether there is programmatic access to the source, and how often it can be captured.
• Selection rules: scoring criteria, weights, minimum thresholds, and requirements for protection against multi-wallet gaming.
• Round timeline: when it opens and closes, by what moment the ready allocation calculation is needed, and whether there is a dependency on an external event.
• Transparency requirements: whether the participant should be able to verify their allocation themselves, whether a dispute procedure is needed, and what reports are expected at the end.

Based on this data, we assemble a work plan for selection: scoring rules, tier model, accrual mechanics, appeals policy, and a verification schedule.

We come back with an estimate of effort and implementation timelines, and we fix the collaboration format in stages — first we run the calculation on historical data and show the result, and only then launch it on a live round.