ERC-20 token development: where contracts break
Errors during token issuance are almost never in the logic — they are in the details that break nothing on a testnet. Decimal precision is set once and for the entire life of the contract: zero instead of eighteen — and the wallet shows one unit instead of the whole amount.
Overflow when adding balances in a build without checks produces a wraparound and an “infinite” balance for one address.
A separate group is permissions. If minting is not restricted by a role, any address can mint an arbitrary amount to itself.
The opposite is also a mistake: the minting role is assigned to an ordinary wallet without multisignature — losing the key stops issuance forever, while compromise gives an attacker control over supply.
The third is unprotected balance operations.
A transfer without a zero-address check sends tokens to an inaccessible place; the absence of a Transfer event breaks indexers and exchanges; and spending by allowance without accounting for the remaining limit allows withdrawing more than approved.
The fourth is token incompatibility with wallets and external services: non-standard return values for transfer and approval, different names for metadata fields, missing familiar events.
The asset does not display in a wallet or is not credited to an exchange deposit, and a smart contract vulnerability surfaces after listing — fixing it requires reissuing and distributing a new asset to holders.
How these scenarios are covered at the design and verification stage — we break down below.
What a correctly designed token provides
A correctly designed ERC-20 contract is not just a working transfer. It has built-in checks that eliminate a whole class of failures: sending to a contract address that cannot accept tokens, loss of precision when splitting shares, repeated invocation of the same operation.
The share of rejected transactions drops from several percent to isolated cases, and each such operation stops turning into manual investigation with resending.
Compatibility with wallets and services is verified, not assumed. The contract behaves the same for custodial solutions, exchange deposit addresses, and network explorers: transfer events are emitted in the expected form, balances reconcile to the last digit.
Connecting a new service is reduced from weeks of correspondence and revisions to a few days — there is simply nothing to fix on the integration side.
Stable token issuance rests on predictability. Limits, roles, and minting rights are described explicitly, bulk accrual scripts are idempotent, and a repeat does not create duplicates.
The number of manual operations during accruals drops severalfold: reconciliation is based on an export, not line by line.
A separate effect is manageability without breaking issued balances. Administrative functions are separated from transfer logic; limits and pauses are changed by parameters, not by reissuing the contract.
This is a margin of safety that allows adding new scenarios — accruals, cashback, staking — without stopping circulation.
Issuance formats: basic standard and extended logic
The token issuance format determines not “sophistication” but which operations with the asset are needed at launch and what will have to be added later.
Standard contract logic — transfer, balance, spending approval, minting, and burning — means minimal code and minimal surface for errors.
Extended token logic adds roles, operation limits, accrual, and freezing: each extension complicates the audit and changes how wallets and exchanges accept the token.
Below are four options that teams actually choose between at the design stage. The limitations of ERC-20 are shown honestly: some tasks the standard does not solve at all, and it is better to see this before development.
| Option | When it fits | Limitations |
|---|---|---|
| Minimal standard | Distribution, listing, share accounting without complex rules | No roles or limits; new rules will require migration to a new contract |
| Token with roles and limits | An administrator, transfer pause, daily limits, and separation of rights are needed | More code — larger attack surface; frequent rule changes alarm holders and exchanges |
| Contract with accrual and freezing | Holder incentives, team vesting, locking a share until a deadline | Requires reliable external data sources; accounting and reporting to exchanges become more complex |
| Wrapper around an existing asset | Moving an existing asset on-chain without a new supply | Requires a responsible reserve holder and regular proof of backing; trust in the wrapper is no higher than in that holder |
Before choosing, we analyze the scenarios that must work a year from now: migration, manual intervention by the owner's decision, and acceptance of the token on platforms.
Stages of engineering work on the contract
The order of stages is needed not for reporting but to catch expensive errors before publication. Code on-chain is immutable: after deployment, fixing a typo in a condition or a hole in access rights without issuing a new contract and migrating holders is no longer possible.
Therefore, the cost of a fix grows with each step — we go from specification to code, not the other way around.
- Analysis of the task and the asset's economic model: how many tokens are issued, whether there is additional minting and burning, what restrictions apply to transfers and fees. The model is fixed in the specification before the first line of code.
- Role and permission schema: who mints, freezes addresses, changes parameters. We separately check that privileges cannot be obtained bypassing the intended path — via a proxy, delegation, or a call from another contract.
- Contract assembly: we take the standard's basic functions from audited libraries and write only the missing logic. The error surface is smaller than when writing from scratch.
- Local runs and contract testing: boundary values — zero addresses, overflows, repeated calls, limits. Then a run on a testnet with real wallets and scenarios.
- Independent smart contract audit: we review the report, close the findings, and re-check disputed areas.
- Token publication: deployment to mainnet and source code verification in the explorer, so the address can be checked against the code.
- Handover and team training: role documentation, instructions for minting and revoking, and the procedure for incident response.
Handover artifacts: code, schemas, issuance procedures
Project handover does not end with deploying the contract to mainnet. The client receives a package that allows the token to be developed and maintained without us: code, separation of rights, procedures, and checks. Below is exactly what is recorded in the handover act.
- Contract source code with comments: readable structure, explanations for external calls and events, no “magic” constants hardcoded into the logic.
- Role and access rights schema: who can mint and burn tokens, halt operations, and change parameters; how rights are distributed between addresses and the multisignature.
- Token issuance procedure: a step-by-step minting procedure with per-operation limits, signing order, and recipient address verification before minting.
- Operations halt procedure: under what conditions the pause is triggered, who makes the decision, how operations resume, and what happens to already issued balances.
- Access recovery instructions: key rotation, transfer of the administrative role, and the procedure in case of signer compromise.
- Set of checks: unit and integration tests for key scenarios, static analysis, and an external audit report with a list of closed findings.
- Contract documentation: external interface description, addresses of deployed instances on testnet and mainnet, issuance parameters, and limitations.
All artifacts are transferred to the client's repository along with the change history — updating the token or changing contractors does not start with reverse engineering.
Case study: eliminated a class of failures during asset issuance
Starting point
The asset was issued as a quick prototype: additional minting, address freezing, and balance reconciliation went through manual scripts — nine operations per cycle, each launched only after visual inspection.
The share of rejected transactions stayed around 7%: some failed because of incorrectly set limits, and some on repeated spending when two scripts managed to access the same reserve.
Investigating one such case took up to an hour, and a full ledger reconciliation took another half of a working day.
What was changed and what the result was
The logic was moved into a single contract with separated roles and replay protection, and routine actions into scripts with mandatory simulation on a testnet before sending.
A batch is issued with one call, limits are calculated from the current network state, so the transaction does not “burn” for nothing. The class of failures related to manual entry of addresses and amounts is fully closed.
The result: the share of rejected transactions is 0.4%, and these are deliberate cancellations by the operator, not failures. The issuance cycle was reduced from 40 to 6 minutes, and manual operations per batch from nine to two.
We take ledger reconciliation automatically from Etherscan data; there have been no discrepancies with internal accounting for several releases in a row — the check takes minutes instead of half a day.
What to do if the contract is already deployed and cannot be changed
A deployed contract cannot be changed — that is the point of immutability: neither administrative functions nor retroactive address substitution will appear there.
But the token state lives not in the code but in balance storage, so contract migration is built not on editing the old one but on issuing a new one and moving holders.
The basic operation is a balance snapshot at a specific block number. It is used to read all addresses and amounts once, and the list is not recalculated afterward: this way holders have no way to move tokens between wallets and double the accruals. The snapshot becomes the official source of rights when replacing a deployed token.
The new contract is published separately, and the old one continues to work — platforms do not switch over in one day.
A holder sends the previous tokens to the swap contract and receives new ones at a fixed rate, usually one to one; the swap address and rate are announced in advance.
The transition period is set with a buffer, after which the swap closes and unredeemed balances are locked. This disciplines holders and prevents liquidity from being dispersed between two versions of the asset.
A separate workstream is coordination with exchanges, wallets, and explorers: they need the new contract address, the ticker change date, and snapshot confirmation.
Once this is done, the migration proceeds without losing history and without manually editing each holder's balance.
Technical concerns: access, limits, code verification
Minting rights, limits, and freezing are part of the access model that is designed together with the contract, not added after launch. Below are the questions that engineering teams most often raise when reviewing administrator rights and accepting code.
Who owns the token minting rights, and how are they transferred?
Minting is enabled by a separate role: an address that can create new tokens. At the start, this is the deployment wallet; then the rights move to a multisignature, and the deployer role is revoked.
We grant roles for freezing and changing parameters separately — compromise of one key does not give control over the entire supply.
Can the contract logic be changed after launch?
It depends on the template. An immutable contract cannot be edited: improvements mean migration to a new address. An upgradeable one keeps logic behind a proxy, and the administrator changes it — convenient, but all the risk moves into administrator rights.
Therefore, we secure them with a multisignature and an execution delay: holders have a window to see the change in advance.
How is the published code confirmed to match the source?
Contract verification is the publication of the source code and build parameters from which the same bytecode as at the address is reproduced. We complete it immediately after deployment: before that, only bytecode is visible from the outside, and no one can verify the logic. We record artifact checksums in the issuance report.
What exactly does an audit check, and what remains outside its scope?
The audit examines arithmetic, separation of roles, external calls, and boundary transfer scenarios.
We separately run invariants for transfer limits and asset freezing: the sum of balances does not diverge from issuance, and a blocked address does not bypass the restriction through an intermediary.
The audit does not validate the economic model and does not replace key management procedures — that is your operational area.
Let's discuss the task and come back with an issuance plan
Estimating token development without context turns into a broad “from and to” range, so we start not with hours but with the asset model.
Send what you already have — a tokenomics draft, an investor presentation, correspondence with lawyers: that is enough to see the real scope of work and bottlenecks.
- Asset purpose: what the token confirms — a share, a claim right, access to a service, or an internal accounting unit.
- Usage scenarios: minting, transfers, burning, address freezing, transfer restrictions, administrator roles and their powers.
- Regulator and partner requirements: holder verification procedures, operation limits, reporting, and participant jurisdictions.
- Where placement is planned: platforms and wallets, and their requirements for the token standard and metadata.
- Existing work: contract drafts, tests, audit reports, if the code was already written by another team.
- Hard constraints: tie-in to an event, issuance volumes, unlock conditions, and the payout schedule.
Based on these inputs, we come back with a contract work plan: a contract diagram with a list of functions, roles, and access rights; a breakdown of stages with a measurable result at each; issuance timelines; and the verification order before publication.
To discuss the issuance task concretely, it is enough to describe it in free form — we will put together an estimate, a plan, and come back with questions if something is missing.