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.