Authorised Spender

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

An authorised third-party spender can spend a certain amount of tokens owned by the approver/buyer.

Context

In blockchain applications, buyers need to transfer tokens to sellers to buy products or services.

Problem

How can a buyer delegate a third party to pay on behalf of him/her?

Forces

  • Security – The approval process needs to be secure in case there is a dishonest delegate. For example, the delegate should be able to spend only within the approved allowance.
  • Complexity – It is usually difficult to delegate a third party to pay on behalf of token owners.

Solution

As seen in the figure, a token owner can approve a third-party user or a smart contract to transfer a certain number of tokens on his/her behalf. First, an approval step can be designed to allow the spenders to use a certain amount of tokens. For example, an approve method can be added to the token template contract with third-party spender address and allowance as parameters. Alternatively, an authorised spender and allowance can be specified on the token registry. Next, when the third party needs to perform a payment on behalf of the buyer, it can send a transaction to the token contract requesting tokens to be transferred from the buyer to the sellers updating the balance of both accounts. Simultaneously, approved balance needs to be updated.

Sequence diagram of authorised spender.

 

Benefits

  • Flexibility – Buyers can find a delegate to pay on their behalf within the allocated allowance.
  • Automation – The buyers can automate payments by relying on the approved third party to perform the payment.
  • Security – The tokens are transferred securely according to the conditions predefined in smart contracts.

Drawbacks

  • Cost – If a public blockchain is used, an additional cost is incurred to call the approval function.
  • Security – There might be a bug in the smart contract that results in unexpected transfers by the deligate (e.g., wrong address or spending beyond the allowance).

Related patterns

  • The token template and token registry patterns are needed to support setting an authorised spender and an allowance for the delegate to act on behalf of the buyer.

Known uses

  • Both ERC-20 and ERC-721 use an approve function to enable a third party or a smart contract to transfer up to a specified number of tokens.
  • Ethex supports setting a custom allowance for token trading to ensure the decentralised exchange cannot spend more than the allowance even if its smart contract is compromised.
  • Saturn Network offers an approve feature that allows users to submit a transaction to approve Saturn Network to trade tokens on their behalf.