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 .md endpoints 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.txt index, and MCP-server docs.