 |
October 17, 2025, 01:59:39 PM |
|
I have been working on actually-stable coins all along, so I shall not assume that by stablecoin you mean a coin pegged to fiat, or for that matter even one pegged to gold or some other peg.
One thing to observe as prices fluctuate is that it need not be the case that price is the same thing as value.
Price is value modified by local factors and convenience, we see this for example in "convenience stores" thriving on charging higher markups on the same goods their customers could get cheaper at some momentarily or persistently less convenient location.
Price is more volatile than value, in effect, even if over a longer term persistently lower or higher price can shift a population's perception of value.
You can see this in things like the price of an outfit of clothing suitable for worktime wear by professionals; a nice toga belt and sandals outfit cost much same same supposedly back in the Roman Empire as a comparably nice "suit" with belt and tie and shoes does today, if measured in some similarly stable commodity such as gold.
The value of being dressed in accordance with the norm expected of a professional hasn't changed a whole lot in thousands of years it seems.
So I have initially been focussed on retaining value rather than on the much more volatile "price".
Price tends to be dependent upon the specific marketplace, maybe partly because holding a market in a expensive neighborhood has higher overhead costs than holding it in a slum; even the standards of dress of retailers in such markets can be different, slum-marketplace dress possibly seeming out of place at rich-neighborhood markets for example.
So price is not something one can as readily make more stable as value is. The exact same ("fungible") commodity can easily, and often does, fetch different prices at different marketplaces.
Stabilising actual price is a marketplace-by-marketplace problem, basically the problem of providing at each marketplace enough "liquidity" to enable that marketplace to continue to operate at the same prices as other marketplaces.
One of the first moves I made was to reverse the usual "market cap" idea, since that tries to come up with value based on price instead of coming up with a price based on value.
Instead of taking a momentary price and multiplying that by the number existing of the fungible commodity bought for that price, I build a "treasury" for each fungible commodity and divide the total value of that "treasury" by the number of units of the commodity in existence to compute a price.
Think of it as like a "recommended retail price"; to "peg" the commodity to that price in any specific marketplace or shop or store or CEX or DEX or whatever is a whole different problem, but any pegging requires something to peg to so it is at least a step on the way.
There is also of course the fun factor, the fun of running around from marketplace to marketplace looking for "bargains"; something you might have noticed about "recommended retail price" is that you can almost always get things cheaper than that somewhere, even if the more of a bargain-price you find the more seedy or dubious the market you find it at might seem...
At some point on the more and more of a bargain curve you likely start to wonder if the bargain might be "too good to be true" as it were; that maybe that marketplace is not a good place to buy and so on.
One can maybe approach the pegging problem a little at a time... that is where the "treasuries" idea begins.
Ultimately the price computed by dividing the total value of the treasury by the number of units in existence provides a mathematical certainty that there actually is enough value reserved specifically for the redeeming of that asset or commodity to redeem each and every unit of it at the computed price, as measured in that same measure of value.
So the problem is pushed back to whatever unit of value you use as unit of account to come up with the total value of the "treasury".
This becomes a circular problem, a constant-feedback problem such as "spreadsheets" were presumably built to handle:
A loop is implied, in which for each asset you calculate the value of its "treasury" based on your most-recent calculations of those assets' own values per unit, round and round and round until your entire table of "Latest Rates" does not change from one iteration of the loop to another.
The more assets used in the "treasuries" and the more evenly they are distributed among those "treasuries" the more stable the over-all results become against any changes made to what any particular "treasury" contains.
The calculated price per unit for each thing can be regarded even as a "liquidation value", not necessarily in the sense that liquidating it at any particular venue will yield that much but, rather, that liquidating - dissolving - the entire asset, breaking its "treasury" open and distributing the contents proportionately to holders of the asset, will yield approximately that much.
I say approximately there because of course dissolving one of the assets used in the "treasuries" will change the contents of the "treasuries" as each "treasury" ceases to contain any of the dissolved asset and contains instead its proportionate part of the contents of the "treasury" of the dissolved asset.
Thus changes will ripple and resonate throughout all the remaining assets, but hopefully the more assets there are in total in the system the less change dissolving one of them will make to the calculated values of all the others.
Is your idea something along these same lines?
-MarkM-
|