> 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/overview/technical-design/components.md). # Components ### Oracle Oracle is an off-chain component operated by each validator within the Skyline's blockchain. Its primary role is to monitor key bridge activities, including: 1. Bridging requests 2. Batch executions Depending on the chain source type, there are a few different ways in which the Oracle identifies the bridging requests: 1. For the UTXO chains, the Oracle tracks transactions that generate output UTXOs associated with the Skyline’s multisignature address, which controls the bridging funds 2. For the EVM chains, the Oracle tracks transactions that are locking the funds to the smart contract, which controls the bridging funds Once such a transaction is detected, it undergoes validation,e.g., checking if the amount stated in metadata corresponds to the amount transferred to Skyline’s multisignature address, including necessary fees, validating if the bridging direction is acceptable, etc. If deemed valid, its data is incorporated into a new 'claim' transaction and submitted to the Skyline's blockchain. Similar claim transactions, containing relevant details, are also submitted for Batch executions and refunds. On the Cardano and Apex Fusion, the metadata stored in executed transactions helps classify the type of bridge-related activity (e.g., bridging request, Batch execution, refund processing, etc.). In the case of batch executions, the Oracle verifies not only the metadata but also whether the observed transaction is signed by the multisignature address to ensure security. On the EVM-type chains, Oracle detects bridge activity by indexing Gateway smart contract events. The event type classifies the type of bridge-related activity(e.g., Withdraw → bridging request, Deposit → batch execution, etc.), and transaction internal metadata is used to further process the transaction. Only Oracles operated directly by Skyline's validator nodes are authorized to submit claim transactions, positioning them as integral and highly trusted entities within the Skyline ecosystem. ### Batcher Each bridge validator operates a trusted off-chain component known as the Batcher, responsible for monitoring the Skyline's blockchain and determining the appropriate time to initiate a Batch creation. The Batcher generates a Batch instance representing the transaction that will be executed on the destination blockchain. In addition to creating the batch, each Batcher must submit one or more signatures to the bridge blockchain, depending on the chain it operates on. For UTXO chains,two signatures are used, one signature is produced by the key associated with the multisig address that controls fund unlocking, while the other is generated by the key linked to the multisig address responsible for covering network fees on the destination chain.For the chains, a single signature is used for smart contract verification. ### Relayer After a batch is confirmed, it must be submitted to the destination blockchain. To handle this process, a dedicated trustless component is required, operating as a single standalone instance. This component, called Relayer, can be run by any participant in the system, as only one instance is needed. The Relayer's primary role is to retrieve batches from the Skyline's blockchain and submit the corresponding transactions to the destination chain. Before doing so, it must aggregate individual validator signatures from the batch to generate the necessary multisignature, which authorizes the spending specified in the batch. Notably, the Relayer does not cover the network fee for the transaction. Instead, the fee is paid by the validator-controlled address. ### Skyline Smart Contracts Skyline Smart Contracts are being executed on Skyline blockchain and represent a “source of truth”, ensuring that the consensus is reached on events registered by the off-chain components, based on the Istanbul Byzantine Fault Tolerance consensus mechanism. For instance, when a bridging request occurs, Oracle independently submits claims or batches to the Skyline Smart contract. Once the Skyline Smart Contract accumulates a sufficient number of these independent validators' submitted claims or batches, the Skyline Smart Contract will officially recognize those claims or batches as valid and securely advance to the required following steps. Figure 3 illustrates the main components of the Skyline Bridge

Figure 3 - Skyline Bridge main components