Minimal price feed design

[mhluongo]

What does a first-release price trusted feed look like?

Document the simplest possible BTC/ETH price feed

[liamzebedee]

Price feed:

• is used simply for calculating the value in native chain currency of BTC.
• the usage is something along the lines of getPrice() * COLLATERAL_VALUE.
• is maintained by a single trusted actor (v1)
• will be governed in future (as in MakerDAO)

A pseudo-interface:

interface PriceFeed {
    function getPrice() external view returns (uint128);
    function updatePrice(uint128 price) public;
}

Resources:

• MakerDAO Price Feed docs

updatePrice

MakerDAO implements two additional prerequisites on updatePrice:

1. Source price differs to the most recently submitted price by more than the defined amount (currently 1%)
2. Last price update was more than 6 hours ago.

#1 avoids the network's nodes from spuriously recomputing things for price changes of negligible magnitudes.

#2 is more a mitigator from DoS attacks of feed providers.

Governance

Eventually KEEP holders will govern a couple aspects of tBTC, including the price feed mechanics. The price feed underlies the entire cryptoeconomic proposition of tBTC and its malfunctioning is a systematic risk.

MakerDAO has quite an effective risk team, evidenced by their preparation for black swans and the like. A couple concerns we should analyse:

• Access control: how do we design for the potential that we will have to change the owner, in the case of hacking etc.
• Aggregating price signals: we at some point move to a Medianizer model from MakerDAO in future (else it's not really decentralized BTC). There's talk of using on-chain markets as signals too (ie. a Uniswap exchange). Do we want the design to allow this to be "governed in"?

[liamzebedee]

Minimal design rationale

• ACL - one operator account
• 1% minimum price change for update
• simple governance through upgradeable contract proxy (if it exists yet, else no): this lets us replace the contract entirely if the operator account is hacked, as well as upgrade in future to support more decentralised designs

Future design rationale

• Medianizer feed model, which is parametrised and governed by;
  • minSources - minimum number of feed sources
  • minDelta - minimum price delta to justify an update
  • minTimeBetweenUpdates - minimum time before the next update

[liamzebedee]

I should add, that Maker uses uint128 representation for USD prices of 1 ETH. I'm going to trust their logic here, my assumption being that it's extremely unlikely that BTC and ETH's value will differ on an order of magnitude big enough to overflow (although ETH does have a different supply/issuance to BTC)

[mhluongo]

We expect weis per satoshi elsewhere- @prestwich promised he'd eat his hat if we ever overflowed 😂

[mhluongo]

To be clear

Eventually KEEP holders will govern a couple aspects of tBTC, including the price feed mechanics. The price feed underlies the entire cryptoeconomic proposition of tBTC and its malfunctioning is a systematic risk.

We don't want this to be KEEP holders- there's a "somewhat free rider problem" where not all KEEP holders are aligned with the best interests of the tBTC system, so they shouldn't govern it. Instead, we'll mint a tBTC specific governance token that we'll use for stuff like this past v1.

That said, the plan for now is just to mint and distribute it appropriately, and eventually turn over param tweaks and governance upgrades to the holders after v1 is on mainnet.

[liamzebedee]

Maker also implements a price expiration time (zzz) - calls to the oracle's getPrice REVERT in the case the price is out-of-date. I think this is a good idea - effectively blocking liquidations, if the price oracle stops being updated (eg. maybe there's an active DoS on the tx pool) - rather than transferring the risk to the bonders. Thoughts? @mhluongo @prestwich

[liamzebedee]

Just did some research into the auth structure. In a system with so many moving parts, especially if they're smart contracts, I think using something that's both well-designed and explicit is essential.

OpenZeppelin contracts have historically been of average quality. I did some brief exploration into MakerDAO's Dappsys libraries (see the branch comparison), which are top-notch and simple to use. They have a couple components: DSThing, DSAuth, DSProxy....that look very useful/powerful for our case. Especially the DSProxy which is good for atomic upgrades (cc: keep-network/keep-core#726)

They look very good. I don't want to tread on anyone's feet, but auth obviously should be standardised across the entire system. Probably best to have a call this week and discuss.

[liamzebedee]

To summarise, based on the feedback from the access control RFC, we're going to standardise on some auth architecture/patterns but at a later date - the current milestone doesn't put this at high priority.

Instead, the minimal design will incorporate a single trusted operator address.

[mhluongo]

Maker also implements a price expiration time (zzz)

Price expiration seems like a good idea