HERTZ - Oscillating Formula Based Asset

[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.