Detecting & Preventing False Price Spikes - PIP 15

Preventing API Errors From Reaching The Blockchain

TL;DR

Once in a while an API reports bad data. When this happens if there is no process for checking that data, the faulty prices reported can be passed onto miners and then published on the blockchain and ultimately cause false conversion rates on PegNet. In order to avoid this issue PIP 15 proposes a simple method for detecting false data and switching data sources when an pAsset is outside a reasonable price band.

The Risk of Faulty Data From An Aggregator Provided to Miners

There is a risk that one of the aggregated data sources (such as CoinMarketCap.com, CoinCap.io) can provide miners with faulty pricing. This faulty pricing would lead to negative outcomes such as those converting pAssets getting incorrect conversion rates, either too high or too low.

Below I examine two methods that might be used to detect and prevent these type of errors.

Method A, FOSEP — (Faulty Oracle Source Exclusion Parameter)

A proposed solution to this risk vector is for PegNetd to poll all enabled datasources for a pAsset, and compare results from multiple data provider API’s to protect against bad prices being published on chain. If one datasource returns a price out of the defined tolerance band (ex: 100%) in comparison with the other sources, it will not allow that source’s price to be included in that block. This can be described as a “validation check” to ensure a primary datasource for any asset (ex: PNMC) is not compromised. This keeps bad prices from being published on chain, and closes the exploit loop if one were able to manipulate a primary datasource.

This solution is fairly straight forward to implement as all pAssets have multiple data sources available to use as back ups. And while miners end up using similar sources of data, by having the software detect the error it will help all the oracles move to a better alternative source of data. Also the API errors would have to be seen across all the data sources in order to stop conversions on the network.

Method B — Spike Triggered Pauses (STPs)

PegNetd can compare prices from the past block to the current block and pause conversions, when pAssets or PEG prices have a greater than 50% reduction or 100% increase block over block.

This circuit breaker type method is more complex though as it causes conversions to stop and it would have to be determined when they should start again. Also if an attacker knew that the oracles were using a particular source of data they could try and compromise that data source as a means of freezing conversions on the PegNet.

Conclusion

For the reasons of robustness method A has been selected to be implemented.