Had the same idea here but then I gave up knowing that in practice most of the demand is purely speculative and not transactional, so I’m not confident on the effectiveness of the formula …
I doubt the real world response of a price to supply change is linear or consistent, it’s probably chaotic. Maybe simulating chaotic behavior is what is needed here. Your framework definitely sounds like it will be useful for gathering test data to do a preliminary gain tuning, but with prices and markets real world data is always best. I don’t know if a test environment can properly capture the emotional swings of a market.
I’ve actually got a working implementation complete that seems fairly usable. I’ll post it in a couple days once I’ve had time to run it thru a few iterations on the testnet.
It’s a simple proportional supply change in response to a pricing error repeated over many cycles to slowly move the price back to the target. I’ve set it for now so that a 1% movement in price leads to a 0.1% change in supply per cycle (P-gain of 0.1). Cycles are 1000 blocks long.
If you have some math that can provide a more rigorous gain calculation, I’d love to see it.
Only one way to find out. It seems a lot better than the current best practice more generally of divinating these parameters out of thin air (“how much total supply do I have?”)
Why not just have large active sell orders at $1.01 equivalent and buy orders at $0.99 equivalent and adjust based on fiat price movements? There are designs other than fixed quantity auctions that could make sense here.
2 Likes
How much control authority do you need to maintain that threshold over time? (e.g. what is the size of those large buy/sell orders)
Why not basically infinite?
I suppose that would be unstable and potentially arbitrageable in case the price feed ever got it wrong; in that case, it could make sense to make the sell price go up as more units get bought (and buy price go down as more units are sold). There’s probably some mathematical formalism that can get you pretty good bounds on loss from arbitrage if the attacker has a more up-to-date view of the price than the blockchain feed. That’s the main thing I would be worried about.
An infinite-sized sell order of a finite quantity item? I’d imagine there’d be a particular quantity of the stable coin at any given time (that could get minted as demand grew cough US Mint) so that the manager of the stable coin retained a certain dominance to the buy/sell orders to maintain that stability. But that dominance can’t be infinite, if there was unlimited supply it would be basically worthless, and you would only have a limited amount of buy power in whatever collotoral you were using to conduct the sale that you had stockpiled.
I was assuming that the PID controller is run by the stablecoin, so of course it would have access to the ability to mint arbitrarily large amounts. Is that assumption mistaken?
Nope, on the sell side you’re right that basically makes it infinite (although you wouldn’t just continuously mint coins, and probably batch them for efficiency). On the buy side you wouldn’t have infinite authority however, eventually you’d run out of collotoral.
1 Like
Right, but on the buy side eventually everyone will have sold all of their coins to you. Also, in Seignorage Shares, the buy order is buying coins for shares, and shares are also something that the system has the right to print an unlimited quantity of.
Hmm, yeah. I think broader Controls Theory isn’t really useful to apply here because it’s full authority as you said, and the dynamic response is pretty minimal as long as cycles are tight enough and enough authority is exhibited.
The theory that I do think is useful is insights from mechanism design about making mechanisms with bounded loss. I do worry that a badly designed seignorage shares system could get money-pumped to hell during periods of high price volatility. Maybe Augur or Gnosis people could come share their insights?
The nice part about the current design is that the price feed doesn’t have to be very accurate because it’s only required once every 1000 blocks and a mis-pricing doesn’t create arbitrage opportunities. Additionally, the only price feed that needs to be maintained is the one between the stablecoins and USD (I’m assuming we’re pegging to USD for simplicity’s sake), which shouldn’t be very volatile.
If the contract is acting as a market maker, an additional price feed would have to be maintained between the shares and the stablecoins for the contract to keep orders at $0.99 and $1.01, and this price feed would be volatile, making it easy to arbitrage. It worries me that the contract could be attacked too easily.
The best method I’ve seen for price discovery so far is the reverse Dutch auction used by the EOS crowdsale. A fixed number of assets are auctioned off. Bidders contribute to a common pool, raising the price of the asset until it meets the market price. At the end of the cycle, bidders can claim the asset proportional to their percentage of the total bid. The code is simple and I’ve seen it work for the past 8 months so I’m pretty confident in it. Mis-pricings are uncommon and don’t affect the financial health of the contract. This is what I’ve used in the current implementation.
The downside to reverse Dutch auction cycles is that the supply can’t respond to price changes as quickly as in the market-maker method.
1 Like
If the market maker could be implemented securely it does seem like it would be a better control system than the auction. But I’m worried about arbitrageurs causing havoc.
So there’s the (1) coin/shares price and the (2) coin/index price (coin/$ for simplicity). Are you suggesting an oracle for (1) as well as (2), and then stablecoin contract mkt maker biases the bid/ask spread around the mid-price feed from (1) on the basis of the feed from (2)?
The simplicity of this LMSR-esq approach seems to invite complicated strategic behaviour, I would guess.
I was wrong about only needing one price feed using the reverse Dutch system. In order to determine how many shares to print when contracting the supply, a price feed for the shares is required as well. However, the price feeds still do not directly determine the buy/sell prices, so mis-pricings do not lead to damaging arbitrage opportunities. They lead to bad supply changes, but those can be corrected in the next cycle.
OK, I thought about this a bit more. My main concern with Robert’s approach of just holding auctions is that under low-volume environments it could lead to arbitrage exploitation. Consider:
- Coin price rises to $1.01, share price $100
- Coins are auctioned. Attacker bids 0.008 shares ($0.80) and wins one newly generated coin.
- Coin price drops to $0.99
- Shares are auctioned. Attacker bids 0.012 shares/coin ($1.20) and converts his coin back into 1.2 shares.
The attacker is now 0.004 shares richer. LMSR-type systems are nice because they tend to be unexploitable even in these kinds of very low volume environments.
1 Like
Is that the only problem you see with Robert’s implementation? The main issue I have with the seigniorage share system is that the only auction type that is possible is coins for shares and shares for coins. It literally makes it so that the only way to retract supply is based on the value that speculators put on future expansion of the network (the main value ascribed to the shares). In a complete seigniorage system, you should be able to auction off newly printed coins for any on chain asset (chosen by shareholders which asset is best at the time of auction) and then hold the assets in the smart contract like a central bank’s vault/balance sheet. The shares in this system would be valued at (1/total share supply)*(total value of all assets held in the smart contract)+(future expansion of the network). In such a system, you are essentially creating a decentralized DAO which functions as the Fed. Anyway…I agree that in the system I proposed, I’d likely opt to use an LMSR too.
It literally makes it so that the only way to retract supply is based on the value that speculators put on future expansion of the network
Technically, it could be the value of the future expansion of the network plus fees. There are at least two kinds of fees that could be charged: (i) demurrage on coins, (ii) exchange fees or profits on the coin/share exchange mechanism. So shares could have value even if there is common knowledge that eventually the usage of the system will go to zero.
1 Like