Transfer Ethereum tokens without Ether — An ERC20 Improvement to Seriously Consider

Ethereum has been around for four years now. The platform that was to “Build Unstoppable Applications” quickly turned out to be a Token Manufacturing Plant which churns out Ethereum tokens for any conceivable idea, object or abstraction imaginable. From those that can be used for ‘Sin Forgiving’ (Jesus Coin) to those that are probably not meant for such use (SpankChain), the tokenization train is seeing more people get on board day by day. However, the train which everyone seems to miss is this one called adoption, also known as ‘getting real users to come on to your platform and do stuff with your highly valuable token’.

One of the primary reasons for the low adoption rate is the poor user experience and the high barrier to interaction that this ecosystem imposes on its users. Convincing investors to buy your ICO tokens is one thing; turning your ICO investors into daily users, or even attracting new users on to your platform is an entirely different ball game.

Token projects and dApps at large have had to compromise user experience in exchange for integrating Ethereum tokens on their platform. Having to deal with 15-second confirmation times, and the occasional failed transaction is not something most users (or for that matter even developers) are accustomed to handling. One scenario in particular where user experience for interacting with tokens takes a headshot is when users have to hold a balance of the native cryptocurrency the token was built on — in most cases that being Ether. Users need to hold an ether balance in their wallets, along with the token, to perform any form of transaction with that token, such as transfers or staking.

To oversimplify and remain in context — You need to hold a balance of both Ether and Jesus Coin for your sins to be forgiven or better, both Ether and Spank Token for receiving the host of exciting benefits that the SpankChain platform offers!

Regardless of the magnitude of excitement these tokens provide, that is still a tall order for attracting new users on to your platform, let alone retaining them.

So, how can we move to a model where tokens can be designed such that users need not hold ether?

The possible solution (and an ERC20 improvement) this article covers is called ERC865 with credits to its author Ludovic Galabru.

To keep it simple (the finer technical details are linked below) — it involves a bunch of functions added to the ERC20 model, which allows third parties (aka ‘delegates’) to execute transactions on behalf of the holder of the token. The delegate will pay the gas fees in ether in exchange for getting extra tokens from the holder. For such a model, custom wallets can be created such that token holders will not need to hold ether for making transfers. The wallet will simply forward all transfer transactions of its users to a delegate who would execute them. The step-by-step mechanics of making such transfers are given below.

For a scenario where Alice wishes to transfer 500 ERC865 Tokens to Bob

Step 1 and 2 demonstrating the collection of details and generation of signature on Alice’s wallet

1. Alice fills out details of her transfer on her wallet, including a fee of 10 ERC865 Token paid to the delegate who would execute her transaction
2. Her wallet makes her sign this transaction and generate a unique signature for this transfer. The details of this transaction and the signature are passed to a delegate off-chain (via API, Telegram or other means)
3. The delegate can choose and execute the signature (of his liking) which will verify the authenticity of the signature, check whether the signer has enough balance, and whether the details of the transfer are correct.
4. If all checks return positive, and the execution was successful, 500 ERC865 tokens will be transferred from Alice to Bob, and 10 ERC865 tokens from Alice to the delegate.

Step 3 and 4 demonstrating how a delegate can choose and confirm a signature from a delegation marketplace

Keeping the above four points fresh in mind, let’s move to a few FAQs which should clear the air about this standard.

Frequently Asked Questions

1. Who can be a delegate?

A. Delegates can be broadly classified into one of two entities —  (i) The owner or creator of the token who probably would have finished his ICO and is already sitting on a stockpile of ether(ii) An independently running marketplace where delegates can come forward and execute signatures of transactions whose tokens they would like to receive as fees.

2. Why should I trust this delegate?

A. Same reason why you would trust the entity who created the wallet in the first place.Decentralization purists would obviously throw tomatoes at this concept, but one should understand that there is no proposed model in this space that is truly decentralized. It is finding the ‘in-between’ that truly adds value.

3. Are transactions confirmed instantaneously?

A. Depends on who the delegate is. If the delegate is the token creator or their partner, one would expect them to have built the capability into their wallets to instantaneously handle delegated transactions. On the other hand, if the wallet is pushing transactions to a delegation marketplace, the transaction would only be confirmed when a delegate comes forward to execute the transaction signature in exchange for receiving those tokens as fees.

4. Can existing ERC-20 tokens be changed to support this ERC-865 capability?

A. If the ERC-20 token was coded such that they are upgradable (a practice which I heavily recommend to all solidity developers) then yes! Else no.

5. What is this transaction signature described in step-2?

A. Essentially a sequence of random characters which is unique to the signer. Any person who possesses the details of the transfer (sending and receiving addresses, the amount transferred and the delegate fee) can verify using the signature that the message was indeed signed by the sender.From the perspective of user experience, the wallet can be designed in such a manner, that senders will not need to have any knowledge about transaction signatures or their inner workings. It should look and feel like any normal transfer made with ether.

6. Can the delegate or any other party play foul by creating double-spends or transferring more fees to themselves?

A. No. There are a handful of checks built into ERC-865 which disallows the delegate from executing a signature twice or changing the fee. Only the details of the transfer signed by the sender can be executed.The only blurry aspect of transaction execution controlled by delegates is avoiding the execution of certain signatures because their tokens are not valuable or the fees are too low.

7. Is there any drawback to using this concept for my new token?

A. None as of yet. But if paying ether for transaction fee is a big issue you are bothered by, you might want to revisit a key decision you made previously — The choice of Blockchain. To some, this approach might feel like sticking a band-aid on Ethereum’s method of handling transaction fees where token holders (or in more technical words — those causing a change of state in the EVM) are charged the fee for gas, without any option to let someone else pay. However, this might be a very Ethereum specific problem as some of the newer, shinier Blockchains have built-in capabilities to handle this issue.

Opportunities

1. Security Tokens: Most people in the Blockchain space would agree that fully regulated security tokens is the next big use case for smart contracts. If Ethereum happens to be the platform of choice for these tokens, then a concept like the one described above would go a long way in streamlining integration and adoption. It would allow these tokens to be moved and exchanged among traders without any attachment to cryptocurrencies.
2. Stablecoins: A stablecoin implemented on the above concept would prove mighty useful for both token holders and delegates alike. A price stable Ethereum token which removes the need to hold ethers, would allow holders to move funds as seamlessly as most mobile and bank wallets (minus the drawback of having to pay the delegate, and the slightly longer confirmation times). On the other hand, delegates would find these tokens more valuable to collect fees, since they won’t have to face the roller-coaster, pump-and-dump excitement when it comes to token price.
3. All future tokens: Because why not? If you happen to own a fairly good amount of ether, better design a token where you can delegate transactions for your users. The tokens that you collect as fee could be issued back to your users in the form of a loyalty reward or better custom baked into your token economics.

Technical Reference

For my technical readers, I’ve written and coded some resources to get you started — Github: https://github.com/adilharis2001/ERC865DemoDemo: http://delegation.adilharis.com:8080/

If you wish to know more about this implementation or you happen to be in the market for a Blockchain expert for your project, book me for free, for a quick 30-minute online consulting session. I have a new initiative called Consult Me Live which will facilitate this.