Technical Architecture
Last updated
Last updated
As Web3 applications and infrastructures continue to grow, with many innovative ideas being built on the blockchain, the need for interoperability between siloed blockchains has become more and more pressing. This is one of the most important problems that need to be addressed in the blockchain space, not just because of its necessity, but also because most existing interoperability solutions pose huge vulnerabilities. Just in 2022 alone, over $2 billion worth of crypto assets were hacked due to exploits on multi-chain bridges that relied on a centralized infrastructure, server/node for cross-chain data validation and transfer. These centralized solutions introduce a single point of failure, where exploiters target and tamper with data being sent across chains.
LiquidsFi Decentralized Oracle Network (LDON) offers a secure, decentralized interoperability infrastructure that connects siloed blockchains. Similar to Chainlink’s Cross-Chain Interoperability Protocol (CCIP), which serves the interoperability needs of EVM chains, LDON enables secure connections between EVM chains and the Soroban/Stellar ecosystem. The goal is to facilitate seamless asset bridging and the transmission of on-chain data between EVM chains and Soroban/Stellar. With LDON, secure bridging between dozens to hundreds of EVM chains and the Soroban/Stellar ecosystem is now possible.
The rest of this document provides a technical overview of the LiquidsFi Decentralized Oracle Network and the EVM-Soroban bridge built on top of it. Since the decentralized and secure EVM-Soroban/Stellar bridge is the primary application built on LDON, the overview presents the system as a whole, with LDON serving as the underlying Oracle network that supports the decentralized bridge.
The LiquidsFi Decentralized EVM-Soroban Bridge (referred to as the "Bridge System") is a secure solution for bridging assets between dozens of EVM chains and Soroban. The system consists of two main components: the underlying LiquidsFi Decentralized Oracle Network (LDON), which ensures the secure transmission of asset transfer data from the source chain (EVM) to the destination chain (Soroban), and the Liquidity Protocol, responsible for asset management, including locking, releasing, or minting assets as needed.
The above schematic (Fig1) illustrates the high-level technical architecture of the Bridge system.
Before diving into the details of each component and its role, here is a brief overview of how the system functions:
When a transfer is initiated on a source chain, such as Ethereum, the tokens are received and locked in the liquidity protocol contract on that chain. The transfer data is then broadcasted/emitted by the on-chain oracle consensus mechanism contract. This data is captured by each node in the decentralized node network (DNN) and routed to the appropriate destination chain. Each node then signs the data payload and commits the data to its receptacle (entry point) contract on the destination chain.
The on-chain oracle consensus mechanism, designed to monitor incoming data from all authorized nodes, checks the receptacle contracts of all whitelisted nodes on the destination chain. It collects the incoming data and performs on-chain consensus validation. If the number of nodes agreeing on the data meets the consensus threshold, the data is accepted as valid, and the intended state update is executed, thereby releasing or minting the tokens transferred to the recipient address on the destination chain.
Fig. 2 here shows the main processes that takes place when a transfer is initiated.
We shall now present and in-depth detail of all the components that makes up the Bridge System
The LDON, or LiquidsFi Decentralized Oracle Network, is responsible for the secure transmission of data between EVM chains and Soroban. It has two main components: the Decentralized Node Network (DNN) and the on-chain Oracle Consensus Mechanism (oOCM).
The DNN is responsible for transmitting data between any pair of supported chains: a source chain (where the data originates) and a destination chain (where the data triggers a state change).
The DNN consists of 10 to 20 independent nodes, each transmitting data between source-destination chain pairs. Each node in the DNN performs the following tasks:
Receiving the data payload from the source chain
Signing the data payload before transmitting it to the consensus contract
Routing the signed data payload to the destination chain and committing both the data and the signature on-chain
As shown in the schematic above, the DNN consists of the Relay Network—a network of independent node relayers, each having two receptacle contracts, one on either side of a node relayer.
To clarify, let’s consider a source-destination chain pair, such as bridging assets from Ethereum to Soroban. Each node in the DNN has two sides: the source chain side (Ethereum) and the destination chain side (Soroban). Therefore, a complete node in the decentralized network has one receptacle contract on the source chain side and another on the destination chain side.
In total, the DNN is composed of 10 to 20 independent node systems, each with a receptacle contract on each supported chain and a node relayer in between.
The receptacle contract serves as the entry point for each node in the DNN where incoming data and data signature are committed. Instead of each node directly committing data to the on-chain Oracle Consensus Mechanism (oOCM), nodes commit data to their respective receptacle contracts on the destination chain. This setup prevents data contention, congestion, and transmission delays that would occur if all node systems in the DNN tried to commit data directly to the on-chain Oracle Consensus Mechanism.
The node relayer is the off-chain component of each node system in the DNN. It captures, signs, and routes the transmitted data to the intended destination chain. Each node relayer in the DNN implements several mechanisms to ensure data transmission efficiency and scalability, while also preventing vulnerabilities such as replay attacks, data manipulation, latency, and more. These aspects will be discussed in the "Security Considerations" section later.
In LiquidsFi Decentralized Oracle Network, there is an on-chain oracle consensus mechanism (oOCM) for each supported chain. The oOCM is a consensus protocol contract deployed on each supported chain and is responsible for the following:
Broadcasting Transmitted Data: When an outgoing transfer originates from a source chain, the on-chain oracle consensus mechanism on that chain broadcasts the outgoing transfer data in the form of an outgoing transfer event emission. This data is then captured by all node relayers in the relay network.
Receiving and Performing Consensus Check on Transmitted Data: On the destination chain, the oOCM receives incoming data from all whitelisted node systems in the decentralized network via their destination chain receptacles. The oOCM then performs a signature based consensus check on the data.
Triggering State Change: If the consensus threshold is met, the oOCM triggers the necessary state change. In the case of a token transfer, this means updating the balance of the recipient wallet. The execution node network then fulfills this by either releasing or minting the token to the recipient, based on the token bridging implementation.
The Liquidity Protocol is a liquidity pool and asset management contract implemented and deployed on each chain supported by the bridge system. This means the Liquidity Protocol is deployed on Soroban, with a version compatible with EVM chains on every supported EVM chain. The Liquidity Protocol implements several mechanisms, including the token lock-and-release mechanism, token lock-and-mint mechanism, token deposit-and-mint mechanism, token burn-and-withdraw mechanism, and asset balance management mechanism.
The Liquidity Protocol is responsible for the following:
Receiving and Locking/Burning Tokens: On the originating chain, the Liquidity Protocol receives and locks or burns the tokens being transferred before the on-chain Oracle Consensus Mechanism (oOCM) on that chain broadcasts the transfer data to the decentralized node network.
Releasing and Minting Tokens: Once an incoming transfer has been validated by the oOCM, the Liquidity Protocol either releases or mints the tokens to the recipient wallet, depending on the token implementation.
In addition to the functions stated above, the Liquidity Protocol is also responsible for:
Locking Asset Deposits and Minting Protocol Tokens: When users add liquidity to the bridge liquidity protocol, their deposit is locked, and an equivalent amount of protocol tokens is minted to the user's wallet.
Burning Protocol Tokens and Releasing Assets: When a user withdraws liquidity, the Liquidity Protocol burns an equivalent amount of protocol tokens corresponding to the amount of assets being withdrawn by the user.
In addition to the mechanisms implemented by the on-chain Oracle Consensus Mechanism (oOCM) to secure the bridge, the Decentralized Node Network (DNN) and its independent nodes incorporate several security measures to ensure that all data transfers are tamper-proof and executed only by authorized nodes. These include:
1. Decentralized Network of Independent Nodes
The DNN consists of 10–20 independently operated relay nodes. Each node independently captures transfer data from the source chain’s oOCM and routes the signed data to the oOCM on the destination chain. Because nodes operate independently and do not coordinate off-chain, the system maintains true decentralization, significantly reducing the risk of collusion or 51% attacks.
2. KYC-Verified Node Operators
All node operators undergo a Know Your Customer (KYC) verification process before being allowed to participate in the network. This ensures accountability, transparency, and regulatory compliance, adding a strong layer of trust to the network’s operator base.
3. Staking Requirements
Relay node operators are required to stake XLM tokens as collateral. A minimum staking threshold is enforced to ensure that only entities with a meaningful economic stake in the system can participate as validators. This aligns incentives and discourages dishonest behavior.
4. Penalization via Stake Slashing
Nodes that behave dishonestly or transmit incorrect or tampered data are penalized through stake slashing. A portion (or all) of the misbehaving node’s staked tokens is forfeited. This acts as a strong economic deterrent against malicious activity.
5. Sliding Time Window for Data Validation
Each node implements a tight sliding time window for monitoring and transmitting data. Only data emitted within the valid window is transmitted and accepted; any data outside of the allowed time frame is stale data hence discarded. This mitigates the risk of replay attacks, where old data is maliciously re-submitted.
6. Signature-Based Verification
Each piece of transmitted data is cryptographically signed by the node operator. The oOCM on the destination chain performs a signature-based consensus check to verify that only valid, authorized nodes have submitted matching data payloads, and that a sufficient quorum of nodes agree on the data.
By combining decentralized node operations, cryptographic validation, staking and slashing, strict timing controls, and KYC-verified participation, LiquidsFi’s Decentralized Node Network ensures a secure, compliant, and tamper-resistant interoperability layer between Soroban and EVM blockchains.
