The Relay Oracle can attest a few types of messages (this list can be extended in the future as new functionality is added to the protocol):
  • depository deposits
  • depository withdrawals
  • solver fills
  • solver refunds

​
Depository deposits

As mentioned in the Depository section, users can deposit funds to the Relay Hub via the depository of any given chain. These deposits are initiated on external chains, which requires an oracle attestation of the deposit details (eg. token, amount, depositor, optional id).

​
Depository withdrawals

Whenever a user wants to withdraw funds available on the Relay Hub, they need to request a signature from the allocator, authorizing the withdrawal of those funds. This signature can then be used in a transaction for triggering the withdrawal of funds. However, it’s never guaranteed that a signature the allocator released is going to be executed onchain. The oracle is responsible for determining the status of an allocator signature: whether it was executed onchain, it’s still pending / possible to be executed onchain, or it’s expired and never possible to have it included onchain.

​
Solver fills

User deposits can specify an optional id, which usually represents the id of an order to be executed on their behalf. In this context, when the user deposit gets on the Hub, it’s going to be locked and associated to the order id. If the order-designated solver successfully fills the order, they can use an oracle attestation denoting the successful fill in order to get the order-locked funds.

​
Solver refund

Similar to the solver fill logic, but relevant when the solver is unable to fill the order, and refunds it instead. The oracle is going to attest a successful order refund.