Skip to content

Commit

Permalink
Update ERC-7631: Grammar updates
Browse files Browse the repository at this point in the history
Merged by EIP-Bot.
  • Loading branch information
cygaar authored Mar 29, 2024
1 parent 7ba10d7 commit adacb1d
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions ERCS/erc-7631.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,17 +13,17 @@ requires: 20, 721

## Abstract

A fungible [ERC-20](./eip-20.md) token contract and non-fungible [ERC-721](./eip-721.md) token contract can be interlinked, allowing actions performed on one contract to be reflected on the other. This proposal defines how the relationship between the two token contracts can be queried. It also enables accounts to configure if ERC-721 mints and transfers should be skipped during ERC-20 to ERC-721 synchronization.
A fungible [ERC-20](./eip-20.md) token contract and non-fungible [ERC-721](./eip-721.md) token contract can be interlinked, allowing actions performed on one contract to be reflected on the other. This proposal defines how the relationship between the two token contracts can be queried. It also enables accounts to configure whether ERC-721 mints and transfers should be skipped during ERC-20 to ERC-721 synchronization.

## Motivation

The ERC-20 fungible and ERC-721 non-fungible token standards offer sufficient flexibility for a co-joined, dual nature token pair. Transfers on the ERC-20 token can automatically trigger transfers on the ERC-721 token, and vice-versa. This enables applications such as native ERC-721 fractionalization, wherein purchasing ERC-20 tokens leads to the automatic issuance of ERC-721 tokens, proportional to the ERC-20 holdings.
The ERC-20 fungible and ERC-721 non-fungible token standards offer sufficient flexibility for a co-joined, dual nature token pair. Transfers on the ERC-20 token can automatically trigger transfers on the ERC-721 token, and vice-versa. This enables applications such as native ERC-721 fractionalization, wherein acquiring ERC-20 tokens leads to the automatic issuance of ERC-721 tokens, proportional to the ERC-20 balance.

Dual nature token pairs maintain full compliance with both ERC-20 and ERC-721 token standards. This proposal aims to enhance the functionality of dual nature token pairs.

To facilitate querying the relationship between the tokens, extension interfaces are proposed for the ERC-20 and ERC-721 tokens respectively. This enables various quality of life improvements such as allowing decentralized exchanges and NFT marketplaces to display the relationship between the tokens.

Additionally, users can configure if they want to skip ERC-721 mints and transfers during ERC-20 to ERC-721 synchronization.
Additionally, users can configure whether they want to skip ERC-721 mints and transfers during ERC-20 to ERC-721 synchronization.

## Specification

Expand Down Expand Up @@ -116,7 +116,7 @@ interface IERC7631Mirror {

### Implementation Detection

The `mirrorERC721` and `baseERC20` methods returning non-zero addresses suffice to signal that the contracts implement the required interfaces. As such, [ERC-165](./eip-165.md) is not required.
The `mirrorERC721` and `baseERC20` methods returning non-zero addresses signal that the ERC-20 and ERC-721 contracts implement the required interfaces respectively. As such, [ERC-165](./eip-165.md) is not required.

The `getSkipNFT` and `setSkipNFT` methods MAY revert. As contracts compiled with Solidity or Vyper inherently revert on calls to undefined methods, a typical `IERC7631Base` implementation lacking explicit `getSkipNFT` and `setSkipNFT` definitions still complies with `IERC7631BaseNFTSkippable`.

Expand All @@ -134,7 +134,7 @@ This proposal does not cover the token synchronization logic. This is to leave f

### Linking Mechanism

The linking process omitted for flexibility purposes. Developers can use any desired mechanism (e.g. linking in constructor, initializer, or via custom admin-only public methods on the two contracts). The only restriction is that the pairing must be immutable once established (to simplify indexing logic).
The linking process is omitted for flexibility purposes. Developers can use any desired mechanism (e.g. linking in constructor, initializer, or via custom admin-only public methods on the two contracts). The only restriction is that the pairing must be immutable once established (to simplify indexing logic).

## Backwards Compatibility

Expand All @@ -152,7 +152,7 @@ For dual nature collections that offer ERC-721 tokens with differing rarity leve

### Out-of-gas Denial of Service

ERC-20 transfers can automatically trigger multiple ERC-721 tokens to be minted, transferred or burned. This can incur O(n) gas costs instead of the typical O(1) gas costs for ERC-20 tokens transfers. Logic for selecting ERC-721 token IDs can also incur additional gas costs. Synchronization logic must consider ERC-721 related gas costs to prevent out-of-gas denial of service issues.
Transferring ERC-20 tokens can automatically initiate the minting, transferring, or burning of multiple ERC-721 tokens. This can incur O(n) gas costs instead of the typical O(1) gas costs for ERC-20 tokens transfers. Logic for selecting ERC-721 token IDs can also incur additional gas costs. Synchronization logic must consider ERC-721 related gas costs to prevent out-of-gas denial of service issues.

## Copyright

Expand Down

0 comments on commit adacb1d

Please sign in to comment.