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.
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.
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.
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.
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.
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.
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.
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.
Copyright and related rights waived via CC0.