LIP Technical Details
At its foundation, LiquidsFi Interoperability Protocol (LIP) operates as a Decentralized Oracle Network (DON) similar in concept to Chainlink’s Cross-Chain Interoperability Protocol (CCIP). However, LIP introduces several key enhancements, including simplified integration for cross-chain smart contracts, native support for non-EVM chains, and an architecture optimized for data transmission as well as asset movement.
The LIP DON enables secure, authenticated messaging between multiple EVM chains and Soroban. This infrastructure supports reliable cross-chain data transmission, asset bridging, and advanced interoperability operations.
The remainder of this documentation provides a technical overview of LIP’s architecture, using the LiquidsFi Soroban–EVM Bridge as a case study — since the bridge itself is built on top of the LIP infrastructure.
LIP Implementation in a Cross-chain Bridge System
Case-study: LiquidsFi Bridge Liquidity Protocol
Overview
The LiquidsFi Decentralized EVM–Soroban Bridge (the Bridge System) is a secure, scalable interoperability solution that enables asset transfers between multiple EVM chains and Soroban. It is powered by two core components:
LiquidsFi Decentralized Oracle Network (LDON) – handles secure data transmission between chains.
Liquidity Protocol – manages locking, releasing, burning, or minting assets depending on the transfer direction.
High-Level Flow
A user initiates a transfer on a source chain (e.g., Ethereum).
The Liquidity Protocol on that chain locks or burns the tokens.
The on-chain Oracle Consensus Mechanism (oOCM) emits a transfer event.
All nodes in the Decentralized Node Network (DNN) listen to the event, sign the payload, and transmit it to the destination chain.
Each node commits the signed payload to its dedicated receptacle contract.
The destination-chain oOCM aggregates data from all receptacles and performs a signature-based consensus check.
If quorum is reached, the Liquidity Protocol releases or mints the tokens to the recipient.
Components of the Bridge System
1. LiquidsFi Decentralized Oracle Network (LDON)
LDON is responsible for securely transmitting data between chains. It consists of:
The Decentralized Node Network (DNN)
The On-Chain Oracle Consensus Mechanism (oOCM)
1.1 Decentralized Node Network (DNN)
The DNN is a network of 10–20 independent nodes. Each node handles payload transmission between source and destination chains.
Each node is responsible for:
Receiving the transfer payload from the source chain.
Signing the payload off-chain.
Routing the payload to the destination chain.
Committing the payload and signature into its receptacle contract.
Node Structure
Each node system consists of:
Two receptacle contracts – one on each participating chain.
A node relayer – the off-chain component responsible for listening, signing, and routing.
Receptacle Contracts
Each node has its own receptacle contract, which:
Serves as the entry point for that node’s payloads on the destination chain.
Prevents congestion and write conflicts.
Allows the oOCM to read data in a clean, organized way.
Node Relayers
The node relayer is responsible for:
Capturing events from the source-chain oOCM.
Signing payloads with the node’s private key.
Routing data to the destination chain.
Writing payloads into the node’s receptacle contract.
Relayers implement security features to protect against:
Replay attacks
Tampering
Stale data
Unauthorized data injection
1.2 On-Chain Oracle Consensus Mechanism (oOCM)
An oOCM is deployed on every supported chain (both Soroban and EVM). It is responsible for validating cross-chain messages and triggering the appropriate state transitions.
1. Broadcasting Outgoing Data
When a transfer is initiated, the source-chain oOCM emits an event containing the transfer payload. This event is captured by all authorized relay nodes in the Decentralized Node Network (DNN).
2. Aggregating and Verifying Incoming Data
On the destination chain, the oOCM:
Receives payloads submitted by whitelisted node receptacles
Verifies each node’s cryptographic signature
Ensures that a required quorum of nodes submitted an identical payload
Only matching, authenticated payloads advance to the next step.
3. Triggering State Changes
If the consensus threshold is met, the oOCM triggers the appropriate state change, such as:
Releasing previously locked tokens
Minting representative/wrapped tokens
This completes the cross-chain transfer process.
2. Liquidity Protocol
The Liquidity Protocol is deployed on every supported chain (Soroban + EVM versions). It manages all token flow operations for cross-chain transfers, including:
Token locking
Token burning
Token releasing
Token minting
Liquidity pool balance management
Responsibilities
1. Locking / Burning Tokens (Origin Chain)
On the originating chain, the Liquidity Protocol locks or burns the user’s tokens before the on-chain Oracle Consensus Mechanism (oOCM) broadcasts the transfer data to the Decentralized Node Network.
2. Releasing / Minting Tokens (Destination Chain)
After the destination-chain oOCM validates the incoming payload, the protocol either:
Releases previously locked tokens, or
Mints wrapped or bridged tokens, depending on the asset implementation.
3. Liquidity Pool Operations
Deposits: When users add liquidity, the protocol locks the deposited assets and mints protocol tokens to the user.
Withdrawals: When users withdraw liquidity, the protocol burns protocol tokens and releases the underlying assets.
3. DNN Security Considerations
The Decentralized Node Network (DNN) adds a robust security layer to the LiquidsFi interoperability protocol, ensuring all cross-chain data transfers remain authenticated, tamper-resistant, and compliant. Its core security components include:
1. Decentralized Node Operations
The DNN operates 10–20 independent relay nodes, each capturing data from the source-chain oOCM and relaying it to the destination chain. Their independence eliminates:
Off-chain coordination
Single points of failure
Collusion or 51% attack risks
2. KYC Verification
All node operators must pass KYC verification before joining the network. This guarantees:
Accountability
Transparency
Regulatory compliance
3. Staking Requirements
Node operators stake XLM as economic collateral. Staking provides:
Incentive alignment
A financial barrier against malicious behavior
4. Slashing Mechanism
Nodes that relay incorrect, tampered, or inconsistent payloads are penalized via stake slashing, partially or fully forfeiting their staked tokens.
5. Sliding Time Window
Nodes only accept and forward payloads emitted within a strict time window, preventing:
Replay attacks
Re-submission of stale data
6. Signature Verification
Each payload is cryptographically signed by its node operator. The destination-chain oOCM validates:
Signature authenticity
Node authorization
Payload consistency
Quorum agreement before accepting the data
By combining decentralized operations, KYC verification, economic staking, slashing penalties, strict timing controls, and cryptographic validation, the DNN ensures a secure, trust-minimized, and tamper-proof cross-chain communication layer.
Last updated