ERC-20 with transaction validation step. | Ethereum Improvement Proposals

Abstract

This standard is an extension of ERC-20. 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 Token theft currently exist, and current Token anti-theft schemes, such as transferring Tokens to cold wallets, make Tokens inconvenient to use.

Having a validation step before every transfer and approve would give Smart Contract developers the opportunity to create secure Token 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 Tokens and accept the correct ones.

Giving this address only the power to validate transactions would make a much more secure system where to steal a Token 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-20 compliant contracts MAY implement this EIP.

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

All the operations that enable an approval to manage a Token, like an approve, 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 projects that require approve to directly move your Tokens.

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

The operations that validate an ApprovalValidation SHALL enable the approval.

Contract Interface

interface IERC7144 {

    struct TransferValidation {
        // The address of the owner.
        address from;
        // The address of the receiver.
        address to;
        // The token amount.
        uint256 amount;
        // Whether is a valid transfer.
        bool valid;
    }

    struct ApprovalValidation {
        // The address of the owner.
        address owner;
        // The spender address.
        address spender;
        // The token amount approved.
        uint256 amount;
        // Whether is a valid approval.
        bool valid;
    }

    /**
     * @dev Emitted when a new transfer validation has been requested.
     */
    event ValidateTransfer(address indexed from, address indexed to, uint256 amount, uint256 indexed transferValidationId);

    /**
    * @dev Emitted when a new approval validation has been requested.
    */
    event ValidateApproval(address indexed owner, address indexed spender, uint256 amount, uint256 indexed approvalValidationId);

    /**
     * @dev Returns true if this contract is a validator ERC20.
     */
    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 Tokens or only for some users.

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

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-20, compatible with all the operations except transfer/transferFrom/approve.

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

Reference Implementation

// SPDX-License-Identifier: CC0-1.0

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "./IERC7144.sol";

/**
 * @dev Implementation of ERC7144
 */
contract ERC7144 is IERC7144, ERC20 {

    // 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_) ERC20(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, "ERC7144: 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, "ERC7144: 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, "ERC721V: the transfer is already validated");

        super._transfer(v.from, v.to, v.amount);

        _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, "ERC7144: the approval is already validated");

        super._approve(v.owner, v.spender, v.amount);

        _approvalValidations[approvalId].valid = true;
    }

    /**
     * @dev Create a transfer petition of `tokenId` from `from` to `to`.
     *
     * Requirements:
     *
     * - `from` cannot be the zero address.
     * - `to` cannot be the zero address.
     *
     * Emits a {ValidateTransfer} event.
     */
    function _transfer(
        address from,
        address to,
        uint256 amount
    ) internal virtual override {
        require(from != address(0), "ERC7144: transfer from the zero address");
        require(to != address(0), "ERC7144: transfer to the zero address");

        if(_msgSender() == from) {
            TransferValidation memory v;

            v.from = from;
            v.to = to;
            v.amount = amount;

            _transferValidations[_totalTransferValidations] = v;

            emit ValidateTransfer(from, to, amount, _totalTransferValidations);

            _totalTransferValidations++;
        } else {
            super._transfer(from, to, amount);
        }
    }

    /**
     * @dev Create an approval petition from `owner` to operate the `amount`
     *
     * Emits an {ValidateApproval} event.
     */
    function _approve(
        address owner,
        address spender,
        uint256 amount
    ) internal virtual override {
        require(owner != address(0), "ERC7144: approve from the zero address");
        require(spender != address(0), "ERC7144: approve to the zero address");

        ApprovalValidation memory v;

        v.owner = owner;
        v.spender = spender;
        v.amount = amount;

        _approvalValidations[_totalApprovalValidations] = v;

        emit ValidateApproval(v.owner, spender, amount, _totalApprovalValidations);

        _totalApprovalValidations++;
    }
}

Security Considerations

As is defined in the Specification the operations that change the ownership of Tokens or enable an approval to manage the Tokens SHALL create a TransferValidation or an ApprovalValidation pending to be validated and SHALL NOT transfer the Tokens 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.