Here’s one https://etherscan.io/address/0x38930aae699c4cd99d1d794df9db41111b13092b#code - see line 87. It uses ERC721A
I’m not sure if there’s any docs about opensea/looksrare indexers but both have properly indexed the above collection and tokens 1 - 1000 were minted using consecutive transfer.
Thanks, that helps a lot.
Hi everyone. Just registered for this site to contribute to the discussion here (only get two links in the post). To briefly introduce: I just launched GigaMart, an NFT marketplace and had previously done some research into 2309 support. To summarize what I learned here:
I discovered 2309 when my indexer failed to detect most of the items minted in the GoonzSchoolPhotos https://etherscan.io/address/0x36e5913bf48ccbd361875d09c0a20a4c144da896 collection, which emitted ConsecutiveTransfer events in its minting process.
I’d previously viewed the fact that ERC-721 and ERC-1155 could not mint an NFT without emitting an event for each unique token or (in the case of ERC-1155) type of token as a sort of backstop against denial-of-service attacks. If someone wanted to flood my indexer with bogus NFTs, they would need to at least pay proportional gas to do so.
Honoring EIP-2309 without limits feels impossible: for the gas cost of a single event, a collection could signal that it is minting a full 2^256 - 1 items. Conventionally, my marketplace would then try to collect the metadata for each newly-minted token that it sees. To prevent the ConsecutiveTransfer event from being abused to fill my metadata collection queue with 2^256 - 1 pending calls, the only reasonable solution I see is for a marketplace to truncate overly-large token ID ranges.
The popular Chiru Labs implementation https://github.com/chiru-labs/ERC721A/issues/310 of ERC-721 has a limit of 5,000 on the size of an EIP-2309 range. That GoonzSchoolPhotos collection that brought this to my attention minted things in batches of 1,000. The OpenSea token ID range size limit is 5,000, determined empirically by Chiru Labs.
Guilty as charged; I’m one of those who wrongly believed this to be the case.
Yes, this is something that marketplaces need to be aware of and support already given that some contracts already use it in the wild.
Neither could I when I went looking; the limit that they respect for 2309 is 5,000 just determined via testing. I think it’s incredibly unfortunate that 2309 itself doesn’t dictate any kind of limit on the number of tokens supported; 5,000 is an arbitrary and rather small range when compared to the “typical” drop of 10,000 in an NFT collection.
TL;DR I did a lot of recent research into supporting the situation caused by EIP-2309, am generally dissatisfied with it as an EIP, agree with @frangio on most of these points, and see option 1b as the only viable solution. That also means I see little value in this EIP beyond clarifying the 2309/721 relationship and maybe dictating a range limit on 2309.
@_Enoch thank you I think you bring up a very good point that ERC2309 without a proper limit provides an opportunity for flooding indexer’s account with very little gas cost.
The goal of this EIP-6047 is to mandate the event-emitting behavior for all EIP-6047 compliant contract. Like any EIP, this EIP will have no effect in any contract whose developer choose to not comply with this EIP.
Whether to require ConsecutiveTransfer or only require Transfer is a decision we need to make for EIP-6047.
I hear loud and clear from you that GigaMart supports ConsecutiveTransfer as well as Transfer and it’s one data point.
To re-iterate: we are choosing between the following options for 6047, and its consequence:
Transfer: then all indexers (regardless of adopting 2309 or not) are compatible with 6047, but 2309 contracts are incompatible with 6047Transfer and ConsecutiveTransfer: any indexers not adopting 2309 yet are incompatible with 6047, but all 2309 contracts are compatible with 6047