I’m working with TON blockchain and trying to deploy multiple NFT collections from the same wallet, but I’m running into issues where the collections seem to conflict with each other.
I’m using the standard nft-collection.fc contract along with its TypeScript wrapper. My main problems are:
I don’t understand the mechanism behind how TON generates collection addresses
The collections appear to overwrite one another instead of creating separate instances
I need to know what parameters to change to ensure each collection gets a unique address
Can someone explain the address generation process for NFT collections and what modifications are needed to create distinct collections from a single wallet? What specific fields or initialization parameters should be different for each collection deployment?
hey! yeah, this is super common with TON collections - ran into the same thing a few months ago.
here’s the deal: TON generates addresses from your entire contract setup (StateInit). same setup = same address = overwriting.
i fixed it by tweaking the initial data before each deployment. added a simple counter or changed a field in the collection metadata. do you use any salt parameter during initialization? some people love that approach.
quick question - when you say “overwriting,” are you seeing this in your wallet or checking the actual blockchain? wallets cache weird sometimes and make it look like overwriting when it’s just a display glitch.
which TypeScript wrapper are you using? the ton-community one or something else? that’ll help figure out which parameters to modify.
also, have you tried deploying from different wallets? would be interesting to see if it happens across different sender addresses too.
totally agree! address generation is all about the StateInit. if you keep it the same, yeah, it’ll clash. just throw in a unique nonce or even a timestamp to spice it up. make sure those params are def changing with each deploy, or you’ll keep hitting walls.
This happens because TON uses deterministic address generation for smart contracts. Your contract address gets calculated from the StateInit, which includes your contract code and initial data. For NFT collections, this typically consists of the owner address, collection metadata, and possibly a salt value. Deploying multiple collections with identical parameters results in the same StateInit hash, leading to address collisions. To prevent this, ensure each collection’s initial data is unique. A simple solution is to add a unique identifier to the initialization data, such as a random number, timestamp, or a counter. Also, modify values like the collection content URI or name in your TypeScript code. Even minor changes in metadata can create distinct addresses while maintaining functionality.