That actually seems pretty reasonable. And simple.
It would still require an oracle though, and if that oracle is going to be a Schelling point, the players might as well just give a number of shares/coins to print.
if that oracle is going to be a Schelling point, the players might as well just give a number of shares/coins to print.
Disagree with that. Such an approach would make it harder for users to understand if the system is behaving honestly. I’d still say a schelling point based oracle for price, and then basing everything else off that, would work best.
When you say “harder for users to understand if the system is behaving honestly” do you mean actual users glancing at the smart contract have to do some mental math to see if everything is running smoothly? Or is there some attack vector I don’t understand.
If you are going to have a Schelling competition for a price feed in order to expand/contract supply of a coin, what is the issue with having the Schelling competition be the actual expansion/retraction signal itself rather than a price feed for the smart contract to then calculate the expansion/retraction amount? Is it because it could be more difficult to arrive at a common, salient Schelling point if it’s the expansion/retraction signal since it’s a more difficult computation for players to report?
Basically yes.
The difference between computing the function in-contract and out-of-contract is fairly small; it’s not all that computationally or gas-intensive, so it seems clearer to have the logic be explicit.
This is both a good AND bad thing. So on one hand, pure seigniorage shares implementation allows for easy forking should the feed get corrupted or the monetary policies of the network be unpopular (for example, say there is contention about whether to transition the price peg from USD to CPI). But on the other hand, with no external assets inside the contracts, it does not create a second layer of network effects on the system which builds cohesion and very strongly incentivizes resolution of contentious conflicts since the non-canonical contract will end up with no assets. I’m not quite sure the best way for a seigniorage shares implementation to accrue external assets (there were ways proposed by other users here), but it would be a smart idea to actually try both implementations on ETH and see which one accrues a large network effect + community faster and stronger.
1 Like
It’s not just about having the logic being explicit though. Having the players signal contraction/expansion amounts directly is more flexible than standardized 1% moves.
@EazyC The next question I have would be can we trust the players to legitimately be able to figure out what the right number should be? Oracles are for bringing external truth into the system. I’m not sure the exact amount to print to stabilize the price is a known quantity. The price on the other hand is a known number
I’m leaning towards using the 1% method to start because it’s simpler and feels more secure.
Auctioning off coins for the assets would work for any Ethereum-based assets. As cross-blockchain communication improves and OmiseGo launches, I’m hoping we’ll see more ERC20 versions of non-Ethereum assets so that the restriction isn’t limiting.
I believe that this is called MakerDAO. My stance on this is: let them try the external asset backed approach, and keep seignorage shares as a “pure” coins-backed-by-shares-and-nothing-else scheme. Both models are worthwhile and have different tradeoffs.
I’m aware of MakerDAO. I don’t think their CDP based approach is the same/similar thing I was insinuating here.
The difference here is that you’re looking at Seigniorage Shares vs. MakerDAO as 2 approaches at producing a stable unit of account while not giving credence to the idea that in order to create the most stable asset possible (assuming that is the goal here), that the monetary policy of the dapp we are discussing needs to have ample flexibility in creating a balance sheet of not just liabilities (the circulating coins) but also assets.
Take a look at the Federal Reserve’s balance sheet. They don’t simply hold bonds as the only asset to balance their liabilities. They have a very diverse set of assets including a massive portfolio of mortgage backed securities. https://www.federalreserve.gov/monetarypolicy/files/quarterly_balance_sheet_developments_report_201803.pdf
If you look at the Federal Reserve for some inspiration, their notes (USD) are not collateral backed (which MakerDAO’s is) but their monetary policy includes holding assets that form a “stability fund” of sorts. Perhaps that is a good middle ground to shoot for here. In essence, what I am saying is that the USD is not an asset-backed unit of account (which Dai is, so comparing them is futile) but the issuer of USD holds assets as part of the stabilizing effort. Pretty big difference.
If all seigniorage shares is going to be is another “stablecoin experiment“ to see if we can keep a coin value stable using a different, novel approach, then sure. I think it doesn’t need any kind of option to hold assets in addition to its liabilities. But if we are trying to come up with a system in which we could potentially produce the first non-nation state backed fiat cryptocurrency with the backing of a DAO-Fed then I think the 2 token system of seigniorage shares is too inflexible and simplistic. But perhaps we are talking about two different aims and visions.
Just for the record, don’t get me wrong, I think SS is the best proposal for a collateral-less backed stable unit of account, I just personally think it is an ‘incomplete’ system if we would like to build a decentralized Fed.
1 Like
I’ve run into a problem while testing this. When the share price is $100 and there are equal amounts of shares and coins, increasing the share supply during contractions by 1% wipes out the whole coin supply.
@mkoeppelmann from Gnosis had a good solution to this. A price feed can be constructed from previous auctions and used without the need for a share price oracle.
When the share price is $100 and there are equal amounts of shares and coins, increasing the share supply during contractions by 1% wipes out the whole coin supply.
Ah, I was thinking 1% of the current coin supply, not the current share supply.
Ok, that’s what I had in my mind with my first iteration but the auction system I’m using requires me to know the exact number of shares to print for contractions ahead of time. Without a share price oracle, I don’t know how many shares a 1% coin supply contraction requires. The two options I see are:
- Use a more sophisticated auction system that halts after 1% of the coin supply has been retracted. Totally doable, but I like the simplicity of the current method.
- Determine the share price somehow
Since I have previous price data available in the contract, I might as well use that to compute a share price instead of coding a more complex auction system.
Why do you need to? The purpose of the auction is to determine how many shares a 1% coin supply contraction requires. I don’t think it’s more complex at all; you let people submit bids and then fill bids going up until the point where 1% of the coins are removed from circulation.
if you’re filling bids as you go and don’t have a price target, how do you prevent low-ball bids from getting filled? You’d have to have a bidding period, then sort all bids to figure out which ones get filled. This leads to attack vectors where you can submit 1000s of bids to balloon the gas fees for the sorting operation.
You can do sorted insertions. When someone calls the on-chain bid function, they provide a prevBid and nextBid hint that tells the on-chain contract where in the sorted list to put the things they are inserting. The contract would then verify that prevBid was < bid and nextBid was >= bid. If it is not, then the contract will walk the bids until it finds the right spot (this is to deal with race conditions between multiple bidders). In this scenario, the person doing the insert pays gas costs for sorting, and assuming throughput isn’t high insertion gas costs are pretty cheap since the sorting is done off-chain.
That sounds like it will work. I will use this method. Thanks.
we would like to build a decentralized Fed
Just to note that Fed original purpose is largely to secure the banking system against liquidity problems due to outstanding loans. We don’t have (yet) the blockchain mechanism of providing non p2p loans to businesses or consumers. We are just at the point of trying to use blockchain as a medium of exchange. Therefor the method for price stability can be much simplier than the one Fed’s using — in the end all coins we have now are always in the hands of their owners.
1 Like
I’m not the original poster you were replying to but that is very interesting. Do you have further reading on the “purpose of the banking system is to [solve] liquidity problems due to outstanding loans (sc)”? I am under the impression that one of the Fed’s primary objectives is to keep its outstanding dollars in circulation at a stable unit of account since it serves the function of a central bank.
That is not a contradiction rather a consequence. The original purpose of CB is to prevent bank runs. Robert J. Shiller. Yale SE. Lecture #18. Monetary Policy
Just FYI - the auction system I described is now fully built out and already deployed on Rinkeby. A mainnet release is imminent. See: DutchX - fully decentralized auction based exchange
2 Likes