Deprecated solution, please check Delphi-II for the currently used architecture.
The Delphi-I Oracle System has the following high-level overview schema.
Each component is detailed in its respective section; this provides an overview of the execution flow and architecture.
Collybus will price the supported assets differently based on Delphi's pushed values.
Given the importance of correctly pricing the supported assets, we tried to create a resistant system to malicious manipulation. It is also vital to allow it to react quickly if the market asset values change.
The security of Delphi heavily relies on the safety and correctness of the on-chain value providers.
Frontrunning and sandwiching transactions are attack vectors we considered when we designed Delphi.
We protect from transaction reordering by:
- guarding the
update()method, allowing only a specific set of actors to trigger oracle updates;
- using a private transaction relayer; does not publicly add the pending transaction to the public mempool.
We considered an attack vector if a malicious actor wants to manipulate an on-chain value right before that value is read by our oracles. We assume a high cost of keeping that value significantly different from the actual value. Suppose the value is manipulated to be different from what the world considers the actual value; we assume actors that arbitrage the markets will act as an opposing force pushing the value to its actual value.
Vetoing the value can be done by resetting the oracle value and pausing the system. This can force the attacker to pay the price of manipulating the markets once again. Again, we consider the cost of manipulation high and unfeasible.
We pick carefully the data sources when we deploy the oracles. At the moment deploying an oracle and including it in the global system is a trusted action, no random actor can create and use their own data source. Our governance defines the accepted data sources and can do the necessary actions to add a new data feed.