HERTZ - Oscillating Formula Based Asset

[R]

During the bitUSD GS, don't forget to check out Hertz as an alternative to short 👍

[R]

https://bitsharestalk.io/btstalk-dev/@customminer/updated-hertz-aba-whitepaper-check-it-out

Updated the Hertz whitepaper 

[R]

that commit mainly changes the warning/skip levels ets...

seems to be a bigger issue in play here..

Does it work for you?

I've not had any feedback from witnesses regarding hertz integration into xeroc's price feed script, it looks like the pull request has been merged by @xeroc, perhaps blockchaind (rudex) are using this repo and can provide input on this matter? I use the stand alone price feed script for hertz.

[xeroc]

I'm not sure why it's not been merged into the master branch yet..

Too busy ... sorry .. will take a look asap

[clockwork]

that commit mainly changes the warning/skip levels ets...

seems to be a bigger issue in play here..

Does it work for you?

[R]

Hey Customminer,

Trying to use: https://github.com/xeroc/bitshares-pricefeed/blob/master/bitshares_pricefeed/examples/hertz.yaml until I sort out my own pricefeed solution and I get the following error:

AssertionError: You cannot provide a 'price' this way

Are there any adjustments needed to the pricefeed code?

Have you implemented this pull request? https://github.com/xeroc/bitshares-pricefeed/pull/32

I'm not sure why it's not been merged into the master branch yet..

[clockwork]

Hey Customminer,

Trying to use: https://github.com/xeroc/bitshares-pricefeed/blob/master/bitshares_pricefeed/examples/hertz.yaml until I sort out my own pricefeed solution and I get the following error:

AssertionError: You cannot provide a 'price' this way

Are there any adjustments needed to the pricefeed code?

[R]

@zapata42 just to confirm, your BTS account is 'zapata42', yeah?

Yes, it's my account.

Do you have any news from the witness?

None yet, sent you 2/3 of the bounty & will send the last 1/3 once it's proven working in production.

[zapata42]

@zapata42 just to confirm, your BTS account is 'zapata42', yeah?

Yes, it's my account.

Do you have any news from the witness?

[R]

@zapata42 just to confirm, your BTS account is 'zapata42', yeah?

[R]

I'll contact you or any witnesses in private so we can proceed with more testing.

Witnesses I've contacted requesting btsprice hertz testing:
magicwallet.witness https://bitsharestalk.org/index.php?topic=26069.msg317391#msg317391
witness.hiblockchain https://bitsharestalk.org/index.php?topic=25888.msg317390#msg317390
winex.witness https://bitsharestalk.org/index.php?topic=25831.msg317389#msg317389

Hopefully this works & these 3 witnesses begin publishing Hertz price feeds

[zapata42]

Code: [Select]

rate_cny["HERTZ"] = compute_hertz() * rate_cny["USD"]
In the above snippet of code, does

Code: [Select]

rate_cny["USD"] result in the bitCNY:bitUSD rate, or the BTS:bitUSD rate?

If it's not BTS:bitUSD then it will not line up with the other hertz price feeds.

It is: CNY/USD rate (FIAT not bit).

