Skip to content

Commit

Permalink
Fix more issues?
Browse files Browse the repository at this point in the history
  • Loading branch information
@Pandapip1
Pandapip1 authored Sep 2, 2023
1 parent 082da88 commit a655425
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions EIPS/eip-721.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -30,9 +30,9 @@ In general, all houses are distinct and no two kittens are alike. NFTs are *dist

A standard interface allows wallet/broker/auction applications to work with any NFT on Ethereum. We provide for simple non-fungible token smart contracts as well as contracts that track an *arbitrarily large* number of NFTs. Additional applications are discussed below.

This standard is inspired by the [ERC-20](./eip-20.md) token standard and builds on two years of experience since EIP-20 was created. EIP-20 is insufficient for tracking NFTs because each asset is distinct (non-fungible) whereas each of a quantity of tokens is identical (fungible).
This standard is inspired by the [ERC-20](./eip-20.md) token standard and builds on two years of experience since ERC-20 was created. ERC-20 is insufficient for tracking NFTs because each asset is distinct (non-fungible) whereas each of a quantity of tokens is identical (fungible).

Differences between this standard and EIP-20 are examined below.
Differences between this standard and ERC-20 are examined below.

## Specification

Expand Down Expand Up @@ -292,7 +292,7 @@ The transfer and accept functions' documentation only specify conditions when th
- **Charge a fee to both parties of a transaction** — require payment when calling `approve` with a non-zero `_approved` if it was previously the zero address, refund payment if calling `approve` with the zero address if it was previously a non-zero address, require payment when calling any transfer function, require transfer parameter `_to` to equal `msg.sender`, require transfer parameter `_to` to be the approved address for the NFT
- **Read only NFT registry** — always throw from `safeTransferFrom`, `transferFrom`, `approve` and `setApprovalForAll`

Failed transactions will throw, a best practice identified in ERC-223, ERC-677, ERC-827 and OpenZeppelin's implementation of SafeERC20.sol. ERC-20 defined an `allowance` feature, this caused a problem when called and then later modified to a different amount, as on OpenZeppelin issue \#438. In `ERC721`, there is no allowance because every NFT 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.
Failed transactions will throw, a best practice identified in ERC-223 and OpenZeppelin's implementation of SafeERC20.sol. ERC-20 defined an `allowance` feature, this caused a problem when called and then later modified to a different amount, as on OpenZeppelin issue \#438. In `ERC721`, there is no allowance because every NFT 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.

Check failure on line 295 in EIPS/eip-721.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

the first match of the given pattern must be a link 

error[markdown-link-first]: the first match of the given pattern must be a link
   --> EIPS/eip-721.md
    |
295 | Failed transactions will throw, a best practice identified in ERC-223 and OpenZeppelin's implementation of SafeERC20.sol. ERC-20 defined an `allowance` feature, this caused a problem when called and then later modified to a different amount, as on OpenZeppelin issue \#438. In `ERC721`, there is no allowance because every NFT 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.
    |
    = info: the pattern in question: `(?i)(?:eip|erc)-[0-9]+`
    = help: see https://ethereum.github.io/eipw/markdown-link-first/

Creation of NFTs ("minting") and destruction of NFTs ("burning") is not included in the specification. Your contract may implement these by other means. Please see the `event` documentation for your responsibilities when creating or destroying NFTs.

Expand Down Expand Up @@ -356,7 +356,7 @@ Example NFT implementations as of February 2018:

- CryptoKitties -- Compatible with an earlier version of this standard.
- CryptoPunks -- Partially ERC-20 compatible, but not easily generalizable because it includes auction functionality directly in the contract and uses function names that explicitly refer to the assets as "punks".
- Auctionhouse Asset Interface -- The author needed a generic interface for the Auctionhouse ÐApp (currently ice-boxed). His "Asset" contract is very simple, but is missing ERC-20 compatibility, `approve()` functionality, and metadata. This effort is referenced in the discussion for EIP-173.
- Auctionhouse Asset Interface -- The author needed a generic interface for the Auctionhouse ÐApp (currently ice-boxed). His "Asset" contract is very simple, but is missing ERC-20 compatibility, `approve()` functionality, and metadata. This effort is referenced in the discussion for [ERC-173](./eip-173.md).

Note: "Limited edition, collectible tokens" like Curio Cards and Rare Pepe are *not* distinguishable assets. They're actually a collection of individual fungible tokens, each of which is tracked by its own smart contract with its own total supply (which may be `1` in extreme cases).

Expand Down Expand Up @@ -394,7 +394,7 @@ XXXXERC721, by William Entriken -- a scalable example implementation
1. [ERC-20](./eip-20.md) Token Standard.
1. [ERC-165](./eip-165.md) Standard Interface Detection.
1. [ERC-173](./eip-173.md) Owned Standard.
1. [ERC-223](https://github.com/ethereum/EIPs/issues/223) Token Standard.
1. [ERC-223](./eip-223.md) Token Standard.

Check failure on line 397 in EIPS/eip-721.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

proposal `eip-223.md` is not stable enough for a `status` of `Final` 

error[markdown-link-status]: proposal `eip-223.md` is not stable enough for a `status` of `Final`
   --> EIPS/eip-721.md
    |
397 | 1. [ERC-223](./eip-223.md) Token Standard.
    |
    = help: because of this link, this proposal's `status` must be one of: `Draft`, `Last Call`, `Review`, `Stagnant`
    = help: see https://ethereum.github.io/eipw/markdown-link-status/
1. [ERC-677](https://github.com/ethereum/EIPs/issues/677) `transferAndCall` Token Standard.
1. [ERC-827](https://github.com/ethereum/EIPs/issues/827) Token Standard.
1. Ethereum Name Service (ENS). https://ens.domains
Expand Down

0 comments on commit a655425

Please sign in to comment.