On a cryptocurrency of dynamic supply

The main idea: two joint cryptocurrencies are programmed such that one can be exchanged for the other as long as their product remains constant, thus tracking the minimal necessary volume of circulation required by a growing economy in a decentralized fashion. 

0. Posts on this blog are ranked in decreasing order of likeability to myself. This entry was originally posted on 30.09.2021, and the current version may have been updated several times from its original form.

1 The issue

1.1 The only credible challenger to the current system of a centralised issuer of currency would be a decentralised system under the auspices of cryptocurrency. Alas, most of the time, the designers of these ingenious tools just went with “fixed supply is good enough” and left it at that, making cryptocurrency a great store of value, but a shonky unit of account. And how much worse this issue becomes when the user base is growing faster than the global economy (which of course it does)!

1.2 I’ve earlier expanded on what a Tier 3 monetary standard entails, namely no dilution effect of any changes in supply to existing holders, and a monetary supply that broadly tracks monetary demand. 

1.3 By that classification, current cryptocurrencies are, at best, Tier 2 Half designs, with limited ability to facilitate monetary calculation and the allocation of capital in time in particular. Note how nobody would willingly accept having to pay back a loan denominated in Bitcoin.  

1.4 So, here’s the fix: you set up a savings pot and spending pot, and exchange between the two by conserving percentage of change, instead of total sum of the pots. In other words, use Gresham's Law to isolate the two functions or, as I’ve only recently learned, generalise the concept of the constant products automatic market maker to an entire currency.

2 The Platonic Design

2.1 Though this would likely not be the actual implementation, for the purposes of explaining the design think of the new cryptocurrency as being issued as two linked coins: the RedLek and the BlackLek. The issue of each is fixed at the start and no new units will ever be created exogenously.

2.2 You can only get more RedLeks by converting BlackLeks, and you can only get more BlackLeks by converting RedLeks. Such conversion can only be done within each individual wallet, by the algorithm consulting the blockchain to calculate how many of either are currently on issue anywhere in the world, including those that other holders may have converted into, to the degree this is captured by your blockchain history.

2.3 Within these strictures, the exchange rate would be set such as to trade a given percentage increase of one for the same percentage decrease of the other. In other words, the product of RedLeks and BlackLeks will always remain constant. 

2.4 To void the issue of division by zero, prevent any trades that would leave less than one unit outstanding of either RedLeks or BlackLeks. Indeed, to proactively solve for divisibility issues, once such a trade is attempted, automatically rescale the issue of whichever of these coins is trending to one by a million, so that we don’t have to see the system break by eventually reaching the limits of divisibility. 

2.5 After some initial random movements, one of these currencies will begin to see growing supply and serve as the unit of account, whilst the other whose supply will be lowered will serve as the store of value. Note how both coins are better at their respective jobs than a constant supply Tier 2 Half standard such as Bitcoin. 

2.6 That’s it, you can stop reading now, or stick around for section 4 with some potential (somewhat more) practical design options. Feel free to implement or share with those who might, but please keep the names of the coins as they are, give credit and do let me know of the ICO beforehand. Some free allocation wouldn’t be bad either, to be honest.

3 Why would this work?

3.1 If a set of decentralised issuers is to be prevented from hyperinflating the supply away, they must be subject to some form of a feedback mechanism (issuers can’t coordinate to maximise value). Assume RedLeks become the unit of account: what stops holders from creating as many RedLeks or as they can? The waiting game.

3.2 You can get more bang for your buck if you convert BlackLeks into RedLeks later than the others must. If you need to spend while the global supply of the former goes from 10 to 9, you’ll boost your supply of the latter by 11%. If you can wait and convert when the supply of BlackLeks goes from 9 to 8, you boost your RedLek stash by 12.5%, while giving up the same single BlackLek. So you wait, or at least try to.

3.3 Any holder has a finite supply of RedLeks and/or BlackLeks, hopefully no impact at all on the exchange rate, and can only spend the former. Assuming RedLeks are accepted as a means of payment, the more RedLeks are spent, the more the supply of BlackLeks dwindles, valorising the remaining units.

3.4 Some folks have high time preferences and don’t care about no waiting game. Probably not the profile of the usual early adopter of things like these, but if you want to make this money proper you’ll get to those spenders eventually. No problem, after all users hold just as many BlackLeks as their time preference dictate the system will be in equilibrium, and only create new money when time preferences across the entire user base increase, all else being equal. How about that, fractional reserve banking?