The rates are taken from hq.sina.cn (see btsprice/sina.py).  Yahoo Finance API could be as source also, but the service has been closed by Yahoo. It might worth updating the scripts to get another source of rates like Alpha Vantage API (https://www.alphavantage.co/).. but this is another topic.

The formula does not end here, you have at btsprice/feedprice.py:161

Code: [Select]

self.price_queue[asset].append(bts_price_in_cny / self.bts_price.rate_cny[asset])
The main work (and difference) of alt's script is to compute 'bts_price_in_cny' from a variety of exchange's _order books_ (not tickers), then compute all other prices using the rate CNY / XXX.
I didn't change this principle, as I think it's the behavior expected by the witnesses are using this script maybe because they trust the BTS/CNY rate more than the others.

This mean the complete formula is:

Code: [Select]

BTS/CNY / (compute_HERTZ() * CNY/USD)
I hope this is fine.

Do not hesitate to do a review of the pull request. It will be easier to discuss around the code.

I'm not a witness so I can't test the publication. I'll try to setup it on testnet when I will have some time (probably next week).
Let me know if a witness using alt's script is avialable for testing.

I've got the hertz name reserved on testnet, I can provide you price feed publish rights on testnet if you're interested.

In the mean time, there were multiple witnesses on bitsharestalk who stated that they would consider supporting hertz once integrated into btsprice - I'll reach out to them in the next couple days.

I'll contact you or any witnesses in private so we can proceed with more testing.

[R]

An attempt to help you: https://github.com/pch957/btsprice/pull/6

Many thanks, I replied to the pull request before spotting your post here. Once it's been tested as functional I'll release the 750 bitUSD bounty.

alt's btsprice use CNY/BTS rate as a base for all the prices, so I'm using it for Hertz/Hero.

Code: [Select]

rate_cny["HERTZ"] = compute_hertz() * rate_cny["USD"]
In the above snippet of code, does

Code: [Select]

rate_cny["USD"] result in the bitCNY:bitUSD rate, or the BTS:bitUSD rate?

If it's not BTS:bitUSD then it will not line up with the other hertz price feeds.

I'm not a witness so I can't test the publication. I'll try to setup it on testnet when I will have some time (probably next week).
Let me know if a witness using alt's script is avialable for testing.

I've got the hertz name reserved on testnet, I can provide you price feed publish rights on testnet if you're interested.

In the mean time, there were multiple witnesses on bitsharestalk who stated that they would consider supporting hertz once integrated into btsprice - I'll reach out to them in the next couple days.

I have also started to gather all changes from the community on my repo: https://github.com/Zapata/btsprice/commits/master (WIP)

Thanks, this is well needed!

[zapata42]

An attempt to help you: https://github.com/pch957/btsprice/pull/6

alt's btsprice use CNY/BTS rate as a base for all the prices, so I'm using it for Hertz/Hero.

I'm not a witness so I can't test the publication. I'll try to setup it on testnet when I will have some time (probably next week).
Let me know if a witness using alt's script is avialable for testing.

I have also started to gather all changes from the community on my repo: https://github.com/Zapata/btsprice/commits/master (WIP)

[R]

Really need to create Hertz price feeds for btsprice https://github.com/pch957/btsprice/issues/4

Would anyone be interested in working on this in return for some bitUSD?

$750 for Hertz implementation sound tempting? It needs to be pegged to BTS:USD settlement rate (not BTS:CNY).

Use the time() reference instead of pendulum & try to get the BTS:USD rate from existing btsprice functionality (or implement following the existing coding style).

Hertz references:
https://github.com/BTS-CM/scripts/blob/master/hertz-feed.py
https://github.com/grctest/bts_tools/blob/master/bts_tools/feeds.py#L275
https://github.com/grctest/bts_tools/blob/master/bts_tools/feeds.py#L439

Anyone interested in this bounty?

[R]

The Hertz whitepaper has been translated into Russian! https://steemit.com/bitshares/@blockchained/hertz-privyazannyi-k-usd-koleblyushiisya-aktiv-osnovannyi-na-algoritme

[R]

https://steemit.com/bitshares/@cm-steem/hertz-passed-its-first-trough-price-feed-appreciation-incoming-updates-and-charts

Passed the first trough in production!

[R]

https://steemit.com/bitshares/@cm-steem/hertz-aba-whitepaper-markdown-edition-translations-inbound

Whitepaper in markdown format for steemit (for PDF phobic users).

Cheers.

[R]

Had an interesting discussion with an user on the /r/cryptomarkets subreddit: https://www.reddit.com/r/CryptoMarkets/comments/811cv0/hertz_an_oscillating_usd_pegged_algorithm_based/dv01paz/

Their idea for algorithm based assets:

[R]

https://steemit.com/bitshares/@cm-steem/hertz-is-now-live-on-the-bts-dex

Hertz is now LIVE on the BTS DEX! 

[R]

@ag2: Speaking of the VIX, it just got halted! https://twitter.com/carlquintanilla/status/960880138257948673

Time for Hertz to replace the VIX?

[R]

Bump! Any interest in the btsprice dev bounty?

Once wackou has created a new release, verbaltech's feeds will line up with the other price feed publishers & Hertz will be highly accurate. We could activate Hertz now technically.

[R]

I do actually use BTSPrice for feeding most of the "currency" markets and gold silver. It's  a great tool and very all-entailing featurerich and well coded by @alt , however as announced, he stopped maintaining it with his exit of BTS. Hence my addition on my GH.

Perhaps it'd be worth maintaining a Bitshares community version, so that we can do pull requests for improvements? Looking at the forked repos, they've made similar & unique changes worthy of use by witnesses.

But i do also run separate scripts for more custom needed feeds, like HERO , Bit20, and now, Hertz.  These are (imho) less about continuous realtime market monitoring (which btsprice-tool for currency markets perfectly serves) and more about the one-off-calculate-ad-hoc algoritmic based feed pushes. Those feeds (in my case) are all based of combining the algorithm calculation with publishing the feed by utilising the feed_publish command from pybitshares. Link with "individual" scripts https://github.com/roelandp/bts-misc-pricefeeds

Perhaps it could be an optional asset rather than mandatory? So that not everyone needs to provide hertz price feeds?

[roelandp]

I made a mod for BTSprice to continue supporting the no longer running btsbots.com DEX order books. https://github.com/roelandp/btsprice

I do actually use BTSPrice for feeding most of the "currency" markets and gold silver. It's  a great tool and very all-entailing featurerich and well coded by @alt , however as announced, he stopped maintaining it with his exit of BTS. Hence my addition on my GH.

But i do also run separate scripts for more custom needed feeds, like HERO , Bit20, and now, Hertz.  These are (imho) less about continuous realtime market monitoring (which btsprice-tool for currency markets perfectly serves) and more about the one-off-calculate-ad-hoc algoritmic based feed pushes. Those feeds (in my case) are all based of combining the algorithm calculation with publishing the feed by utilising the feed_publish command from pybitshares. Link with "individual" scripts https://github.com/roelandp/bts-misc-pricefeeds

That said, let's keep this thread for Hertz / Hero and see whether someone jumps on your bounty and focus back to Hertz

[R]

i did make some changes to btsprice by alt to keep it running, however no intergration with hertz yet.

Is the btsprice repo still actively maintained? I've seen that several forks of btsprice have made their own changes, but perhaps just not created a PR to merge back into master?

giving its nature of being an algorithmic mpa not so much based on “old skool”  market monitoring / price moves i’m not sure if it fits the scope of btsprice.

Several witnesses use btsprice to provide price feeds & @win.neil expressed interest in providing hertz feeds if it was implemented into btsprice: https://bitsharestalk.org/index.php/topic,25831.msg315187.html#msg315187

Support in btsprice will greatly increase witness price feed coverage, Hertz currently has 7 feeds (with another 2-3 possible with current feed scripts), HERO has 8, yet bitUSD has 21 feeds. A greater quantity of feeds improves the median settlement price list & improves decentralization.

Do you believe there would be opposition to Algorithm Based Assets (MPA/Smartcoins w/ algorithm) in the Chinese community? Wouldn't hurt to create a Hertz/Hero compatible implementation for manual implementation by specific witnesses using btsprice.

Perhaps it'd be appropriate to only propose the Hertz bounty, as the Hero feeds are maintained by the hero foundation.. yeah let's go ahead and cancel the hero bounty due to being out of scope, hertz implementation is now $750 bitUSD.

https://steemit.com/bitshares/@cm-steem/hertz-bounty-750-bitusd-for-implementing-hertz-in-the-btsprice-python-price-feed-repo

people running btsprice already have python, so its a small step
to py-bitshares imho.

I don't think we'd need to import python-bitshares nor pendulum (using time() instead), if we can get the USD:BTS price (perhaps USD:CNY:BTS) using existing btsprice functionality then we can implement Hertz without disrupting the current software stack too heavily.

[roelandp]

hey sakhan,

no those individual scripts are custom mpas and are fed via xerocs pybitshares.

i did make some changes to btsprice by alt to keep it running, however no intergration with hertz yet.

giving its nature of being an algorithmic mpa not so much based on “old skool”  market monitoring / price moves i’m not sure if it fits the scope of btsprice.

people running btsprice already have python, so its a small step
to py-bitshares imho. 

[sahkan]

Really need to create Hertz price feeds for btsprice https://github.com/pch957/btsprice/issues/4

Would anyone be interested in working on this in return for some bitUSD?

$500 for Hertz implementation and $250 for Hero implementation sound tempting? It needs to be pegged to BTS:USD settlement rate (not BTS:CNY).

Hertz reference: https://github.com/BTS-CM/scripts/blob/master/hertz-feed.py
Hero reference: https://github.com/hero-global/scripts/blob/master/hero-feed.py

I think @roelandp already wrote those. Here is HERO: https://github.com/roelandp/bts-misc-pricefeeds/blob/master/hero.py and he is feeding HERTZ as well.

[R]

Really need to create Hertz price feeds for btsprice https://github.com/pch957/btsprice/issues/4

Would anyone be interested in working on this in return for some bitUSD?

$750 for Hertz implementation sound tempting? It needs to be pegged to BTS:USD settlement rate (not BTS:CNY).

Use the time() reference instead of pendulum & try to get the BTS:USD rate from existing btsprice functionality (or implement following the existing coding style).

Hertz references:
https://github.com/BTS-CM/scripts/blob/master/hertz-feed.py
https://github.com/grctest/bts_tools/blob/master/bts_tools/feeds.py#L275
https://github.com/grctest/bts_tools/blob/master/bts_tools/feeds.py#L439

[R]

But to think about, if a blockchain like STEEM or GOLOS paid out rewards with such a token. risk probability could be considered of printing % of anual inflation in said token? perhaps some restriction of settlement maybe. Less often would a arbitrary limit of the total allowable debt be breached, and perhaps higher limit set.?

Steem & Golos don't maintain their USD reference peg though, SBD is currently ~$6.50 right now each. If this Hz token proves successful, then its introduction on other graphene chains would be fine - everything Hertz is MIT licensed. Don't know how the effect would be though given that these pegged assets don't maintain their peg.

Also understand the total allowable debt as a function of the powered up token. With a projection of this value possible  examining the the component of it in a powering down contract

In Steem and Golos examples where ratio powered up : powered down, tends to exceed 1, makes this projection better.

The Hertz variables could be modified dynamically depending on external factors, sure - you just need to make sure that it doesn't introduce too much volatility.

---

Think about the Market BTS Market Hertz : BTS.

When BTS behaves volatile either swinging up or down in real terms and from average. Understand someone may prefer sell BTS token for BTS Market hertz to realize profit on upswing but remain invested in BTS, or to mitigate losses on down swing, but still remain invested.  These are new options, and are naturally met with converse options That apply to this new investor in BTS Market Hertz.

There's always been the option to use bitUSD to evade falling BTS prices & likewise to sell bitUSD to buy cheap BTS when it's increasing in value.

The appreciation/depreciation of debt is indeed a valuable new concept that's not been explored elsewhere (AFAIK), it introduces new trading strategies in BTS for sure.

Think of BTS Market Hertz as part of an investment portfolio and being able to trade the BTS market while maintaining this investment trivially.

Not for long term holding, since there's limits to the price feed appreciation. But sure, buying low and selling high would be pretty simple. It is however highly experimental which is a risk in of itself.

Other considerations:

BTS Market Hertz as the preferred collateral rather than BTS in a system such as bitshares.

Anyone can create an MPA which uses Hertz as the backing asset, similar to how XCD uses bitUSD as collateral. I'm not sure of the implications of such a smartcoin

The volatility of a market can be measured i.e VIX.

Interesting, https://en.wikipedia.org/wiki/Variance_swap Variance swaps sound similar to Hertz except centralized & generalized.

What would the VIX value of Hertz be?

Daily change of 2%, 364 trading days in the 28 day calendar, 2*square_root(364) = 38.157

2*square_root(28) = 10.583

https://www.investing.com/indices/volatility-s-p-500-historical-data VIX is currently 12.99

Anyone could create their own Hertz style smartcoin which was pegged against one of these established VIX/Variance-Swap mechanisms.

new type of price-feed: subject the number of days in the average to democratic process, variable which witnesses decide dynamically.

What if each witness monitored a burn/null role's memo data for burn transactions - the more smartcoins destroyed the greater the impact on the smartcoin's settings. Imagine a tug of war, the more destroyed against A causes appreciation, more destroyed against B causes deppreciation.

If a smartcoin is destroyed, there's debt without associated liquid smartcoin, so theoretically more will need shorted.

Permanently locking up collateral by burning smartcoins is next level!

[ag2]

Hi, I'll respond with detail later. I gave no consideration or suggestion on collateral, etc., parameters that would have to be defined.

But to think about, if a blockchain like STEEM or GOLOS paid out rewards with such a token. risk probability could be considered of printing % of anual inflation in said token? perhaps some restriction of settlement maybe. Less often would a arbitrary limit of the total allowable debt be breached, and perhaps higher limit set.?

Also understand the total allowable debt as a function of the powered up token. With a projection of this value possible  examining the the component of it in a powering down contract

In Steem and Golos examples where ratio powered up : powered down, tends to exceed 1, makes this projection better.

Think about the Market BTS Market Hertz : BTS.

When BTS behaves volatile either swinging up or down in real terms and from average. Understand someone may prefer sell BTS token for BTS Market hertz to realize profit on upswing but remain invested in BTS, or to mitigate losses on down swing, but still remain invested.  These are new options, and are naturally met with converse options That apply to this new investor in BTS Market Hertz.

Think of BTS Market Hertz as part of an investment portfolio and being able to trade the BTS market while maintaining this investment trivially.

Other considerations:

the Demand of this token in a graphene chain based community that has the only other alternative of the native currency.

 BTS Market Hertz as the preferred collateral rather than BTS in a system such as bitshares.

The volatility of a market can be measured i.e VIX.

new type of price-feed: subject the number of days in the average to democratic process, variable which witnesses decide dynamically.

That's all for later, just thoughts on my mind. Response to Customminer coming next.

[R]

I would like a price feed for a BTS HERTZ but that oscillates by tracking a simple 30, 14 day moving average. Still this appears difficult.

You can see the price feeds here: https://btsapi.grcnode.co.uk/home and here: http://cryptofresh.com/a/HERTZ

It wouldn't be difficult to track the price feeds, you could scrape the price feed data (https://btsapi.grcnode.co.uk/get_hertz_value?api_key=123abc) once every x mins & establish a history then plot this on a chart.

In terms of moving average, the average settlement price will be $1.00 over 28 days because it oscillates 14% equally each direction.

You could perhaps take the moving average market price, because that will account for the fluctuation in the USD:BTS market. There's certainly the potential for shorting at the stop to net more than 28% profit if BTS was to appreciate whilst your debt depreciated (and if you were able to settle your debt at the bottom).

BTS HERTZ that works by sine wave, is adding a predictable volatility to existing underling volatile price. This seems pointless. But does create an asset that tends to the state of being fully backed by 1x collateral.  even large amplitude it comes back predictably to the 1:1 state.

Backed by 200% collateral, not 100% collateral. But yes, if you settle, you'll trigger a shorter's force settlement at the current settlement rate in BTS (Which could be between $0.86 & $1.14). If you mean the moving average for settlement price is useless, sure. If you mean that the purpose of hertz is pointless then I disagree, I believe that the sine wave will have a noticeable effect on the market compared to say bitUSD.

how many days you add to the average? More days you get less volatile asset but one that doesn't intersect with the price as often - which is the state of coming into  being fully backed ( which is important to me ).

7, 14, 31 all seem very attractive to me.

the problem unlike a mathematical oscillation. how do you build this curve that tracks and average of the past and updates frequently.

Re: Which state is fully backed: All states should be fully backed by Bitshares, if a shorter's collateral falls below the minimum collateral ratio then the shorter is force settled.

You could track the daily market rate average, then compare that against the known settlement price range for that day.

I think we can use published price-feeds on blockchain, going back 7, 14 , 31 days to construct the average which will be weighted as well.

You could certainly track the price feeds of Hertz either via the blockchain directly or by scraping the hug rest api for the required data real time & establishing a price feed history.

[ag2]

I would like a price feed for a BTS HERTZ but that oscillates by tracking a simple 30, 14 day moving average. Still this appears difficult.

BTS HERTZ that works by sine wave, is adding a predictable volatility to existing underling volatile price. This seems pointless. But does create an asset that tends to the state of being fully backed by 1x collateral.  even large amplitude it comes back predictably to the 1:1 state.

tracking a moving average, attempt to create an asset that is more stable in value than bitshares  (close to bitUSD) . Also it oscillates below and above the bts price.

how many days you add to the average? More days you get less volatile asset but one that doesn't intersect with the price as often - which is the state of coming into  being fully backed ( which is important to me ).

7, 14, 31 all seem very attractive to me.

the problem unlike a mathematical oscillation. how do you build this curve that tracks and average of the past and updates frequently.

I think we can use published price-feeds on blockchain, going back 7, 14 , 31 days to construct the average which will be weighted as well.

can I have some comments?

[R]

Created a price feed script HTML page for Hertz: https://btsapi.grcnode.co.uk/home

[R]

https://steemit.com/bitshares/@cm-steem/hertz-71-activated-on-the-bitshares-network-2-more-witnesses-to-go

We're up to 5 of the 7 required witnesses now! Getting close to activation!

[R]

Updated the reference Hertz price feed script:

• Updated rate calculation
• Code cleanup - moving code around & changing comments.

https://github.com/BTS-CM/scripts/blob/master/hertz-feed.py

Updated the HUG REST API function:

• Stop crashing due to non-publishing manually configured private price feed publishers.
• Inherited the hertz-feed updated formulas.
• Showing more info in the

https://btsapi.grcnode.co.uk/get_hertz_value?api_key=123abc

[R]

[R]

Thanks to @roelandp, the reference price feed script has been fixed so as to output the correct price feed.

I've updated both the reference price feed script repo and the BTS HUG REST API repo to reflect this change.

Looking forwards to additional active witnesses publishing price feeds for the Hertz MPA! 

Edit:

Just updated the first post to reflect the latest changes!

[R]

New website: https://sites.google.com/view/hertz-aba/
New domain: www.hertz.network  (Should redirect to the above)

[R]

We've got our first witness! @roelandp!

A huge shout out to him, this is the first step towards HERTZ trading on the BTS DEX!

6 more to go

https://steemit.com/bitshares/@cm-steem/hertz-14-activated-6-more-bitshares-witnesses-to-go

[R]

I recently posted an update regarding Hertz to Steemit: https://steemit.com/bitshares/@cm-steem/hertz-updates-seeking-price-feed-publishers

I'm seeking new price feed publishers, specifically Bitshares witnesses.

The smartcoin currently requires 7 price feed publishers, and we've got our first - @rolandp, thanks you very much!

I'm hopeful that we can reach 7 publishers soon.

Best regards,
CM.

[R]

Price feed script changes

• Created a price feed verification script! Using this, I was able to confirm that the phase was correctly set & Wednesdays line up as the primary Hz day for the next 10 years.
  
• Created dedicated python functions for improved dynamic use. Anyone can fork the price feed scripts, change these values and begin publishing price feeds for your issued ABA.
• Pushed updates to Xeroc & Wackou's price feed script PRs.

Spreadsheet changes

• Improved timestamp accuracy (now accounts for change in period)
• Applied new default variables
• Included proof of phase validity (10 years of wednesdays with only values 0.5, 1.0 & 1.5).

Variable changes

• Amplitude = 1/3 (No longer 1/2)
• Period = 28 days (No longer 30.43, to line up with the typical work week).
• Phase = < 1 day (To make wednesday the primary Hz day).

Community updates

• I've spoken during the last two (40 &amp; 41) bitshares hangouts about HERTZ.

TODO

• Poll multiple full nodes for the BTS/USD settlement price, so as to harden script from compromised nodes.
• Find willing high-frequency (at least a couple times per day) price feed publishers.
• Improve upon the hertz-verification.py script
• Output charts within the script.
• Possibly pull BTS historical data to plot how HERTZ would have faired against past price movements.
• Further consider the amplitude value (still too high?)
• Run initially in Bitshares testnet.
• Wait for BSIP-0018 to go live prior to running HERTZ asset in production.

Best regards,
cm-steem

[R]

Some interesting ideas:

Creating a Trochoid (https://en.wikipedia.org/wiki/Trochoid) or Cycloid (https://en.wikipedia.org/wiki/Cycloid) ABA.


Creating a Trochoidal wave (https://en.wikipedia.org/wiki/Trochoidal_wave) ABA - "In fluid dynamics, a trochoidal wave or Gerstner wave is an exact solution of the Euler equations for periodic surface gravity waves. It describes a progressive wave of permanent form on the surface of an incompressible fluid of infinite depth."

Alternatively, combining sin waves (wave inference) with different frequencies (calculator: https://academo.org/demos/wave-interference-beat-frequency/)

[R]

I created an ELI5 worthy intro to HERTZ on steemit: https://steemit.com/hertz/@cm-steem/what-is-the-hertz-algorithm-based-asset

[R]

Once the HERTZ price feeds are in a production worthy state & BSIP-0018 is implemented, would anyone be interested in being a private price feed publisher?

[R]

Price feed updates: https://steemit.com/bitshares/@cm-steem/hertz-price-feed-script-updates-september-2017

Next development steps: https://steemit.com/bitshares/@cm-steem/hertz-next-area-of-investigation-prior-to-production

[R]

I've been thinking about HERTZ recently, and thought about what if we simply pegged against BTS and applied the sin wave modifier to that? So the Hertz token would range from 0.5 to 1.5 BTS throughout the month.

Why use BTS as the reference asset?

• Less risk of force settlement due to BTS (or reference asset) price volatility.
• Decoupling of BTS from external assets.
• Less likelihood of global settlement events taking place due to reduced forced settlement risk.
• Predictable price volatility, enabling risk-free borrowing given sufficient collateral.

I suppose it'd be the same as using bitUSD as collateral to borrow bitUSD into existence, except using the core BTS asset.

Steemit post: https://steemit.com/bitshares/@cm-steem/back-to-algorithm-based-assets-and-targeting-bts-as-an-mpa-s-reference-asset

Thoughts?

[R]

Users mentioned concerns regarding the peak and trough phases of a HERTZ token, specifically that at the peak there would be overwhelming selling/settling pressure (less buy pressure) and that during the trough there would be overwhelming buying pressure (why sell when it's going up?).

To combat these moments of market imbalance, we could potentially utilize BSIP's 19/20 (MPA/UIA dividends) to incentivize the purchase of HERTZ at the peak and the sale of HERTZ during the trough.

What do you think? Dividends for providing market making?

[R]

Wackao responded to the Github Issue: https://github.com/wackou/bts_tools/issues/24#issuecomment-306741609
"Thanks for the suggestion, I like the idea! Not sure if it's going to be useful (don't have enough understanding of economics yet), but just the fact that we are able to try things like that on BitShares is plain awesome.
A bit busy with the launch of PeerPlays right now, but I'll give it a try soon "

[R]

https://github.com/grctest/HERTZ-Price-feed-script/blob/master/min_hertz.hs

I have created a simplified version of the Haskell HERTZ price feed script.

The script no longer scrapes cryptofresh for asset values, doesn't handle json, doesn't output to CSV nor use the turtle library.

The script now runs from the command line and takes 5 arguments:

Code: [Select]

./min_hertz.hs referenceBlock genesisBlock blocksInPeriod amplitude referenceAssetValue
example: ./min_hertz.hs 50 1 100 0.5 25
output: 25.784882
Since you can now enter values easily from the command line as arguments, it will be easier for everyone to test out their own hertz configurations (different frequencies, amplitudes and backing assets).

Any suggestions?

Steemit mirror: https://steemit.com/beyondbitcoin/@cm-steem/hertz-haskell-price-feed-script-update

[R]

It's be great if the price feed publishing fees were free so that we could have very high frequency HERTZ tokens.

[R]

I've created issues for HERTZ potential inclusion in xeroc & wackou's price feed scripts (both use python)

https://github.com/wackou/bts_tools/issues/24
https://github.com/xeroc/bitshares-pricefeed/issues/3

[R]

Since CNY is one of the most popular smartcoins on the BTS DEX, perhaps it would be wise to use it as the reference asset instead of USD and/or XDR.

It appears to be leading the poll at the moment too.

[R]

I'm not sure I understand much of the above correctly, but if traders could make a 1% profit every ~1-4 hours by shorting the asset at the peak, and then buying again at the low, then holding until the peak.

A repetitive bot trading the 4 hour profit cycle (6 x 1% profit opportunities per 24 hours), would make 1.01x their initial investment.
Using a bot to trade each of these cycles every day for a month would create a (Initial-Investment * 1.01^(6*31) equals a 600% increase in capital, just from playing the tick-tock game of 1%

This asset needs to track the value of something that the mainstream will want to hold.
There will be lots of shorters wanting to earn the 1% profit 6 times a day.
BitShares-customers who want to buy CNY (?) at volume in a liquid market will not mind paying a 1% "fee" depending on where they are on the HERTZ cycle.
They won't even notice it

There would be lots of liquidity, shorters are guaranteed profits if there are buyers of the token.
High liquidity looks attractive to potential customers, and gets BitShares on the "front page" of crypto-news, because traders will see volume rankings and BitShares will be up there

Is this the kind of thing you're talking about?

Yes, however I'm initially thinking of a large amplitude (50% fluctuation from feed value) and a period of 1 month, effectively 0.138..% every hour not 1% every 4 hours.

We also need to take into account that not all witnesses publish price feeds for all smartcoins, and frequency of price feed publishes is variable, see: https://roelandp.nl/bitshareswitnesslog/
Thus, high frequency price feed publishing would require convincing the witnesses to shell out.

But the idea can be applied to any amplitude, period, graph function and reference asset. You need to take into account the specific smartcoin options for different algorithms.

---

Edit: There's also phase shift to consider, you could have two tokens which have an opposite phase, canceling each other out.

[Permie]

I'm not sure I understand much of the above correctly, but if traders could make a 1% profit every ~1-4 hours by shorting the asset at the peak, and then buying again at the low, then holding until the peak.

A repetitive bot trading the 4 hour profit cycle (6 x 1% profit opportunities per 24 hours), would make 1.01x their initial investment.
Using a bot to trade each of these cycles every day for a month would create a (Initial-Investment * 1.01^(6*31) equals a 600% increase in capital, just from playing the tick-tock game of 1%

This asset needs to track the value of something that the mainstream will want to hold.
There will be lots of shorters wanting to earn the 1% profit 6 times a day.
BitShares-customers who want to buy CNY (?) at volume in a liquid market will not mind paying a 1% "fee" depending on where they are on the HERTZ cycle.
They won't even notice it

There would be lots of liquidity, shorters are guaranteed profits if there are buyers of the token.
High liquidity looks attractive to potential customers, and gets BitShares on the "front page" of crypto-news, because traders will see volume rankings and BitShares will be up there

Is this the kind of thing you're talking about?

[R]

What should the "Percent offset of forced settlements" value be for HERTZ?

Considering that the amplitude is 0.5 (50%), the value will fluctuate from 0.5 to 1.5, if someone was to short the asset into existence at the top and they were to hold the asset/debt until the y value was at 0.5, then the asset will be worth 66% less than when they bought it at the top. If we kept the 1% offset for forced settlement then many users would be force settled during each oscillation.

If we set the percent offset to 70% then the fluctuation of the sin wave wouldn't trigger force settlement, only the volatility of the backing asset.

Would there be any repercussions to setting such a high force settlement percent requirement?

---

Another concern would be whether or not users create tokens with enough collateral to take the change in feed price into account?

---

I've set the max price feed lifetime to 420 minutes, as 7hrs makes for a difference of almost 0.01*Base_reference_asset ($0.01 for example).

---

Any thoughts on the above? I'd appreciate any input.

CM.

[R]

Regarding existing price feed scripts written in python such as bitshares-pricefeed by xeroc: https://github.com/xeroc/bitshares-pricefeed/

Reference hero file: https://github.com/xeroc/bitshares-pricefeed/blob/master/bitshares_pricefeed/examples/hero.yaml

hero formula (line 41):

Code: [Select]

formula: 1.05 ** ((date.today() - date(1913, 12, 23)).days / 365.2425) / {quoteSettlement_price}
The haskell script could be replicated in python, or we could use the haskell script to precompute a large CSV of blocknumbers to modify the latest price feed value with.

Code: [Select]

formula: quoteSettlement_price + read_CSV_For_Wave_Value(BlockNumber)
The python price feed script uses time/dates instead of block numbers, so perhaps there will be a difference in computed values between haskell and python.

python implementation? (I don't know python)

Code: [Select]

import math
import date

quoteSettlement_price = XDR
Time_In_Period = one month duration
amplitude = 0.5

x_value = (remainder of ((date.today() - date(Asset_Genesis_Date_Timestamp))/Time_In_Period) divided by 1.00)  // to return 0.xx

feed_price = quoteSettlement_price + (((quoteSettlement_price * amplitude)*(sin((x_value * Time_In_Period)) * ((2*math.pi)/Time_In_Period) ))))


[R]

Rather than a simple sin wave, we could have a sin wave with a period on the way down where the asset would be equal to the backing asset for about a week?

What do you think about the use of Fourier series? https://en.wikipedia.org/wiki/Fourier_series

Think wave interference would be simpler? Combining a triangle/sawtooth wave with a sin wave to get the above desired effect?

Thoughts?

[Permie]

Keep it up Customminer!
 

[R]

I have produced a price feed generation script in Haskell for the HERTZ FBA:
https://github.com/grctest/HERTZ-Price-feed-script/blob/master/hertz.hs

It currently scrapes the price feed for XDR from cryptofresh, averages the last 10 published price feeds and outputs the results in a CSV file. It's outputting to a CSV for use in excel for charting.

Any suggestions?

[R]

BackingAssetValue = [USD | XDR] //Still need to decide on basing it against the USD or the XDR/SDR.

....gold?

Love the idea. I understand the aim is a stable reliable price(?) but using an IMF product just seems icky. Maybe the USD isn't any better.

We could remove reliance upon the IMF by simply calculating our own basket currency using the price feeds of several fiat currencies.
We could do Hertz.Gold and other variations, don't need to be limited to one asset.

[Permie]

BackingAssetValue = [USD | XDR] //Still need to decide on basing it against the USD or the XDR/SDR.

....gold?

Love the idea. I understand the aim is a stable reliable price(?) but using an IMF product just seems icky. Maybe the USD isn't any better.

[R]

What is Hertz?

Hertz is a highly experimental Market Pegged Asset (MPA) created on the Bitshares network. Elected Bitshares witnesses will publish price feeds which are pegged against the United States Dollar (USD) and predictably oscillates using a sine wave algorithm. The sine wave has an amplitude of 14% and a period of 28 days, thus the price feed value changes 2% every day and a resulting max price feed value of $1.14 and min of $0.86 (Note: Depending on the combination of Bitshares price volatility and age of price feeds published by witnesses, these limits may not always hold).

Hertz tokens are shorted (borrowed) into existence by users on the Bitshares network with at least 175% backing collateral in Bitshares; there is no centralized issuance and asset creator permissions have been restricted for increased decentralization.

By implementing a sine wave phase offset (date/time), we are able to make each Wednesday (mid working week) the most important day for Hertz.

Price feeds:
Reference Python scripts & calculator (https://github.com/BTS-CM/scripts)
  hertz_calculator.xlsx : A spreadsheet for evaluating the effect of different sine wave variables (amplitude, period, etc).
  hertz-verification.py : Used for verifying that the phase offset lines up appropriately.
  hertz-feed.py : What you'd use if you don't use wackou or xeroc's price feed scripts.
Wackou's 'BTS_Tools' (Only use if pull request #36 is merged, OR if you change 1/3 to 0.14 yourself manually).
  https://github.com/wackou/bts_tools/blob/master/bts_tools/feeds.py#L275
  https://github.com/wackou/bts_tools/blob/master/bts_tools/feeds.py#L441
Xeroc's 'Bitshares-PriceFeed' (Issue #25 addresses the inaccurate amplitude comments)
  https://github.com/xeroc/bitshares-pricefeed/blob/master/bitshares_pricefeed/examples/hertz.yaml

Surrendered FBA settings
- Disable confidential transactions:
- Require holders to be white-listed:
- Issuer may transfer asset back to himself:
- Issuer must approve all transfers

TODO
- Get witnesses to publish price feeds for the Hertz MPA

Links
https://sites.google.com/view/hertz-aba/

Best regards,Customminer.