In my previous post, I started with presenting how Hive distributes newly minted tokens in order to introduce the DHF, which is the built-in DAO to fund further blockchain development.
I ended by proposing what I believe should be a prioritary feature to introduce: a Hive-Backed Euro (HBE) alongside the HBD.
Now this could be a good idea or a bad idea, depending how it's implemented.
But first, the objectives.
Offering "a chance to arbitrage between HBD and HBE" is not among the objectives I had in mind. As a matter of fact, I tend to think the code should including an "arbitrage bot", that should mop up the most glaring arbitrage opportunities. But because we all like to play and speculate, yeah, sure, why not?
Being "easier to follow by europeans" and the symbolism of "appearing less US centric" - yes, why not, but very far from what I consider the core objectives.
To me, the core objective is to make Hive a platform on which small businesses in Europe could receives payments from customers.
The power of an actual cryptocurrency
Remember my post from long ago about paying for beer in luxembourg with SBD? One of the reasons the project didn't take off is that the merchant had to shoulder the currency exchange ('FX') risk. His barrels of beer were billed in euro and his margins were slender. With payment in USD (SBD at the time), a 3% variation in the EUR/DOL rate (plus additional friction in the crypto-fiat gateways) and he had to forgo his margin, or basically "work for nothing".
Let's not forget: with the Hive blockchain, we have payment rails which are fast and free (and consume very little RC and storage space). Yet they are underutilized because of volatility. In order to integrate with the fiat economy, you need a stable "medium of exchange", an actual currency, whose value with respect to a basket of goods and services is as stable as possible.
How would a HBE be implemented?
It would start in the interfaces, where users can already choose between being paid "100% HP" or "50% HP and 50% HBD". The interfaces could add a third option "50% HP and 50% HBE" (I know I would choose that option, I guess most people in the Eurozone will do the same as soon as they become aware)
At the backend, a robust EUR/DOL oracle needs to be connected. That is not too difficult, anyone can get a very accurate EUR/DOL rate for free from a zillion of reputable sources.
When the virtual op to pay for an article executes, if the author choice has been to be paid in HBE, the oracle rate is used to mint HBE instead of HBD at the spot EUR/DOL rate. Internally, that oracle can be used at each block (or less often) to compute a global "debt" rate for the haircut rule. Conversions to and from HBE will be possible with the internal EUR/DOL oracle informing the calculation by providing the HBE/HBD ratio.
Users would be able to choose to convert HIVE to HBE (using the HBD rate provided by witnesses multiplied by the much more stable EUR/DOL rate provided by Google or Reuters or the FT or basically any data provider on Earth for free). And similarly HBE could be converted to HIVE by using (internally) the oracle to transform HBE to HBD at the same moment that the HBD/HIVE ratio provided by witnesses is taken.
The most important part is to have a "HBE stabilizer" for users of HBE to be able to sell their HBE instantly on the internal market at a rate as close as possible to 1 eur in Hive. A eurozone business accepting payment in HBE would automate that: as soon as a HBE payment is received, it sells HBE on the internal market (hence an AMM with ample liquidity is needed), transfers the resulting HIVE to Binance, sells HIVE to USDT and USDT to EUR (which it accumulates there for use in bulk, possibly through a Binance credit card). While Hive has no transaction fees, all the steps involving Binance introduce friction and transaction fees but these can be dealt with if they end up being less than what VISA and Mastercard charge in fees.
@gadrian writes "You no longer have one debt token, you have two of them: HBD and HBE". Several things come to mind here:
- "So what?" - companies do not have only ONE debt instrument. They issue long term and short term debt at different rates, with different maturities and covenants ... it's just maths that can be coded, there's no wizardry involved.
- As said before, the EUR/DOL rate is probably the cheapest and most reliable piece of financial information one can get. Integrating an internal oracle that uses that info is neither difficult (I believe) nor particularly risky. Then you don't have "two debt tokens" but, for all practical purposes, ONE debt token (because the internal oracle pegs the HBE to HBD easily).
He also writes "HBD has in fact nothing in common with USD apart from the soft peg to it." Hell, yeah ! That is HUGE! Because of that soft peg, TerraUSD attracted tens of effing BILLIONS of inward investment to Luna!!!
Yes it was a scam and it imploded, but we know HBD is not and has much better mechanisms which protect it from imploding.
Please, read that again: Luna went from basically nothing to tens of billions of market cap on the back of the soft peg between TerraUSD and USD and not much more! Well, also some aggressive and deceptive (and fraudulent) marketing ... The demand for a true currency, whose value with respect to a basket of goods and services remains stable, and which avoids the traditional bank payment rails is ENORMOUS.
Also, there needs be no "change to the tokenomics". For all practical purposes, the HBE would be internally converted to HBD. There has to be a buffer for variations, like in a "currency board", a "strictly rule-based institution" (hence codable in a smart contract) but there are many books and articles on the topic and implementing a currency board is not rocket science:
See for instance the World Bank, the IMF, the Review of European Economic Policy, the OECD, even NATO has sponsored research on this topic!
@gadrian ends his comment with "I wonder if a different solution might be easier to implement"
Sure. But what for? My fault, I didn't state the objective clearly. It's not about "seeing the amounts in euro" (which Ecency already allows). It's about using Hive for B2C payments in the Eurozone. A small business can choose to accept instant payments on Hive if they are ultimately cheaper, faster and less reversible than credit card payments.
A Eurozone small business pays its suppliers in euros. It can't accept payment for its products in dollars because of the unacceptable currency exchange risk this introduces. It wants to be paid in euros as well. For this, you need a "euro-stablecoin". The HUGE advantage of implementing such a cryptocurrency on Hive is the absence of transaction fees.
I do believe that this can make sense, But concerning the arbitrage bot, if it's meant to be built into the system, then it should not collect profits for anyone. Arbitrage profits should be burned. If this sort of bot is meant to be used by anyone to trim the peg, then that's fine too.
Other than that detail, I think that this is a good idea and should be coded as soon as possible, so that it can receive some testing and real world usage. If no one is using this system, I do believe it would be best to retire it quickly, but if it ends up being useful, then it will truly be a feature, with only a few weak points.
I totally agree, the arbitrage bot should be built-in and not collect profits, burn the profits.
Once this is available, there should be some time allowed for a marketing push.
One thing I'm missing in Hive Keychain app for instance is the ability to pay phone-to-phone by reading a QR code. Currently if I want to pay someone using Hive Keychain I first go through a double authentication (is that really needed?) and then I'm on a interface with too many choices.
I'll need to select HBE, select "send" and then type in manually the name of the recipient. It would be really cool if that process could be streamlined
It's much simpler than it actually seems. The debt can also be issued in HBD and all the rest of the operations as well, it would be enough to define an "official" conversion price, as we do now to convert Hive to HBD and one could hypothetically support any foreign currency pegged token in an "official" manner
yes, implementation is not complex, and not too risky - it can be kept at arm's length from the rest of the economics of Hive
Ok, B2C could be a great use case for a euro stablecoin on Hive (or elsewhere, but on Hive, as you remarked, there are no fees).
And let's assume the implant of HBE in the Hive economy is as easy as it sounds from your post. I don't think it is, but I am too tired right now to find reasonable technical counterarguments.
If HBE was implemented, who would list it? Otherwise, what would be its point from a B2C point of view? We already know how few exchanges list HBD, which is our main (only) stablecoin. Do you think a fiat gateway would bother listing HBE? Well, maybe it would if their listing fees are paid.
No, it needs an internal fee-less market like the HBD - HIVE but with an LP and an AMM (like on typical DeFi swaps). It needs not be listed outside at first. Although, if it catches on, it might become listed.
I explained in the post how the exchange from HBE to actual fiat euros could be automated (although going to a couple of Binance trades will add fees and a little risk too)
Ok, but why does it need to be at the base layer? There's too much risk involved when updating the economic part of Hive. Something like that can be created at the second layer or on a sidechain.
And obviously, as someone living in the EU, I'd like to have a Euro stablecoin, so I'm not against exploring such an eventuality.
But then, some people from other parts of the world may want their own regional stablecoins. And complicating the base layer tokenomics will only result in potential critical errors down the road, plus it will make the whole Hive economy difficult to update/upgrade when it will come to that, and potentially may have some effects on scalability (although for Hive, posts and custom JSONs have a much higher weight than financial transactions).
On the base layer because of its importance?
We are talking real money, you need some serious security! You can put inconsequential game transactions on a flimsy second layer (Hive Engine is down every other day) but you can't actually pitch an unstable and unsecure system such as hive-engine to real businesses and encourage them to use it to handle tens of thousands of euros or more every day !
For Pete's sake, we are talking actual financial transactions! Real sums of money, not "social media comments". Let's get a sense of relative importance. If you move something to the second layer you should rather considering moving the "post / comment" transactions (such as this one) to the second layer ...
Yes, some people from other parts of the world may want their own regional stablecoin. It should be considered depending on a rigurous cost-benefit analysis. The base layer tokenomics will change very little - once you have one "reverse convertible" (HBD) you can extend to as many as you wish at little cost. And it would not change the tokenomics, as I've tried to explain in the post above (and clearly failed). The same number of HIVE will be minted, the same total "debt" will be supported, the same haircut applied. The difference is that, if today we have 20 000 000 HBD, once HBE is introduced we might have (for illustration purposes) 10 000 000 HBD and 9 090 909 HBE (at a rate of 1,10 HBD to 1 HBE). It shouldn't impact the Hive economy at all (again, I've tried to explain that and failed miserably), it's modular and transparent to the rest of the economic design.
And yes, it might have some effect on scalability. This is why the topic needs to be discussed by the community: what would you rather have on Hive: 1 custom_json from a little game or 10 value transfers corresponding to real people buying real stuff in the real world and paying through Hive rather than through the banking system? Which one do you feel will have the most impact on the world at large and will ultimately benefit more to the whole community? For me the answer leaves no doubt
You've made some important points here.
Should comments or custom JSONs be moved to a second layer/sidechain (by the way, when I was talking about "weight", I was talking about number and size, not relevance or importance)? Indeed, it makes sense to have serious financial transactions on the base layer. And there have been recurrent proposals in the community to stop rewarding HIVE Power (or HBD) for creating content and leave it exclusively at the communities level. So far I haven't seen this subject gather significant interest.
Or the other hand, should we do such a move? There are other blockchains out there that handle financial transactions and only financial ones well.
As I was writing this comment I was wondering... How many US small businesses do we have using HBD? Not many. Maybe Europe will turn the leaf for the better for crypto businesses starting with MiCA. We will see...
Great idea!
thanks!
Interesting concept. I would !LUV to see anyone of hives devs sound off on this.
@sorin.cristescu, @wanderingmoon(1/1) sent you LUV. | tools | discord | community |
HiveWiki | 
NFT | <>< daily
Yeah, me too! :)
Thx!
I get you completely, it seems to be no different to just having HBD, it's just like changing out some of the HBDs for an oracle-managed HBE, so it seems like a no-brainer, I mean the two FIAT pegs are relatively stable in relation to each other.
Would seeding with an initial HBD - HBE conversion be an idea? Because if we're relying on payouts as the only mint, liquidity is going to be tight for ages for trades.
Also I'm not sure how easy it would be technically to implement this, it's about as deep as it goes in terms of chain code I'm sure.
Great idea though! Makes total sense!
Congratulations @sorin.cristescu! You have completed the following achievement on the Hive blockchain And have been rewarded with New badge(s)
Your next target is to reach 84000 upvotes.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out our last posts:
Support the HiveBuzz project. Vote for our proposal!
great idea, should be discussed further!