[Phase-3][Binding] UIP-2: Adding EIP-2612 permit function to UBI

UIP: 2
title: Adding EIP-2612 permit function to UBI
author: @donosonaumczuk
status: Phase 3
created: 2021-08-27
conflicts with: None
languages: EN

Simple summary

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 permit and transferFrom, instead of the common two-transaction method.

The permit function is already integrated to UNI, AAVE, GRT and other well-known ERC-20 tokens.


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

Next steps

The ‘Signalling’ (Phase-2) was approved through this snapshot voting. A snapshot for voting ‘Binding’ (Phase-3) will be published soon.


Please, @ludovico, feel free to suggest any change that facilitates everyone to understand the details of this proposal, as you mention here.

After community reaches consensus about if this proposal is following the UIP guidelines, I will poceed by creating and publishing here the Phase-3 voting snapshot.

1 Like

EDIT: I thought I understood this proposal but now I’ve spoken with some humans at the PoH Gov channel and it seems the text is not clear enough.

Old message:
I don’t want to delay the vote, I believe it’s good enough to send it to Snapshot and any additional explanation/enquiries could be done in this same post.

Also I will vote yes to this.

Well, I went into the PoH Gov channel and talk with their members. Everything about UIP-2 was clear, as far as I understood, the confusion came from thinking that UIP-1 and UIP-2 were the same proposal.

Also, previous phases of the UIP-2 got good feedback. Signaling snapshot had a really good feedback too.

So, here I created the Phase-3 Binding snapshot voting. It’s running right now and finishes on Nov 11th (a little bit more than a week). Here is the link:

[Phase-3][Binding] UIP-2: Adding EIP-2612 permit function to UBI