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