-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
optimizing futarchy for least volatility #237
Comments
instead of gambling on the short term volatility, we should have a couple layers. |
The layering idea comes from Robin Hanson http://www.overcomingbias.com/2019/01/fine-grain-futarchy-zoning-via-harberger-taxes.html "A solution to this problem is to use, instead of declared values, prices for the purely financial assets that represent claims on all future tax revenue from the Harberger tax on a particular property. That is, each property will pay a tax over time, we could divert that revenue into a particular account, and an asset holder could own the right to spend a fraction of the funds in that account. Such tax-revenue assets could be bought and sold in financial markets, and could also be made conditional on particular zoning scenarios. As such assets are easy to create and duplicate, the usual speculation pressures should make it hard to manipulate these prices much in any direction. A plan to temporarily inflate the declared value of a property shouldn’t do much to the market price for a claim to part of all future tax revenue from that property. So instead of summing over conditional differences in declared-values to see if a zoning change is good, it is probably better to sum over conditional differences in tax revenue assets. Subsidized continuous market makers can give exact if noisy prices for all such differences, and for most property-scenario pairs this difference will be exactly zero." |
upside volatility doesn’t break contracts like downside vol does |
The best currency for derivatives:
|
There has been debate in Amoveo about whether our futarchy markets for updates to Amoveo should optimize for the market cap or for the price of a VEO.
Spike offers up a third option of what we should optimize for. We should try to keep the volatility as low as possible.
The cost of making derivatives is proportional to how wide the margins are on those derivatives. The width of margins priced in VEO is mostly determined by how volatile VEO is.
So, if we want Amoveo to be a useful platform for derivatives, we should try to keep the volatility low.
We should come up with some ways of estimating the volatility, and make some graphs of it changing over time so we can visualize the situation.
The text was updated successfully, but these errors were encountered: