FAQ
Who are building it?
LevX: Founder, Architect / ex. SushiSwap Core Dev, LayerZero Engineer
Ayoki: Marketing, BD / ex. SushiSwap Marketing/BD, Across Bridge Marketing Manager
0xMaki: Advisor / ex. SushiSwap General Manager, LayerZero Advisor
Geven: Finance / ex. CPA at PwC
ScarX: Software Engineer
Does xDLOL require trust assumptions like a bridge?
No. Unlike traditional bridges that custody assets, xDLOL does not rely on third-party trust assumptions. It achieves decentralized cross-chain liquidity synchronization through:
1. LayerZero’s read protocol (lzRead) for cross-chain liquidity data fetching.
2. Merkle-based liquidity proofs for data integrity across chains.
3. On-chain liquidity settlement logic, ensuring correctness without relying on external validators.
What happens if different chains report conflicting roots for the same epoch?
xDLOL never assumes cross-chain consensus. Each chain produces and verifies its own roots independently.
If Chain A’s root diverges from Chain B’s in the same epoch, that’s expected behavior—because they represent local snapshots.
The system avoids inconsistency not by enforcing uniform roots, but by requiring cross-verification via Merkle inclusion proofs before any transaction is executed using remote data.
Can I build vaults that route yield to a specific chain?
Yes. You can define vault logic that accrues yield only on a target chain (e.g. Ethereum), while allowing users to interact from other chains via xDLOL.
Because reward indices are synced via dataRoot, balances on non-origin chains can still reflect real-time yield growth, even if the underlying yield is routed to a single vault location.
What if a user’s balance is updated on one chain but not another?
That’s impossible under xDLOL’s model. A user’s total effective balance is determined by aggregating all known debts and credits from other chains via lzRead()—and only executed after verifying with the latest root snapshot.
This model ensures that any pending balances, regardless of chain, are always accounted for before executing a transfer or withdrawal.
Can MEV bots exploit gaps between roots?
Cross-chain MEV is drastically reduced because all interactions are gated behind synchronized root validation.
There is no execution before reading the latest remote debt and balance data.
Bots cannot frontrun unless they can alter already-verified Merkle roots—which is cryptographically infeasible.
Can someone stake from multiple chains simultaneously and break accounting?
No. Even if a user stakes into the same vault from multiple chains in parallel, the system treats these as delta updatesthat are later verified and rolled into the same global balance snapshot.
Double-spending is prevented by rejecting any execution that exceeds the total net balance verified via lzRead() across all chains.
How are malicious Settlers prevented from syncing incorrect data?
Settlers submit Merkle inclusion proofs, but the data is only accepted if it’s verifiable against the published liquidityRoot or dataRoot.
A Settler can’t insert fake balances, override another chain’s state, or bypass root validation—because every mutation must be cryptographically proven.
Incentivization of Settlers (e.g. via fee rebates or token rewards) is opt-in and programmable by vault creators.
Can I fork xDLOL and customize root structure?
Yes. The root schema is modular—developers can define custom key/value mappings in their contract’s integration with the LiquidityMatrix.
This makes xDLOL extensible for specialized vaults, gamified staking, or even AI agents operating across-chain.
Last updated