Skip to content
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.

Sign up for GitHub

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

Jump to bottom

ERC-2309 Updating Username / Adding backwards compatibility #2717

Merged
merged 2 commits into from
Jul 17, 2020
Merged

ERC-2309 Updating Username / Adding backwards compatibility #2717

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4374f89
adding backwards compatibility, implemenation, update username
pizzarob Jun 12, 2020
0437f40
draft + backwards compatibility
pizzarob Jun 12, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 10 additions & 3 deletions EIPS/eip-2309.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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
Expand Down Expand Up @@ -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

Expand All @@ -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.-->
Expand Down