bridge-analysis
Methodology playbook for analyzing cross-chain bridge and messaging-protocol data on Allium — CCTP, LayerZero, Wormhole, Across, canonical/application bridges, and general lock-and-mint flows. Use whenever a question touches bridge transfer volume, net flows between chains, tracing a specific cross-chain transaction, or attributing bridge activity to a protocol/integrator — even if the user just names a bridge or asks to "trace this transfer across chains." Covers the direction/double-counting mechanics and non-EVM tracing gap that come up repeatedly before you write the SQL. Distinct from a formal third-party coverage benchmark (see bridge-protocol-coverage-assessment for that) — this is the lighter-weight reference for getting an individual bridge query right.
Install
With your agent
Install OMGSkills skill "allium-labs/allium-claude-plugin:skills/bridge-analysis" into this agent's normal skills directory: call the OMGSkills MCP get_install_plan tool for your agent and run the script it returns (it installs only the pinned commit and verifies SKILL.md), and stop if MCP or the pin is unavailable. Do not overwrite or change existing skills without asking me.
Manual command
git clone https://github.com/allium-labs/allium-claude-plugin /tmp/allium-claude-plugin && ln -s /tmp/allium-claude-plugin/skills/bridge-analysis ~/.claude/skills/bridge-analysis
From README
Bridge Analysis Bridge transfer tables are asymmetric by design — they don't always record both legs of a transfer. Get the directionality model right before summing anything. Bridge transfer tables record net single-directional flows, not always both legs The exact coverage shape depends on the bridge type: Canonical bridges on Ethereum typically carry both inbound and outbound rows. Application-level bridges, and bridge activity on non-Ethereum chains, typically carry only the outbound leg from the chain that initiated the transfer. This is a deliberate anti-double-counting design, not a coverage gap — but it means SUM(usdamount) behaves differently depending on which chain/bridge-type combination you're querying. Check what direction values actually exist for the specific bridge/chain before summing across them, rather than assuming every transfer has a matching inbound+outbound pair somewhere in the table.
More from this repo
allium-investigation
Investigate an onchain entity, protocol, market, or wallet question with Allium.
dashboard-design
Used to build and update Allium Explorer dashboards with set_dashboard.
data-matching
Match an analytical question to the right Allium table, metric, dashboard, or realtime endpoint.
