Using price oracles to set the stake per relay rate

#1

The earliest discussions of Pocket Economics which I recall focused on how to insure that the dollar cost of running a node was sufficiently covered by the dollar value of the reward in POKT token. cost to developers of acquiring the necessary stake to supply them with relay usage, did not drastically increase or decrease along with drastic changes in the market price of the POKT token.
The direction chosen at that time was to use the federated nodes as price oracles and adjust reward levels the relay per stake ratio accordingly.

Edit: original post was based on some major memory errors in my brain and has been largely deleted. The edited part above is (I think) correct.

PS: Thanks for the clarifications, sorry for the early onset Alshimer’s

Reward for Validators from Relays on the Network
#2

Personally I think that price stability and efficiency is worth the extra R&D, including avoiding manipulating the price, as could be done in a liberal radicalism model, as opposed to a capitalist model.

#3

There may be some confusion here, as the initial proposal would not be manipulating the token’s price, but the cost at which the token can purchase relay bandwidth. It adjusts based on the token’s price.

In both scenarios there will likely be significant market manipulation outside of what the protocol incentivizes.

#4

Won’t price oracles just reduce speculation?

#5

Yes. I think you are correct. I’m going to strike through that point.

#6

Very interesting read. Thanks! There is potential application to Pocket Network’s DAO funding aspect, but it does not appear to apply to this discussion (perhaps I am wrong?). I’m going to look deeper into it and look forward to further discussion as to it’s applicability/desirability.

#7

Increased price should cause reduced stakeing requirements which should increase supply which should reduce price. The net effect should reduce volatility in both directions.

That’s a lot of “should’s” but that’s the logic behind the original idea.

Note that (I believe) we decided against trying to implement this as part of MVP. So, this is a Final Protocol discussion, not a do it now thing.

#8

You’re right, it is rather outside the scope. I try to think outside the box sometimes! I was thinking that how the tokens are funded will affect decisions around token economics and the protocol. A stable coin or less volatile coin is more in the interest of users, while a volatile coin may have more upside potential, and thus be more in the interest of early adopters and early token holders with the network effect. Funding via an ICO and VCs is probably going to increase the likelihood of choosing a volatile coin, while funding via liberal radicalism has been shown to yield near optimal funding provision of public goods, and this model could also be combined with a decentralized autonomous iterative investment (DAII), e.g. with Dogezer.

There is another option somewhere between volatile coins and stable coins that I just outlined in a Twitter thread:

#9

As has been recognized, there are risks of manipulation with oracles, whether centralized or decentralized (obviously with the former it is extremely hard / impractical to avoid manipulation). If you censor/omit data, then you can manipulate the price. So any kind of decentralized oracle (as would be the case here) either needs to be extremely carefully designed and thoroughly tested for security and anti-manipulation proofness, or not use a decentralized oracle at all!

Further reading on oracles are e.g. here (I just read the first three threads):

https://ethresear.ch/search?q=decentralized%20oracle

Reading the white paper again, I can see the white paper says on p. 6, end of col. 1, that you are planning to:

Stake X pocket for P*X utilization (P
is a dynamically changing variable
based on the market value and
overall usage).

That will be complicated to implement in a trustless, safe, way.

#10

Also there’s a typo in the diagram to the right of that, it says “Sesion”.