UIP: 2 title: Adding EIP-2612 permit function to UBI author: @donosonaumczuk status: Phase 3 created: 2021-08-27 conflicts with: None languages: EN
This change adds
permit function as defined at EIP-2612 allowing users to approve transfering their UBIs to another address (user or contract) in a gasless way.
When a user wants to transfer a specific amount of UBI to an address it must perform a
transfer transaction. Another way could be performing an
approve transaction allowing the recipient to pull some amount through a
transferFrom transaction (this last one is the common approach when depositing an ERC-20 to a smart contract).
These two methods of transfering UBI have one thing in common: they both requires UBI sender to perform a transaction. In consequence, requires UBI sender to have ETH to pay for that transaction.
This proposal allows transfering UBI in the second mentioned way but letting a third party to perform the approval through a
permit function, that requires a signature of the UBI holder to give consent about the operation, that could be executed by anyone.
In addition, this improves the UX when integrating UBI with other contract as, after signing the permit, UBIs could be deposited to the contract in a single transaction that performs
transferFrom, instead of the common two-transaction method.
The permit method signature is the following:
/** * @dev Approves, through a message signed by the `_owner`, `_spender` to spend `_value` tokens from `_owner`. * @param _owner The address of the token owner. * @param _spender The address of the spender. * @param _value The amount of tokens to approve. * @param _deadline The expiration time until which the signature will be considered valid. * @param _v The signature v value. * @param _r The signature r value. * @param _s The signature s value. */ function permit(address _owner, address _spender, uint256 _value, uint256 _deadline, uint8 _v, bytes32 _r, bytes32 _s) public;
A complete implementation of this proposal could be found at UBI repository, pull request #95.
The following tests cases had been added:
✓ require fail - permit signature expired ✓ happy path - permit increases allowance to expected value ✓ require fail - permit signature already used ✓ happy path - permit setting allowance to zero ✓ require fail - permit signature built with invalid nonce ✓ require fail - permit with owner as zero address ✓ happy path - permit called by a third party increases allowance to expected value
The ‘Signalling’ (Phase-2) was approved through this snapshot voting. A snapshot for voting ‘Binding’ (Phase-3) will be published soon.