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.

Quote from: ag2 on July 02, 2017, 07:34:40 am

We want developers to be able to psychologically leave ethereum, so we want to make their investment  worth little.

Could you elaborate a bit? Core developers or people building on the platform?

I think both. For instance it would be great for everyone if Vitalik could leave and do an internship at block.one, then see what it was he was really trying to do.

But I think it's most likely Vitalik  will try and position ethereum as distinct to EOS, and it's future trajectory will be in regards to this. Maybe it could succeed. But right now there is a depressing reality for ethereum enthusiasts coming when the test net launches, if one makes an honest comparison.

EOS like STEEM will benefit from network effect to succeed, being the first mover. An Ethereum bear market would aid that.

First of all I doubt that the Larimers are just for the money. I believe Dan has some ideals above money and would prefer to be remembered as someone who truly changed the world rather just become another very rich person. In the end of the day I think he has already earned a lot so money should not be an issue here. He really likes his work so he will deliver.
secondly if you believe that eos will be delivered then comparing to eth, eos is ridiculously cheap now..

100 is a lot if it was snapshotted, and you didn't already import the key. that might be something around 10,000 - 20,000 BTS

I'm being patient, but I'm also really looking foward to stealth. I will download bitshares daemon and use the API if that can be delivered now.

Also does stealth++ require a fork? that's an important question we should know about

Stealth related:
 
Lots of progress made on Stealth this week! The 2 "serious issues" that we found last week with the libsnark and gadgets have been solved. So, now that that is out of the way, we have been debugging libsnark proofs and proving keys. This entire week has been spent in the debugger and logs, so no github commits to link here.
 
Now that we have reached this point in the core code, I am able to add another cryptographer to the Stealth team in about a week. This will help us speed the Stealth project up of course, and add more security auditing as we go, but I also require my teams to cross-train just in case someone has a family emergency or something.
 
We should be able to start proving transactions within 3 weeks, and then begin closing the gaps in the api, which is needed to connect to the UI. Most of the UI work, at least in a rudimentary sense, is already done. We can make it pretty later, for now, I just want it working asap. I pushed hard on that too because I want to begin public beta testing on our testnet as soon as possible.
 

I will use as soon as I am allowed