Etherless Ethereum Tokens: Simulating Native Tokens in Ethereum

By June 22, 2022DeFi
Click here to view original web page at


Standardized Ethereum tokens, e.g., ERC-20 tokens, have become the norm in fundraising (through ICOs) and kicking off blockchain-based DeFi applications. However, they require the user’s wallet to hold both tokens and ether to pay the gas fee for making a transaction. This makes for a cumbersome user experience, and complicates, from the user perspective, the process of transitioning to a different smart-contract enabled blockchain, or to a newly launched blockchain. We formalize, instantiate, and analyze in a composable manner a system that we call Etherless Ethereum Tokens (in short, EETs), which allows the token users to transact in a closed-economy manner, i.e., having only tokens on their wallet and paying any transaction fees in tokens rather than Ether/Gas. In the process, we devise a methodology for capturing Ethereum token-contracts in the Universal Composability (UC) framework, which can be of independent interest. Our system can be seen as a targeted instance of the more general paradigm put forth—without a formal study—by the Ethereum Gas Station Network (GSN). We have implemented and benchmarked our system and compared it to GSN. In addition to being the first system with a rigorous security analysis, we demonstrate that EETs are far easier to deploy and less gas intensive than the GSN.


  1. There are a number of legal issues regarding ICO’s—in particular, how to hold the token creator to his promise and how to avoid scamming attacks—and there are technological advances that allow us to circumvent them; these topics are outside the scope of this paper.

  2. We do not specify a model of computation for describing the VM; one can use any such model, e.g. Turing machines, RAMs, etc.

  3. It is easy to intialize the functionality with an arbitrary number of parties that hold an initial amount of coin. To simplify the description on the functionality, we decided to use only one party in this phase.

  4. As before, we could have multiple addresses having different amounts of tokens, but for simplicity, we assume that only one party initially holds tokens.

  5. The payload also includes an identifier chosen by the adversary, which we omit in this informal description.


  1. Andrews, J., Ciampi, M., Zikas, V.: Etherless ethereum tokens: Simulating native tokens in ethereum. Cryptology ePrint Archive, Report 2021/766 (2021).

  2. Badertscher, C., Gazi, P., Kiayias, A., Russell, A., Zikas, V.: Ouroboros genesis: composable proof-of-stake blockchains with dynamic availability. In: Lie, D., Mannan, M., Backes, M., Wang, X. (eds.) ACM CCS 2018, pp. 913–930. ACM Press (2018).

  3. Badertscher, C., Maurer, U., Tschudi, D., Zikas, V.: Bitcoin as a transaction ledger: a composable treatment. In: Katz, J., Shacham, H. (eds.) CRYPTO 2017, Part I. LNCS, vol. 10401, pp. 324–356. Springer, Heidelberg (2017).

  4. Canetti, R.: Universally composable security: a new paradigm for cryptographic protocols. In: 42nd FOCS, pp. 136–145. IEEE Computer Society Press (2001).

  5. Canetti, R.: Universally composable signatures, certification and authentication. Cryptology ePrint Archive, Report 2003/239 (2003).

  6. Chakravarty, M.M., Karayannidis, N., Kiayias, A., Jones, M.P., Vinogradova, P.: Babel fees via limited liabilities. arXiv preprint arXiv:2106.01161 (2021)

  7. Daian, P., Pass, R., Shi, E.: Snow white: robustly reconfigurable consensus and applications to provably secure proof of stake. In: Goldberg, I., Moore, T. (eds.) FC 2019. LNCS, vol. 11598, pp. 23–41. Springer, Heidelberg (2019).

  8. Garay, J.A., Kiayias, A., Leonardos, N.: The bitcoin backbone protocol: analysis and applications. In: Oswald, E., Fischlin, M. (eds.) EUROCRYPT 2015, Part II. LNCS, vol. 9057, pp. 281–310. Springer, Heidelberg (2015).

  9. Garay, J.A., Kiayias, A., Leonardos, N.: The bitcoin backbone protocol with chains of variable difficulty. In: Katz, J., Shacham, H. (eds.) CRYPTO 2017, Part I. LNCS, vol. 10401, pp. 291–323. Springer, Heidelberg (Aug 2017).

  10. Kerber, T., Kiayias, A., Kohlweiss, M.: KACHINA - foundations of private smart contracts. In: 34th IEEE Computer Security Foundations Symposium, CSF 2021, Dubrovnik, Croatia, 21–25 June 2021, pp. 1–16. IEEE (2021).

  11. Kerber, T., Kiayias, A., Kohlweiss, M., Zikas, V.: Ouroboros crypsinous: Privacy-preserving proof-of-stake. In: 2019 IEEE Symposium on Security and Privacy, SP 2019, San Francisco, CA, USA, 19–23 May 2019, pp. 157–174. IEEE (2019).

  12. Kiayias, A., Litos, O.S.T.: A composable security treatment of the lightning network. In: 33rd IEEE Computer Security Foundations Symposium, CSF 2020, Boston, MA, USA, 22–26 June 2020, pp. 334–349. IEEE (2020).,

  13. Pass, R., Seeman, L., Shelat, A.: Analysis of the blockchain protocol in asynchronous networks. In: Coron, J.S., Nielsen, J.B. (eds.) EUROCRYPT 2017, Part II. LNCS, vol. 10211, pp. 643–673. Springer, Heidelberg (2017).

  14. Pass, R., Shi, E.: The sleepy model of consensus. In: Takagi, T., Peyrin, T. (eds.) ASIACRYPT 2017, Part II. LNCS, vol. 10625, pp. 380–409. Springer, Heidelberg (2017).

  15. Seres, I.A.: On blockchain metatransactions. In: 2020 IEEE International Conference on Blockchain (Blockchain), pp. 178–187. IEEE (2020)

