HomeEIPs
EIPsERC-6997
ERC-6997

ERC-721 with transaction validation step.

A new validation step for transfer and approve calls, achieving a security step in case of stolen wallet.
ReviewStandards Track: ERC
Created: 2023-05-07
Requires: EIP-721
Eduard López i Fina (@eduardfina)
DiscussionsOriginal linkEdit
1 min read

The ERC-6997 proposal is an extension of ERC-721 that adds a new validation step for transfer and approve calls to prevent wallet draining and NFT theft. This validation step would require a validator address to approve transactions, which would make it more difficult for thieves to steal NFTs. The proposal also includes specifications for implementing this validation functionality and emphasizes the importance of security in protecting against unauthorized validation. Additionally, the proposal acknowledges the evolving use cases for NFTs, particularly in the realm of digital art, and suggests creating a concise standard for art to make it easier for artists to maintain a connection with the Ethereum blockchain and their fans. This standard would allow for the designation of original NFTs and printed editions with signatures in a trustless manner, creating a link between the NFT, digital art, owner, and artist. ERC-721 compliant contracts may implement this ERC for editions to provide a standard method for designating the original and limited-edition prints with signatures from the artist.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

This standard is an extension of ERC-721. It defines new validation functionality to avoid wallet draining: every transfer or approve will be locked waiting for validation.

Motivation

The power of the blockchain is at the same time its weakness: giving the user full responsibility for their data.

Many cases of NFT theft currently exist, and current NFT anti-theft schemes, such as transferring NFTs to cold wallets, make NFTs inconvenient to use.

Having a validation step before every transfer and approve would give Smart Contract developers the opportunity to create secure NFT anti-theft schemes.

An implementation example would be a system where a validator address is responsible for validating all Smart Contract transactions.

This address would be connected to a dApp where the user could see the validation requests of his NFTs and accept the correct ones.

Giving this address only the power to validate transactions would make a much more secure system where to steal an NFT the thief would have to have both the user's address and the validator address simultaneously.

Specification

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

ERC-721 compliant contracts MAY implement this EIP.

All the operations that change the ownership of an NFT, like a transferFrom/safeTransferFrom, SHALL create a TransferValidation pending to be validated and emit a ValidateTransfer, and SHALL NOT transfer the ownership of an NFT.

All the operations that enable an approval to manage an NFT, like an approve/setApprovalForAll, SHALL create an ApprovalValidation pending to be validated and emit a ValidateApproval, and SHALL NOT enable an approval.

When the transfer is called by an approved account and not the owner, it MUST be executed directly without the need for validation. This is in order to adapt to all current marketplaces that require approve to directly move your NFTs.

When validating a TransferValidation or ApprovalValidation the valid field MUST be set to true and MUST NOT be validated again.

The operations that validate a TransferValidation SHALL change the ownership of the NFT or enable the approval.

The operations that validate an ApprovalValidation SHALL enable the approval.

Contract Interface

