Skip to main content

Fee Oracle

The concept of off-chain oracles and on-chain oracle contracts was initially publically proposed by Vitalik Buterin in the Ethereum Whitepeper on page 12 concerning a scripting language. He suggested that an oracle architectural solution

"...is a massive improvement in trust and infrastructure requirement over the fully centralized solutions available now."

In the current official Ethereum documentation oracles are defined as:

Oracles are data feeds that bring data from off-the-blockchain (off-chain) data sources and put it on the blockchain (on-chain) for smart contracts to use. It is necessary because smart contracts running on Ethereum cannot access information stored outside the blockchain network.

Smart contracts have no way of verifying the data coming from the oracles. It introduces an element of trust. If the trusted entity malfunctions or misbehaves, it will affect the decisions made by the smart contract and may damage the users.

Oracles can use various methods to collect data, such as APIs, scraping websites, or IoT devices. Once the data is collected, the oracle can use cryptographic techniques to prove its authenticity and integrity and then send it to the smart contract.

To avoid a single point of failure and an element of trust, multiple identical oracles are launched in parallel. The oracles may submit data individually, which is expensive and unscalable (the more oracles there are, the more expensive their service becomes). An alternative is arriving at a consensus off-chain, signing the agreed data using elliptical cryptography, and submitting this signed message once in an interval of time or on demand.

XP.NETWORK Bridge Fee Oracle

Problem:

XP.NETWORK bridge collects the fees for bridging on the chain of departure and destination once in the native tokens on the chain of departure. The smart contract sitting in a blockchain is not aware of the existence of the other chains, leaving alone tracking the exchange rates of the native and the foreign token. All it can do is check that the msg.sender paid some fee greater than zero. It can be billions of dollars or a billionth of a cent. The contract cannot verify the amount's validity on its own.

It can cause one of two problems. It can become an attack vector when users deliberately provide minimal fees to drain the tokens from the bridge validators. Users can lose their tokens if the validators compare the fees and refuse to submit a transaction because they will lose their tokens instead of earning a reward.

Solution:

Here is where the Fee Oracles come into play. They fetch the estimation of the transaction fee on the chain of destination along with the exchange rates between the destination and the native tokens.

Now the smart contract can securely estimate whether the amount the user provides is enough. It is enough the contract goes on with the bridging transaction. Otherwise, the bridge reverts the transaction and returns the NFT to its original owner without moving it forward to the bridge validators.

Architecture and the new bridging flow:

Prerequisites: Alice has an NFT on chain A and wants to bridge it to Bob's account on chain B. Here are the transfer steps with the Fee Oracle in place.

  1. Alice selects an NFT in the XP.NETWORK bridge UI and signs the Transfer transaction.
  2. The UI uses the TypeScript xpjs API library.
  3. The API library sends a request to the network of fee oracles, each listening to the API of different market aggregators.
  4. The oracle network estimates the average price of the tokens, signs it using elliptic cryptography, and returns the data to the API library.
  5. XPJS submits the signed transaction with the signed fee estimation.
  6. The bridge smart contract locks the selected NFT in its vault.
  7. The bridge contract emits an event with all the relevant bridging data.
  8. The bridge validators unpack the event, repack it to the transaction, sign it with FROST, and submit it to the destination bridge contract.
  9. The bridge contract verifies the signature, unpacks the data, and mints a wrapped NFT in an NFT contract for Bob.

Fee Oracle Arcitecture

Thus, the fee oracle further hardens the bridge security protecting the validators from draining their tokens and the users from getting their NFTs locked by the smart contracts on the chain of origin but never minted on the chain of destination.