​

Why it matters

Bridges are critical infrastructure and a major source of exploits and systemic risk. Two bridges can both “connect Ethereum to X” while having completely different security assumptions (rollup bridge vs multisig vs validator set vs messaging-based).

A bridge registry in Geo makes interoperability more transparent and helps users and builders choose safer defaults.

What to publish

  • Create Bridge entities for major cross-chain bridges (create if missing).

  • For each bridge, publish:

    • Name and short description

    • App URL (bridge UI)

    • Documentation URL

    • Supported chains

    • Bridge and security model (tag; choose what fits the ontology):

      • main or official rollup bridge

      • lock-and-mint or burn-and-mint

      • multisig-controlled

      • validator set or MPC committee

      • light-client or trust-minimised (if applicable)

      • messaging-based (if applicable)

    • Operators or validator set owner (link to Company, project or Organization entities where clearly stated)

    • Contracts and repos link (optional; keep high-level, deep contract address mapping out of scope here)

    • Known incident link (optional: link to an incident or post-mortem if the bridge has a major public exploit; do not recreate the incident dataset here)

  • Link bridges to:

    • Relevant Topics (bridges, interoperability, security)

    • Parent org or project (if a bridge is operated by a specific project)

Scope

  • 20-35 bridges, prioritising:

    • widely used general-purpose bridges

    • major ecosystem bridges where the “bridge” is a named product

    • notable messaging and bridge hybrids (only when clearly used as bridges by end users)

Potential sources

  • Bridge websites and documentation (primary)

  • Ecosystem portals and chain docs that reference the bridge (primary confirmation)

  • Security analyses and reputable trackers (secondary; use to discover, then confirm via official docs)

  • GitHub repos for architecture notes (secondary)

Quality rules

  • Be explicit about trust assumptions: choose a clear security model label and source it when possible.

  • Don’t overfit categories: if the model is unclear, label as “unknown” and include docs link.