How would we do something like that while allowing shares to be staked? Staking is a hallmark of a Byzanztine process.
Staking in this case can be applied to the stability layer rather than the consensus layer – staked shares may be borrowed by the system to finance contractions (by burning coins ala SS), and in exchange receive txn fee dividends (as interest). So like PoS by staking you are rewarded for offering a service to the system. In this design we can have a fixed supply of shares, since contractions are financed using outstanding shares. This fixes the problem that shares in the SS mechanism are infinitely dilutable. Shares also retain value during extended contractions, which improves the ability of the system to finance them adequately.
For expansions, how does the stablecoin contract decide which crypto assets are “eligible” for auction vs new coin? Hard-coded or some sort of governance? For contractions, is the collateral ever sold vs destroying coin (and if so, how does that mechanism work), or only shares ever sold (and collateral locked up forever)?
What sort of tests have you run?
I’m wary of moving averages because when a demand shock occurs it will likely require an immediate response and an SMA would dull the response of the system.
Governance. The monetary policy should be decided by shareholders (like how equity holders vote on board resolutions in a company). The way that I am envisioning this is that there are functions called buyWhatForExpansion() sellWhatForRetraction() and it is voted on simply as a majority vote (or some more complex voting scheme if possible to prevent gaming). For example, if more stablecoins need to be printed and auctioned off, the contract checks what the current asset that is voted by majority of shareholders is. If it’s ETH then any time the coins are printed, the asset that they are auctioned for is ETH. If the majority vote is for another asset such as BAT then that’s what it is auctioned off for. When retraction needs to happen, the asset set by the function sellWhatForRetraction() is auctioned off for coins and the coins are burned.
Keep in mind that the base case of buyWhatForExpansion(SeignorageShares) and sellWhatForRetraction(SeignorageShares) is the normal implementation described in your whitepaper. These two functions just provide a democratic way for the SS smart contract to vote on holding different assets like how the Fed sells/loans USD for other national currencies, stocks, bonds when it needs to increase the money supply. It’s just a neat feature I think would allow further flexibility and expansion of the system. For example, ETH price is pretty low right now compared to the USD price. If coins are pegged to USD price, it might be a good idea for the SS contract to buy ETH when new coins are printed if shareholders believe that ETH price will go up in comparison to the pegged price in the future.
I posted the implementation with Etherscan and Github links to a new thread since the thread title isn’t totally relevant anymore.
I ran numerical tests on historical BTC #transactions, price and supply.
The prototype includes an economic limit for period shocks on #transactions to limit the profit of an attacker when the supply is impacted. The inflation of supply per period is never profitable as an attack on a single period. Also Moving Average on 100 periods for #Transactions to control supply makes any attack harder because the attack has to persist for many periods to affect the supply. The concepts are based on NVT Ratio influence on Price:
"In other words, the cryptoassets exhibit reflexivity. In the short run, the price changes the fundamentals. In this case, transaction volume follows price. I don’t want to go into much detail on this, but I can refer you to an excellent article on the topic by the Coinmetrics team: “Mean-reversion and reflexivity: a Litecoin case study”.
So why does a longer period average result in a better indicator? Intuitively it makes sense. By definition, the role of Transaction Volume in the NVT denominator is to be a proxy for fundamental utility that users get from using the network. A longer smoothing period helps to get rid of the reflexivity effects described above — spikes in transaction volume that follow sharp price increase."
If I have direct access to the price feed though, why do I need to track the transaction volume at all? Bitcoin prices are volatile and I understand the need for moving averages. If you look at the price feed of something like Tether though, the movements away from $1 are sharp, sudden swings following periods of long stability.
Slightly off-topic but someone pointed me to this comment.
We have build an exchange based on dutch auctions. The parameters are:
- Anyone can register a new token pair.
- auctions will start at 2x the previous price and fall down to 0 after 24h. They reach the previous price after 6h
- thus on average an auction should run 6h
- the system will always start two parallel auctions (selling A for B; selling B for A)
- auction start 15min after previous auctions closes - but only if a threshold in sell volume is reached
One of the things that motivated us to build this was indeed to have a resilient price feed. We will take a weighted average of the 2 parallel auction and in addition a median value of the last 6 auctions. This will make the feed quite slow but also very hard to manipulate. Other usecases might want a more reactive feed and use data from a automated market maker like Bancor.
(we need that obviously for many prediction market use cases but also for stuff likedecentralized collateralized token lending)
The first audit passed already - expect a public bug bounty program next week and a mainnet launch within the next 6 weeks:
Seignorage Shares implementation on Testnet
This looks like an interesting system @mkoeppelmann. I’ll take a look at the code and keep an eye out for how it works on the mainnet. I like the idea of creating a decentralized price feed from previous auctions. I was planning on doing a series of 10-30 minute auctions so a reliable price signal could be established in an hour or so.
Good luck with the launch.
I’m not sure how you planning to “destroy” tokens. Once I built a token for study purposes where the “balances” could be changed on the fly over a new “base”. You could derive that to make your “PID” control input.
Here is the code https://github.com/ethereans/abstract-token/blob/master/contracts/AbstractToken.sol#L47
Take close look to “safe decimals” methods.
we’re using an auction system where shares are printed and auctioned off to remove coins from circulation.