There are parts of the example implementation that diverge from the specification or are added functionality (e.g. the endContract, getContractAddress, myBalance functions). I think it might be good to keep the example contract as close to the spec as possible.

Also, it's possible to implement atomic swaps for tokens in a single transaction with contracts that exist above current ERC token so that we don't have to add this functionality to every token contract that gets deployed. Adding this is general purpose contract seems like a better approach than implementing it in every token contract (maintainability and cost reasons). Otherwise, we can keep changing the token spec to add arbitrary functionality.

Does this standard allow someone to store different ERC721 tokens in the same ERC875 token? I.e. Could I create an ERC875 token that holds a basket of assets such as stocks, bonds, real estate, all of which have are different NFAs?

@naterush Hi Nate, thanks for your comment! I added those functions in as boilerplate, they are not part of the ERC Spec by default I just wanted them in there in case I wanted to remove the contract later etc.

The getContractAddress() is needed in this spec as a protection against double spending (i.e. I could get you to sign a message for my contract and rebroadcast it on another contract, by adding this data in as well as a message like ERC875 etc this is not possible)

Yes, open to here the views of what people would like to change in this draft!

@cylon56 the token itself is a 256 bit unsigned int, you could represent multiple assets in the one variable via encoding but it depends how complete your info is. From my understanding this would not be the case for cryptokitties as each cat requires the full 256 bit number to be represented, however if you asset info is simple enough, you could represent multiple assets in one token index.

Why does this need to be a standard that competes with the proposed #721, #841 or #821? This looks more like a version of those same standards which ignores most of the improvements that have been made in each of them (based on community discussions) simply for the sake of adding additional transfer functionality.

This seems more like something that should be suggested as an optional extension interface for the existing standards proposals, rather than attempting to be its own entirely new proposal.

Hi @Nanolucas , Thanks for the feedback! I am open to have it be an extension or it's own standard or a standard that has proposed changes which are implemented. This is only meant as an initial draft and I am open to hearing suggestions to change it.

In #841 you can see the optional extensions ERC721Metadata and ERC721Enumerable, I think providing your proposal in that format as some sort of ERC721Trade would be much more logical.

That way, the base functionality of the NFT/deed/asset registry standard isn't something you have to worry about when your focus is on developing a standardised way to perform swaps or multiple transfers.

Edit: Accidentally referenced incorrect EIP

@Nanolucas, I guess you refer to ERC721Enumerable in #841.

A few years ago I was involved in a project by Sydney entrepreneur Nick Addison (now of Consensys Sydney) where we wanted to tokenise subway advertisement screens in batches of 5-minute. For example, someone can buy the 5-minutes ad of Sydney Townhall station LCD ad in a rush hour because it's his birthday, or because he believes it was undervalued. It failed for regulatory reasons but what I observed is that investors tend to buy and sell hours or days of advertisement together, moving 2000 tokens a time - each covers 5 minutes of one screen in one subway station. The technical learning is that transaction fee only increase a little (less than 10%) if you transact 200 tokens instead of 1 in one transaction because most of the fee goes to the update of state tree. So there definitely is an incentive to transfer them in one call, instead of calling an Enumerator and transfer each asset piecemeal by the identifiers returned from Enumerator. Furthermore, being able to specify a range is helpful for reducing blockchain size, since such batch movements are usually done in lots. If someone moves 2000 tokens, there is a good chance all of them are from the same subway station or same hour of all subway stations.

It turns out that the Sydney subway experiment was not one of a kind - there are in fact more business cases of batch NFT operations than there are for individual NFTs (collectables), as I learned by working on a blockchain architect role in Australia's largest bank. For example, RESIMAC regularly transfers thousands of loan titles to Westpac in one go and requires them to move in an atomic fashion. The thriving of the kittens did give an impression that NFT is usually traded one by one - all because real businesses haven't moved in.