3.5 You want others to spend as much as they can, but you should spend as little as you must, all the while keeping your entire portfolio in BlackLeks until such time as you need to spend something, at which time you convert. So, the portfolio will probably automatically do this for you, convert everything into BlackLeks and let you pay RedLeks without the need for you to do a thing, while always showing a (slowly growing) sum of RedLeks as balance. Will people even know what a BlackLek is?

3.6 The supply of RedLeks will increase with demand for spending (to the degree that velocity pickup does not suffice), but no further than strictly necessary to keep up with the spending needs of the economy / user base.

3.7 I think what the setup does is to set the marginal cost of money at the natural interest rate, which I think is optimal. Could be wrong on any or both of those two though.

3.8 Note how this setup ensures full money neutrality: all money created and destroyed is proportional to everyone's holdings and no dilution can ever be experienced. 

3.9 A major issue I can foresee is some genius keeping to himself a large stash of BlackLeks after the initial ICO, which would spook all holders far more than it does with a fixed supply coin (BlackLeks will dwindle in time, and your share will explode if you let it). If a holder has a large enough proportion of BlackLeks such as to impact the exchange rate, the limitations of the system start to cede. In the extreme scenario of just one holder having all BlackLeks (assume away conversions for the sake of the argument), there would be nothing holding him back from printing trillions. Big stashes of BlackLeks left over from the ICO? Don’t do that.

3.10 Could a similar system be implemented in a centralised fashion, i.e. by some Central Bank out of ideas? Central Banks nowadays mostly target inflation. This is just a patch, a rough guide CBs rely on to determine when to amend the supply of money. The real goal, that of matching demand, is attempted only through the stabilisation of some proxy of purchasing power. The system I propose here system would stabilise supply automatically, and no one would need to get into arguments on core inflation anymore.

3.11 The same issue re a large holder of BlackLeks as under 3.9 would come to the fore with a centralised issuer, but harder. So, a central authority using such a system would only work if that authority only functions as a central clearinghouse, tracking everyone’s BlackLek deposits, but holding little of their own (still centralised in the sense of acting as a single point of failure). Monetary Boards are a thing. The centralised version would certainly be unbound by scaling constraints, something I fear the decentralised version may not be able to replicate. No matter, make up for it in anonymity.

3.12 If such a scheme were to be run by a centralised clearinghouse, one could never increase the supply of both RedLeks and BlackLeks at the same time and their product would always remain constant. But running this from a decentralised blockchain would allow for the supply of both to increase in time and their product to vary upward or downward a bit. Not a big issue in the great scheme of things.

3.13 Will this work? Will the issue hyperinflate anyway? Will it ever take off as a spending tool? Will the system be self-adjusting or will the users fall prey to random panics? I don’t know for sure. I won’t claim to know enough about this mammoth system of monetary calculation to make predictions with confidence.

3.14 But I can tell you how to know if it has worked or failed: are there any loans being repaid in RedLeks? If so, and the longer the schedule the better, this has worked. If actual consols are issued in RedLeks, we are done. 

4 Implementation Thoughts

4.1 One option would be to implement the system as described above, with two actual cryptocurrencies working on two separate but linked blockchains for redundancy. One could go deep into the weeds and adopt two different consensus mechanisms to optimise each currency’s role as unit of account and store of value respectively, but I’m not sure that this would be feasible technically given the need for both to be interchangeable.  

4.2 Another option would be to issue just one cryptocurrency, the BlackLek. This can still be created or burned at will, and the algorithm calculates a phantom RedLek as per the constant product formula. Your wallet balance would be displayed in RedLeks though its contents would be BlackLeks. When transacting a set sum in terms of RedLeks, the algorithm would transfer just as many BlackLeks as required. Note how this design automatically keeps your balance in BlackLeks as per 3.5 above, which is the optimal strategy given the system’s constrains.

4.3 Now we go into options that try to jump start the value gain process by linking to an existing cryptocurrency, say Bitcoin. Complexity increases quite a bit though, as we now have to account for a phantom third pool of money besides the first two.

4.4 So, option three would see the issue of RedLeks and BlackLeks linked to locking one Bitcoin: I issue a given and equal number of RedLeks and BlackLeks to you if you lock in one Bitcoin, and will return that Bitcoin if given one RedLek and BlackLek at any time. 

4.5 The constant product of the virtual pool would need to change any time there’s an infusion or withdrawal of Bitcoins, and so we cannot promise to always give you one RedLek and BlackLek for every Bitcoin deposited, though we can promise to always reverse this at a stable one-to-one rate. 

