status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 20:28:21 +00:00
Code Issues Projects Releases Wiki Activity

ERC-2309 Updating Username / Adding backwards compatibility (#2717)

Browse Source 
* adding backwards compatibility, implemenation, update username

* draft + backwards compatibility
This commit is contained in:
pizzarob 2020-07-17 03:16:10 -06:00 committed by GitHub
parent 9119a4f0a1
commit c8564c3ce0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
EIPS/eip-2309.md
View File

@ -1,7 +1,7 @@
---
eip: 2309
title: ERC-721 Consecutive Transfer Extension
author: Sean Papanikolas (@pizza-r0b)
author: Sean Papanikolas (@pizzarob)
discussions-to: https://github.com/ethereum/EIPs/issues/2309
status: Draft
type: Standards Track
@ -101,8 +101,7 @@ The `ConsecutiveTransfer` event can be used for a single token as well as many t
`emit ConsecutiveTransfer(1, 100000, from, address(0));`
---
When emitting the `ConsecutiveTransfer` event the `Transfer` event **MUST NOT** be emitted. This can lead to bugs and unnecessary complex logic for platforms using these events to track token ownership.
Contracts that implement the `ConsecutiveTransfer` event **MAY** still use the original `Transfer` event, however when emitting the `ConsecutiveTransfer` event the `Transfer` event **MUST NOT** be emitted. This can lead to bugs and unnecessary complex logic for platforms using these events to track token ownership.
## Rationale
@ -114,6 +113,14 @@ Take this example. I sell lemons and have a farm with 10,000 lemon trees and 1,0
With this extension I would be able to to mint my initial 10,000 lemon tree tokens in one transaction. I would be able to quickly and cheaply mint my additional 1,000 lemon tree tokens when a new batch is planted. I would then be able to transfer all of the 10,000+ lemon tree tokens to a special smart contract that keeps track of the selling and distribution of funds in one transaction all while adhering to a specified standard.
## Backwards Compatibility
This extension was written to allow for the smallest change possible to the original ERC-721 spec while still providing a mechanism to track the creation, transfer, and deletion of a massive amount of tokens. While it is a minimal change the effects on platforms that only use the original `Transfer` event to index token ownership would be severe. They would not be properly recording token ownership information that could be known by listening for the `ConsecutiveTransfer` event. For platforms that wish to support the `ConsecutiveTransfer` event it would be best to support both the original `Transfer` event and the `ConsecutiveTransfer` event to track token ownership.
## Implementation
[Cargo](https://cargo.build)
<!-- ## Implementation
<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->