Unspoken limitations of programmable money on Ethereum and other blockchains

Besides contextual obstacles, current blockchain technologies have technical architectures that limit how creative we can be when designing large scale systems of cooperation such as monetary systems.

Unique IDs and prohibitive transaction costs limit innovative monetary architectures and the implementation of a wide array of governance systems.

I will avoid focusing on Bitcoin since its architecture is by design one of the most limiting ones and in it resides Bitcoin’s value, which is much more aligned to a type of commodity-money than to a form of social-contract-money. Since money is not just a commodity but is also a social contract, other platforms, like Ethereum for instance, have since added the ability for programmers to create their own programs (smart contracts) that live on-chain. These smart contracts are simply pieces of webware that perform one or more functions, hold data, and have their own specific immutable addresses on the Ethereum blockchain, meaning that anyone can find them and read them. Although this seems to unveil an endless world of possibilities, if we actually want to reimagine monetary systems and program money we will quickly meet strong design constraints.

The first of blockchain technical restrictions for designing monetary systems has to do with the cost of creating unique document IDs. Minting a digital coin with a unique ID requires running a smart-contract that writes that unique ID on the blockchain, and every time someone writes on the blockchain there’s a fee (gas fee) to be paid to the network validators (miners or stakeholders)¹. Moreover, there is also a gas fee to record a transaction between two wallets.

When Alice sent the money, 1.0042 ETH would be deducted from Alice’s account. Bob would be credited 1.0000 ETH. Miner would receive 0.0042 ETH.

So from a system design point of view, if a community would like to establish a rule on their monetary system saying that one coin could only be used three times, that coin would have to be as valuable as the gas paid to write on the blockchain four times (one to create a coin, and three transactions between wallets). Currently the most common way to generate a unique token is by minting an NFT (non-fungible token) which, by the time I’m writing this paragraph (March 2022), costs approximately 0.5€ per token on the cheapest of the big blockchains (Tezos) and 170.00€ on the leading one (Ethereum) — with immense variation due to the unpredictable cost of the consensus mechanism. Imagine if states would have to pay 0.5€ for each Euro printed.

Why is this a serious limitation to designing a better monetary system? Because among other things, it prevents monetary models from incorporating short currency life-cycles in their design. In all monetary systems, money is created, used, and destroyed. Money designers might need to program the monetary life-cycle to create mechanisms to control inflation and deflation. Today, most, if not all, cryptocurrencies are fungible (no unique IDs) because it is currently too expensive to put a serial number on a crypto coin. Pre-programmed life-cycles are associated with high costs. Besides that limitation, features like coin tracking to address frauds, facilitate refund mechanisms, or any type automated precise currency indexation processes are hindered by this handicap.

Another technical limitation has to do with how contracts are triggered. With current technology, triggering smart contracts periodically can only be done from a centralised place or a permissioned place.

Imagine you want to design a monetary model in which some amounts are issued to various accounts periodically. Like a clock mechanism that deploys an specific amount of coins to all accounts for instance. This apparently simple monetary procedure is not so easy to achieve on the Ethereum chain. All Ethereum smart-contracts are public and can be thought of as open interfaces (APIs) — think of this as computer programs that reside on the blockchain and that everybody can access. This means, everyone can try to interact with them and try to trigger them. So if you want to create a smart-contract that is only triggered periodically, you have to protect that contract in such a way that it can only be triggered using a digital signature from permissioned or centralised place. In a way Gary Gensler had alerted this limitation when highlighting coordination and security problems. This becomes a core design limitation capable of blocking all pure on-chain solutions for decentralised architectures, that require regular and controlled issuance of coins.

1. Ethereum.org (2022, July 13). What is gas? — Available at: https://ethereum.org/en/developers/docs/gas/ [Accessed 27 July 2022]