interface IERC6997 { struct TransferValidation { // The address of the owner. address from; // The address of the receiver. address to; // The token Id. uint256 tokenId; // Whether is a valid transfer. bool valid; } struct ApprovalValidation { // The address of the owner. address owner; // The approved address. address approve; // The token Id. uint256 tokenId; // Wether is a total approvement. bool approveAll; // Whether is a valid approve. bool valid; } /** * @dev Emitted when a new transfer validation has been requested. */ event ValidateTransfer(address indexed from, address to, uint256 indexed tokenId, uint256 indexed transferValidationId); /** * @dev Emitted when a new approval validation has been requested. */ event ValidateApproval(address indexed owner, address approve, uint256 tokenId, bool indexed approveAll, uint256 indexed approvalValidationId); /** * @dev Returns true if this contract is a validator ERC721. */ function isValidatorContract() external view returns (bool); /** * @dev Returns the transfer validation struct using the transfer ID. * */ function transferValidation(uint256 transferId) external view returns (TransferValidation memory); /** * @dev Returns the approval validation struct using the approval ID. * */ function approvalValidation(uint256 approvalId) external view returns (ApprovalValidation memory); /** * @dev Return the total amount of transfer validations created. * */ function totalTransferValidations() external view returns (uint256); /** * @dev Return the total amount of transfer validations created. * */ function totalApprovalValidations() external view returns (uint256); }

The isValidatorContract() function MUST be implemented as public.

The transferValidation(uint256 transferId) function MAY be implemented as public or external.

The approvalValidation(uint256 approveId) function MAY be implemented as public or external.

The totalTransferValidations() function MAY be implemented as pure or view.

The totalApprovalValidations() function MAY be implemented as pure or view.

Rationale

Universality

The standard only defines the validation functions, but not how they should be used. It defines the validations as internal and lets the user decide how to manage them.

An example could be to have an address validator connected to a dApp so that users could manage their validations.

This validator could be used for all NFTs or only for some users.

It could also be used as a wrapped Smart Contract for existing ERC-721, allowing 1/1 conversion with existing NFTs.

Extensibility

This standard only defines the validation function, but does not define the system with which it has to be validated. A third-party protocol can define how it wants to call these functions as it wishes.

Backwards Compatibility

This standard is an extension of ERC-721, compatible with all the operations except transferFrom/safeTransferFrom/approve/setApprovalForAll.

This operations will be overridden to create a validation petition instead of transfer ownership of an NFT or enable an approval.

Reference Implementation

// SPDX-License-Identifier: CC0-1.0 pragma solidity ^0.8.0; import "./IERC6997.sol"; import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; /** * @dev Implementation of ERC6997 */ contract ERC6997 is IERC6997, ERC721 { // Mapping from transfer ID to transfer validation mapping(uint256 => TransferValidation) private _transferValidations; // Mapping from approval ID to approval validation mapping(uint256 => ApprovalValidation) private _approvalValidations; // Total number of transfer validations uint256 private _totalTransferValidations; // Total number of approval validations uint256 private _totalApprovalValidations; /** * @dev Initializes the contract by setting a `name` and a `symbol` to the token collection. */ constructor(string memory name_, string memory symbol_) ERC721(name_, symbol_){ } /** * @dev Returns true if this contract is a validator ERC721. */ function isValidatorContract() public pure returns (bool) { return true; } /** * @dev Returns the transfer validation struct using the transfer ID. * */ function transferValidation(uint256 transferId) public view override returns (TransferValidation memory) { require(transferId < _totalTransferValidations, "ERC6997: invalid transfer ID"); TransferValidation memory v = _transferValidation(transferId); return v; } /** * @dev Returns the approval validation struct using the approval ID. * */ function approvalValidation(uint256 approvalId) public view override returns (ApprovalValidation memory) { require(approvalId < _totalApprovalValidations, "ERC6997: invalid approval ID"); ApprovalValidation memory v = _approvalValidation(approvalId); return v; } /** * @dev Return the total amount of transfer validations created. * */ function totalTransferValidations() public view override returns (uint256) { return _totalTransferValidations; } /** * @dev Return the total amount of approval validations created. * */ function totalApprovalValidations() public view override returns (uint256) { return _totalApprovalValidations; } /** * @dev Returns the transfer validation of the `transferId`. Does NOT revert if transfer doesn't exist */ function _transferValidation(uint256 transferId) internal view virtual returns (TransferValidation memory) { return _transferValidations[transferId]; } /** * @dev Returns the approval validation of the `approvalId`. Does NOT revert if transfer doesn't exist */ function _approvalValidation(uint256 approvalId) internal view virtual returns (ApprovalValidation memory) { return _approvalValidations[approvalId]; } /** * @dev Validate the transfer using the transfer ID. * */ function _validateTransfer(uint256 transferId) internal virtual { TransferValidation memory v = transferValidation(transferId); require(!v.valid, "ERC6997: the transfer is already validated"); address from = v.from; address to = v.to; uint256 tokenId = v.tokenId; super._transfer(from, to, tokenId); _transferValidations[transferId].valid = true; } /** * @dev Validate the approval using the approval ID. * */ function _validateApproval(uint256 approvalId) internal virtual { ApprovalValidation memory v = approvalValidation(approvalId); require(!v.valid, "ERC6997: the approval is already validated"); if(!v.approveAll) { require(v.owner == ownerOf(v.tokenId), "ERC6997: The token have a new owner"); super._approve(v.approve, v.tokenId); } else { super._setApprovalForAll(v.owner, v.approve, true); } _approvalValidations[approvalId].valid = true; } /** * @dev Create a transfer petition of `tokenId` from `from` to `to`. * * Requirements: * * - `to` cannot be the zero address. * - `tokenId` token must be owned by `from`. * * Emits a {TransferValidate} event. */ function _transfer( address from, address to, uint256 tokenId ) internal virtual override { require(ERC721.ownerOf(tokenId) == from, "ERC6997: transfer from incorrect owner"); require(to != address(0), "ERC6997: transfer to the zero address"); if(_msgSender() == from) { TransferValidation memory v; v.from = from; v.to = to; v.tokenId = tokenId; _transferValidations[_totalTransferValidations] = v; emit ValidateTransfer(from, to, tokenId, _totalTransferValidations); _totalTransferValidations++; } else { super._transfer(from, to, tokenId); } } /** * @dev Create an approval petition from `to` to operate on `tokenId` * * Emits an {ValidateApproval} event. */ function _approve(address to, uint256 tokenId) internal override virtual { ApprovalValidation memory v; v.owner = ownerOf(tokenId); v.approve = to; v.tokenId = tokenId; _approvalValidations[_totalApprovalValidations] = v; emit ValidateApproval(v.owner, to, tokenId, false, _totalApprovalValidations); _totalApprovalValidations++; } /** * @dev If approved is true create an approval petition from `operator` to operate on * all of `owner` tokens, if not remove `operator` from operate on all of `owner` tokens * * Emits an {ValidateApproval} event. */ function _setApprovalForAll( address owner, address operator, bool approved ) internal override virtual { require(owner != operator, "ERC6997: approve to caller"); if(approved) { ApprovalValidation memory v; v.owner = owner; v.approve = operator; v.approveAll = true; _approvalValidations[_totalApprovalValidations] = v; emit ValidateApproval(v.owner, operator, 0, true, _totalApprovalValidations); _totalApprovalValidations++; } else { super._setApprovalForAll(owner, operator, approved); } } }

Security Considerations

As is defined in the Specification the operations that change the ownership of an NFT or enable an approval to manage the NFT SHALL create a TransferValidation or an ApprovalValidation pending to be validated and SHALL NOT transfer the ownership of an NFT or enable an approval.

With this premise in mind, the operations in charge of validating a TransferValidation or an ApprovalValidation must be protected with the maximum security required by the applied system.

For example, a valid system would be one where there is a validator address in charge of validating the transactions.

To give another example, a system where each user could choose his validator address would also be correct.

In any case, the importance of security resides in the fact that no address can validate a TransferValidation or an ApprovalValidation without the permission of the chosen system.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve EIP builders, scale Ethereum.
Resources
GitHub
Supported by