PID control with stablecoins

I really like the idea of shares being a staking token. But that would basically mean that the system would be a separate blockchain and not a solidity contract since the staking tokens allow the holder to participate in a Byzantine process (PoS). I think the simplest method for a seigniorage shares implementation might be to start it out as a pure solidity contract (that can then use Plasma later if need be). The other thing is that being fully on Ethereum allows assets to be auctionable for any on chain asset other than just coins for shares and shares for coins (you can refer to my other post above for this idea, although I’m not sure how amenable you are to it).

I guess this ends up as a hybrid between an SS design and a crypto collateral design like MakerDAO. Both valid approaches with very different economics. Not sure how they would work together, maybe the
other tokens crowd out the shares and it just converges to a collateral scheme defacto.

I think the simplest method for a seigniorage shares implementation might be to start it out as a pure solidity contract (that can then use Plasma later if need be).

I’m a fan of a SS stablecoin on ethereum that targets plasma chains. We’ve been looking into that recently, think there’s real synergy there!

1 Like

Interesting. Will checkout your implementation.

I have this implementation on the same line for an ICO/Token with floating supply based on #TransactionsPerDay, if transactions go down I remove supply per wallet, or viceversa. The idea was to reduce volatility of the token price:

I recommend a 100 day Moving Average for Daily updates (100 points), based on empiric tests…

I agree that “hybrid SS” is a good way to describe it, but I don’t think it would ever converge to a MakerDAO collateral scheme because in the Hybrid SS way that I proposed, the shares always act as equity in the system which means 1 share is always entitled to (1/totalShares) of the assets held in the smart contract + (future expected expansion of the network) which is never the case for MKR holders since CDPs are needed to act as collateral for outstanding Dai. Additionally, shares can be printed to retract supply at any time which isn’t possible for MKR tokens unless the system needs a “lender of last resort.” I really like the seigniorage share system (you’ve done a great job conceiving it!), it’s much better than alternatives, but I think having the flexibility to auction printed cash/coins for any asset to build a balance sheet of many products (like a real Federal Reserve balance sheet) would make the idea truly good enough to become a global, stable currency since it incorporates the most adaptive features of central banking monetary policy + the efficiency of decentralized systems. :smiley:

1 Like

Staked shares can in fact be used as collateral to finance contractions. By receiving txn fee dividends they are less speculative than shares in pure seigniorage, and per Vitalik’s point retain value even in long-term/terminal recessions. This need not assume PoS for consensus. We can decouple the stablecoin mechanism from the consensus protocol.

1 Like

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:
https://github.com/gnosis/dutch-exchange-smartcontracts/tree/contracts/SmartContractAudit2.0

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.

1 Like

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.

Is this mechanism applied to the ETH, too ?