<center>![crystalball.jpg](https://images.hive.blog/DQmPMBUep2qU143C8RsUo3unu9UxT4hyst4Mpp6vj2pv58h/crystal-ball.jpg)</center>

A big part of the [project I'm trying to build right now](https://peakd.com/hive-167922/@edicted/magitek-tokenomics) DEPENDS on the witness price feed.  While we are trapped in the <code>void</code> behind the <code>firewall</code> the only way to guess how much FIRE tokens are worth will be to assume they are pegged to Hive.  Not a great solution but it should be good enough in the beginning.  Considering the only way to create FIRE will be to send HIVE to @null it makes sense that it would maintain the peg for at least long enough to come up with some better solutions. 

This peg is very important because it will estimate the value of FIRE.  Using that estimation I'll figure out the value of all the other tokens (MANA, LIGHTNING, ICE) so if the value of FIRE is wrong the value of all the other tokens will also be proportionately incorrect. 

I'm starting to realize that even though the price of FIRE should be hard-pegged to the upside due to being able to destroy HIVE for it, this is actually not the case.  It's possible that FIRE is worth more than Hive and users wouldn't realize it because there is no other baseline but the price feed. 

When it really comes down to it, the only way to know how much something is worth is to track how much users on the outside of the network are paying for it.  When I boot up this project there will be very little connection to the outside so this will be quite hard to calculate.  I'll figure it out. Definitely need to set up over-the-counter trades.  Shouldn't be too hard. 

<center>![witness.jpg](https://images.hive.blog/DQmSzedsjPmkLHfPtSYtM64EeMvB5j9aqiGfGvXkGBngZdZ/witness.jpg)</center>

>####  Do you solemnly swear to to tell the truth, the whole truth, and nothing but the truth? 

#### Sure, why not? 
But the point of this post is to showcase how ridiculous Hive is in many aspects.  I always get reminded of these facts when I find the strength to continue development and learning about the API.  Our documentation is trash and our functions are cluttered and nonsensical half the time.  We always need more devs.  Hopefully this time around we'll actually be able to retain them rather than lose them to the bear market. 

<center>![t1.jpg](https://images.hive.blog/DQmPEBzkTsrodjXuHzHUoCfwBZZc7hCLVGVwdPqcu4Vtozp/t1.jpg)</center>

#### So yesterday I started tracking the price feed. 
There are so many things wrong here I don't even know where to begin.  First of all lets start with why the price feed exists.  Hive does not know how much HBD to print without it.  If 1 Hive is worth 10 cents very little HBD will get printed because HBD printing needs to match inflation.  If our inflation rate is only 8% we need to print less HBD when the price is low so we don't print too much.  If 1 Hive was worth $10 we'd print x100 times more HBD than if it was 10 cents. 

#### So what's wrong. 
So so many things... first of all, this 'feed_publish' operation isn't the only way for witnesses to change the feed.  Many witnesses started doing it another way more recently. 

#### https://github.com/someguy123/hivefeed-js
@someguy123
@drakos
@yabapmatt
@rishi556 (@hextech witness)

So apparently even my own witness team has a hand in this.  
There's a new way to post price feed that looks like this:

![t1.jpg](https://images.hive.blog/DQmSq81XbRAY3UzyCxh4Y1zCay6Z7FSFi4FZadKFwAyHEBE/t1.jpg)

#### <code>witness_set_properties</code>
By changing the <code>hbd_exchange_rate</code> on the witness properties this gives witnesses another way to change the feed.  Why is this useful?  Because the <code>feed_publish</code> operation requires the active key and the witness_set_properties only requires the witness' signing key.  It's a nice way to add some protection to the active key so that funds can be less easily stolen in the event of a hack. 

The problem with this clusterfuck is that how the hell am I supposed to convert this gigantic hex string into the useful price feed that I actually require? 

>19020000000000000353424400000000e80300000000000003535445454d0000

>17020000000000000353424400000000e80300000000000003535445454d0000

>fa010000000000000353424400000000e80300000000000003535445454d0000

>18020000000000000353424400000000e80300000000000003535445454d0000

>79020000000000000353424400000000e80300000000000003535445454d0000

>85020000000000000353424400000000e80300000000000003535445454d0000

Upon further review, the only numbers that change are the first four digits.  This makes sense as only the HBD price changes while the other three variables remain static.  So what happens when we run this thing through a HEX decoder?

#### https://codebeautify.org/hex-string-converter

![t1.jpg](https://images.hive.blog/DQmToQSBZS8FapiK6wtUyt1k8zsQzfuMmNNM3htu2PgkL2P/t1.jpg)

### SBD and STEEM!!!!!
GAH, I thought we were past this bullshit!  The ghost of Christmas Hostile Takeover remains.  Not only that, it wasn't even able to decode the beginning part that I actually need.  Here's what it's supposed to look like:

> base: '0.505 HBD', quote: '1.000 HIVE'

Considering there are only 4 parts to this hex it's probably:

> 0.505 SBD 1.000 STEEM

That's being stored in the code.  The reason why 3 of the parts remain static across all <code>witness_set_properties</code> updates is because "SBD 1.000 STEEM" never changes. 

### No problem, right? 
I should easily be able to find the documentation on this.  All I have to do is decode 4 hex digits.  How hard could it be?  Over an hour later and all I have is more questions as I fall down the rabbit hole of shitty documentation wondering how this patchwork hackjob operates. 

##### https://openhive-network.github.io/dhive/index.html
I use this DHIVE API.  There are many clues here.  

<center>![t1.jpg](https://images.hive.blog/DQmVw1RQCGJsnRbBeAxWD8F44WvAg1m3aoTfaT6TmsmjWd8/t1.jpg)</center>

It appears as though the price has been serialized into this hexadecimal form.  Serialization is a very important process that occurs when we need every node to be on exactly the same page.  A single digit out of place would cause an error and possibly even an unintended fork of the network. 

#### So how do I decode this shit? 
Someone who actually knows what they are doing will let me know. 100% upvote pending. This is the future of development: getting paid to help people with their tech problems is a must.  https://stackoverflow.com/ is due for a huge upgrade. 

### In any case
There's still a lot more stuff to say.  First of all, it is very foolish to even pretend that this operation is an HDB EXCHANGE RATE.  @Dan Larimar was a little to big for his britches on that one.  This is not an HBD price feed it is VERY OBVIOUSLY a USD price feed.  The network simply assumes that HBD is pegged to USD, which of course it is not.  On top of HBD not being pegged, not using the correct verbiage is downright confusing and betrays what is actually happening in the background. 

### USD PRICE FEED
We need to know how much Hive is worth in terms of USD, not HBD.  Why?  Because USD is the larger network connected to a much bigger community. The stability of USD allows the feed to anchor Hive to the greater network, just like I'm trying to anchor my project to Hive with Fire tokens. 

When the witness post their "HBD" feeds they are really posting "USD" feeds and calling it HBD as if HBD is the same thing as USD.  Pretty ridiculous on every level.  What do you think, @blocktrades?  An HBD feed isn't useful; a USD feed is (which is exactly what we have but we call it HBD to act like we have a functioning hard-pegged stable coin).  Even if we did have a hard-pegged stable coin it would still be a USD feed, as the only purpose is to determine the price according to the outside world. 

<center>![oracleprophecycrystal.jpg](https://images.hive.blog/DQmZAtHxAo44MQt6FUBGibyke55rePu3DmLeTKcdty2x9QP/oracle-prophecy-crystal.jpg)</center>

### Underutilized 
It's very clear to me that we are completely wasting one of the most valuable resources we have: witnesses.  Networks like ChainLink are working day and night to come up with decentralized oracle systems, and Hive already has a decentralized oracle system built in and we don't even use it. 

The only oracle service Witnesses are providing at the moment is this price feed.  Why?  There are so many things we could be doing with this.  For example, if witnesses were feeding Bitcoin block hashes into the system we could be running lotteries and other unhackable gambling dapps on Hive. [Project Lottoshi](https://peakd.com/hive-167922/@edicted/project-lottoshi) comes to mind.  If witnesses were monitoring certain Bitcoin wallets or wallets on other networks we [could be doing atomic swaps right now.](https://peakd.com/hive-102930/@netuoso/atomic-swaps-with-hive-core-integration)  

### Conclusion 
At the end of the day we always need more devs, cleaner code, and better documentation.  We're constantly touting that Hive is a great place to build because "it scales".  Yeah that's great.  Too bad the learning curve and the documentation is dogshit.  I shouldn't have to waste an hour trying to figure out how to decode a price feed.  That's fucking ridiculous.  Multiply that frustration by x1000 to know what it's like to try and build here.  We've got a long way to go.  As Jeff Bezos would say: "It's still day one." 

Posted Using [LeoFinance <sup>Beta</sup>](https://leofinance.io/@edicted/witnesses-as-oracles-vastly-underutilized-resource)