Is there something similar to IERC2309 for non-consecutive batch transfers?

Support Contracts
1

The event within IERC2309.sol is useful for batch minting of consecutive tokenIds. However, I need something that can handle non-sequential tokenIds so that it can be extended outside of minting. For example, when Alice transfers tokenIds 2,3,6,10,12 to Bob using a batch transfer function, I'd like to be able to emit a single event summarizing that transfer, i.e:

event ConsecutiveTransferBatch(
    uint256[] indexed tokenIds,
    address indexed fromAddress,
    address indexed toAddress
);

Does something like this exist?

I did a quick test in Remix with the following code:

// SPDX-License-Identifier: MIT
pragma solidity >=0.8;

contract A {

    // Copied from IERC721.sol
    event Transfer(
        address indexed from,
        address indexed to,
        uint256 indexed tokenId
    );

    // Modified from IERC2309.sol, and made to look more like Transfer(...)
    event ConsecutiveTransferBatch(
        address indexed from,
        address indexed to,
        uint256[] indexed tokenIds
    );

    function transfer(uint256[] calldata tokenIds)
    public {
        uint256 _batchSize = tokenIds.length;
        for (uint256 i; i<_batchSize;) {
            emit Transfer(address(0), address(0), tokenIds[i]);
            unchecked {++i;}
        }
    }

    function transferConsecutive(uint256[] calldata tokenIds) 
    public {
        // Including the loop to get a more accurate cost difference
        uint256 _batchSize = tokenIds.length;
        for (uint256 i; i<_batchSize;) {            
            unchecked {++i;}
        }
        emit ConsecutiveTransferBatch(address(0), address(0), tokenIds);
    }
}

Results for the execution gas costs are as follows:

BatchSize | Transfer | ConsecutiveTransferBatch
1 | 2496 | 2578
2 | 4534 | 2633
5 | 10648 | 2798
10 | 20838 | 3073

So it's obvious the improvement could be extended to non-sequential transfers. I'm just not sure if anything like this exists somewhere? And if not, where is the best place to go about suggesting an update/improvement to the existing IERC2309 to handle non-sequential transfers?

2

There are many issues with this proposal.

If your purpose is efficiency, this kind of batch transfer will not achieve the same efficiency that ERC-2309 has. The reason is that you can represent a range of consecutive token ids succinctly by the pair (start, end), whereas when you have non-consecutive ids you need to list them all out. Emitting this event will be somewhat cheaper, but it will still be proportional to the number of tokens.

Note that in your example you used the indexed keyword on the array of token ids. This causes Solidity to hash the array of token ids and include only that hash in the event parameters. This is why your gas benchmarks show that the gas cost doesn't grow as much as the non-batched transfer. But you need to include the token ids in the event if you want off-chain observers to be able to keep track of token ownership. So you would need to remove the indexed keyword.

Additionally, ERC-2309 enables an implementation to use special purpose data structures in storage that can use very little storage to track token ownership of a consecutive batch. This efficiency gain is not possible with non-consecutive transfers either.

Note that your implementation is only emitting events, and is not dealing with the ownership data structures in storage.

Lastly, ERC-2309 is a Final EIP, this means that it can't be changed. You are able to propose another EIP though, but due to the problems I outlined I would not recommend doing that.