That was just the argument why Enumerator is not the answer for a batch transaction. trade() was for a different reason though. I see reasons for ERC721Trade extension to be there in #841 as well as for having a version of trade() function to move assets in batch.

@colourful-land My reference to ERC721Enumerable was only as an example of an optional extension for the ERC721 base standard. I was suggesting that the non-base functionality of this proposal should be in the form of an ERC721Trade extension to ERC721 so that the base functionality doesn't have to be reproduced in a separate standard.

I was certainly not meaning to imply there was an existing useful method for batch transactions, since there isn't (as far as I'm aware).

With the delegation added to the current 721 standard shouldn't atomic swap be possible with the use of a proxy(the same way 0x project is doing it)?

@MoMannn yes, however this is an alternative implementation.

The proxy could either hold a key or hold a batch of signed orders and release them according to expiry, neither is fully trust-less but the attack vector is limited.

I think it is important that there should be a compatible method as following with-in ERC20 & ERC721:

function transfer( address to, uint valueOrTokenId) public returns (bool ok);

Otherwise, some existing contracts using "transfer" will not be able support ERC875, e.g.

function withdraw(address _token, uint _balanceOrTokenId) public {
        if (_token == 0x0) {
            target.transfer(this.balance);
            return;
        }

        ERC20ERC721 token = ERC20ERC721(_token);
        token.transfer(target, _balanceOrTokenId);
    }

@hackfisher are you suggesting containing two mapping variables with different balances types for compatibility with other ERC's like ERC20 and 721?

@James-Sangalli I was suggesting supporting the transfer cases of only one tokenId, this was proposed when I'm trying to design a contract can support future assets standards, but found that This ERC875 have different API with ERC721. I resolve that buy using more general methods, but by compatible with existing API, could gather more support from existing standards infrastructure.

@hackfisher I see what you mean however I don't think it makes much sense to have that even in erc721 when it is causing an inefficiency for no good reason (cannot transfer by bulk). Most of the gas cost usually comes from the transaction itself so I am not sure why it was decided that you could only do it one by one.

I am open to being corrected on my view however...

You can do bulk transfer in 721. But that would be an implementation-specific design.

I would be happy to standardize after we see some use in the wild.

@fulldecent yes but it should probably be included in the standard. We will be doing a ticketing project soon which requires such functionality and I am sure many others will as well.

Personally I think the time to discuss a standard is after your ticketing application is live and on mainnet and wallet wants to interface with it.

Right now your best bet is to launch with 721 include extension for the parts you want. 721 is extendable and two extensions are already provided.

Here is an example link that uses the standard: https://app.awallet.io/AJiWgGhh6nmmaj8IBoF06PAFESqLLHpQeoIjNQZTftbzkBzkhVw8h7dsVi3lK30zDQQHGJyJKGJavooHfyxh9ZNvcIAk4mzAO9fjjGmt8xyylxsnWdVfZr48rG1PHA==

Our protocol allows you to transfer and sell links via URL's like this. The parameters for the trade function can be parsed from this link and plugged into the trade function.

You can now easily create your own ERC875 token here: https://alpha-wallet.github.io/ERC875-token-factory/index

How the seller cancels a transaction?

@bianning I am not sure what you mean? Once a transaction has been executed you cannot stop it.

An order (constructed offline) will have an expiry timestamp

I have signed for the trade and disclosed the information, but I change my mind before someone transfer the trade. How can I withdraw it?

I have 3 question, please help me:
(1) trade(uint256 expiry,
uint256[] tokenIndices,
uint8 v,
bytes32 r,
bytes32 s)
A sample is given as 0, [3, 4], 27, "0x2C011885E2D8FF02F813A4CB83EC51E1BFD5A7848B3B3400AE746FB08ADCFBFB", "0x21E80BAD65535DA1D692B4CEE3E740CD3282CCDC0174D4CF1E2F70483A6F4EB2"
QUESTION: what the means of v, r, s ？

