An elastic supply coin like what I’m currently working on will make sure that spikes in interest don’t cause unsustainable bubbles, so the average person won’t be buying an overvalued coin. Perhaps without bubbles most people won’t ever hear of a currency though. Every time I mention my coin project to somebody they usually express disappointment when I get to “hodling will never net you money, by design”
Every time I mention my coin project to somebody they usually express disappointment when I get to “hodling will never net you money, by design”
You might not be talking to the right people
It also might be possible to reward coin holders in ways that are not purely speculative. You could redistribute transaction fees (although this does come from users, it’s a lot more ‘fair’ then a bubble), or have some other use case for the coin so they people have a value case that isn’t just selling at the top.
Well the coins are used in a larger blockchain project whose value proposition isn’t primarily giving people a less volatile coin, but rather trying to smash the “blockchain trilemma” of decentralization/scalability/security as hard as possible at the expense of layer 1 features.
So no Turing complete smart contracts, you just have UTXOs with an unlock script system barely powerful enough for light-client-usable metachains, transactions within a block can’t even depend on each other, and so on and so forth. Almost any dapp is gonna have a pretty deep protocol stack with the blockchain sitting at the bottom. The idea is to imitate IPv4: build something that’s really good at doing one thing at the expense of direct usability (best-effort datagrams? seriously?), and let layer 2 and above evolve while layer 1 stays rock solid and never even hard/soft-forking unless in extremely extraordinary circumstances. I might post about it once I have a proper website and team and everything unless that’s considered spamming your own coin.
Anyway to get back on topic the less volatile coin would be the coin used to pay transaction fees and such, so I suppose if my blockchain somehow takes off the coin would also become a fairly successful currency. Unfortunately it seems blockchains only gain interest when their native coins undergo speculative bubbles…
@ MihailoBjelic well said! In the paper it says exactly that, it’s a very interesting approach and idk of any attempt on that still, have to signal a pretty similar approach - in the sense that use a P-controller - and it’s NuBit, really old the idea and easy: to stop the price to go up, you create an “artificial” sell wall, managed from the delegates (it’s a DPoS); but you can’t stop selling this way, so you try to incentivize the buying getting a better PoS reward for holding the coin. This was my tl;dr, sorry if not clear.
Important note, technically demurrage is done to achieve exactly the opposite, that is to say inflation and currency devaluation, this is done with the idea that currency should flow, and that giving possible incentive to hold and stop the flow is very bad and dangerous for the economy. If I understand you mean to create a system where dM/dt ∝coin_price-usd_dollar_price, (M=monetary mass, t=time) demurrage is only one direction. But ok I get the concept I think.
Hello from Radix (also my first post here).
Radix is experimenting with all three approaches as OP mentions. The most interesting being the third approach of having a decentralized bank that runs on an algorithmic supply policy baked into the protocol. Yes, its quite hard to burn the currency during low demands to keep the price stable, but we do believe that we have a solution without deducting them from the wallets of our currency holders or creating bonds. Moreover, this economic policy needs to react in real-time to demand pressure. To further this cause, we have built a DEX as a part of our protocol that will help us gauge demand in real-time and feed this data into the monetary supply policy.
It will be helpful to get external feedback. The economics white paper will be published soon, so ill post it here when its available.
I actually think that for Radix’s goals, which if I understand correctly is to simply be a low-volatility currency independent of any peg, a way of burning currency during low demand might not be necessary, since coins get lost randomly anyway. Huge declines in demand will still cause price crashes, but such declines are really unlikely, since maintaining a peg isn’t going to be a big value proposition of the currency that people speculate upon. Small declines would have no reason to trigger panics, unlike in a traditional stablecoin.
Such a coin’s price would probably behave something like the price of paper. Paper is fairly durable and fungible, but unlike commodities like gold speculative bubbles don’t form for paper, since it’s is produced at a fairly constant cost (unless demand spikes so high you run out of trees) and thus has an elastic supply. Drops in demand of paper, though, generally do not cause dramatic collapses in paper prices, since few people “invest” in paper expecting its price not to ever drop anyway. Paper “gluts” certainly cause depressed prices, but of a much smaller magnitude than gold or bitcoin crashes.
Actually, we use both, byzantine fault tolerance and byzantine fault detection techniques. Vector clocks are not new, and have been extensively used in distributed systems for synchronization and for causally ordering transactions. Vitalik recently posted a great article on it. I could go into more detail why having fault detection for validating transactions is many times more efficient, while only invoking the consensus mechanism when malicious transactions are detected, to discard them; but this topic demands a blog post of its own, or you can head to our docs to read more about the Radix project.
I’m certainly not objecting to vector clocks, but rather relying on them to work correctly in a byzantine environment; I misunderstood Radix DLT to provide proactive byzantine fault tolerance rather than fault detection. I’ll certainly read more about Radix!
I still think in many cases proactive fault tolerance is much better than “eventual fault detection”, since “eventual” is unbounded in the case of an asynchronous network. In practice networks are likely to be more centralized, less protected, and less costly to use as an attack vector than compromising enough stake to subvert a fault-tolerant consensus. Blocking a fault-detection signal in the very short-term is not really difficult. This also leads me to be a little skeptical of things like fraud proofs that fundamentally require network synchronicity to work (though I do think that they are a great idea for systems where asynchronicity produces bounded “damage”, like payment channels for smaller sums).
This might just be my personal bias due to my experience dealing with how centralized and adversarial networks are in China though.
I think the idea around stablecoins is to create something that provides a stable store of value. Demurrage kind of goes against this idea. Under this suggestion, the price of the coin will ideally remain close to the target (say $1 USD), but the actual value of holdings will be very volatile. Imagine putting $1 into such a coin. Now if demand for these coins increases, more coins are airdropped and you may end up with say 1.5 coins worth a total of $1.5. On the other hand, if demand for these coins decrease, everyone’s holdings are slashed and you may end up with say 0.5 coins worth $0.50. That the price remained stable wasn’t really helpful for you. You still owned something essentially as volatile as other cryptocurrencies.
By the way, I believe Fragments essentially does this.