Why an airdrop-tracking system breaks under peak load
Peak load is the moment when the balance snapshot is taken at a different block than the one fixed in the distribution rules.
A participant moves tokens between wallets in the final minutes of the window, the snapshot reads the already-updated state, and addresses that did not exist at the moment of fixation end up in the distribution.
Then comes double crediting: the same capital is counted across two addresses, and the total share exceeds one hundred percent.
The second failure point is lost events. When the number of transactions spikes, the indexer cannot keep up with the blockchain, and some transfers and liquidity additions drop out of the accounting.
A participant who did everything by the rules receives less reward than they should, and the appeal is reviewed manually against the logs.
If the accounting is kept in tables, recovery takes days: cross-checking thousands of addresses by eye is not a process but manual work that does not scale and offers no guarantee of reproducibility.
The third problem is the lack of idempotency. Re-running the distribution after a failure credits rewards twice, and this can no longer be rolled back without a state snapshot.
A system that does not store snapshot history and cannot recompute the result from the source data turns into a source of losses and reputational damage at the very first incident.
Here is how this is closed: a deterministic snapshot at a specific block, idempotent crediting operations with a journal, an indexer resilient to load, and automatic reconciliation of amounts before sending transactions.
What well-structured tracking and reward distribution delivers
Snapshot speed and share calculation
The balance and activity snapshot is taken at a pre-fixed block height, rather than "by eye" at the moment distribution is launched.
This removes the main source of disputes: all participants see the same state of the network, and share recalculation follows a deterministic rule.
In practice, snapshot calculation across addresses with a history of tens of thousands of transactions takes minutes instead of hours of manual reconciliation, and the result is reproducible by re-running at the same height — that is verifiability.
Share of accrual errors and handling of disputed cases
Erroneous accruals almost always come from three places: unaccounted transfers between one's own addresses, rewards for actions in linked protocols, and edge cases with partial withdrawals.
When accrual rules are described formally and verified by automated tests on historical data, the share of erroneous accruals drops to a few per thousand — the rest is caught before the list is published, not after.
A disputed case is examined via the log: you can see which actions of an address made it into the sample, which were filtered out, and by which condition. Time spent on resolution shrinks from hours of back-and-forth to a few minutes — the answer is backed by data, not promises.
Resilience to load spikes
The peak of interest comes in the first hours after the announcement — thousands of addresses simultaneously check their eligibility for the reward.
The tracking system handles such load through caching of results and separation of reads and writes: an eligibility check does not recalculate the entire history from scratch but serves a prepared response.
This removes the risk that at the most visible moment the verification interface goes down and some participants leave without waiting for a response.
Predictability of distribution
Well-structured tracking turns distribution from a one-off event into a repeatable process: the rules, the snapshot, and eligibility verification are described and reused in subsequent rounds.
The client receives not a one-off list of addresses but a mechanism that scales to new campaigns without rewriting the logic from scratch.
Airdrop tracking architecture options and their limitations
The choice of approach determines how resilient the system is to recalculations and how quickly you respond to a participant's dispute.
There are three basic options: counting directly from network logs, keeping records in an internal database, or combining both with periodic reconciliation. Below is when each one works and where it breaks.
| Option | When it fits | Limitations |
|---|---|---|
| Accounting by network logs | One-off campaigns, a small number of participants, maximum transparency required | Every recalculation means re-reading the history; under high activity the bottleneck is query speed, not logic |
| Internal database | Regular campaigns, complex accrual rules, fast reports required | Data lives separately from the network: divergence from real transactions accumulates unnoticed |
| Hybrid scheme | Long-running programs, frequent snapshots, disputed cases | Requires a reconciliation procedure and handling of discrepancies — otherwise the point of the hybrid is lost |
Where each approach breaks
Accounting by logs is accurate by definition, but scales poorly: the longer the history and the more active the network, the more expensive each snapshot.
An internal database is fast, but diverges from the network during reorganizations and missed events — and the divergence surfaces at the moment of distribution, when it is already too late to dispute.
The hybrid scheme removes both extremes: hot queries go through the database, while periodic reconciliation confirms that the recorded operations match the logs.
The key here is the reconciliation procedure: how often, over which window, and what to do with the discrepancies found. Without it, the hybrid turns into the same internal database, just with an extra layer.
We look at how to choose a scheme for your scenario and build in reconciliation so that the distribution withstands scrutiny.
Implementation stages: from data audit to handover of regulations
Implementing an airdrop-tracking system is not a software installation, but a sequence of engineering decisions where each subsequent step builds on the previous one.
Below is what the workflow looks like from the first data review to the moment when your team runs the system independently.
- Source audit. We examine where the data on holders and activity comes from: network nodes, indexers, exports from exchange and wallet services. We establish which addresses and events are available at all, where the data is incomplete, and which discrepancies need to be resolved before launch.
- Snapshot scheme. We define the moment at which the network state is captured and the rule by which an address is included in the sample: minimum balance, position holding, exclusion of service and exchange addresses. The snapshot scheme must be reproducible — the same block yields the same result on a repeated run.
- Accrual rules. We formalize the distribution formula: weights by volume, coefficients for holding duration, cutoff thresholds. We describe the rules so that they can be verified on a test sample and explained to a participant why they received exactly that amount.
- Setup and launch. We assemble the calculation module, connect the sources, and configure logging for every accrual transaction. Any change to the rules goes through versioning — the old version remains available for reconciliation.
- Verification on historical data. We run the rules on past snapshots and compare the result with actual distributions. This is how double accruals, lost addresses, and edge cases are identified before they affect real participants.
- Handover of regulations. We provide documentation on the snapshot scheme, formulas, and the procedure for updating the rules, and we train your team to perform calculations and investigate disputed accruals independently.
This sequence removes the main risk — a discrepancy between what was promised and what was accrued. Each stage ends with an artifact that can be verified, rather than a verbal agreement.
What the client receives upon completion of implementation
Implementation is considered complete not at the moment the system runs its first distribution, but when the client's team can carry out the next one independently — without us.
That is why we hand over not "access to the panel," but a complete set of artifacts: configurations, rules, schemas, and procedures by which the system can be operated, verified, and developed.
- Snapshot configuration — fixed parameters for capturing state: the capture moment, history depth, list of addresses and exceptions, behavior on re-run. The snapshot is reproduced one-to-one, so a disputed result can always be recalculated.
- Accrual rules — formalized distribution conditions: weights, cutoff thresholds, activity multipliers, handling of edge cases. Each rule is described in such a way that it can be changed without modifying code.
- Data flow schema — where balance and transaction data comes from, where reconciliation takes place, where the distribution result goes. It is clear at which step a discrepancy arises and how to localize it.
- Reconciliation procedure — the order of verifying results: checksums, sample for manual review, criteria for halting distribution in case of a discrepancy. Reconciliation is performed step by step, not "by eye."
- Support documentation — description of typical failures, procedure for rolling back to the previous snapshot, logging points, contacts of responsible persons. The on-duty engineer figures it out from the instructions, without calling us.
- Access segregation — roles for viewing, launching, and modifying rules, an action log for each operation. Who changed the accrual conditions and when is visible in hindsight.
- Development plan — what is planned for future rounds: new data sources, additional activity metrics, re-distribution scenarios.
We hand over the set to the client's repository along with the change history — the artifacts live in their environment, not ours.
Describe your task: we will come back with an estimate and a plan for how much documentation and how many procedures are needed specifically for your distribution process.
Case study: how tracking withstood a distribution to 180,000 addresses
The task was typical for an airdrop campaign: a snapshot across several activity sources, calculation of shares, and distribution of tokens to 180,000 addresses.
The previous attempt using scripts and spreadsheets failed — some addresses ended up in the sample twice, while others dropped out due to a discrepancy in the rules between sources. Analyzing the errors took weeks, and participant trust declined.
We rebuilt the pipeline: the snapshot is recorded according to a single rule with a log of all input data, the calculation of shares is deterministic, and every accrual gets a traceable identifier.
A disputed case can now be raised by this identifier in minutes — you can see which data and which rule produced the result.
Chainalysis has repeatedly shown in its analyses that it is the transparency of the calculation, not the size of the payout, that determines whether participants stay with the project after the distribution.
What changed in terms of metrics. Snapshot calculation time dropped from several days of manual reconciliation to hours on the same volume of addresses.
The share of erroneous accruals fell from percentages to fractions of a percent — the remainder is closed by manual review before transactions are sent.
Resolving a disputed case shrank from days to minutes, because the engineer sees the entire calculation chain instead of reconstructing it from logs.
The client confirmed the result separately: the distribution proceeded without stoppages, support requests regarding accruals turned out to be several times fewer than expected, and rollback for erroneous addresses was performed in a targeted way, without affecting the others.
How does a snapshot based on network logs differ from a snapshot based on the internal database?
A snapshot based on network logs is built from the events that the contract itself emits: we index logs within a block range, match addresses and amounts, and obtain the state at the required height.
This source is primary — it does not depend on how our system interpreted the transaction, and any participant can reproduce the dataset independently.
The downside is latency: time passes between sending a transaction and its inclusion in a confirmed block, and during a chain reorganization some events have to be re-read from scratch.
A snapshot based on the internal database is taken from an already assembled index: a balances table, transaction history, aggregates by wallet. It is served instantly and does not require querying a node, but its completeness is limited to what our indexer managed to record.
If the handler missed an event or crashed in the middle of a range, a gap will remain in the database — and the snapshot will be formally valid, but incorrect in composition.
The key difference lies in the cost of reconciliation. Network logs are more expensive at the reading stage, but cheap to verify: the checksum over a block range matches for any independent participant.
The internal database is cheap to read, but requires a separate audit — reconciliation with the primary source, searching for discrepancies by address, and investigating cases where the index and the network diverged.
In practice, we do not choose one source but build a pairing of them: network logs are the reference and recovery point, the internal database is the fast serving layer for calculating shares.
A discrepancy between them is a signal that the indexer has fallen behind or lost a range; then the snapshot is rebuilt from the logs rather than "patched up" with edits in the database.
This removes the main risk of distribution — silent incompleteness, because of which some addresses do not make it into the list and receive less than they are due.
Technical doubts before starting work
Before the start, the same questions almost always come up: what to do with tracking that is already deployed, what to do if wallet history is incomplete, and how to make sure the accrual was calculated correctly. Below is a breakdown without generic wording, with engineering logic.
We already have tracking deployed — should we rewrite everything from scratch?
No. First we capture the current state: which events are being written, in what format, and where they are lost. Then we either build the missing layers on top of what exists, or migrate the data to a new schema while preserving history.
A full restart is justified only if the current model does not distinguish between activity types and it cannot be reconstructed after the fact.
What should be done about partial wallet data?
Partial data is the norm, not the exception: some addresses appeared after the snapshot, and some activities were not indexed. We mark such records with a separate status rather than discarding them, and we calculate the accrual according to explicitly defined backfill rules.
This keeps the distribution reproducible: for any position, it is clear which data formed the basis and what was missing.
How is the correctness of the accrual verified?
The accrual is checked against an independent recalculation using the same input data — any discrepancy for any address surfaces before distribution, not after.
In addition, we record checksums by batch and a change log: if a rule changed, it is clear which version was applied to which group. This makes it possible to roll back a specific batch without affecting the others.
How is history transferred during data migration?
Migration preserves the original identifiers and timestamps so that old and new records are not duplicated during reprocessing.
Before switching over, we run a parallel calculation on the old and new data and compare the result — the transition is considered complete only if they match. Rollback is possible at any step until the final snapshot is locked in.
If your case does not fall into any of these scenarios, describe the task, and we will come back with an estimate and a work plan.
Let's discuss your tracking and distribution task
To come back with an estimate and a plan rather than generalities, we need to understand your configuration: where the snapshot lives (your own network, EVM-compatible, or several), how the list of addresses is formed, who decides on inclusion in the distribution and on what basis.
The tracking architecture depends on this: whether we index events from blocks directly, listen to the mempool to capture activity before it is included in a block, or build a hybrid scheme with an intermediate state store.
Separately, we will clarify the distribution rules: fixed shares, weights by volume of activity, cutoff thresholds, handling of contract addresses and multisigs.
This is where discrepancies most often surface between what is intended in the tokenomics and what can actually be calculated on-chain — it is better to resolve them before the start, not at the distribution stage.
For the discussion, we will prepare:
- a draft indexing scheme: which events and contract calls are included in tracking, and with what storage depth;
- a snapshot model: the moment of capture, handling of chain reorganizations, idempotency of repeated runs;
- rules for calculating weights and thresholds — in a form that can be verified on a test set of addresses;
- a prototype of the distribution pipeline with a dry-run mode: first a run on a copy of the data, then real transactions;
- a policy for access to keys and roles: who initiates the distribution, who confirms it, how action auditing is structured;
- a monitoring plan: alerts for a discrepancy between the total amount to be distributed and the volume actually sent;
- a preliminary estimate of timelines by stage — from scoping to the first test distribution.
Describe the task: the network, the number of recipients, the current method of tracking activity, and what has already been implemented. We will come back with an estimate, a work plan, and a list of materials that will be needed from your side.