ERC721 token

[martriay]

No description provided.

[fracek]

Not sure this is the right issue for this, on discord we discussed that users may want to bridge their nfts to starknet to take advantage of the low low gas fees.

Issues I see that can arise from this:

• should we bridge only the ownership information or also the tokenUri? What if the tokenUri is dynamic like in the DVD logo nft?
• how to distinguish between bridged and native nfts?

[martriay]

1. I believe we need at least to copy + freeze metadata from L1, querying information should be made easy. This means not having to make inter-layer calls to get metadata from L1 when looking at an L2 token. Dynamic tokenUris are definitely and additional challenge.
2. what do you mean by distinguishing?

I also wonder how NFTs bridges should/will look like.

[fracek]

Let me start by prefacing I'm only concerned about bridging from L1 to L2, not from L2 to L1 or from L2 to L2 (which is a much harder problem from what I understand). I'm also looking at this from the point of view of individual users that want to move their NFT to a Layer-2 to take advantage of the cheap services there, not from projects that want to migrate entirely on L2.

1. I believe we need at least to copy + freeze metadata from L1, querying information should be made easy. This means not having to make inter-layer calls to get metadata from L1 when looking at an L2 token. Dynamic tokenUris are definitely and additional challenge.

Agree. On the other hand users could query information that is outdated or wrong which is pretty dangerous. Basically I'm wondering if we can make it convenient and foolproof.

2. what do you mean by distinguishing?

If I'm writing a dapp frontend I want to know if the ERC-721 I'm looking at is an L2 one or bridged. If it's bridged I want to know what's the original L1 token so that, for example, I can use the L1 tokenUri method to correctly support dynamic NFTs (or I can fetch analytics data about the L1 collection). I'm thinking like creating a new interface for bridged ERC-721:

interface BridgedERC721 {
    function l1Address() view returns address;
    function l1ChainId() view returns uint256;
}

I also wonder how NFTs bridges should/will look like.

I started thinking about this too and I would love to hear more from others. At the moment there are not many NFT bridges available. One advantage of StarkNet is that it should be possible to go back from L2 to L1 in less than a day and not a week like other Layer 2.

[martriay]

@0xsoon mentioned on twitter that Vitalik wrote a post about it

[perama-v]

I wonder, for the tokens that originate in L2, what the pattern is in the event of a roll-up fallback event. You inherit the L1 security and can recover your token on L1 (at some cost). This would involve minting, and does this imply that an L2 token points to a contract factory on L1?

[frangio]

My intuition is that the token URI should not be copied, and the L2/bridged NFT should just redirect the client to fetch the URI from the L1/original chain.

XLNT/use.nifti.es is kind of a way to do this. It offers an endpoint to fetch metadata of an arbitrary NFT from any chain. This is a centralized service so it would not work as is, but I believe the solution should look something like it. The original NFT remains the source of truth, and dynamic URIs would in theory be seamlessly supported. I would consider definining a new URI protocol inspired by use.nifti.es, together with a library that can resolve those URIs.

Curious if @shrugs has any input, as the author of use.nifti.es!

[shrugs]

it would be best if clients knew to fetch metadata from the L1 contracts but i'm not sure if there's a way to do that automatically without a proxy like you mentioned with use.nifti.es. centralized definitely wouldn't be ok for such a core piece of infrastructure.

the freeze doesn't feel like a perfect idea either. what about a new URI scheme that indicates that one should search on a specific chain for a token's metadata? like (asset-metadata://eip155:1/erc1155:0x28959Cf125ccB051E70711D0924a62FB28EAF186/0) (that's the CAIP-19 asset id) and clients could treat that as a redirect to go to that contract and pull the appropriate tokenURI or uri result and resolve from there?

[fracek]

what about a new URI scheme that indicates that one should search on a specific chain for a token's metadata? like (asset-metadata://eip155:1/erc1155:0x28959Cf125ccB051E70711D0924a62FB28EAF186/0) (that's the CAIP-19 asset id) and clients could treat that as a redirect to go to that contract and pull the appropriate tokenURI or uri result and resolve from there?

I like this idea a lot! I'm concerned how you would support a ERC-721 (1155) that doesn't implement ERC721Metadata?

[shrugs]

if L1 token doesn't support metadata, neither should L2, since there's nothing to display, right?

[fracek]

Sorry I didn't express myself clearly. How would a dapp or smart contract know a token is a bridged token if they cannot inspect the tokenuri? Should a dapp even care if a token is bridged if there is no token uri?

[frangio]

A URI scheme like that is exactly what I was thinking!

If the original NFT doesn't implement ERC721Metadata, I think the bridged NFT should still offer a tokenURI and the client upon being redirected would find that there is no metadata to be shown.

[shrugs]

ah yeah that makes sense and has fewer edge cases. then the spec for L2 tokens is quite simply "a token uri always exists, follow the redirect as you choose, and then resolve as in EIP-721/EIP-1155 as before"

[frangio]

There is a project to register a caip: URI scheme (ChainAgnostic/CAIPs#67). I wonder if it would be ok to use that directly? That is, rather than a custom asset-metadata:// URI, just the caip URI refering to the original asset. It is not specifically referencing the tokenURI, but I don't know if that's an issue.

[shrugs]

yeah that seems ideal tbh