Build your own cost model: what scales per piece and what is one-off

My NFT cost model separates costs that grow with inventory from transactions paid once for a specific deployment or approval state.

The collection runs on Base. Minting is free, with buyers paying their own gas. That makes cost tracking important: the mint itself does not recover issuer-side expenses.

The line items that scale per piece versus the one-offs

I use variables until a transaction or invoice provides an actual value.

N is the number of pieces prepared. V is the measured preload transaction cost per piece. S is the storage pin cost allocated to each piece. D and A come from their transaction receipts.

My measured on-chain preload is about 0.0000008 ETH per piece. For the full 131-piece drop, the preload term is therefore:

131 × 0.0000008 ETH

Storage stays separate because its billing depends on the pinning arrangement. I do not replace an unknown invoice with a convenient estimate.

The complete model is:

total cost = D + A + N × (V + S)

Deployment is one-off for that contract. Approval is one-off only while the same wallet, operator, and approval state remain in use. Revoking approval or changing operators creates another transaction, so I record it rather than silently treating it as permanent.

The 5-per-wallet limit affects distribution, but it does not change the issuer’s preload cost per piece.

How to measure instead of estimate

I record the receipt after every preload transaction. The chain already reports the inputs needed for the actual gas charge: gasUsed and effectiveGasPrice.

const receipt = await provider.getTransactionReceipt(txHash);
const gasUsed = BigInt(receipt.gasUsed);
const effectiveGasPrice = BigInt(receipt.effectiveGasPrice);
const wei = gasUsed * effectiveGasPrice;
appendFileSync("preload-costs.csv", `${tokenId},${txHash},${gasUsed},${effectiveGasPrice},${wei}\n`);
console.log({ tokenId, eth: ethers.formatEther(wei) });

The CSV gives me an auditable per-piece ledger. I store the token identifier, transaction hash, gas usage, effective gas price, and final cost.

I use the same procedure for deployment and wallet approval, but classify those rows as one-offs. If a transaction covers multiple pieces, I allocate its measured cost across the pieces included in that transaction instead of calling the entire receipt a per-piece cost.

This matters because gas settings and network conditions can change. The receipt is a measurement; a gas estimate is only a planning input.

Break-even math at the mint price using only the numbers in this post

The mint price is free. Buyers pay their own mint gas, but that payment goes to network execution rather than to me. There is therefore no issuer-side mint revenue to offset preload, pinning, deployment, or approval costs.

For the complete drop, the known variable preload expression is:

131 × 0.0000008 ETH

Storage pinning and the measured one-offs must be added to that expression. Because mint revenue is free, there is no finite break-even point from primary mint revenue alone.

If I replace the free mint with a paid sale price P, I use net receipts rather than the displayed price:

break-even pieces = (D + A) / (P - V - S)

That formula only works when P is greater than the per-piece cost V + S. If the sale price is wrong and falls below that cost, every additional sale increases the unrecovered balance. Raising P improves the arithmetic but does not guarantee that buyers will execute the sale.

Practical takeaway: add receipt logging before adding inventory, then calculate from measured costs rather than wallet balance changes. The live collection count is readable from the contract linked at https://thunderous-sunflower-a910b4.netlify.app.