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

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

:us: EN

Note: This proposal came after @fnanni-0 opened an issue about this at UBI repository.

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.

Abstract

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.

Implementation

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

Future ideas

This idea of using EIP-712 for meta-transactions could be extended also for other UBI operations like creating the UIP-1 streams. So a user C could create a stream from user A to user B, as long as it has the EIP-712 signature of this operation signed by A.


:argentina: ES

Nota: Esta propuesta surgió luego de que @fnanni-0 abra un issue sobre esto en el repositorio de UBI.

Resumen simple

Este cambio agrega la función permit tal como está definida en el EIP-2612 permitiendo a los usuarios aprobar la transferencia de sus UBIs a otra address (usuario o contrato) sin utilizar gas.

Abstract

Cuando un usuario quiere transferir un monto específico de UBI a una address debe realizar una transacción de transfer. Otra manera podría ser realizando una transacción approve permitiendo al destinatario extraer cierto monto a través de una transacción transferFrom (este último es el método común a la hora de depositar un ERC-20 en un contrato inteligente).

Estas dos formas de transferir UBI tienen una cosa en común: ambas requieren que quien envía los UBIs realice una transacción. En consecuencia, requiere que quién envíe los UBIs tenga ETH para pagar esa transacción.

Esta propuesta permite transferir UBI de la seguna manera mencionada pero permitiendo a un tercero realizar la aprobación de extracción a través de la función permit, que requiere la firma del dueño del UBI para dar consentimiento de la operación, que podría ser ejecutada por cualquiera.

Además, esto mejora la UX cuando se integra UBI con otro contrato ya que, luego de firmar el permit, los UBIs podrían depositarse en el contrato en una sola transacción que ejecuta permit y transferFrom, en lugar de usar la manera clásica de dos transacciones.

La función permit ya está integrada a UNI, AAVE, GRT y otros tokens ERC-20 destacados.

Implementación

La firma del método permit es la siguiente:

  /**
  * @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;

Una implementación completa de esta propuesta puede ser encontrada en el repositorio de UBI, pull request #95.

Los siguientes tests cases han sido agregados:

✓ 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

Ideas a futuro

Esta idea de usar EIP-712 para meta-transacciones podría ser extendida también a otras operaciones sobre UBI, como la creación de streams que define el UIP-1. Entonces, un usuario C podría crear un stream desde el usuario A hacia el usuario B, siempre y cuando tenga la firma EIP-712 de dicha operación firmada por A.

6 Likes

I could only add two links. Here is the EIP-2612.

3 Likes

This is an excellent initiative. Will review code as soon as possible but it already looks really great from where I’m standing. Amazing contribution @donosonaumczuk

3 Likes

Love the Idea!
In fact, I was thinking about something like this for Posta. The funded postas feature is great, but it would be greater if the person making the Post Request could also offer some UBI for whoever funds the post.

This could be a great place to start using UBI as a means of exchange for a service (Funding a posta in this case).

4 Likes

Standard improvement which saves gas. Looks good.

4 Likes

As we talk today, permit would work for your use case if you use Posta contract as intermediary. Users must generate permit signatures to Posta contract address, then Posta contract could pull the tokens and transfer them to the poster. Probably a signature binding permit signature to a specific post content would be needed.

So I think we could keep this proposal as it is.

2 Likes

Looks like is time to go into Phase-2. I will create a Signaling snapshot for this proposal.

3 Likes