Lazy minting NFT: why token issuance stalls on gas
The collection is announced, the cover and metadata are ready, the edition size is mapped out — but issuing the token collection runs into paying gas at issuance.
In the classic scheme, minting each token is a separate transaction that the creator pays for in advance, before a buyer appears. Prepaying for gas becomes a mint bottleneck: the larger the edition, the more must be frozen idly.
The problem is not only volume. Gas cost is not constant: at peak network load, the fee rises several times over, transactions hang in the queue, and some fall out when the waiting time expires.
Mint requests are lost at the worst possible moment — the buyer sees an error and leaves, and the place paid for in advance ends up occupied by a failed attempt.
Then there is the budget arithmetic. Issuing a collection of ten thousand units means ten thousand advance payments, even though only a tenth will actually sell — the rest remains frozen capital that the owner cannot move into marketing or into developing the product itself. Because of this, releases are split into waves, stretched over time, and still lose requests.
Hence the workaround: lazy minting NFT shifts gas payment to the moment of purchase, and the creator does not pay for tokens that no one bought. We break down how this is solved and what limitations remain in the scheme.
What delayed mint changes: coverage, speed, class of failures
Buyer pays gas
With delayed mint (lazy minting), the token is not created in advance: a signed permission lies on the network, and the record appears at the moment when the buyer initiates the transaction themselves.
Gas moves from collection preparation to the moment of purchase — there is no need to reserve it for tokens that no one bought. For an edition where a tenth of the release sells, this is the main share of launch costs.
Volume does not hit a one-time reserve
The usual scheme requires buying gas for the entire edition in advance, so the collection size is limited by what one is ready to reserve before the first sale.
With the delayed scheme, costs grow in proportion to actual sales: you can announce 10,000 items instead of 500 and not pay for unsold ones. The scale of the collection becomes a product decision, not a reserve-size decision.
The “mint failed” class of failures goes away
Gas exhaustion at the moment of issuance, a jump in the base fee, the block gas limit — with batch minting, this is a mass failure that breaks the release and requires re-running the entire batch.
With the delayed scheme, the buyer initiates the transaction, so the failure is localized to a single purchase and is retried with one button.
Collection launch speeds up
Preparation comes down to uploading metadata and signing permissions: deployment does not wait in a transaction queue and does not stretch into peak hours. The collection opens for sales on the day the content is ready, and new batches are added without a separate gas issuance.
Comparison of issuance schemes: direct mint and lazy minting
An issuance scheme answers two questions: who pays for gas and at what moment the token record enters the network. Direct mint fixes the token immediately upon creation, delayed mint moves the record to the moment of purchase, and hybrid combines both approaches.
Below is a comparison of working schemes by applicability and limitations, so the choice rests on the collection scenario rather than on taste.
| Scheme | When it fits | Limitations |
|---|---|---|
| Direct mint | Closed membership, predictable number of tokens, a full list of owners is needed immediately | Gas for each instance on the issuer’s side; for mass issuance, this is the main expense |
| Delayed mint (lazy minting) | Open collections, issuance on demand, buyer pays | The token does not exist until the first sale — storefronts and wallets do not show it in advance |
| Hybrid issuance | Part of the set is exclusive, part is mass; a fast start to sales is needed | Two logics in one contract: tests and royalty distribution between issuances become more complex |
| Signature-based issuance | Limits, allowlists, price and lifetime of the permission are needed on the issuance side | Dependence on the service that issues signatures: key compromise opens unlimited minting |
The limitations of the schemes do not cancel each other out: delayed issuance removes the expense from the issuer’s side but adds dependence on the storefront, while hybrid partially covers this risk for the anchor part of the collection.
During assessment, we compare the issuance scenario with these schemes and record which class of failures remains acceptable.
Implementation step by step: audit, signature scheme, acceptance, handover
Implementing delayed mint is not flipping a switch but a sequence in which the signature, rights, and storage must fit coherently onto an already operating issuance. First, we capture the current scheme so that the new order does not conflict with roles and metadata. Then come the stages, each ending with a verifiable artifact.
- Analysis of the current issuance scheme. We look at which roles exist in the contract, who initiates minting, where metadata comes from, and what the peak issuance frequency is. The output is a process map and a list of places where delayed mint changes behavior.
- Signature design. We define the composition of the signed message: collection, recipient, price, expiration, and nonce. We decide where the signing key is stored and how the contract invalidates reuse of the same signature.
- Contract and storage setup. We assemble the contract with signature verification, deploy it to a test network, connect distributed storage for metadata, and fix the collection address before release.
- Load testing. We run scenarios: successful mint, expired signature, race for the same token, storage failure. We measure response time and the share of paths covered by checks.
- Contract acceptance. We verify behavior against agreed criteria: correct rights transfer, rejection of an expired signature, readable events for accounting. We maintain an acceptance report.
- Handover and training. We provide access, keys in secure storage with a rotation policy, the mint flow scheme, and support instructions.
Describe how issuance is set up now — we will return with an assessment and a plan for these stages.
Handover artifacts: configuration, schemes, issuance policy
Project handover is not an archive with source code but a working system that your team can develop without us.
We record not only the code but also the decisions that led to it: why this signing method was chosen, how rights are structured, what happens if an external service is unavailable. Below is what remains with the client after delivery.
- Issuance configuration: lazy minting parameters — batch size, per-address limits, signature disclosure conditions, behavior when a node is unavailable. Moved into environment files rather than hardcoded: changing conditions does not require a rebuild.
- Signing keys and their storage scheme: where the private key lives, how a signature is applied to each token, the rotation procedure, and revocation of already issued permissions before the mint moment.
- Access policies: role matrix for issuance, pause, and revocation, rules for service accounts, and a list of actions requiring two-person confirmation.
- Issuance documentation: step-by-step order for publishing the collection — from metadata preparation to checking the first mint on a test network, with the expected result of each step.
- Minting policy: what to do in case of a quantity mismatch, a stuck transaction, or a repeated signature; who responds and within what time frame.
- Integration schemes and maintenance instructions: connections between the storefront, signing service, and network with failure points; dependency update procedure, where to view logs, and which checks to run before changing configuration.
Case: a collection of 12,000 tokens without prepaying for gas
Starting point
The client was preparing a collection of 12,000 tokens on the ERC-721 standard. Minting ran in advance via a batch script, and the project paid gas for the entire collection before sales started.
At peak network load, transactions from the batch hung, some failed due to the gas limit and transaction ordering conflicts — up to 18% of buyer requests were lost in reverts.
A single release stretched over five to six hours, and the team stayed on duty at night, manually restarting the tail of the batch.
What was changed
Minting was moved to the moment of purchase: the service issues a signed permission off-chain in tens of milliseconds, and the buyer sends the transaction themselves and pays gas at the current price.
Signatures for the entire collection are prepared in advance and given to the collection application, while per-wallet limits and the allowlist are checked before sending.
A separate handler monitors confirmations and resends transactions that fell out of the queue during overload.
What became
- Successful mint rate during peak hours: 82% → 99.4%.
- Release opening: five to six hours of batch run → minutes to prepare signatures.
- Lost requests at peaks: 18% → less than 1%, and only those canceled by the buyers themselves.
- Release duty shifts: night shift → zero, with a notification only when the confirmation rate drops.
The metrics were taken from node logs and the purchase funnel during the first day after launch — this is the same load profile as on the previous release, so the comparison is valid.
How delayed mint differs from direct issuance
Until the mint moment, the token does not exist in any network. The collection contract stores only metadata and the creator’s signature — a dataset that lies off-chain and is not a record of ownership. Such a claim can be verified off-chain, and the buyer’s balance at that moment is zero.
Direct issuance works differently: the token is created at the moment of uploading to the contract, and the collection author pays gas for each instance.
For a series, this is a fixed cost that grows linearly with the number of items — even if one instance out of a thousand is sold.
In the delayed scheme, the author signs the issuance parameters: price, instance identifier, recipient address, quantity limits — and publishes this signature.
The buyer sends it to the contract, the contract verifies the signature against the creator’s public key, and creates the token exactly at the mint moment. The buyer bears the gas, and only for one instance.
Before the mint, the buyer has not a token but a right to it. The signature has a lifetime and a one-time nonce that protects against reuse, and the author can revoke it — before the contract call, it is nobody’s asset.
Marketplaces like OpenSea show such claims in their storefront, but the ownership record appears only upon purchase.
For the collection owner, this changes the workflow: publishing the catalog stops being a costly operation, but signatures become a production secret.
They are stored in protected form, a registry of issued signatures is maintained, nonces are monitored, and a revocation procedure is prescribed for key compromise.
Technical concerns: gas, re-mint, access to files
Concerns usually relate not to the scheme itself but to edge cases: what has already been issued, what happens during a failure, and whether one can migrate to another contract without losing the collection. Below are five questions that most often come up during the design stage.
What happens to an unpaid mint?
Until gas is paid, the token does not exist on the network — there is only a signed issuance permission with fixed parameters. The buyer loses nothing: the permission either executes upon payment or expires by its term, and it can be revoked.
What happens if the signing service is unavailable?
Signatures are stored separately from the issuing node, so service unavailability stops only new signatures, not storefront display or already issued tokens. Recovery is a matter of switching to a backup node, while the integrity of issued permissions is preserved.
Can a token be minted again?
No. Each permission is one-time: the contract marks the used identifier and rejects a repeated mint with the same signature. This also protects against an attempt to issue one token to two buyers during parallel requests.
Where are the collection files stored?
Media are placed in distributed storage with content addressing, so the file address changes with the content. We replicate copies across independent nodes and monitor availability so that collection metadata does not point to a missing file.
How can an already deployed collection be migrated?
There are two possible paths: transferring issuance rights to a new contract or taking a snapshot of holders and exchanging according to an immutable rule.
The choice depends on whether backward compatibility with current addresses is needed; we test both scenarios on a test network before switching.
Let’s discuss the collection: what to send for assessment and a plan
To return with a development assessment and a work plan for delayed issuance, we need not a ready-made specification but inputs about the collection. From them, we estimate the scope of contracts, the composition and order of signing, and the work on the mint storefront.
Describe the task in free form — we will ask clarifying questions ourselves; this is faster than coordinating a long specification.
- Network and token standard: where the collection is issued and what the unit is — a unique instance or a fungible one; the logic of delayed issuance and distribution depends on this.
- Volume and metadata: how many instances are in the collection, how images and attributes are prepared, where the content lies before minting, and what enters the registry afterward.
- Who signs the issuance: the signer wallet on the client’s side, who holds the keys, and how rights are transferred when the responsible person changes.
- Mint conditions: price in the network’s native coin, per-wallet limit, time window, open access or a closed address list.
- Roles and payouts: to whom and in what share the sales royalty goes, whether there are privileged addresses and reserved instances.
- Storefront: where the buyer performs the mint — their own site, a third-party marketplace, or both options, and which wallets must be supported.
Send the inputs in any format — a document, a spreadsheet, or a short message. We will return with a timeline estimate, a stage-by-stage work plan, and a list of debatable points worth discussing before the start.
If there are launch timeline constraints for the collection, mention them right away — we will take them into account in the order of stages.