On a simpler blockchain of dynamic supply

The main idea: adopt a self-splitting token to mostly counter excessive appreciation or depreciation against the Dollar. 

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

1.1 So it’s not easy to come up with Tier 3 currency designs, but do these have to be as complicated as this one?

1.2 Well yes, if you want a fully self-contained and indefinitely sustainable system. But can we cut a few corners to gain simplicity and legibility?

1.3 You create a given quantity of your token, and no more can ever be created after this point. You pool it all in an (ideally native) Automated Market Maker with a quantity of some reliable stablecoin (assume USD links). This is our price oracle.

1.4 The token reads its price against USD continuously, averaging on a running week basis, and comparing against the same running week average four weeks ago.

1.5 As soon as a price change on this basis is detected that exceeds a ±10% range, a split or reverse split is initiated, where every old token is recoded as x new tokens, where x = (1+Dprice) / 101%, hopefully causing the per-token price to move by as much in the opposite direction, leaving a 1% gain or loss in price compared to four weeks ago.

1.6 Such a split factor functionality would be coded into the design and be updated continuously as above. Perhaps it would link to and update all UTXOs or states recorded. When I send you one token, I really am sending 1/ current compounded split factor of the original tokens. The operations of the AMM under 1.3 would be proofed against the split factor changing, of course, by applying the same split factor to the otherwise constant product.

1.7 Note how the application of the split leaves all holders of our token entirely indifferent: the supply of their tokens will change, with the price changing in the opposite direction and by exactly as much. As befits a Tier 3 standard, our token is neutral.

1.8 But note now what this does for those who either hold now and expect to sell at some point, or those who don’t and expect to buy (i.e. those who interact with the real economy): it enforces a relatively narrow but fanning  band of deviation against USD which our token can never exceed.

1.9 Indeed, now the market can with confidence transact long-term business (loans) in our token (at least take them out if not give them, see 1.19), armed with the certainty that it shan’t lose or gain more than 23% against the USD at the very worst moment (11 monthly increases and the moment just prior to the 12th), or 14% in any one year in the long run (and you wouldn’t in practice get 12 months of consecutive growth anyways), instead of shooting up like Bitcoin. As befits a Tier 3 standard.

1.10 Also note how that 14% p.a. is roughly equivalent to the expected gains of a diversified portfolio, i.e. the risk-free rate in practice. Which should be zero, and only exists due to excessive dilution of USD, which we counter here.

 1.11 The simple operations of the algorithm would be coded in the blockchain itself, calling for a very basic virtual machine. Ideally, the AMM and its operation too would be coded therein as well, for a nearly entirely enclosed system, at the cost of a somewhat more complex code base to run virtually. 

1.12 The design is a simplification of my RedLek/BlackLek duo, with the token and the stablecoin playing either part, but would only be as good as the stablecoin it relies on, the only external input into the system.

1.13 At a deeper level though, the real issue with this design – and the reason it is only a medium-term alternative – is that it is tethered to USD, and can only escape its trajectory by 14% a year. If USD crashes into hyperinflation, we will crash with it, but as long as it behaves reasonably, the 14% buffer would be plenty.

1.14 Of course one could change the 101% factor that enforces this link to 102% or a higher number, but I do not know how to encode a rule for this that does not rely on nodes voting and gives algorithmic certainty to holders.

1.15 You could, I suppose, encode a ratchet such that 20 or so consecutive splits in a row (each four weeks apart, as measured on a block count basis) would trigger an increase of the factor from 101% to 102% (consecutive reverse splits would then lower the factor to a minimum of 101%), but have not fully gamed this out not thought about the proper schedule to encode.

1.16 Now, this simple design showcases a potential conflict between neutrality and facilitation of long term loans: I would agree to replay a loan denominated in this token given the anchor against USD, but I might be less inclined to lend in it.

1.17 If I expect the value of my holdings to increase (semi stable price but increased number of tokens) given positive real growth rates of the economy and a constant portion of the total supply of tokens for me, why would I loan them out for anything but the expected increase plus some margin on top? And if I do so, what is the point of the split function, if it just gets baked into the interest rate anyway? 

1.18 Long story short, neutrality implies that gains from real growth of the user base accrue to the current holders.

1.19 Though not an issue limited to this particular design, it would appear that people might take out loans in USD to be repaid in our token, instead of directly lending out the token itself. Some improvement over current arrangements, but not as much as one might have hoped for and no full replacement for the USD yet.

1.19 Now, I'm aware that an expected price increase translates into an immediate price increase if shared widely enough, but I'd still like the system to be proof against this, which this isn't.