Oracle systems
LI.FI intent lets you plug in custom validation and oracle layers, empowering you to choose the optimal trust and speed tradeoffs for your cross-chain use case.
Any validation layer can be added as long as it supports validating a payload from the output chain.
In the simplest implementation, a validation layer needs to support the following:
-
A submission interface where solvers can submit their filled outputs. The submission interface should accept arbitrary packages for validation and then call the associated output settlement contract to check whether the payloads are valid.
-
Implement the associated validation interfaces so that Input Settlement implementations can accurately verify whether outputs have been filled.
Importantly, the submission interface does not have to be standardized; it just needs to be accurately documented so solvers can implement it.
Implemented Validation Interfaces
There are three types of validation interfaces:
- Self-serve: Validation interfaces where submitting the payload generates an off-chain proof that must be collected and submitted on the input chain.
- Automatic: Validation interfaces where submitting the payload automatically delivers the associated proof on the input chain.
Currently, all supported oracle systems are self-serve.
:::note[Speed & Price] Polymer is significantly faster than most other oracle systems. While speed does not impact asset delivery for users, it matters for solvers. Choosing an oracle system with fast repayments results in cheaper intents, as solvers can rotate their capital faster. :::
Polymer
Polymer allows validation of emitted events. The target event for validation is the OutputFilled
event, emitted when an output has been filled.
Using the Polymer prove API, a proof of the event can be generated. Once generated, it can be submitted to receivedMessage
.
For an example of such an integration, see the lintent.org implementation.
Polymer can only prove one filled output at a time.
Wormhole
The Wormhole implementation is based on the broadcast functionality of Wormhole. Messages must be submitted to the Wormhole Implementation via the submit
interface. Messages must be encoded into FillDescription
s and then submitted:
This message is then emitted to the Wormhole guardian set. Once the associated proof becomes available, the solver can submit the proof to receiveMessage
on the input chain to validate their intents.
Note: The Wormhole implementation uses a more efficient validation algorithm than Wormhole’s Implementation.sol
.
Bitcoin
LI.FI Intents has a Bitcoin Simplified Payment Validation (SPV) client implementation. This implementation works both as an Output Settlement implementation and as a validation layer.
The Bitcoin SPV client requires constant upkeep—the blockchain must be updated approximately every 10 minutes, or whenever a transaction needs to be proven—to properly validate transactions.
To generate a transaction proof, refer to the code below: