deBridge primary-source snapshot
Fetched: 2026-04-26 UTC
1) Official docs welcome page
Source: https://docs.debridge.com/
Selected excerpts from the docs:
deBridge is a non-custodial execution layer for cross-chain and same-chain actions.
It uses a 0-TVL architecture where competitive solvers provide liquidity on-demand, with no shared liquidity pools.
Additional signals from the docs:
- The docs explicitly resist the narrower “just a bridge” framing and instead position deBridge as an execution layer
- The use-case surface includes same-chain swaps, cross-chain swaps, onboarding, hooks, messaging, and chain abstraction
- The welcome page is a strong primary source because it clearly describes the trust model and execution model at a high level
2) Execution model
Source: https://docs.debridge.com/home/architecture/execution-model
Selected excerpts from the docs:
The deBridge Liquidity Network uses a transaction-based model where users create orders by submitting transactions on the source chain.
Solvers detect the new order … Winning solver sends tokens to recipient on destination … Solver claims locked tokens on source chain.
Additional signals from the docs:
- The source-order / solver-fulfillment / source-claim sequence is the key operational detail for understanding deBridge’s architecture
- deBridge is explicit that users pay source-chain gas while solver destination-chain gas is baked into the quote, which is useful for cataloging the real operating model
- Settlement-time guidance and order-tracking docs make the platform look like production execution infrastructure rather than a thin routing UI
3) Security overview
Source: https://docs.debridge.com/home/security/security-overview
Selected excerpts from the docs:
Traditional bridges have lost over $2 billion to hacks targeting locked liquidity. deBridge eliminates this attack surface entirely.
Smart contracts act as pipes, not pools — funds pass through them briefly on a per-order basis, and there is no shared liquidity sitting in contracts for attackers to target.
Additional signals from the docs:
- The security model is unusually explicit about trust assumptions, fund recovery, cancellation rights, and how the design differs from pooled-liquidity bridges
- The docs link audits and an Immunefi bug bounty directly from the security overview, which makes this page a meaningful first-party trust surface
- The distinction between the DLN execution layer and the DMP messaging layer is important for correct categorization
4) Documentation index (llms.txt)
Source: https://docs.debridge.com/llms.txt
Selected signals from the index:
- The docs are exposed through a machine-readable index with
.mdendpoints for major product, architecture, security, API, and protocol-spec pages - The product map shows that deBridge spans DLN, DMP, infrastructure-as-a-service, dePort, hooks, supported-chain docs, monetization features, and legal/API surfaces
- The index is high-signal because it makes the breadth of the official documentation set very easy to inspect programmatically
5) Official MCP server docs
Source: https://docs.debridge.com/dln-details/mcp/mcp-server
Selected excerpts from the docs:
The deBridge MCP Server gives AI agents direct access to the deBridge Liquidity Network.
The MCP server is a stateless proxy that translates MCP tool calls into deBridge REST API requests.
Additional signals from the docs:
- The MCP docs show deBridge actively packaging its execution layer for AI-agent usage, not merely exposing standard REST docs
- The security boundary is explicit: the MCP server can quote and generate links, but the user still executes the transaction in a wallet
- This AI-facing surface is a useful differentiator when cataloging newer interoperability infrastructure vendors
Notes
- This pass did not confirm a classic standalone whitepaper or litepaper from current official deBridge materials.
- deBridge appears best categorized as a cross-chain execution layer / interoperability infrastructure / solver-based liquidity network rather than as a simple bridge frontend.
- The strongest first-party materials were the docs welcome page, execution-model page, security overview,
llms.txtindex, and MCP-server docs.