A Concept for Decentralized & Incentivized Oracles
In mid-July this year the largest cross-chain bridge, Multichain (Anyswap), stopped its operations. The effects can only be summarized with the word “chaos” as many bridged assets lost their value and many Web3 applications halted.
The Fantom Network was one of the most affected networks as most of its stablecoins were bridged assets (including $USDT and $USDC), assets that are not supported natively. However, the biggest outcome was that most of the lending/borrowing protocols halted their operations as the Chainlink oracles were not reliable anymore because of the de-pegging of bridged stablecoins.
This made me think, what if we can create an oracle that is just an on-chain smart contract and doesn’t rely on 3rd parties for the data entry but everybody can contribute?
The Need for Oracles
Let’s assume we want to use the price of ETH in our protocol, why do we need an oracle? There are many liquidity pools (LP) of ETH and a stablecoin. In theory, our protocol just needs to look at the ETH and stablecoin reserves of one of those LPs and do the calculation. (The price can be calculated by dividing the amount of ETH in LP by the amount of stablecoin, keeping in mind the decimals.)
However, a malicious party may do a flash loan (borrowing a coin and repaying at the end of the transaction), buy a bunch of ETH to inflate its price, and exploit the protocol for its profit. This is where the concept of oracles comes in, a reliable data source.
The Concept
If we go with the example of ETH and USDT, the ETH price exists on-chain which can be calculated by dividing the number of ETH in the liquidity pool by the number of USDT in the liquidity pool. So any user can record this data to the Oracle contract with the block timestamp. As this is not a custom value it can be trusted to some extent.
As this is a collaborative oracle, every wallet & smart contract will be able to record this data. Time-weighted prices are more trusted than instant values, so the time-weighted average price of the token can be calculated by going through the last n values recorded in the Oracle contract. This time-weighted price can also be stored on the contract for more gas-efficient retrieval when a contract reads the price.
The Incentives
As it is much better to reward good behavior ‘financially’ instead of relying on people doing good from the bottom of their hearts, a reward/incentive system for collaborating users is a must.
The most straightforward system would be to take a small fee (probably in the chain’s native currency) from every smart contract or person who performs a read from the Oracle protocol. This pool of fees then can be distributed to wallets which recorded data to the oracle. Many paths can be taken about how to distribute the rewards; for example: every recording can be rewarded the same or the data recordings that happened when there is less data can be rewarded more (similar to a supply & demand logic).
Possible Risks and Attack Vectors
As mentioned before, the main problem with reading the on-chain data and acting accordingly is that it can be manipulated easily with flash loans. Calculating the time-weighted price and allowing entries from multiple sources prevent this type of attack to an extent but still, an attacker may do multiple flash loans & record data transactions with high gas prices to inflate the target price.
Only allowing wallets to record data, not smart contracts, can also be a preventive measure as flash loan attacks become risky for the attacker itself without a contract as a proxy.
Making the Oracle openly collaborative probably includes other risks I can’t think of now but if you want to share and discuss your ideas feel free to leave a comment or add me on Twitter to discuss privately.
