-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERC1412: Batch Transfers For Non-Fungible Tokens #1412
Comments
Does this really need to be a part of the token contract itself? It's already possible to batch token transfers via contracts that are approved operators, and those would be usable with ERC721 tokens that predate this standard. Additionally, separate contracts could potentially batch tokens from multiple ERC721 contracts in a single transaction. This might be able to save a little bit of gas over using a separate contract, but it doesn't seem significant enough to justify complicating the token contract when it can be done almost as efficiently on a separate contract. |
@AusIV Thank you for taking a look at this standard and considering it. It does not need to be a part of the token contract itself. Contract programmers are free to implement this standard or not. Implementing this standard does not prevent third-party contracts from doing batch transfers. Someone could implement this standard and still have third-party contracts do batch transfers. Implementing batch transfers in the token contract just solves certain problems and makes some things easier/better and saves gas. I do not claim that this standard is appropriate for all NFT contracts, just that I think it is appropriate for enough to be useful. If you don't want batch transfer functions complicating your NFT contract then they will complicate your third-party contract or wherever they end up. I don't know what complication you are thinking about. The complication depends on your contract and contract design. For some contracts and contract designs the complexity of adding 2 batch transfer functions is minimal and not an issue. Here are problems solved by having batch transfers in the token contract:
Here are things that are made better:
Gas savings of batch transfer functions implemented in an NFT contract:
|
I am still not satisfied with the quality of data being presented to argue that this approach will save (a meaningful amount of) gas. Quick math: SSTORE = 20,000 gas or 5,000 gas or Gas used to transfer one token = TX overhead + permission check + actual transfer
I would like to see concretely the gas costs of using multiple transfers versus the proposed batch function. |
This proposal does batch transfers only from A to B. This could be enhanced to do batch transfers from A to n. Either by _to being an array of equal size then tokenIds or using structs as an input parameter(ABIEncoderV2). |
@MoMannn - If _to becomes an array, you're paying and additional 1360 gas per transferred item to designate its recipient (68 gas per byte of input data, times 20 bytes per address). That's fine if you want to send to a bunch of different recipients, but eats away at about 70% of the gas savings of this EIP if you want to send a bunch of items to the same recipient. This brings me back to my point about just delegating batch transfers to another contract. What people want to get out of batch transfers isn't going to be consistent, and there are going to be tradeoffs of each approach. Trying to bake all of those possibilities into the token contract is going to create a lot of complexity and room for error, just to save a bit of gas on something that could already be handled pretty efficiently through purpose built contracts. If the argument is that those contracts don't exist, go build them. |
@AusIV My argument is that if we are talking about standardizing batch transfers we should think more broadly then just transfer a to b. Plus I don't think that gas cost should be the driving force for standardization. Otherwise I agree that delegation of batch transfers to another contract Is sufficient. |
Not sure if this needs to be a standard but its a good add on in my opinion. I need this function for my contract. |
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
You know without actually seeing this EIP, I recreated it. Personally think it's a good Idea. |
why that fuction is payable we just need to send gass |
Payable functions leave open the possibility of extensions that might need the functionality that it offers. |
eip: 1412
title: Batch Transfers For Non-Fungible Tokens
author: Nick Mudge nick@mokens.io
status: Draft
type: Standards Track
category: ERC
created: 2018-09-15
requires: ERC721
Simple Summary
An extension of the ERC721 standard that provides batch transfer functions.
Abstract
Adds batch transfer functions for ERC721 non-fungible tokens.
Motivation
Transferring multiple ERC721 tokens requires multiple transactions, which is inconvenient and uses more gas than necessary.
This standard solves this without replacing the ERC721 standard.
In some cases the gas savings that is possible with batch transfers is huge.
Specification
safeBatchTransferFrom(address _from, address _to, uint256[] _tokenIds, bytes _data)
must implement the same functionality assafeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data)
from the ERC721 standard but for multiple NFTs.safeBatchTransferFrom(address _from, address _to, uint256[] _tokenIds)
must implement the same functionality assafeTransferFrom(address _from, address _to, uint256 _tokenId)
from the ERC721 standard but for multiple NFTs.Rationale
This standard solves the problem of needing or wanting batch transfers without replacing the ERC721 standard which is widely adopted.
You will notice that there is no
batchApprove
function in this standard. The reason is because ERC721 already provides thesetApprovalForAll
function which is a form of batch approve and suffices.A non-safe/unsafe batch transfer function is not needed.
Backwards Compatibility
This standard is compatible with the ERC721 standard.
Implementing this standard does not prevent third-party contracts from making batch transfers.
Copyright
Copyright and related rights waived via CC0.
The text was updated successfully, but these errors were encountered: