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

* adding backwards compatibility, implemenation, update username

* draft + backwards compatibility

EIPS/eip-2309.md

@@ -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.-->