When it comes to building a bridge for NFTs between ETH and a layer2, how can I make sure that a same token ID wouldn’t have a duplication on either side of the chains?

For eg, I could have token ID 123 on ETH chain. But what happens if the minter mints another token with the same ID of 123 on Polygon chain? How do I even determine which is the original token now that both chains have the same token ID?

maybe specify chain at deposit time, as an argument or something

umm... sounds interesting. would u mind elaborating a little? so at deposit time, we are referring to when the user calls deposit() to initiate the bridging of the token from ETH to Polygon, right? So what u mean is to make my deposit function like this deposit(tokenId, chainId) where chainId is the Polygon chain ID?

But still, wouldn’t the minter be able to mint the same token ID 123 on Polygon before the deposit happens?

minter should wait confirmations... so no, the mint should not happen before deposit time

sorry, I think I’m missing something here. the minter mints token ID 123 to account 0xabc on ETH. But at the same time, the minter accidentally minted token ID 123 on Polygon too. Now, both chains have token 123.

How does making deposit(tokenId, chainId) help at recognising which is the correct token?

deposit(tokenAddress,tokenId,destinationChainId)

minter doesnt accidently do anything, that sounds fishy

maybe add a argument to deposit (that is required to be unique) for each request, and then the minter can sort of check-off these request ids

maybe
deposit(tokenAddress,tokenId,destinationChainId,userProvidedUniqueId)

That’s what I’m trying to illustrate here. What happens if the minter is crooked or just for some reason forgotten that he has already minted the ID 123 on another chain before?

In this case, I assume tokenAddress is the token contract address on Polygon chain. The minter can mint on both the token contract address on ETH and Polygon. So he could still mint token ID 123 on both chains, and how is having the deposit function deposit(tokenAddress,tokenId,destinationChainId) going to help?

umm... But how does modifying the deposit function with an additional unique ID going to help with the duplication of tokens on both chains?

Imagine if the minter had minted token 123 to account 0xabc on ETH first and then subsequently minted another token 123 to account 0xdef on the Polygon chain later. Now there are 2 duplicated tokens of the same IDs.

in that example, wheres the real original token 123 ? bridged token should be burned when unbridged (original token stays in bridge contract until unbridge)

bridged nft is sort of nothing more than a certificate of ownership that contains some location of the actual nft

Currently, what I have intended is for the NFT to be able to be minted on either the ETH chain or the Polygon chain if the minter wants to save on gas. Would this an issue?

yea thats funky because what would be the real NFT contract address? hmm 🤯

and then, each nft contract has to somehow know not* to mint the same id as the other chain

Does that mean there must be a predefined chain that minting can only happen and not on the other chain? But I could see most NFT contracts still has the mint function on both chains. So the minter could still technically mint the same token ID on both chains, couldn't he?

Yea, that's something I wonder how NFT bridges are done today.

possibly

have token 0x1111, id 123 (on ETH)

bridge it to polygon, by sending to eth contract

bridge loop script waits confirmations and mints new (fake) nft that represents that 0x1111:123 one

user now has a fake 0x1111:123, lets say "0x2222, token ID 5000" but its on the same matic contract address as all the other bridged nfts (regardless of source contract address or tokenID)

user can sell/list on matic nft marketplace

owner of this fake nft can then unbridge it back to ETH and receive the real one, burning the fake one in the process

somethin like that

to get the metadata to match is another can of worms etc

umm... But wouldn't the duplication of the tokens still be possible?

yea u have to trust the bridge service

(theres ways to build a decentralized one using signatures and verifiers, with some sort of stake to lose if they are dishonest)

On a second thought, I have question about you've suggested. You mentioned:

"user now has a fake 0x1111:123, lets say "0x2222, token ID 5000" but its on the same matic contract address as all the other bridged nfts (regardless of source contract address or tokenID)"

I believe the 0x1111 and 0x2222 are token contract addresses on the ETH and Polygon chain respectively. Then the concern should be when 0x2222 on the Polygon chain also has token ID 123 and not 5000, isn't it? Or did I understand something wrong here?