（2）What's the means of the code below in function trade() ?
inventory[msg.sender].push(inventory[seller][index]);

(3) How can I trigger "trade" function to get a success process in REMIX & MetaMask environment with Ropsten test net?

Hi @duncanwang

1. v r and s are simply the cryptographic signature split up into 3 parts
2. As the balance of non fungibles is stored as an array, the sellers elements are added to the senders array on success of the trade
3. I recommend you go here: https://github.com/alpha-wallet/ERC875-Example/blob/master/TradeImplementationExample.java and generate a signature, at the moment the contract is on rinkeby: https://rinkeby.etherscan.io/address/0xffab5ce7c012bc942f5ca0cd42c3c2e1ae5f0005 for which you can copy and paste the address into remix with the contract and call the trade function. Do you require it to be done on ropsten?

Bianning
I have signed for the trade and disclosed the information, but I change my mind before someone transfer the trade. How can I withdraw it?

You can “transfer”/purchase the token by yourselves before anyone else does.

How can I get some free ETH on rinkeby test net? Can you send 2 ETH to the address "0xB51Fa936B744CFEbAeD8DbB79d2060903e689F89" ?

@duncanwang sent you some test ether

I've received 2 ETH。Thank you very much, james.
As your proposal，I run trade function after my MetaMask connected to rinkeby network
.
How can I buy this ticket in chrome browser with MetaMASK, then?

Can ERC875 be used for shopping scenario ? For example, a custom buy many NFTs one times paying with ERC20 tokens. Or exists any other solution ？

@duncanwang You mean purchasing ERC875 non fungibles with ERC20 tokens rather than ether?

@James-Sangalli yes

@duncanwang this feature is not implemented as is and would be a bit tricky to do, but it is probably possible.

Closing as this has been merged. Further discussion can take place here: #1549 and in future PR's/issues

Closing as this has been merged. Further discussion can take place here: #1549 and in future PR's/issues

Pull requests cannot be nominated as a discussion URL.

👍 I think EIP875 is ready to be finalized, If someone has some changes they would like to suggest, we should discuss it now.

I believe ERC875 (this EIP) should be finalized, because there is not only commercial example (2018 world cup ticket trail), but also have ethereum developer's support, let's say HiBlock had run several workshop to promote ERC875.

If any further change, there should be an additional/extra patch for it.

I just added approve functionality to the spec as this is necessary for all token standards. Other than that I think it is ready to go.

I will review this at some point if it is still in last review by 2019-07-29.

But right now, this draft does not follow the required format for EIPs. See

https://github.com/ethereum/EIPs/blob/master/eip-X.md

Currently the largest weaknesses are

• Lack of implementations
• It keeps changing
• "Gas savings" is mentioned but there is no gas analysis
• It is very similar to another EIP but no attempt is made to address compatibility

Following is my review of ERC-875. This includes technical problems which warrant cancelling/extending this Last Call.

This EIP puts forth a standard but provided implementations are not provided

There should be a deployed implementation as a case for standardizing the interface. At current, no such implementation is presented where Ether has been spent and the product has been developed. It fails to demonstrate that the lead author has skin in the game.

It keeps changing

The standard has changed but the Last Call has not been cancelled.

"Gas savings" is mentioned but there is no gas analysis

A primary motivation for this EIP is to reduce gas costs

this is heavy on gas

but no analysis is provided to show that this proposed standard solves that problem.

It is very similar to another EIP but no attempt is made to address compatibility

This could clearly be implemented as an extension to ERC-721 or ERC-1155 but no such notes on backwards compatibility are addressed.

@fulldecent

Following is my review of ERC-875. This includes technical problems which warrant cancelling/extending this Last Call.

This EIP puts forth a standard but provided implementations are not provided

Implementation has (and has been for a long time) been provided here: https://github.com/AlphaWallet/ERC875-Example-Implementation

