Ethereum Payable Token and how it works

The story of the ERC1363's birth

Each of you have surely already heard of ERC20 tokens.
In this article I will discuss how they could be used for real life payments and why I’m building the ERC1363 Payable Token.
Here you can find the ERC1363 EIP and implementation.

What are ERC20 tokens?

As EIP 20 says:

ERC20 provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party.

So basically you can use tokens to represent any fungible tradable good: coins, loyalty points, in-game points, etc.

Here the standard ERC20 definition:

ERC20 interface definition

Here a basic implementation of thetransfer function.

ERC20 transfer implementation

And below a basic implementation of the approve and transferFrom functions.

ERC20 Approve workflow implementation

Token Balances

So, as you can see, balances is not more than a mapping between tokens holder address and its amount of tokens.

For example, assume that a token contract has two token holders:

• 0x111...111 with a balance of 100 units
• 0x222...222 with a balance of 200 units

The token contract’s balances data structure will contain the following informations:

balances[0x111...111] = 100
balances[0x222...222] = 200

The balanceOf(...) function will return the following values:

tokenContract.balanceOf(0x111...111); // will return 100
tokenContract.balanceOf(0x222...222); // will return 200

Transfer Token Balance

If 0x111...111 wants to transfer 10 tokens to 0x222...222, 0x111...111 will execute the function:

tokenContract.transfer(0x222...222, 10);

The token contract’s transfer(...) function will alter the balances data structure to contain the following informations:

balances[0x111...111] = 90
balances[0x222...222] = 210

The balanceOf(...) function will now return the following values:

tokenContract.balanceOf(0x111...111); // will return 90
tokenContract.balanceOf(0x222...222); // will return 210

Approve And TransferFrom Token Balance

approve(...) and transferFrom(...) are used when someone wants to authorise another address to spend tokens in its behalf.

Again, allowed is not more than a mapping between tokens holder address, spender address and the amount of tokens approved.

So, if 0x111...111 wants to authorise 0x222...222 to transfer some tokens (30), 0x111...111 will execute the function:

tokenContract.approve(0x222...222, 30);

The approve data structure will now contain the following information:

allowed[0x111...111][0x222...222] = 30

If 0x222...222 wants to later transfer some tokens (20) from 0x111...111 to 0x333...333, 0x222...222 executes the transferFrom(...) function:

tokenContract.transferFrom(0x111...111, 0x333...333, 20);

The balances data structure will be altered to contain the following information:

balances[0x111...111] = 70
balances[0x222...222] = 210
balances[0x333...333] = 20

And the allowed data structure will now contain the following information:

allowed[0x111...111][0x222...222] = 10

0x222...222 can still spend 10 tokens from 0x111...111.

The balanceOf(...) function will now return the following values:

tokenContract.balanceOf(0x111...111); // will return 70
tokenContract.balanceOf(0x222...222); // will return 210
tokenContract.balanceOf(0x333...333); // will return 20

What’s the issue?

All good but, what if token receiver wants to make an action after token received or after a token approval?

Imagine you are sending tokens to pay the ACME#1 invoice so the receiver contract should set your invoice as paid.
How it could be possible? Nobody is notifying nobody else that the contract has received tokens to pay the invoice number ACME#1.

Or imagine that you want your subscription enabled after you approved your tokens to be spent from the subscriptions’ manager contract.

Or imagine… everything else you can do in real life by paying something and having something else in return.

So, actually, solutions maybe:

• making an approve to the receiver contract and then make another transaction to a contract method to notify that you have just approved it to spent your tokens (this is in charge of user)

or

• you made your transaction and then the receiver contract’s system should “listen” for the Transfer or Approval event and make another transaction to close the circle (this is in charge of developers)

Anyway these solutions expect to be done in at least 2 transactions and it means double spending fee, double waiting time, lots of complexity and more.

And mostly, from my point of view as a Smart Contracts and DAPP developer, it means that I must set and maintain a GETH node with a nodejs service listening for any Transfer event coming from the token contract, call any callback on the receiver contract to set stuffs done, being updated on the gas costs to have my transactions done quickly and not to pay more gas than the received token value, and… oh oh oh… how many things.

So this is the reason because of I decided to build my own implementation of a payable token.

Nobody has already a solution?

Yeah, I Googled it lots of time, sure. Many people have already explored this problem and there are many other ERC and proposals that have been used by lots of tokens but, there is not a standard yet.

For instance you can use the approveAndCall method that approves and then call a callback on the receiver contract, or use the ERC677 that adds the transferAndCall method allowing to call a function on the receiver contract or the ERC223 that wants to do it into the standard transfer method.
Each of these require that a different callback function must be implemented on the receiver contract.

The birth of Payable Token was when I studied more the ERC721 or well known as Non-fungible or Collectible token.

ERC721 has been accepted and merged as a standard EIP, so it means that its approach could be extended for similar purposes.
It requires that ERC165 must be implemented to explore what interfaces are supported by the contract and “a wallet/broker/auction application MUST implement the wallet interface if it will accept safe ERC721 transfers” as described below.

ERC721 Token Receiver

What is an ERC1363 Payable Token?

It defines transferAndCall and transferFromAndCall functions that will call an onTransferReceived on a ERC1363Receiver contract.
It defines approveAndCall functions that will call an onApprovalReceived on a ERC1363Spendercontract.

By doing so, contracts can accept ERC-20 payments to create a token payable crowdsale, selling services for tokens, paying invoices, making subscriptions, or use them for a specific utility and many other purposes.

Sounds good?

Every Payable Token compliant contract MUST implement the ERC1363 interface other than ERC20 and ERC165 interfaces.

ERC1363 Interface

A contract that wants to accept token payments via transferAndCall or transferFromAndCall MUST implement the ERC1363Receiver interface:

ERC1363Receiver Interface

A contract that wants to accept token payments via approveAndCall MUST implement the ERC1363Spender interface:

ERC1363Spender Interface

Here there is my own implementation of an ERC1363 Token using the OpenZeppelin library.

vittominacori/erc1363-payable-token

Any suggestion will be appreciated so, please, comment on the official EIP or open an issue to my code implementation.

You can use it in your project by installing with npm:

npm install erc-payable-token

Follow Vittorio Minacori on GitHub, Twitter or LinkedIn.