ZKLiquid
  • Introducing ZKLiquid
  • Technical Architecture
  • Multi-chain EVM Bridge
  • Soroban-EVM Bridge
  • Polkadot - EVM Bridge
  • SCF 34 Feedback Response
  • đź”—Bridge
    • ⬛Page 1
    • Page
Powered by GitBook
On this page
  • Response to Feedback 1 & 2: Technical Complexity, Stellar Integration, and Need for Further Research
  • Response to Feedback 3: Stellar Integration and Bridge Security Risks

SCF 34 Feedback Response

PreviousPolkadot - EVM BridgeNextPage 1

Last updated 1 month ago

The feedback we got on our SCF #34 submission are as follows:

  • The project offers a solution that is theoretically complex to implement but still requires deeper Stellar integration, particularly in the technical architecture and relay network.

  • The concept is interesting and presents an alternative to Allbridge, but further research is needed.

  • More details about the Stellar integration would be helpful if they are planning to re-submit. Bridges can be very risky.

Response to Feedback 1 & 2: Technical Complexity, Stellar Integration, and Need for Further Research

We fully acknowledge that building secure and decentralized cross-chain infrastructure is inherently complex—especially when done correctly. At LiquidsFi, we've embraced this challenge by dedicating several years to deep research and development. Our team studied the interoperability architectures of established protocols like Chainlink and alternatives such as Allbridge, conducted feasibility assessments, and rigorously tested multiple implementation paths before finalizing our current technical architecture.

We believe LiquidsFi offers a novel approach that complements and improves upon existing cross-chain solutions, and we are continuing to research evolving interoperability approaches to refine our solution further.

Our team brings years of experience in blockchain development, spanning both application and protocol layers, as well as R&D. This expertise ensures we’re well-equipped to execute a solution of this magnitude.

We also agree that deeper integration with Stellar and Soroban is essential. To address this, we've published expanded technical details outlining how LiquidsFi interfaces with the Soroban and the Stellar ecosystem. This includes a breakdown of our decentralized node network (network of independent node systems), on-chain oracle consensus mechanism, and liquidity protocol—core components of our architecture.

These technical architecture and specifications can be found here:

Response to Feedback 3: Stellar Integration and Bridge Security Risks

We appreciate the concern around bridge security and the need for more clarity on how LiquidsFi integrates with the Stellar/Soroban ecosystem. Bridges indeed pose significant risks, and security is at the core of our architecture.

To address these risks and enable deep Stellar/Soroban integration, we've developed the LiquidsFi Decentralized Oracle Network (LDON), which serves as the foundation of our bridge system. This system enables secure interoperability between multiple EVM chains and Soroban, without relying on centralized relayers or custodians — which have historically been single points of failure in many bridge exploits.

Here’s how we address Stellar/Soroban integration and mitigate bridge vulnerabilities:

Deployment on Soroban:

The Liquidity Protocol is deployed directly on Soroban, with a corresponding version for each supported EVM chain. This allows for onchain asset management and token burning/locking or minting/releasing on Soroban, enabling seamless cross-chain interactions.

On-Chain Oracle Consensus Mechanism (oOCM)

Each supported chain, including Soroban, runs an on-chain consensus contract that validates data transmitted by the Decentralized Node Network (DNN). The DNN consists of 10 to 20 independent node systems that securely relay data between EVM chains and Soroban. Each node receives data from the originating EVM chain, signs, and transmits it to the on-chain oracle consensus mechanism deployed on Soroban. This setup ensures that only data from verified nodes is added to the consensus pool, and only validated data can trigger state changes on Soroban. To further strengthen security, the oOCM includes a slashing mechanism: any node that transmits tampered or invalid data risks having its stake slashed, deterring malicious behavior within the network.

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.

Receptacle Contract Architecture

To minimize congestion and contention on Soroban, data from node relayers is routed through individual receptacle contracts before reaching the oOCM. This design improves scalability while preserving security.

Security-Focused Relay Network

The off-chain node relayers that transmit data are designed with safeguards against common vulnerabilities, such as replay attacks, data manipulation, and latency-induced inconsistencies. These are further detailed in the DNN Security Considerations section of our documentation.

Stellar-Focused Testing

We have conducted implementation testing specifically around Soroban’s smart contract model, and adapted our consensus and liquidity protocols to align with the ecosystem.

We hope this provides a clearer picture of how Stellar is integrated and how LiquidsFi mitigates the well-known risks associated with bridges.

More technical details on these components can be found in our full technical architecture documentation: đź”—

https://docs.liquids.fi/technical-architecture
https://docs.liquids.fi/technical-architecture