Author information

Authors and Affiliations

Corresponding author

Correspondence to Michele Ciampi .

Editor information

Editors and Affiliations

Our protocol is described in the -hybrid world, where is parametrized by , and the fee function f which, upon receiving an input transaction , does the following: 1) Parse as ; 2) if , then return ; 3) Otherwise, return . In a nutshell, the fee required for a transaction to settle in the ’s state is , plus and additional for each bits contained in the payload, where and are part of the description of f. We provide the formal description of our protocol in Fig. 2. At a very high level, the protocol works as follows: Each party registers with and runs to obtain , where represents the token wallet address. A party that wants to send to and has at least coins of type can do so by issuing a transaction for that contains in its payload , where is a random value, and is a signature of that verifies under the verification key . We require to pay a fee of at least because we assume that, in this case, . When an honest party receives the command , they shall retrieve ’s state, filter out the payload of each transaction (thus obtaining only the information related to token transactions), and output only the valid token transactions. A token transaction is valid if has received at least v tokens, is a signature of that verifies under the verification key , and there does not exist any other token transaction with the same sender address and identifier . Our protocol allows any party that does not have coins of type to delegate the payment of the fee to , paying with at least tokens . To do so, creates and signs it, thus obtaining . then sends to . The honest then creates a transaction for that includes in its payload and has a fee of at least , and submits it. We require to pay a fee of at least because we assume that, in this case, the payload of the transaction is bits (as, indeed, the payload of this type of transaction contains more information). The honest would immediately create and submit such a transaction, whereas the corrupted might decide when (and if) to create the transaction. We require each token transaction to contain a random identifier in order to avoid replay attacks; without such an identifier, the adversary could take the payload of any transaction from ’s state, (for instance, the payload of a transaction that moves v tokens from the address of an honest party to some potentially adversarial address,) copy this payload, and use it to generate a new transaction for . In this way, the adversary could empty the token wallet of the honest party without their knowledge. The other advantage of using identifiers is that an honest party that has delegated a transaction to a malicious intermediary can at any point decide to withdraw the delegation. Indeed, if is not responding to a party that has delegated the transaction for a long time, and m does not appear in the payload of any transaction that appears in the ledger’s state, then can withdraw the delegation by submitting (or delegating) a token transaction with the same identifier; then, at most one of these transactions will be valid and accepted by the functionality. We refer to Fig. 2 for the formal description of .

Fig. 2.
figure 2

About this paper

Andrews, J., Ciampi, M., Zikas, V. (2022). Etherless Ethereum Tokens: Simulating Native Tokens in Ethereum. In: Dolev, S., Katz, J., Meisels, A. (eds) Cyber Security, Cryptology, and Machine Learning. CSCML 2022. Lecture Notes in Computer Science, vol 13301. Springer, Cham.

Download citation

All Today's Crypto News In One Place