ICO platform development: smart contracts, KYC, multi-network, vesting

ICO platform fails under load: where fundraising breaks

The first point of failure is receiving funds on-chain. While the smart contract processes operations one per block, the queue of requests grows faster than it is cleared: a participant sees confirmation in their wallet, but there is no balance in the dashboard.

At peak, these are no longer isolated cases but a stream of requests, and it begins exactly when advertising brought people in.

The second layer is double crediting. If payment is recorded by an on-chain event and in parallel reconciled with an internal database, without idempotency by transaction hash the same transfer passes twice.

Multi-chain makes it worse: accounting desync between chains does not appear immediately, but at the token distribution stage — when fixing it is most expensive.

The third point is manual payment confirmation. While deposits are reconciled by eye, support cannot keep up with replies, and a participant who did not see their tokens leaves.

Peak load on the contract is not the only problem here: not only the code breaks, but also the process around it.

That is why an ICO platform is designed from failure scenarios: idempotent intake, queue with reservation, automatic reconciliation using an event log, and accounting that reconciles across networks before payouts. Below we examine how this is covered at the contract and infrastructure level.

What a managed ICO platform gives to the investor and issuer

A request goes through the platform, not through email and spreadsheets. The round contract stores the stage parameters: price, per-address limit, round size, deposit window.

As soon as the payment is confirmed on-chain, token crediting happens automatically — without manual matching of deposits and wallet addresses.

At this stage, the share of requests processed without human involvement reaches nine out of ten, and request processing time is measured in minutes instead of hours.

Code tracks rounds and limits: exceeding the per-address limit is rejected at entry, not surfaced during reconciliation after the fact.

Manual operations remain where they are truly needed — identity verification, sanctions lists, disputed transaction review. The rest is covered by contract rules: vesting accrual, share recalculation, blocking crediting until verification is passed.

The error class "wrong address", "credited twice", "payment lost" goes away with manual input: each operation has a transaction and a log entry.

Round reporting is assembled from the same data as accruals — a single source of truth for the issuer and investor. The token is issued under the ERC-20 standard, so accounting in wallets and platforms does not require customization for each of them.

The final round report — total raised, number of addresses, distribution across stages, unlock schedule — is exported on request, not compiled manually for a week.

Ways to conduct rounds: comparison of approaches

A round is not just a start date but a set of rules inside the contract: who is allowed to buy, how many tokens per wallet, when unlocking begins.

These rules affect both the network load in the first minutes and the amount of documentation that must be prepared for the regulator. Below are the options that are actually chosen between.

Modes are compatible in one contract: the seed stage and closed round run from a common pool, and the public one opens after them by changing the state of the admin role.

The whitelist of addresses is stored as a Merkle root — adding a participant does not require redeploying the contract, and the per-participant limit and sale window are adjusted without migration.

Mode change is recorded by an on-chain event, so audit and reporting are built on immutable history, not on interface exports.

Stages of engineering work: from diagram to handover to support

We start work on an ICO platform not with code, but with a requirements audit: we analyze issuance economics, round rules and allocation distribution. Then we design the fund flow diagram and only then move to implementation. The stage order is as follows.

1. Requirements audit. We consolidate round rules, limits, token distribution, KYC requirements and jurisdictional restrictions into one document. Each rule has a verifiable criterion, not the wording "that's how it's done."
2. Fund flow diagram. We fix the route: payment, platform wallet, distribution, withdrawal. We define address roles, the multisig threshold and points where funds can get stuck.
3. Configuration and implementation. Issuance, vesting and KYC status accounting contracts are assembled into a single environment, and round parameters are moved to configuration — they can be changed without rebuilding contracts.
4. Testing on test environment. We deploy a copy of the network and run edge scenarios: round oversubscription, sale cancellation, early withdrawal, re-verification of address. Each run with logs and a coverage report.
5. Acceptance testing. The customer goes through key scenarios themselves using a checklist: we record discrepancies before release, not after launch.
6. Handover to support. We hand over configurations, address scheme, update procedure and incident response instructions; customer engineers are trained on their own test environment.

After handover, a clear map remains: what changes by parameter and what requires a new contract version.

What we hand over to the customer: configurations, diagrams, procedures

Project handover is not an archive with source code, but a state in which the platform can be operated without us. Therefore each document below has an audience: some are read by an engineer, some by support, some by the manager who approves token issuance or limit changes.

We assemble the package so that new people on the customer's team are onboarded through it, not through chat.

