Central to any economy is a medium of exchange and a store of value: money. We often think of money in the context of banks and finance, but some variation on the basic idea of money is critical to supply chains, service businesses, labor contracts, retirement planning, and more. Today we mostly use fiat currencies issued by national governments, but there are also well-functioning of “money” issued by cooperatives, national alliances, and mutual funds.
An example of a cooperative issuing “money” is the Swiss WIR, created in 1934 (during the Depression) by a cooperative of local businesses and landholders in order to spur local development, and which are backed by local property and infrastructure. The International Monetary Fund’s Special Drawing Rights are backed by a basket of national currencies, and issued to countries typically for national development purposes. Electronic Trade Funds (ETFs) are digital certificates giving ownership rights to a basket of company stock shares or bonds.
Today there is tremendous interest in the possibilities of using crypto-technologies and ETF-style assets replace physical cash and national currencies. Although the notion electronic cash (eCash) has been around for almost three decades now (e.g.  ), it was the emergence of the Bitcoin  system that provided a first working example of payment system that operated based on a peer-to-peer network and which could scale-up operations in a decentralized fashion.
In this chapter we outline an approach to building a consortium of sponsors, who contribute real assets, a narrow bank handling financial transactions involving fiat currencies, and an administrator, who issues the corresponding digital token in exchange for fiat payments and makes fiat payments in exchange for digital tokens. In short, our idea is to apply distributed ledger technology to give a new lease of life to the old notion of a sound asset-backed currency, and to use this currency as a transactional tool for a large pool of potential users, including small and medium enterprises (SME) and individuals.
Most recently we have seen the Facebook back the Libra digital currency, and the Chinese government back their own national digital currency, as well as a variety of banks beginning to use their own digital currencies in order to transfer money between partner banks. In this chapter we will describe how to build a currency whose governance is transparent and thus can be regulated, and which encourages legitimate commerce, but makes illegal activities difficult.
In essence, we wish to replace physical cash with a supranational digital token, which is insulated from adverse actions by central banks and other parties, due to the fact that it is asset-backed. We believe the DTC is ideally suited as a medium of exchange for groups of smaller nations or supranational organizations, who wish to use it a counterweight to large reserve currencies.
Supranational currencies have been known for two millennia. For instance, Roman, and later Byzantine and Iranian gold coins were used along the entire Silk Road; Spanish and Austrian silver coins were prevalent medium of exchange in the Age of Sail. Closer to our time, the British Pound was used as reserve currency for the British Empire and, to a lesser degree, the rest of the world; the Dollar and the Pound were used as a reserve currency basket for the world economy in the 20th Century, to which the Euro and the Yen were added in late 20th Century; and now the Yuan might be used along a revived Silk Road.
Today, for the first time ever, there is a possibility of designing a digital currency that combines the best features of both physical cash and digital currencies, including finality of settlement, partial anonymity, and usability on the web. This currency is largely immune to policies of central banks that control the worlds’ reserve currencies. Such a currency has enormous potential to improve the stability and competitiveness of trading and natural resource producing economies. In the DTC we propose to develop a trade-oriented asset- backed digital currency, aimed at facilitating international trade and making it as seamless as possible. This currency will be based on a proprietary framework combining the most recent advances in blockchain and distributed ledger technology, cryptography, and secure multi-party calculations, together with time-tested methods for preventing double spending. In view of the fact that our framework relies in part on our own research and in part on ideas readily available in public domain, we do not anticipate specific intellectual property right issues. Unlike Bitcoin, it will be fast, scalable, and environmentally friendly. It will also be transaction friendly because of its low volatility vs fiat currencies, not to mention cryptocurrencies.
Over the past decade, potential advantages, and disadvantages of distributed ledgers or blockchains, have been discussed by numerous researchers (see, e.g.,  and references therein). While numerous potential applications of blockchains have been entertained in the literature – including title deeds, post-trade processing, trade finance, rehypothecation, and syndicated loans, to mention but a few, the main usage of blockchains has so far been in the general area of payments, more specifically cryptocurrencies.
World-wide interest in distributed ledgers was ignited by Bitcoin, which is a cryptocurrency protocol operating without a central authority. It was described first in the seminal white paper by S. Nakamoto .
Since then Bitcoin has inspired creation of more than a thousand of other cryptocurrencies, all with various degree of novelty and utility (if any). One of the most promising is Ethereum, which is significantly more versatile than Bitcoin, not least because is supports so-called smart contracts . Another interesting and popular cryptocurrency protocol is Ripple . The Ripple system departs of the Nakamoto consensus approach. It is not truly decentralized because it does not rely on the thousands of anonymous (pseudonymous) mining nodes that form the peer-to-peer network underlying Bitcoin. Instead, the Ripple system uses a small set of nodes that act more like notaries, validating transactions at a higher throughput and much lower cost compared to Bitcoin. Unlike Bitcoin, most entities in the system are known and not anonymous. By their very nature, all of these currencies are native tokens, residing on a blockchain. Their transition from one economic agent to the next is controlled by the set of rules that are inherent or “hardwired” in the blockchain setup and are needed to maintain the integrity of their blockchain as a whole. However, until now, attempts to build tokens backed by real-world assets – first and foremost, fiat currencies – have been unsuccessful. Yet, until this all-important problem is solved, in is virtually impossible to make cryptocurrencies a part of the mainstream financial infrastructure, because otherwise the inherent volatility of cryptocurrencies will severely curtail their usability.
Although potential application of distributed ledgers mentioned earlier, such as post-trade processing and trade finance, are particularly important, they are technical in nature and lack the revolutionary spirit. However, a distributed ledger can potentially play a truly transformative role and bring a dramatic departure from the past by making Central Bank Digital Currency (CBDC) and stable cryptocurrencies a reality.
In the current work we propose a stable asset-backed cryptocurrency which we refer to as DTC. It can be viewed as a natural extension of a fiat-backed cryptocurrency called the Utility Settlement Coin (USC), see . Setting aside operational aspects of gathering and managing collateral assets, we need to design a ledger associated with value transfers. Since, by design, Nakamoto’s approach is neither scalable, nor efficient, we need to use a different design. Our analysis indicates that combining blockchain with an earlier approach for issuing electronic cash (eCash), developed by Chaum  , seems to be promising. Recall that Chaum introduced a blind signature procedure for converting bank deposits into anonymous cash. On the one hand, Chaum’s protocol is much cheaper, faster and more efficient compared to Bitcoin. It also offers an avenue towards true anonymity and unlinkability (as in paper cash), as compared to the weak pseudonymity of Bitcoin. If true anonymity is not desired, there are variations on the Chaum approach on offer, for instance, anonymity for the purchaser but not for seller, and so forth. However, on the other hand the basic Chaum model and many of its variants rely on the integrity of the issuing bank. To alleviate this issue, we propose the use of blockchain technology itself to track the relevant transaction parameters, reducing the opportunity for parties to be dishonest. Payments are still direct between users as in Chaum’s proposal.
In the DTC we propose a solution to the stable cryptocurrency problem, which boils down to assembling a pool of assets, contributed by sponsors, appointing an administrator, who will manage the pool, and digitizing the ownership rights on this pool. In addition, we build a special-purpose narrow bank, which facilitates activities of the administrator. By construction neither the pool itself, nor the supporting bank can fail due to market and liquidity risks. Their operations are streamlined as much as possible to limit operational risks. It is worth noting that operational risks are always present; this statement is true not only for the setup we are proposing, but for an ordinary cash and bank deposits too, not to mention cryptocurrencies, which are notorious for their operational risk exposures. The narrow bank receives fiat currency submitted by the users, passes it to the administrator, and ultimately, to sponsors, while the administrator issues digital tokens in return. These tokens will circulate within the group of users in a fast and efficient manner by utilizing distributed ledger mechanism, thus creating native tokens proportionally convertible into the underlying assets at will. Their value is maintained in a relatively narrow band around the value of the underlying asset pool, with lower bound enforced by arbitrage, while the upper bound enforced by the administrator assisted by sponsors.
The key insight of the paper is that the properly designed DTC can serve as an international reserve currency remaining stable in the long run and serving as a much-needed counterbalance to fiat currencies issued by individual nations, which can be easily affected by their respective central banks.
The paper is organized as follows. Background on asset-backed currencies is discussed in Section
3. Design of Bitcoin and Ripple, including their similarities and differences, is outlined Section 4. CBDC and closely related USC are discussed in Section 5, respectively. DTC is discussed in Section
6. Conclusions are drawn in Section 10.
The idea of anchoring value of paper currency in baskets of real assets is old, see, e.g., . Gold and silver as well as bimetallic standards have been used for centuries to achieve this goal.
Two approaches are common: (A) a redeemable currency backed by a basket of commodities; (B) a tabular standard currency indexed to a basket of commodities.
Lowe, , was the first to explain how to use a tabular standard of value to the price inflation; a similar plan based on a basket of 50 commodities was developed by Scrope, . Jevons, , pushed these ideas (much) further and proposed an indexation scheme based on a basket of a 100 commodities; while Marshall, , proposed a similar tabular standard.
Inspired by developments during the Great Depression, F. Graham, , developed an automatic countercyclical policy based on 100 percent backing of bank deposits by commodities and goods, while B. Graham, , proposed backing the USD with a commodity basket at 60% and gold at 40%. Hayek, , advocated establishing a universal basket of commodities, which every country would use to back its currency. Roughly at the same time, Keynes, , designed an international gold-linked multilateral transaction currency, which he called the bancor. Unfortunately, his ideas were discarded by the architects of the Bretton Woods system.
After the WWII, interest in commodity-based currencies has been lukewarm. Still, Kaldor, , proposed a new commodity reserve currency, which he also called bancor. More recently, Zhou, , proposed a new international reserve currency anchored to a stable commodity basket benchmark.
The choice of the actual asset basket backing DTC is not an easy one. It is partly dictated by the composition of the sponsors’ pool and partly by what assets they actually possess and are willing to contribute. For instance, depending on their resources and abilities, sponsors can contribute oil, gold, base metals, and agricultural commodities. Given that storage of significant amounts of the above is difficult and costly, it is natural to use collateral, which is in storage already, thus making stored commodities economically productive.
When discussing asset-backed currencies, it is necessary to mention the WIR. “WIR” is both an abbreviation of Wirtschaftsring (Economic Circle) and the word “we” in German. This wordplay emphasizes WIR’s dual role as an economic circle and a community. According to WIR’s statutes, “its purpose is to encourage participating members to put their buying power at each other’s disposal and keep it circulating within their ranks, thereby providing members with additional sales volume.” WIR issues a purely digital private currency. Participants can use WIR in combination with the Swiss franc as part of dual-currency transactions. Thus, we can view WIR as an analog precursor of the DTC.
WIR serves small and medium enterprises (SME) as well as private individuals WIR was founded in 1934 to address currency shortages and global financial instability, receiving a banking license in 1936. In the beginning, WIR’s founders followed the theory of Silvio Gesell, which requires money to be free from interest; however, eventually (and unsurprisingly), the WIR Bank renounced Gesell’s ideas in 1952, and introduced monetary interest. WIR gradually grew from the original sixteen members in 1934 to more than 60,000 today. Total assets are approximately 5.3 billion CHF, loans of 4.5 CHF billion, and deposits of 3.9 billion as of the end of 2016.
A particularly important fact about the WIR Franc is that it is an electronic currency reflected in clients’ trade accounts and not represented by paper money. Thus, the WIR bank maintains the entire ledger. The initial purpose of the currency was to increase sales, cash flow, and profits for qualified participants. Eventually, WIR created a credit system that issues credit in WIR Francs, (over)collateralized by assets, which ensures that the currency is fully asset-backed.
New WIR francs are created when a loan is issued and destroyed when it is repaid, but a small interest stays in the system forever and contributes to bank profits. A typical transaction between two members involves payment in both Swiss Francs and WIR Francs, thus reducing the amount of cash needed by the buyer but without the seller discounting the price of their product or service.
Since its first announcement in 2008 Bitcoin  has captured the imagination of the public by proposing the first cryptographic electronic currency having no intrinsic value, issued without central authority, and capable of peer-to-peer digital transfers. Anyone can join the Bitcoin ecosystem, which is both a strength and a weakness.
Because it’s currently the best-known form of cryptocurrency, it’s worth exploring how Bitcoin works. Financial transactions are made directly between users, without the help by designated intermediaries. Transactions are publicly broadcast and recorded in a “blockchain ledger”, which can be seen by all participants. Once a transaction is broadcast, the so-called “miners” come into play. They aggregate individual transactions into blocks (currently of about 2000 transactions each), verify them to ensure that there is no double spend by competitively providing proof of work (PoW), and receive mining rewards in bitcoins (BTCs). The proof of work is based on finding a cryptographic nonce making the hash value of the candidate block of transactions lower than a given threshold. As such, the “hash power” (i.e. hardware and software processing capacity) of a node makes a difference in the likelihood of the node finding the match.
It is assumed (but not proven) that there are sufficiently many honest miners, so that collusion among them (known as 51% attack) in not possible. A transaction is considered to be confirmed if there are at least six new blocks built on the top on the block to which it belongs. The Bitcoin ecosystem is not without very serious issues – it can handle no more than 7 transactions per second (vs. Visa which can handle more than 20000 transactions per second), and it consumes enormous amounts of electricity used by miners (by virtue of underlying PoW computation). Thus, the immutability of Bitcoin’s blockchain ledger and the prevention of double spending is achieved through mining based on PoW.
In view of the above, bitcoins themselves are just unspent transactions outputs of a long chain of transactions, which can be traced all the way back to the time when it was minted, either to the very first “genesis” block, or as part of a “coinbase” transaction included in a block by a successful miner.
Since Bitcoin’s inception in 2009, its price has gone up several orders of magnitude, making it the darling of speculators across the globe. However, a word of caution is in order. Since Bitcoin has no value, it can have any price, hence one should not be surprised if its price falls dramatically. Other than for speculative purposes, Bitcoin’s uses are rather limited, because its price versus the US dollar and other fiat currencies is extremely volatile, which prevents it from becoming a medium of transaction. In addition, in spite of claims to the opposite, Bitcoin transaction costs are very high and growing.
Although Bitcoin may not be the disruptive force as its supporters are claiming, its underpinning distributed ledger technology has a clear potential to transform the financial ecosystem as a whole.
Ripple is a money transfer protocol; ripple is the underlying native currency. It is completely different from Bitcoin. For starters, ripples are pre-minted, while bitcoins are mined. In fact, Ripple is not decentralized at all. The stated purpose of the protocol is to facilitate fiat currency transfers among participating banks. However, due to the fact that there is a native token, Ripple can be used along the line of Bitcoin as well. Details of how Ripple works are given in various Ripple promotional materials including their white paper .
The main ingredients of the Ripple ecosystem can be summarized as follows: (A) Servers, which maintain the ledger; (B) Clients, who can initiate transactions; (C) Proposers, which can be any server; and (D) the Unique Nodes List (UNL), indicating parties, which can be trusted by the participants in the protocol.
The life cycle of a single transaction consists of several steps. First, a transaction is created and signed by an account owner. Second, this transaction is submitted to the network; If it is badly formed, this transaction may be rejected immediately; otherwise it is provisionally included in the ledger. Validating nodes propose new ledger. Transmitting nodes broadcast it to the network. Consensus is achieved by voting of the validators. The result of a successful consensus round is a validated ledger. If a consensus round fails, the consensus process repeats until it succeeds. The validated ledger includes the transaction and its effects on the ledger state.
Ripple consensus assumptions are:(A1) Every non-faulty Server makes decision in finite time; (A2) All non-faulty Servers arrive at the same decision; (A3) Both true and false decision regarding a given transaction are possible.
Ripple Protocol Consensus Algorithm (RPCA) works in rounds: (A) Initially, every Server compiles a list of valid candidate transactions; (B) Each Server amalgamates all candidates coming from its UNL and votes on their veracity; (C) Transactions passing the minimum threshold are passed to the next round; (D) The final round requires 80% agreement. In general, RPCA works well, however, it can fail provided that validating nodes form cliques, which cannot agree with each other.
Could and Should Central Banks Issue Central Bank Digital Currency? Recently, a previously academic question of feasibility and desirability of CBDC came to the fore, see, e.g.,  - . By issuing CBDC, states can abandon physical cash in favor of its electronic equivalent and replace a large chunk of government debt with it. The impact on society at large will be huge, . CBDC can obviate the need for fractional banking and dramatically improve the stability of the financial system as a whole. On the other hand, the ability of the banking sector to create money “out of thin air” by making loans will be significantly curtailed and transferred to central banks. It is clear that developments in this direction are inevitable, but their timing and magnitude are uncertain.
Interest in CBDC has been ignited by two unrelated factors - the introduction of Bitcoin, and a persistence of negative interest rates in some developed countries. In Medieval Europe negative interests existed in the form of demurrage for centuries. Recall that demurrage is a tax on monetary wealth. In principle, demurrage encourages spending money, rather than hoarding it, thus accelerating economic activity. The idea of demurrage was reborn shortly after the WWI in the form of scrip money, which requires paying of periodic tax to stay in circulation. Scrip money was proposed by the German-Argentinian entrepreneur and economist S. Gesell, , whose idea was restated by Irving Fisher during the great depression, . Demurrage was thought to be a suitable replacement for mild inflation. Since in the modern economy demurrage is hard to orchestrate due to the presence of paper currency, its conversion into the electronic form is necessary for making seriously negative rates a reality, .
Currently, there are three approaches to creating CBDC on a large scale:
Economic agents, from enterprises to private individuals, can be given accounts with central banks. However, in this case, central banks would have to execute know your customer (KYC) and anti-money laundering (AML) functions, tasks which they are not equipped to perform. Besides, under duress, rational economic agents might abandon their commercial bank accounts and move their funds to central bank accounts, thus massively destabilizing the entire financial system.
Inspired by Bitcoin,, CBDC can be issued as a token on an unpermissioned distributed ledger, whose integrity is maintained by designated notaries receiving payments for their services, see, e.g., . Given that notary efforts do not require mining and hence are significantly cheaper and faster than that of Bitcoin miners, this construct is scalable and can satisfy needs of the whole economy. Users are pseudo-anonymous, since they are represented by their public keys. Since at any moment there is an immutable record showing the balance of every public key, it is possible to deanonymize transactions by using various inversion techniques applied to their recorded transactions, , thus maintaining AML requirements.
A central bank can follow the Chaumian scheme,  , and issue numbered and blind signed currency units onto a distributed ledger, whose trust is maintained either by designated notaries or by the bank itself. In this case it would have to rely on commercial banks, directly or indirectly, for satisfying the KYC/AML requirements.
To summarize, by using modern technology it is possible to abolish paper currency and introduce CBDC. On the positive side, CBDC can be used to alleviate some of the societal ills and eliminate costs of handling physical cash, which are of order of 1% of the country’s GDP. It can help the unbanked to participate in the digital economy, thus positively affecting the society at large. On the negative side, it can give central authorities too much power over the economy and privacy, which can potentially be misused.
While CBDC is absolutely stable with respect to the underlying fiat currency, it does not make the fiat currency stable in itself. For that we need a carefully constructed DTC.
CBDC is technically possible but politically complicated. Hence several alternatives have been proposed. One promising venue is USC, which is developed by a consortium of banks and a fintech startup called Clearmatics.1 Initially, USC can be an internal token for a consortium of participating banks. These coins have to be fully collateralized by electronic cash balances of these banks, which are held by the Central Bank itself. Eventually, these coins can be circulated among a larger group of participants. However, in this case, issuance of USCs has to be outsourced to a narrow bank, which can perform the all-important KYC and AML functions.
Recall that a narrow bank has assets, which include solely marketable low-risk securities and central bank cash in an amount exceeding its deposit base as per the regulatory prescribed capital cushion, see, e.g.,  among many others. As a result, such a bank is impervious against credit and liquidity shocks. However, as any other firm, it can be affected by operational failures, including fraud, computer hacking, inability to solve the KYC/AML problem, etc. These failures can be minimized, but not eliminated, by virtue of using proper modern technology. Accordingly, narrow bank deposits would be as close to the fiat currency, as technically possible.2 Ideally, one narrow bank per fiat currency is required. Further details are given in .
USC is helpful from a technical perspective, but it does not solve issues of monetary policy. We wish to address this issue by building a counterweight for fiat currencies by backing the DTC by a pool of real assets.
The idea that a blockchain system can withstand a concerted attack simply because it consists of physically distributed nodes is an untested and unproven proposition. The possible types of attacks to a blockchain system has been discussed elsewhere, and consists of a broad spectrum. These range from classic network-level attacks (e.g. network partitions; distributed denial of service; etc.) to more sophisticated attacks targeting the particular blockchain-specific constructs (e.g. consensus implementations; ), to targeting specific implementations of mining nodes or notaries (e.g. code vulnerabilities; viruses; etc.). An attack on a blockchain system may not need to cripple it entirely a degradation in its overall service quality (e.g. slower transaction throughput) maybe sufficient to disincline users to use the system.
The notion of interoperability across blockchain systems is an important one in the light of survivability . The Internet was able to expand and allowed autonomous systems (i.e. routing domains) to interconnect with one another due to good design principles. The design philosophy of the Internet is based on three (3) fundamental goals, namely (i) network survivability (Internet communications must continue despite loss of networks or gateways); (ii) variety of service types (The Internet must support multiple types of communications service); and (iii) variety of networks (The Internet must accommodate a variety of networks). We believe the same fundamental goals must be adopted for the current development of blockchain technology – and more specifically they must drive the technological selection for the implementations of the DTC architecture.
Bitcoin and Ripple protocols can be used as a prototype for a distributed ledger-based cryptocurrency more suitable for transactional financial purposes. Several issues, some technical and some economical, have to be addressed before this goal can be achieved:
The KYC problem has to be formulated and articulated and a suitable framework for solving it has to be designed;
An AML mechanism has to be developed;
A highly efficient method for maintaining consensus on the ledger, with the industrial strength transactions per second (TpS) capabilities, has to be built;
A transparent and economically meaningful system for issuing new DTCs and retiring the existing ones has to be implemented;
And, most importantly, a satisfactory mechanism for making DTC a stable cryptocurrency has to be designed.
Although public ledgers are not truly anonymous, but rather pseudonymous, it is difficult to use them in the KYC/AML compliant fashion. Accordingly, the DTC ledger has to be made semi-private (but probably not private) in order to solve the KYC/AML problem. At the same time, a right balance has to be struck between privacy and accountability, so that excessive restrictions should not impede the flow of legitimate commerce.
In order to achieve the level of speed and efficiency we are aspiring for, including TpS of order several thousand, the Ripple-style consensus protocol has to be used. Following Ripple’s approach, we choose a group of notaries, who are known in advance and properly licensed. These notaries are responsible for performing ledger updates and maintaining its integrity by ensuring Byzantine fault tolerance, see, e.g.,  . For their services notaries are paid a small fee, say a percentage of the transaction amount they approve, which is naturally denominated in DTC, so that their commercial interests are aligned with their functions. If notaries stay inactive, or systematically approve invalid transactions, they are financially penalized. In each round, validators create their own versions of the ledger, and propose these to the rest of the group. Several rounds of voting take place until a super-majority candidate ledger is selected. This approach is similar in spirit to the well-known Paxos algorithm. In order to increase TpS number, we use the idea of sharding and assign individual notaries to particular sets of addresses. In this setup, a quorum verifies its own shard, while the full ledger is assembled out of the corresponding shards.
The DTC architecture recognizes that there are two or three types of application-level transactions commonly found in many blockchain implementation. The first is the one-party recording of assets to the ledger. Logically the DTC represents this on an assets ledger. The second type is the two-party transferal transaction, exemplified by the transferal of coins from one party to another. The DTC captures these logically on the coins ledger. The third type of transaction is the off-chain transferal of value (i.e. eCash) in a privacy-preserving manner. Here the goal is to allow a limited amount of coin-backed anonymous eCash to be transferred from one user to another, following the classic Chaum approach. Relevant parameters of the eCash flow are recorded on the DTC tracking ledger in order to reduce the opportunity of fraud by entities involved in the eCash flows.
This design decision of recognizing the three types of application-level transactions provides the broadest flexibility for the DTC architecture to be tailored for specific use-cases, and for different implementations of the three ledgers to be chosen according to the requirements of the use-case.
For now, we shall consider this pool and its associated narrow bank as given, and describe the creation and annihilation mechanisms for the DTC. New coins are injected in the distributed ledger by virtue of the following mechanism. During the initial stage, participants who wish to acquire a freshly minted DTC have to proceed as follows. First, they have to have a conventional fiat account, which can be held either directly with the narrow bank or with their commercial bank. Second, they have to open an initially empty wallet ready to accept DTCs. Third, participants transfer the desired amount of fiat currency to the narrow bank. Fourth, the narrow bank transfers these funds to sponsors who, in turn, release some of the DTCs created when the asset pool is built to the pool administrator. Fifth, the administrator transfers the corresponding DTCs from its public key address to the public key address provided by the participant. Thus, in effect, participant becomes a shareholder in the pool administrator. Subsequently, participants can acquire DTCs from other participants in exchange for goods and services, so that a newly born DTC starts its journey from one address represented by a public key to the next, until it is annihilated by a participant sending it to the administrator in exchange for cash. When a participant in the ledger wishes to receive fiat currency for their DTC, they transfer DTCs from their public key to the public key of the administrator, who, in turn, sells an appropriate proportion of the assets, deposits proceeds with the associated narrow bank, which, in turn, credits fiat currency either to the account on its own ledger or to a designated account in a different bank. The corresponding DTCs are destroyed by sending them to the “terminal” public key without a private key.
As a result, the administrator is in possession of real assets, sponsors with fiat currency, general public with DTCs, which can always be converted into fiat at the current market price.
Finally, the value of the DTC is kept relatively stable by virtue of the independent actions of participants and the administrator. If the value of a DTC goes below the value of the fraction of the asset pool it represents, which we call its intrinsic value, then rational economic agents will turn it back to the administrator in exchange for cash. If, on the other hand, the market value starts to deviate upward compared to the intrinsic, then, after a certain threshold is breached, the sponsors will contribute more assets to the pool, which can come from their own sources or be purchased on the open market, in exchange for DTCs, which they will sell on the open market, thus pushing the market price of DTCs down. These two complementary mechanisms can keep the market price of the DTC in a bank around the market price of the underlying basket.
More precisely, the price PDT C of DTC will be close to (but not exactly at) the market price of the corresponding asset pool, PM . Indeed, if PDT C falls significantly below PM , economic agents will put DTC back to the administrator, who will have to sell a fraction of the pool’s assets for cash and pass the proceeds to these agents. If PDT C increases significantly above PM , sponsors will supply more assets to the administrator, who will issue additional DTC and pass them to sponsors, who will sell them for cash, just pushing the price down. This mechanism ensures that |PDT C −PM |/PM « 1, a very desirable feature, especially compared for conventional cryptocurrencies, habitually exhibiting extreme volatility. At the same time, outright manipulation by central banks is not possible either.
Note that the notion of economic agents (e.g. sponsors with assets) is distinct from system entities (e.g. notaries) in the DTC architecture (see below).
In order for DTC to be a stable and durable digital currency that can store value as well as provide utility, there are a number of principles driving its architecture. The DTC architecture seeks to be a “blueprint” that allows the DTC to be implementable for various use cases. Some uses cases which have been identified are: (i) a reserve digital currency shared by a number of geopolitically diverse small countries, as a means to provide local financial stability; (ii) a digital currency operating for a narrow-bank that can provide relative stability during financially volatile periods. A number of system design principles are as follows:
Unambiguous identifiability and ownership of properties: Assets (represented digitally), coins and eCash must be uniquely identifiable, and have unambiguous ownership at any given time. A corollary of true ownership is that these must be transferrable (portable) by its owner.
Identifiability of entities and devices: All entities (e.g. sponsors) must be uniquely identifiable using identifiers which are legally recognized (e.g. Legal Entity Identifier ). Similarly, all devices interacting on the blockchain must be uniquely identifiable and each device must have an owner. Additionally, they users and devices must authenticable.
Anonymity of node devices may lead to concentrations of hash-power . In some permissionless blockchain networks, any entity can take the role of a mining node and be identified on the blockchain solely by their public-key (i.e. “address”). Although this anonymity may be considered as a virtue in some blockchain networks (e.g. Bitcoin ), there may be some disadvantages to this approach. One disadvantage is the potential for the amassing (centralization) of hashing power by a handful of anonymous nodes or entities, which goes against the proposition of decentralization of the blockchain paradigm. Such entities could conceivably use this concentration of hash-power to skew or manipulate the network over time.
Visibility into shared state: Entities in the ecosystem should have visibility into the state of the DTC system and network, and have equal access to such information. More specifically, this means visibility into the assets which back the issuance of coins, and visibility into the circulation of coins and eCash.
Mechanisms implementing monetary policies: In order for the DTC ecosystem to operate according to the desired community behavior, there must be technical mechanisms that allow agreed policies to be carried out in the system as a whole. Such mechanisms can be controlled centrally (e.g. single entity), controlled in a group-oriented manner (e.g. consensus of entities), or a combination of both (e.g. leader election protocols).
Correct, accurate and unhindered system-wide reporting: System components that implement DTC must each be unhindered in the reporting of its internal state. Furthermore, there must be ways to validate reported state, so that misbehavior can be detected and acted upon. Such misbehaviors can be the result of human or system error, degradation in system components over time (hardware and software), or the result of active or passive compromises (i.e. attacks).
Well-defined operations (limited programmability): One of the key factors in the success of the Bitcoin  system is very limited available operations (op-codes). These operations are geared towards a very specific application of the blockchain, namely electronic peer-to-peer payments. This is in contrast to the Ethereum system , which was touted to be a highly programmable platform for distributed applications. However, the high degree of programmability may be a double-edged sword ion the sense that human error and malicious code can be deployed on the platform that harms other users or applications (e.g. DAO Hack ).
The above system design principles borrow from a number key design principles underlying the Internet . The need for unambiguous ownership of an asset is an obvious one. The DTC seeks to use standard object identification solutions (e.g. GUID standard) for digital assets. The legal ownership of assets is a construct that is external to the DTC system, and as such must be established prior to assets being introduced by its legal owner (e.g. Sponsor) into a given DTC deployment.
The principle of visibility is driven by the need for entities in a DTC implementation to have equal access to data, and is implemented through the assets ledger and coins ledger. The Consortium Administration (see below) must have full visibility into all operational aspects of a given DTC implementation. Certain DTC implementations may restrict visibility of parts of the systems (e.g. assets ledger) to entities that have “skin in the game” (e.g. Sponsors who have actual assets on the DTC assets ledger).
A key aspect of the success of a DTC implementation is the ability of the Consortium to carry out monetary policies and other governance rules in the system as a whole. Technical mechanism can be implemented as “hooks” or control-points through which policy decisions are executed. For example, a DTC implementation may require that each Sponsor have assets (in the assets ledger) above a given threshold (i.e. reserve ratio) at all times. The actual value of the threshold should be dynamically adjustable according to the Consortium-agreed policies and be carried out by the Consortium Administration as the appointed authority. In this case, the Consortium Administration can transmit a special “policy implementation” transaction (to the assets ledger and coins ledger) setting the new threshold value. Notaries observe such policy decisions by declining an asset-to-coin conversion transaction from a Sponsor if it causes the Sponsor’s asset reserves to dip below the new threshold value.
Key to the operation of a DTC implementation is the ability of entities to identify and authenticate each other. We believe this is closely related to the principle of system-wide reporting. Some DTC implementation may choose to deploy advanced cryptographic techniques that provide anonymity and untraceability of entities. However, such features must still satisfy the principle of unambiguous identifiably and mutual authentication.
There are a number of active (human-driven) entities in the DTC ecosystem (Figure 1):
Sponsor: A sponsor is an entity who supplies assets to the DTC ecosystem in return for coins. The community of sponsors forms a consortium (see below) tasked with the various management aspects of coins and eCash in the ecosystem.
Consortium: A community of sponsors forms a consortium, operating under an agreed governance model that specifies the legal, business and technical operational rules of members of the consortium. In essence, the consortium is a network of sponsors who are participating in the DTC ecosystem.
Additionally, a Consortium Administration carries out the monetary policies of the membership of the consortium. The consortium administration is legally empowered by the consortium membership to implement (centralized) control over certain system functions.
Users: A user is an entity that obtains eCash from the consortium for the purpose of payments for goods and services from other users.
The DTC architecture logically separates functions into those pertaining to assets, coins and eCash (Figure 2). Here we use the term ledger generically without calling out specific realizations, to allow focus on logical functions that meet the system design principles stated above.
Specific technical implementations of the ledger may include a distributed database system, a peer-to-peer network of nodes, a fully distributed blockchain system, or even an append-only single database system.
Assets management: Visibility into the assets which sponsors contribute in exchange for coins represents a foundational requirement in DTC. DTC employs an assets registry and an assets ledger. The registry records verified real-world assets that is associated to a sponsor who forwards that asset to the consortium.
The assets ledger captures the binding between real-world assets (put forward by a sponsor) and the amount of coins equivalent to (proportional to) those assets. The assets ledger also records the proportion of coins that are in the consortium’s reserves and those that are in a sponsor’s reserve. These coin-equivalents are considered to be non-circulation.
Coin circulation: Allowing sponsors to exchange (i.e. sell or lend) with each other their asset-backed coins represents a cornerstone of DTC. The coins ledger records the coin movements and transactions in the DTC ecosystem (Figure 4). The coins ledger is used by sponsors and the consortium administration. Sponsors exchange or “trade” coins with each other on this ledger.
eCash circulation: Providing stable digital currency to users also represents a cornerstone of DTC. The eCash tracking ledger records the movement of eCash (i.e. cryptographic keys and parameters) between users.
Each of the three ledgers in DTC are independent, but are connected in the sense that transaction in one ledger may refer to (point to) recorded transactions in other ledgers. This independence of ledgers is important not only from the perspective of technological choice (i.e. adoption of new ledger technologies), but also crucial to the operational resilience of the system as a whole.
An example of the connection of the ledgers is the “pushing” (or pulling) of coins into (out of) circulation by a Sponsor following the policies of a given DTC implementation. When a Sponsor seeks to have its assets (on the assets ledger) be converted to coins and for the resulting coins to be accessible by the Sponsor on the coins ledger, the Sponsor must transmit a push-transaction. This results in a transaction occurring on the assets ledger and a corresponding transaction occurring on the coins ledger. These two transactions – albeit on different ledgers – are related in that one refers to (i.e. carries a hash of) another. In the push case, the transaction on the coins ledger points to a completed transaction on the assets ledger.
The purpose of the assets ledger together with the assets registry to satisfy the design principles with regards to the conversion of real-world assets into its coin equivalent (see Figure 3).
A key requirement here is the validation of the legal ownership of assets as claimed by a given sponsor. The sponsor must provide legal evidence in such a way that a digital representation of the evidence can be captured and presented within the assets ledger.
Examples of such evidence include a paper certificate and its digital representation that has been digitally-signed by the issuer using legally acceptable digital-signature technology (e.g. Digital Signature Act of 2000). For example, a digital version of a gold certificate (e.g. unallocated gold) could be signed by an authority and presented by a sponsor as evidence. It is the responsibility of the consortium administration to validate the evidence.
The medium for sponsors to exchange coins with each other is the Coins Ledger. The notion here is that coins to be bought, lent and returned among sponsors on the ledger, providing transparency and visibility into the trading behavior of all sponsors in the DTC network.
Prior to having access to coins on this ledger, a sponsor must explicitly request the consortium to “push” the sponsor’s coins from the assets ledger (from the sponsor’s reserves) into circulation on the coins ledger (see Figure 4). The consortium administration must respond to this request in an explicit manner (request granted, denied or postponed) on the assets ledger. A request that is granted is followed by the consortium administration transferring coins from its account on the coins ledger to the sponsor’s account on the same ledger.
This explicit request-response paradigm is a manifestation of the mechanism to implement monetary policies. It is a “hook” into the system in which the consortium administration – as the representative of the community of sponsors – enforces policies agreed to by the community. A simple example of a monetary policy decision is the reserve ratio that must be met by each sponsor on the assets ledger. A sponsor that exhausts its reserves on the assets ledger, thereby violating the policy of sponsors maintaining a minimum reserve, should not be granted a request to push further coins into circulation on to the coins ledger.
A symmetric operation to pushing coins to the coins ledger is that of “pulling” coins from circulation (see Figure 5). This may occur when a sponsor wishes to enlarge its reserves on the assets ledger by moving coins from the coins ledger to the assets ledger.
We believe that there are use-case scenarios for the Chaumian electronic cash (eCash)  in the context consumer day-to-day usage. In this section we explore how eCash schemes could be integrated into the DTC model. In general, a user (i.e. consumer) is distinguished from a sponsor in that a user does not possess assets in the consortium. The user obtains eCash in exchange for fiat currencies that are acceptable by the consortium. The goal of the user is to utilize a convenient and low-cost (zero-cost) eCash payment method, one that is stable on a day-to-day basis and which can store value over a reasonably long period of time.
In DTC the entity that issues and redeems is the consortium itself. This ensures that the stability of eCash is directly related to the stability of coins and assets in the consortium, all three of which are under the monetary control of the consortium as a community. The consortium as the issuer of eCash to a user enacts monetary policies that govern how much eCash a user can request specifically at any one time. More generally the consortium can govern how much eCash is permitted to be in circulation at any given moment in time, as a function of the total assets at the consortium.
The notion of electronic cash (e-cash) was first put forward in the landmark work by Chaum . One key goal of the original e-cash proposal was that of preserving (as far as possible) the privacy features of paper cash. That is, to prevent third parties from discovering the identity of the payer/payee, the amount and the time of payment. Hence the usage by many eCash schemes of cryptographic constructs (e.g. blind-signatures, zero-knowledge proofs) which hides an entity’s true identity. Another important goal was to prevent collusion of entities from defeating the scheme as a whole. An example would be the collusion between the issuer (e.g. bank) and payee (e.g. merchant) which harms the payer. Similarly, a colluding payer and payee must not be able to cheat an honest bank.
In general, e-cash schemes seek to possess the technical features of blindness on the part of the Bank that prevents it from seeing what the payer is spending, unlinkability that prevent the Bank from correlating e-cash units belonging to the same payer, and unforgeability that prevents payers and payees from forging fake e-cash   . Other desirable features include exculpability of honest entities (i.e. defend them from being framed by dishonest entities).
The basic flows of currency units in eCash systems are typically 3-party. A person Alice (payer) withdraws eCash from her account at the Bank (sponsor), and delivers the eCash directly to a merchant Bob (payee). The Merchant must then present the eCash to the same Bank in order to get his account credited with the amount. It’s worth noting here that the transferal of the e-cash units from Alice to Bob is a direct one, without the mediation of a ledger or third parties.
Aside from the cryptographic complexity of many proposed e-cash schemes, there are a number of practical factors that have prevented the wide adoption of e-cash schemes over the past two decades. Some are as follows:
Reliance on centralized entity: In many e-cash schemes the Bank plays the dual role of: (i) issuing authority, and (ii) the redeeming (clearing) authority for e-cash. As such, for daily use such e-cash schemes offer little benefit over traditional credit cards.
Unmediated peer transferability: Many e-cash schemes suffer from inefficiencies with regards to the multi-hop transferability (portability) of e-cash units (e.g. Alice to Bob to Charlie) without the mediation of the bank.
The need for the bank entity to be online all the time has often been cited to be a stumbling block. However, in the current age of Internet connectivity this may no longer be a factor.
The GNU Taler system  is one of the more recent practical iteration of Chaum’s electronic cash proposal. The Taler system is notable because it provides anonymity only to the payer entity. The payee is assumed to be a merchant and thus for taxation purposes its identity must be disclosed upon redeeming the eCash to the bank.
The following summarizes the high-level goals of the ledger-assisted eCash:
Support off-ledger direct payment mechanisms using eCash:
Provide users to perform payments of eCash without adverse impact on the Tradecoin ecosystem.
Retain visibility into the circulation of eCash in a privacy-preserving way:
Retain visibility into the circulation of eCash backed by coins while preserving the privacy of the user.
The relevant entities are prevented from colluding to defraud or damage the Tradecoin ecosystem.
Reduce the risk from possible collusion in eCash:
Provide the necessary mechanisms to prevent collusion by entities in the eCash flow that that adversely impact the Tradecoin ecosystem.
There are number of design constraints we impose on the use of eCash in the Tradecoin ecosystem. These are summarized as follows:
Consortium as the Issuer of eCash: In Tradecoin the Consortium (Administration) is the issuer (source) of all eCash. That is, the Consortium plays the role of the Bank in the classic Chaum model.
Limited 3-party flow: The eCash flow follows the classic Chaum three (3) party flows. This consists of the Consortium (as issuing Bank), the Payer (Alice) who withdraws eCash, the Payee (Merchant) who receives payment from the Payer. The loop is closed with the Merchant depositing the eCash back to the Consortium.
Limited amounts of eCash withdrawals: Users are permitted to obtain only limited amounts of eCash from the Consortium. The amount and rate are subject to monetary policies. As such, this approach provides an early detection mechanism for users who are “hoarding” large amounts of Tradecoin eCash outside their accounts at the Consortium. We believe this limitation is a reasonable constraint that reflects the current paper-cash withdrawal limitations imposed in the US banking industry.
User anonymity to the Merchant only: In the Tradecoin usage of eCash, the user is anonymous only to the Merchant. The Consortium knows the identity of the user and the merchant.
User Identification at eCash Withdrawal: A user that seeks to withdraw eCash from the account at the Consortium must be strongly authenticated by the Consortium. This constraint is also reasonable and reflects the current industry practice of a person needing to authenticate themselves at the teller/counter or at the ATM machines as a step prior to withdrawing paper cash.
Merchant non-anonymity: Another constraint in Tradecoin is the non-anonymity of the merchant (payee). That is, the merchant entity is known and identified by the User and by the Consortium. This is in-line with the recent GNU Taler Project .
Non-transferability across peer users: Currently, Tradecoin precludes the notion of peer transferability (i.e. multi-hop transfers) between users. Thus, the payee (merchant) is not able to forward unmediated the eCash to other entities. The merchant has only one option which is to deposit the eCash to its account at the Consortium.
Size of eCash circulation subject to monetary policy: An overall constraint is that the total value of eCash in circulation at any given time is subject to the Tradecoin community monetary policy.
The tracking ledger is an append-only distributed log mechanism. That is, the tracking ledger is read-and-append (read/write) accessible to the Consortium and to parties involved in the eCash related flows (Consortium, Payer and Payee). It is read-accessible (read-only) for all parties in the Tradecoin ecosystem.
When the Consortium issues (redeems) eCash to (from) a payer (payee), it makes use of the tracking ledger to “declare” these actions. In essence, even though the identity of the user obtaining eCash is anonymized from the rest of the world, the Consortium is making an assertion on the tracking ledger that it has issued some eCash units that corresponds to a given set of coins.
This act of the Consortium declaring eCash issuance on the tracking ledger allows the sponsors to have visibility into the size of the eCash units being issued at any given time. It also allows the payer and payee to verify the Consortium has behaved honestly (i.e. issues the correct number of eCash units to the payer).
In order to preserve the true identity of the payer, it is important: (i) that the payer does not employ its ledger identity when sending payments to the payee (merchant); and (ii) that at Spend flow the payer does not link to transactions recorded on the ledger that may disclose its identity to the payee.
Among others the purpose of the tracking ledger is to record the actions taken by entities (Consortium, Payer and Payee) in such a way that there is a mechanism for the Consortium as a whole to observe the flow eCash in the Tradecoin ecosystem. Since some of the parameters in an eCash system is confidential (e.g. blinded parameters) and are typically exchanged between parties pair-wise over a secure channel (e.g. SSL or HTTP/S connection), the tracking ledger relies on the honesty of each entity to record a hash of the relevant parameters to the tracking ledger.
The generic eCash protocol flows that are most representative the variants of the Chaum schemes consists of three (3) groups of protocol flows: Withdraw, Spend and Deposit protocols. The evidence to be recorded on the tracking ledger are those pertaining to pair-wise interactions between two entities involved in each of the three Chaum flows. Thus, for example, when a Payer withdraws eCash from the Consortium Administration, both the parameters sent by the Administration to the Payer and the parameters received by the Payer from the Administration are to be recorded to the ledger. That is, both the sender and recipient must log what they sent and received respectively. This is illustrated in Figure 7.
The following provides an outline of the states relating to the ledger-assisted eCash protocol flows:
Evidence of the Withdraw: When a payer withdraws eCash from his or her account at the Consortium (i.e. as the eCash issuer), each eCash unit takes the form of a Serial-Number (call it Siss) plus the Consortium’s signature part over that eCash unit (call it sigS ). Step 1(a) of Figure 7 shown the withdraw stage.
In addition to storing each of these eCash units (i.e. the serial number and the issuer’s signature) in its internal system, the Consortium must record a hash of the following values on the tracking ledger such that they are visible to the other Tradecoin entities:
Identity of Consortium (issuer).
Hash of signed eCash (serial number Siss and its signature sigS ).
eCash denomination (name of eCash scheme)
eCash unit value.
This is shown in Step 1(b) of Figure 7. The payer may also record on the ledger a hash of what it received from the Consortium (Step 1(c) of Figure 7).
Evidence at Pre-Spend: When the payer has obtained the eCash unit in the form of a serial numbers Siss, the payer must transform this unit in such a way that it retains some desired properties of the unit (e.g. payer becomes anonymous at spend time, etc.).
We denote this transformation simply as the serial numbers Spayer, where Spayer = F (Siss) for some eCash scheme-specific function F . These transformed serial numbers Spayer are the units that the payer spends or delivers to the payee.
For its exculpability the payer must record a hash of the transformed serial numbers on the tracking ledger (Step 2(b) of Figure 7):
Identity of Consortium (from which the payer obtains the serial numbers).
Hash of original serial number (namely the hash of Siss).
Hash of transformed serial number (namely the hash of Spayer).
eCash denomination (name of eCash scheme)
eCash unit value.
Pointer to corresponding earlier withdrawal transaction on the tracking ledger.
Evidence at Spend: Typically, the act of spending the eCash units involves a challenge-response exchange between the payee and the payer (Step 2(a) of Figure 7). Here the payee sends a challenge value Cpayer to the payer. The payer then must prove that the serial number Spayer is valid by responding to the challenge with the response Rpayer.
Evidence at Post-Spend: For its own exculpability the payee must keep a transcript of the challenge-response exchange and also record parts of it on the tracking ledger (Step 2(c) of Figure 7):
Hash of transcript (namely the hash of the set of values Spayer, Cpayer and response Rpayer).
eCash denomination (name of eCash scheme)
The spent eCash unit value.
Pointer to corresponding Pre-Spend transaction (Flow 2) on the tracking ledger.
Evidence at Pre-Deposit: When the payee (e.g. merchant) deposits the serial number received from the payer into the payee’s account at the Consortium (Step 3(a)), the payee must deliver the values Spayer, Cpayer and response Rpayer to the Consortium.
For its exculpability the payee must capture or log the eCash parameters which it deposited to the Consortium (Step 3(b) of Figure 7):
Hash of signed eCash (serial number Siss and its signature sigS ).
eCash denomination (name of eCash scheme)
eCash unit value.
Pointer to corresponding Post-Spend transaction (see above) on the tracking ledger.
For its exculpability the Consortium must keep a transcript of the exchange with the payee for deposits, and also record parts of the transcript on the tracking ledger.
Climate change has a profound negative impact, visible in the plethora of very unpleasant physical consequences, such as the need to move entire cities (including capitals like Jakarta) to avoid perennial flooding, refitting industrial plants on a gigantic scale and the like. Besides, it has a profound financial component. In addition to utilities, extractive industries, construction, etc., some of the financially oriented industries, including banking, insurance, asset management, pensions, will suffer very substantial losses. The Wall Street Journal dubbed the recent bankruptcy of the major Californian utility PG&E, “the first climate-change bankruptcy.” There is no doubt in our mind that it is not going to be the last. According to the Bank of England: “Climate change poses significant risks to the economy and to the financial system, and while these risks may seem abstract and far away, they are in fact very real, fast approaching, and in need of action today.”
Experience suggests that protestations alone are insufficient to convince people to make their behavior more environmentally friendly. Thus, we need to introduce a set of suitable financial tools and incentives, which can gently push people in the right direction.
We can achieve the above goal by introducing the Environmental DTC (EDTC) - an environmentally friendly version of the DTC. There is an example we can model such a coin on, namely, a coalition loyalty program. A loyalty program can be conceptualized as an amalgamation of several single issuer loyalty programs so that that loyalty points can be accrued and redeemed at a variety of participating businesses. From their humble beginning in the seventies when American Airlines launched the first frequent flyer program (incidentally introducing the term itself), loyalty programs have grown exponentially.
The economic value of these programs is enormous. For instance, in January 2019, Air Canada, along with TD, CIBC, and Visa, acquired a loyalty program called Aeroplan, which has about 5 million active members, from Aimia for CA$450 million in cash. Besides, they assumed liability for the unused Airplane points at an estimated value of CA$1.9 billion, at 2.5 cents a mile. Given the above, the potential benefit of the EDTC-related deployment along the loyalty program lines can be substantial.
A vital part of loyalty programs, including EDTCs, is a platform for business intelligence reporting and analytics, which analyzes member information, tracks purchasing patterns, identify profiles of loyal members, and aligns its loyalty program with members’ preferences. For the EDTC to be successful, the utmost attention should be paid to privacy-preserving measures.
The EDTC ecosystem consists of several components. Its heart is an efficient, precise, and easy to use app, which records positive actions by program participants. This app is a “money printing press.” The next constituent part of the ecosystem consists of individual participants interested in fighting climate change and attracted by suitable financial initiatives. Their natural counterpoint is corporate sponsors, i.e., companies and taxing authorities sufficiently concerned about climate change to be prepared to spend money to fight it. Currently, all major companies with exposure to climate change and sustainability have substantial budgets to support environmentally friendly proposals. In turn, Environmental DTC presents them a source of income via attracting more customers and increasing revenues and profitability, cost-cutting on sustainability infrastructure, and a tool for reducing climate change bankruptcy risk such as experienced by PG&E. The glue holding the EDTC ecosystem together consists of coalition members, who are prepared to accept EDTCs for partial payment for their goods and services. For instance, a utility provider might allow paying up to 10 percent of utility bills with EDTCs. A coffee shop might charge up to 10percent in EDTCs and use them for buying environmentally friendly coffee beans or paying its electricity bills. AI-based data collection systems and blockchain technology can be used to record EDTC balances of all activities of participants, sponsors, and coalition members in a robust and reliable ledger.
Since participants earn EDTCs for performing seemingly unrelated activities, such as walking instead of using a car or consuming green electric power instead of the conventional ones, a fair mechanism that brings all these actions to a common denominator is crucially important. There are several possibilities. For example, different activities can be valued based on their reduction in the participants’ CO2 footprint.
Implementation of a robust monetary policy, which determines the rate of disappearance of EDTCs earned by participants with time, is crucial for the stability of the ecosystem as a whole. A comparison with successful loyalty programs suggests that a form of demurrage is the most natural. In simple terms, it means that EDTCs accumulated by participants should expire and disappear after a certain period, the same mechanism that exists in various frequent flyer programs.
It is necessary to design suitable circulation rules by identifying “sources and sinks” for EDTCs. If we follow a strict loyalty point analogy, we must conclude that EDTCs are created at “source” when individual participants perform environmentally friendly actions and destroyed at “sink” when they are used as partial payment for goods and services. This setting is overly restrictive because it obliterates the useful WIR analogy, by which EDTCs should not disappear at all. It appears that an intermediate solution is in order. EDTCs can be both earned by participants and borrowed by sponsors. There is an intermediate level of businesses accepting EDTCs, which also can use them as partial payment for their own needs with the participating coalition members. Finally, there are “super sponsors” who accept EDTCs but destroy rather than recirculate them. Such sponsors may include tax authorities, major multinationals spending part of their climate change budgets on promoting environmentally friendly policies.
In this paper, we have discussed conceptual underpinnings and technical approaches to building DTCs. We have shown that DTCs have several decisive advantages compared to more established cryptocurrencies, such as Bitcoin and Ripple. In addition to being a convenient transactional cryptocurrencies for the internet era, DTCs can serve as important counterbalance to fiat currencies, and, when fully developed, can play the role of a supranational currency facilitating international commerce and allowing groups of small countries to create their own viable currencies.