There should be a deployed implementation as a case for standardizing the interface. At current, no such implementation is presented where Ether has been spent and the product has been developed. It fails to demonstrate that the lead author has skin in the game.

We have many such tokens running in our own wallet and we supported atomic swap magic links natively in AlphaWallet. An example is our FIFA ticket experiment(where FIFA tickets were tokenised and held significant value (>1000USD), xDAI coin drop links (giving free xDAI to participants) and various tickets for events we have held.

Example magic link which supports ERC875: https://xdai.aw.app/AQAAAABc0rRfuU_5wI_lgMWiln2fYuVc3hb41s4HcpCXNwNvIMdK3fj8odeAhUIWgBJtmZnEvNaZlrOYSsB0esHHVaoIOFFyHFJXfmrM-1vzL6qLCYIAEhXUlWbozhw=

Our wallet also supports redeeming, selling and transferring such tokens and we even had a payment server to cover the transaction cost for cryptoless users and to prevent front running.

It keeps changing

The standard has changed but the Last Call has not been cancelled.

Our only major changes were from bytes32[] to uint256[] and adding the approve spec.

"Gas savings" is mentioned but there is no gas analysis

A primary motivation for this EIP is to reduce gas costs

this is heavy on gas

This conclusion was reached when ERC721 had just come out, back then it only supported transfers of one token at a time. This was much more gas heavy when a user wanted to transfer multiple tokens. It was and still is a pain to use erc721 in wallets because it is impossible to get the users full balance without a fully fledged service like OpenSea which indexes events.

but no analysis is provided to show that this proposed standard solves that problem.

It is very similar to another EIP but no attempt is made to address compatibility

This could clearly be implemented as an extension to ERC-721 or ERC-1155 but no such notes on backwards compatibility are addressed.

Extensions would be a good idea, agreed. For now we will mostly be using it as a showcase for some tokens but our wallet is agnostic on this front and we are building a powerful framework to add extra functionality to existing tokens (regardless of the spec). See TokenScript if you are interesting in taking a glimpse of what can be done with tokens :)

Thank you for your feedback!

Implementations

Glad to see this implementation. Please update the EIP draft to use the heading "Implementation" per https://github.com/ethereum/EIPs/blob/master/eip-template.md then add that implementation you have cited.

Changes to EIP specification

Fair enough. This item is resolved.

Gas savings

Regarding gas savings for batch. This is a technical decision. Please cite it in the rationale section including references to any prior discussion that you believe are relevant. ERC-1155 also provides batch transfers. The text of the new EIP should explain its technical decisions in the rationale section and make reference to ERC-721 and ERC-1155 if the intention is to present itself as superior in some respect. Doing the analysis to present an actual gas comparison to with multiple techniques (this draft EIP vs. 1155 vs. 721 multiple transactions vs 721 using a batch transfer agent) would be very helpful for your intended audience.

You also mentioned token balance under that heading, which I address in the next point.

Backwards compatibility

The decision to not provide backwards compatibility with ERC-721 or ERC-1155 is your decision to make. These points should be raised inside the EIP text under the backwards compatibility section and also the rationale section as required in https://github.com/ethereum/EIPs/blob/master/eip-template.md.

Your note regarding balance is not clear to me because ERC721Enumerable does provide the total supply onchain without the need of an offchain wallet.

Headings

Please adopt the other required headings as per https://github.com/ethereum/EIPs/blob/master/eip-template.md

• Summary -> simple summary
• Purpose -> Abstract
• Rinkby Example -> put somewhere else
• Motivation missing
• Optional functions -> should be part of specification, not its own heading
• Interface -> should be part of specification
• Rational missing
• Backwards Compatibility missing
• Test cases missing
• Example implementation -> Implementation

Can this last review be ended please and return to draft. It seems this does not have enough momentum to get to final directly at this time.

Requesting to please mark this as back to DRAFT status or ABANDONED.

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.