status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-01-24 21:59:07 +00:00
Code Issues Projects Releases Wiki Activity

Eat my words, add the transfer function

Browse Source
This commit is contained in:
William Entriken 2018-02-16 03:02:03 -05:00 committed by GitHub
parent ddd2525792
commit 8743a2286c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
EIPS/eip-721.md
View File

@ -22,7 +22,7 @@ The scope of this interface includes **interrogating the smart contract about de
## Motivation ## Motivation
A standard interface allows wallet/broker/auctioneer applications to work with any deed on Ethereum. This contract considers simple deed contracts as well as contract that track large number of deeds. Additional applications are discussed below. A standard interface allows wallet/broker/auction applications to work with any deed on Ethereum. We provide for simple deed contracts as well as contracts that track a *large* number of deeds. Additional applications are discussed below.
This standard is inspired by [the ERC-20 token standard](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md) and builds on two years of experience since EIP-20 was created. EIP-20 is insufficient for tracking deed ownership because each deed is distinct (non-fungible) whereas each token is identical (fungible). This standard is inspired by [the ERC-20 token standard](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md) and builds on two years of experience since EIP-20 was created. EIP-20 is insufficient for tracking deed ownership because each deed is distinct (non-fungible) whereas each token is identical (fungible).
@ -127,6 +127,12 @@ interface ERC721 {
/// valid deed. /// valid deed.
/// @param _deedId The deed that is being transferred /// @param _deedId The deed that is being transferred
function takeOwnership(uint256 _deedId) external payable; function takeOwnership(uint256 _deedId) external payable;
/// @notice Set a new owner for your deed
/// @dev Throws if `msg.sender` does not own deed `_deedId` or if `_to` ==
/// `msg.sender` or if `_deedId` is not a valid deed.
/// @param _deedId The deed that is being transferred
function transfer(address _to, uint256 _deedId) external payable;
} }
``` ```
@ -241,15 +247,13 @@ The basis of this standard is that every deed is identified by a unique 256-bit
ERC-721 standardizes a two-step process for transferring deeds inspired from [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md). This requires the sender to approve sending and the receiver to accept approval. In the original ERC-20, this caused a problem when `allowance` was called and then later modified to a different amount, as [disucssed on OpenZeppelin](https://github.com/OpenZeppelin/zeppelin-solidity/issues/438). In this deed standard, there is no allowance because every deed is unique, the quantity is none or one. Therefore we receive the benefits of ERC-20's original design without problems that have been later discovered. ERC-721 standardizes a two-step process for transferring deeds inspired from [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md). This requires the sender to approve sending and the receiver to accept approval. In the original ERC-20, this caused a problem when `allowance` was called and then later modified to a different amount, as [disucssed on OpenZeppelin](https://github.com/OpenZeppelin/zeppelin-solidity/issues/438). In this deed standard, there is no allowance because every deed is unique, the quantity is none or one. Therefore we receive the benefits of ERC-20's original design without problems that have been later discovered.
With two years experience, we have found that the one-step `transfer(address _to, uint256 _value)` is undesirable. This is because it is very simple to accidentally send property to an address that cannot use it, as discussed in [ERC-233](https://github.com/ethereum/EIPs/issues/223) and [ERC-677](https://github.com/ethereum/EIPs/issues/677). A careful reading of this standard's `approve`, `takeOwnership` and `transfer` functions also shows that *any* business reason may be used to deny transactions. Failed transactions will throw, a best practice identified in [ERC-233](https://github.com/ethereum/EIPs/issues/223) , [ERC-677](https://github.com/ethereum/EIPs/issues/677), [ERC-827](https://github.com/ethereum/EIPs/issues/827) and [OpenZeppelin](https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/ERC20/SafeERC20.sol). Use of the `transfer` function is controversial and is discussed in [ERC-233](https://github.com/ethereum/EIPs/issues/223) and [ERC-677](https://github.com/ethereum/EIPs/issues/677), but we take the position that misuse of the `transfer` function is an implementation mistake not a standards mistake.
A careful reading of this standard's `approve` and `takeOwnership` functions also shows that *any* business reason may be used to deny transactions. Failed transactions will throw, a best practice identified in [ERC-233](https://github.com/ethereum/EIPs/issues/223) , [ERC-677](https://github.com/ethereum/EIPs/issues/677), [ERC-827](https://github.com/ethereum/EIPs/issues/827) and [OpenZeppelin](https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/ERC20/SafeERC20.sol).
Creating of new deeds and destruction of deeds is not included in the specification. Your implementing contract may implement these by other means. Please see the `event` documentation for your responsibilities when creating or destroying deeds. Creating of new deeds and destruction of deeds is not included in the specification. Your implementing contract may implement these by other means. Please see the `event` documentation for your responsibilities when creating or destroying deeds.
**Function mutability** **Function mutability**
The transfer functions `approve` and `takeOwnership` are payable. Yes, really. The standard contemplates a real estate ownership application where transfer of property will require paying tax and/or various fees (including, but not limited to mining fees and pre-set transference fees), which may be paid by the old and/or new owner in any pre-arranged amount. Such an application would be compliant under this specification. Note that your contract may be nonpayable (syntactic sugar for `require(msg.value == 0)`) and be compliant, see caveats. The transfer functions `approve`, `takeOwnership` and `transfer` are payable. Yes, really. The standard contemplates a real estate ownership application where transfer of property will require paying tax and/or various fees (including, but not limited to mining fees and pre-set transference fees), which may be paid by the old and/or new owner in any pre-arranged amount. Such an application would be compliant under this specification. Note that your contract may be nonpayable (syntactic sugar for `require(msg.value == 0)`) and be compliant, see caveats.
**Supports interface** **Supports interface**