• Configured settings: connected networks, sale stage parameters, confirmation thresholds for crediting, vesting boundaries by participant groups.
• Flow diagrams: user path from registration to token crediting, identity verification process, rejection and document resubmission branches.
• Contract documentation: purpose of each contract, its permissions, points where address replacement or operation pause is possible, update procedure.
• Role matrix: which employees can sign what — issuance, freezing, withdrawal from vesting pool, limit changes, and how permissions transfer when a person changes.
• Incident response procedure: which events are considered incidents, whom we notify, in what order we stop operations and how we document the investigation.
• Team instructions: step-by-step scenarios for typical operations — new sale stage, vesting extension, response to request, reporting export.
• Observability: which metrics and events are monitored, which thresholds trigger warnings, where to view operation history.

We consider the package delivered when the customer's engineer performs key operations according to instructions themselves, without hints from our side.

Case: round with multi-chain deposit intake

Before: manual reconciliation and discrepancy resolution

The round accepted funds in three networks at once — Ethereum and two low-fee networks, and transfers came with their own quirks: sometimes in the wrong network, sometimes the amount was less due to network fee withholding.

Credits were reconciled manually: an operator matched the transfer, address and request. At peak, about 40% of deposits were processed this way, support received up to 120 requests per day, and disputed transfers were returned manually.

The consolidated round report took two days to assemble: three exports were merged into one table, duplicates were searched for and missing requests were added. By the end of collection, the data had diverged from the actual contract balance.

After: automatic intake and a single data source

We introduced a separate wallet address for each participant and automatic matching of transfer to request: the system itself detects the network, checks the received amount and waits for the required number of confirmations, after which it credits tokens according to the vesting schedule.

Crediting failures as a class disappeared — a transfer to an unsupported network is filtered out before signature, not after.

The consolidated report is built from a single source: 30–40 minutes instead of two days, the export matches the contract balance. Manual review — less than 5% of requests, support load dropped fourfold, and the freed-up team was moved to the next round.

What to do if fundraising is already going to a single wallet?

The first action is not transferring funds, but capturing the current state. We export the entire history of incoming transactions with addresses, amounts and time, and reconcile the line-by-line deposit register with the wallet balance.

Discrepancy is caught exactly here: while participants haven't started reconciling their credits, any difference can be investigated and closed with documentation.

Accounting migration is built around this register, not around the wallet. The register becomes the source of truth, and each deposit gets a flag — accounted for at the old address or already at the new one.

Nothing changes for the participant: the same balance, the same vesting schedule, the same KYC status, wherever their funds arrived.

We connect the new network gradually, preserving round continuity. First a testnet run with the same rules and limits, then limited intake — a per-address cap and a minimum amount threshold — and only after reconciling the first operations are the thresholds removed. The old wallet continues accepting funds all this time, so no pause in fundraising occurs.

Safekeeping control rests on the key scheme: multiple signers with a threshold, separate addresses for intake, reserve and payouts, batch transfers with identifiers recorded in both systems.

Each operation is recoverable from the log, and the old address after the cutoff date is switched to withdrawal-only mode — no free access to it remains.

This way the round proceeds without stopping, no deposit is lost, and the transition can be rolled back at any step.

Answers to technical concerns about contracts and access

Before publication, the contract undergoes static analysis and scenario runs on testnet: issuance, transfer, permission revocation, emergency stop.

Separately, we review the role matrix — who can change parameters after release and whether the admin has a function to revoke their own permissions. The verification report is versioned together with the code, so it is visible which contract revision went to the public network.

Network congestion does not break the sale. The transaction either fits within the set fee limit or is not sent at all — the request waits in the platform queue, and resending is idempotent and does not cause double crediting. The request status reconciles with the chain by hash.

Participant verification results are stored separately: personal data in secure storage with access control, and only the flag of passed verification goes on-chain.

How are vesting and unlocking structured?

Shares unlock according to the schedule set in the contract: linearly or in steps with a waiting period. The schedule cannot be changed after launch — the participant is protected from retroactive changes.

Let's discuss the task: environments, roles and work order

The timeline for such a project is made up not of "hours per contract", but of environments: how many networks, which roles, where the boundary lies between the smart contract and an external service.

Therefore, first we fix the task statement and initial requirements, and only then assemble an implementation plan with stages and checkpoints.

To come back with a realistic estimate, not a range "from and to", we need inputs from your side:

• user scenarios: who buys the token, how identity verification proceeds, what happens on rejection;
• target networks and multi-chain requirement: one network or parallel launch with unified balance accounting;
• token economics: issuance volume, vesting rules, early exit and pause conditions;
• KYC environment: in-house verification or integration with an external provider, what data is stored off-chain;
• participant roles: who administers contracts, who approves lists, who has stop authority;
• external timeline dependencies — contract audit, legal part, custody service.

We structure the work order so that before the first line of code you see the entire route: scenario analysis, environment diagram, role distribution, interface mockups, list of stages with the result of each.

Describe the task in a convenient form — we'll come back with an estimate, work plan and areas of responsibility.