ERC721 token

[martriay]

What considerations should we have in mind when developing the L2 version of ERC721?

[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

[fracek]

Related to ERC-721 is how should we handle the NFT royalty standard.

[glihm]

Hello! The discussion is a bit old, but here is my take on this @martriay.

1. Starknet is limited with felt. I mean by this any external interaction with a contract view for instance will result in a response composed of an array of felt. Taking this in account, we can think of two things:

   • Devs on Starknet have the habbit to deal with short strings (31 chars that fit in a felt).
   • However, this is very limitating and someone who is using ipfs for instance will not be able to use the standard interface if token_uri only returns a single felt.

2. About the L1 data, I do agree on your comments guys. If a token is bridged for the first time L1->L2, we should ensure data retrieval from L1.
   This actually can be done on-chain.

   • When a NFT is bridged, the bridge contract does a mapping eth://ABCD... <-> (collection_id, token_id) where the primary key string is always 31 chars long. (it can be a subset of a keccak of the original URI or any random and unique string generated by the bridge contract).

   • In the L2, the associated bridge contract has now an URI prefixed with eth:// and like this, when token_uri is called, any URI starting with eth:// the Dapp just have to make a eth_call to the L1 bridge contract which can expose a bridged_token_uri(string) return (string) similar to ERC721 spec. And internally, the L1 bridge contract make a call to the corresponding collection address to get the original token URI. This is free, as those are view calls.

This solution can always be used (independently if Starknet supports long strings or not), as it allows the Dapp to directly go to the source of the token URI. That also solves the @fracek proposal of knowing when a token was bridged or not. With the eth:// prefix, no doubt.

Talking more about Starknet, if we want easy adoption for creators to upload their collections, we must support natively at least ipfs URI. Which are always more than 31 chars.

A first solution can be that, token_uri always return an array of at least 2 felts. The first one is the length, then the other ones are the content.
We waste a lots of bandwidth.. as the first felt may always fit in one byte instead of 32... But this is at least extensible.

We can also imaging that the first felt is a header giving information about possible encoding or stuff like that as we have 32 bytes... 4 bytes for the length are enough, then we can define more stuff in there.

Or better than an array, a tuple perhaps? Struct?

token_uri(token_id: u256) -> (felt252, Span<felt252>);

struct TokenUri {
    len: felt252,
    content: Span<felt252>,
}

Hope that can be interesting, I do like the eth:// prefix as it allows a very safe retrieval of original data. For sure, it's the responsibility of the L1 bridge contract to maintain the mapping. But it's still better than an external centralized service in my opinion.

[remiroyc]

I find @glihm 's proposal extremely interesting. This is a crucial topic, and I believe it deserves special attention. It is a significant blocking point for bridged L1 tokens, and finding effective solutions to manage token URIs is essential.

The use of two fields would allow for the management of long URIs, including IPFS schemas. The recent advancements in Cairo would make it "relatively easy" to handle an array of fields.

Another thing to consider is implementing a system similar to Ethereum's contract structure, where only the baseURI is stored, and a tokenURI view function concatenates the baseURI and the tokenId. Adopting this approach would facilitate smoother integration for collection creators and eliminate the need to store a felt252 for each tokenId. Instead, a concatenation of the tokenId with the baseURI, similar to the methodology employed in the OZ contract on Ethereum, could be utilized.

By implementing these ideas, we can enhance the overall efficiency and practicality of managing token URIs for bridged L1 tokens.

[martriay]

hey there! i haven’t had opportunity to review it thoroughly yet since we’re focused on migrating to Cairo 1 with all the associated intricacies (dual interfaces, replacing the introspection mechanism from ERC165 to SRC5, etc) rather than changing the overall behavior of contracts. i do have it in my backlog though.

if i understand correctly, @glihm's proposal is to take an opinionated approach on how strings will look like. what happens if tomorrow Cairo releases long string support and it has nothing to do with this proposed struct? we’ll have incompatible tokens.

we also know long string support is coming soon. since our hands are full right now, it might be the case that long string support comes before we can look into it, case in which it might make sense for us to wait until then to evaluate once we know more about long strings.