> For the complete documentation index, see [llms.txt](https://docs.skylinebridge.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.skylinebridge.tech/bridge-components/oracle.md).

# Oracle

To bridge funds from the source to the destination chain, a transaction is made on the source chain. The sender sends the amount they want to bridge, plus the bridging fee, to the address owned by the bridge, where the bridged amount is locked. This is all paid in the native currency of the source chain. If a native token is being bridged, the token is paid in its native form, and the bridging fee is paid in the source chain’s native currency. The sender also pays the transaction fee on the source chain. A transaction is created and submitted to the source chain, with metadata specifying the transaction type, which identifies the transaction as a bridging request, in addition to the initiator, recipients’ addresses, amounts being bridged, and the bridging and operation fees.

The Oracle component called the Observer is responsible for monitoring a specific blockchain and staying in sync with it. An Observer is started individually for each chain participating in the bridge. It connects to the node of the corresponding chain and starts syncing from a specified slot. When a new block header is received from the node, the Observer's syncer forwards it to the indexer for processing. The Observer's indexer processes the block once it is confirmed. A block is considered confirmed when enough newer blocks have been added after it. Processing begins by retrieving the block's transactions from the node. Each transaction is then checked to see if it is relevant. For UTXO chains relevant transactions are transactions that involve UTXO related to a known bridge-controlled multisig bridging addresses. For EVM chains, the observer uses log indexing: it filters logs by the configured Gateway contract address and a fixed set of event signatures. After the required number of confirmations, each relevant log is converted into an internal transaction record and stored for processing. Such transactions are considered relevant, recorded in the database, and require further processing. Based on the transaction's metadata, from which the transaction type is extracted, the transaction is forwarded to Oracle's appropriate processor. At this stage, a bridging request transaction is assigned the status *discoveredOnSource*.

Depending on the transaction type, the processor applies a corresponding validation logic. Transactions that fail validation are marked with the status *invalidRequest*. For each valid transaction, the processor immediately creates and submits a claim by calling the bridge's smart contract. The processor then waits for the transaction receipt to check whether the logs contain specific events indicating that the submission of one of the bridging request transactions was unsuccessful. If such an event is detected, the bridging request transaction will be retried in one of the next processing cycles. Upon successful submission to the bridge's smart contract, transactions are given the status *submittedToBridge*.

Batch execution transactions are also recognized by Oracle's indexer component, and Oracle is responsible for validating them, creating claims, and submitting them to the bridge's smart contract. A dedicated processor for this transaction type validates the batch and creates a corresponding claim, which may be a successful or failed claim depending on the validity of the batch transaction. The claim is then submitted. All individual transactions included in the batch must be retrieved from the bridge's smart contract. In the case of a failed claim, the associated bridging request transactions are marked with the status *failedToExecuteOnDestination* and will be reprocessed. Transactions that are successfully executed are marked as *executedOnDestination*.