TON NFT Collection Development: Smart Contracts, Mint, Marketplaces

Why TON NFT Development Is a Challenge for EVM Developers?

We develop TON NFT collections with robust smart contracts, efficient minting, and seamless marketplace integration. TON is architecturally different from EVM. If you're used to Solidity and EVM, where an NFT is a record in a contract mapping, here each token is an independent smart contract. This changes everything: deployment, mint, transfer, and even simple operations like listing on a marketplace. We, our team, have specialized in TON since its mainnet launch. With 7+ years of blockchain experience and over 50 NFT collections launched on Ethereum and TON, we've honed our skills on such projects. We guarantee code audit and 30-day post-launch support. We work turnkey: analytics, contract development, mint site, marketplace integration. We provide a free project assessment — just reach out.

TEP-62 Architecture

Collection and Item Contracts

A TON collection consists of two contract types: NFT Collection contract and NFT Item contract. The Collection stores owner_address, next_item_index, content (collection metadata), nft_item_code (code for deploying item contracts). On mint, it deploys a new NFT Item contract via internal message.

Each token's Item contract stores: index, collection_address, owner_address, individual_content. The item contract address is deterministically computed from collection_address and index via stateInit:

cell calculate_nft_item_state_init(int item_index, cell nft_item_code) { cell data = begin_cell() .store_uint(item_index, 64) .store_slice(my_address()) .end_cell(); return begin_cell() .store_uint(0, 2) .store_dict(nft_item_code) .store_dict(data) .store_uint(0, 1) .end_cell(); } 

This allows computing any NFT address off-chain, which is important for indexers and marketplaces.

NFT Transfer Process

Transferring an NFT on TON is sending an internal message from the current owner to the NFT Item contract with operation code transfer. The Item contract changes owner_address and optionally sends an ownership_assigned notification to the new owner:

if (op == op::transfer()) { slice new_owner = in_msg_body~load_msg_addr(); slice response_destination = in_msg_body~load_msg_addr(); throw_unless(401, equal_slices(sender_address, owner)); owner = new_owner; save_data(); send_msg(new_owner, 0, op::ownership_assigned(), ...); } 

Unlike EVM, where transferFrom is synchronous, TON transfer is async. The new owner will receive a notification in the next block. This affects marketplace logic: listing and delisting require handling async confirmation.

Metadata Storage

TON NFT metadata is stored in two formats: on-chain (TL-B encoded directly in the contract) and off-chain (URL to a JSON file). For collections with generative metadata, snake encoding of the URL is typical:

Cell content = begin_cell() .store_uint(0x01, 8) .store_slice("https://ipfs.io/ipfs/") .end_cell() 

Individual content stores the suffix (e.g., 123.json), the collection stores the base URL. The get_nft_data() getter combines them for the full URI. The JSON format is identical to EVM: name, description, image, attributes. Storage on IPFS works the same — the difference is only in how the URI is transmitted.

How Much Does Minting on TON Cost and How to Save?

Each mint deploys a new contract, which costs more than an EVM SLOAD. On TON, deploying one NFT Item costs about 0.05 TON. For a batch mint of 10,000 tokens all at once, that's 500 TON just in storage fees.

Optimization: lazy mint — the NFT Item is deployed only on first transfer or explicit claim, saving up to 50% of costs. An alternative is pre-deployment with distribution in batches with a delay between blocks. Thanks to TON's sharding architecture, it's possible to mint 10,000 NFTs in one block, which is 20 times faster than on Ethereum. Our certified TON developers have implemented lazy mint for multiple collections, achieving 30% average savings.

How to Deploy an NFT Collection in 4 Steps

1. Prepare metadata: generate JSON files for each token (name, description, image, attributes) and upload to IPFS.
2. Develop Collection and Item contracts in FunC with TEP-62 and TEP-64 support. Use proven templates from ton-blockchain/token-contract.
3. Deploy the Collection contract on testnet via TEP-62. Specify owner_address, nft_item_code, content metadata.
4. Mint tokens: send internal message with operation code deploy_nft_item for each index. Use batch mint for groups of tokens to reduce load.