4.6 As an example, imagine a pool into which 2 Bitcoins have been initially deposited, yielding a constant product of four, and which has since seen the conversion of BlackLeks into RedLeks such as to have 4 of the later and one of the former. 

4.7 Now I wish to add one Bitcoin, but if I were given one RedLek and one BlackLek at this point, the sum of currencies would be 5 and 2, for a product of 10, whose square exceeds the 3 Bitcoins we have in reserve. Though unlikely, the owners could coordinate to try to get more Bitcoins in return for the three that they put in. Credibility would be gone and a run would be a matter of time.

4.8 So, instead I can only give you 0.8541 RedLeks and as many BlackLeks for your one Bitcoin now, such as to retain a constant product of three squared. If you were to accept but then change your mind and wish to have your Bitcoins returned right away, you would lose the 0.146 Bitcoins, which would be the pool’s profit and due to no one.

4.9 With this setup (and the upcoming fifth option as well), what “profit” one makes for a round trip depends on the status of the pool at the time of the deposit and withdrawal. I think the tendency is for those who withdraw first to suffer nominal losses, and those who withdraw later make gains, an emergent defence of sort against runs. So, here we have introduced a kind of inadvertent game of chance that may help with adoption. 

4.10 Option four would be to entirely substitute the BlackLek for Bitcoins and use the former’s network for all transactions: there would be no new cryptocurrency at all here, just a special wallet on the Bitcoin protocol. You “burn” Bitcoins by locking them, and the system calculates a RedLek’s value as per the constant product formula, again assuming all such locked Bitcoins are burned.

4.11 As per option two in 4.2, paying in RedLeks would simply mean paying the appropriate amount in Bitcoins, with the rest locked until that wallet’s user decides to unlock some Bitcoins, assuming he has enough of a RedLek balance in the wallet to destroy. 

4.12 Note how, unlike the “pure” design, here you can never create more Bitcoins than you put in, unlike the BlackLek which can be created at will.

4.13 Further, you are reliant on the Bitcoin protocol for all actual transfers, and the only thing you are doing is to coming up with a new unit of account that lets people pay in (ideally) ever decreasing sums of Bitcoin, thus addressing the deflationary tendency of its otherwise constant supply. Any shortcomings of the protocol that may be linked to its consensus mechanism, notably in terms of scalability, are retained. 

4.14 You will need to adopt a rather convoluted protocol for determining what exactly the product would be here though, as detailed after option five is done.

4.15 Finaly, option five would then do away with the propagation network being blockchain based at all, and do all this based on a Chaumian eCash protocol based on Bitcoin. Whilst the issue of rugging could potentially be alleviated by accepting Bitcoin deposits as double-signed escrows, this is till by far the most centralised, though potentially the most scalable, option.

4.16 Like in option three, in options four and five you would need to account for Bitcoin being an external currency, only some of which would be locked in this mechanism. Note how, in the last two options, there’s no pool, and all Bitcoins deposited we consider Bitcoins “burned” which, starting from a balance of zero, makes no sense. So, we have to assume that some number of Bitcoins are extant.

4.17 You could assume that all 21 million Bitcoins are extant, as well as as many RedLeks, but so few Bitcoins would be deposited in both options as a proportion of this that the ratio of RedLeks to Bitcoins would not materially differ from one for ages.

4.18 So, you start by assuming that only 2.1 Bitcoins exist, as do 2.1 RedLeks. When a Bitcoin is locked / deposited with the mint, the constant product would assume that amount is destroyed from the extant 2.1 Bitcoins, and issue the required RedLeks, again assuming 2.1 are already out there. 

4.19 Once the exchange rate hits 1.1, you change the assumptions to assuming 21 Bitcoins were extant (before the ones in the mint were “destroyed”), whilst back solving for the number of extant RedLeks to ensure that what you have actually issued can be fully converted into whatever is the number of Bitcoins the mint actually has, a very simple problem.

4.20 Once the exchange rate hits 1.2, you change this again, assuming 210 Bitcoins extant, and so on until, after the exchange rate hits 1.6, you are finally free to assume that 21 million Bitcoins are extant, and the constant product ratchet stops updating. Even if the exchange rate were to fall after the next step of the ratcheting has been initiated, there would be no going back (its a ratchet, duh).

4.21 Option five relies on a central mint, so all Bitcoins deposited can be fully returned in need. Option four though, relies on each wallet being its own mint, so I’m less sure that the ratcheting mechanism would allow all to be unlocked absent perfect coordination. Also, unlike options three and five as per 4.9, an individual wallet can never make Bitcoin profit under option four, as one can only unlock what was locked in the first place.