Every chain has its own RPC quirks, its own finality window, some L2s can reorg longer than people expect, bridges emit weird events, and cross-chain dApps don’t line up on their own. So indexers end up writing glue code to guess which event on chain B belongs to which action on chain A and applications are still limited in access to data, chains (usually only EVM) and performance. That guesswork is the part Pelagos can kill.

Pelagos already sits in the middle, watching many chains, tracking their finality, and only committing a cross-chain flow when every leg is valid. That means Pelagos is already holding a version of reality that’s cleaner than what indexers can reconstruct from raw RPCs. Pelagos puts applications and users’ indexers into the same process, eliminating any latency or inconsistencies.

So instead of every indexer reinventing multichain logic, Pelagos can just hand it to them.

Pelagos does three important things:

1. It correlates events across chains. If a user starts something on Ethereum and it finishes on an L2 and then pushes a transfer to Solana, Pelagos knows those are one flow, not three unrelated transactions.

2. It knows finality. Pelagos tracks how long to wait for each chain.

3. It knows the outcome. Pelagos can say “this flow committed” or “this aborted because leg 3 failed.” That’s huge because most indexers only see the successful legs on the destination chain and don’t even know something failed.

This is exactly the information indexers struggle to derive.

User swaps on Ethereum, settlement happens on Arbitrum.

Without Pelagos

The indexer has to:

• watch Ethereum for swap/start event,

• watch Arbitrum for some bridge/mint/settlement,

• match them based on address, timestamp, maybe a memo,

• pray there’s no delay or reorg,

• and maybe fail to match if the dApp changed its pattern.

With Pelagos

Pelagos emits: “bundle started on Ethereum, settled on Arbitrum, all legs committed.”Indexer ingests one record and knows it’s the same operation. No guessing.

A lending protocol integrated with Pelagos can trigger a liquidation on chain A and settle collateral on chain B in one atomic flow.

Indexers hate this kind of thing because it looks like two unrelated onchain actions. On chain A: liquidation. On chain B: transfer. Different blocks, different chains, maybe different timing.

Pelagos can emit:

• Bundle_id

• reason: liquidation

• leg 1: liquidation on Base

• leg 2: collateral payout on Ethereum

• status: committed

Now an indexer can build a “multichain liquidation dashboard” without doing dark magic.

Big indexers sometimes need to rebuild: new schema, new feature, new chain. Replaying 10 chains from genesis is expensive.

Pelagos can serve immutable snapshots of its multichain view: “here is the state as of block X / slot Y / bundle Z.” Then it can serve a delta stream “all changes since bundle Z.”

Indexer flow becomes:

• download snapshot

• store it

• start consuming deltas

• All your wallets across chains view that isn’t lying

• Real cross-chain volume charts

• All aborted bundles and which chain caused it

• All cross-chain liquidations for protocol Y

• Time-to-finality per chain in the real world

That last one is actually useful for infra teams.

If explorers, dashboards, analytics tools, custodians, even wallets start taking Pelagos’ feed, then Pelagos becomes the reference for what actually happened across chains. That locks in Pelagos as infrastructure, not just “another cross-chain thing.”

Pelagos already knows what happened across chains. Indexers don’t. If Pelagos publishes that view, i.e., bundles, legs, status, finality-safe events, snapshots, indexers can stop guessing and just store it. That makes explorers, dashboards, and analytics line up with reality instead of half-merged data from five RPCs.

Once a few indexers use Pelagos as their multichain source, the rest will follow, because nobody wants to maintain 10 different finality paths and brittle cross-chain matching when there’s a single place that already did it.

Every chain has its own RPC quirks, its own finality window, some L2s can reorg longer than people expect, bridges emit weird events, and cross-chain dApps don’t line up on their own. So indexers end up writing glue code to guess which event on chain B belongs to which action on chain A and applications are still limited in access to data, chains (usually only EVM) and performance. That guesswork is the part Pelagos can kill.

Pelagos already sits in the middle, watching many chains, tracking their finality, and only committing a cross-chain flow when every leg is valid. That means Pelagos is already holding a version of reality that’s cleaner than what indexers can reconstruct from raw RPCs. Pelagos puts applications and users’ indexers into the same process, eliminating any latency or inconsistencies.

So instead of every indexer reinventing multichain logic, Pelagos can just hand it to them.

Pelagos does three important things:

1. It correlates events across chains. If a user starts something on Ethereum and it finishes on an L2 and then pushes a transfer to Solana, Pelagos knows those are one flow, not three unrelated transactions.

2. It knows finality. Pelagos tracks how long to wait for each chain.

3. It knows the outcome. Pelagos can say “this flow committed” or “this aborted because leg 3 failed.” That’s huge because most indexers only see the successful legs on the destination chain and don’t even know something failed.

This is exactly the information indexers struggle to derive.

User swaps on Ethereum, settlement happens on Arbitrum.

Without Pelagos

The indexer has to:

• watch Ethereum for swap/start event,

• watch Arbitrum for some bridge/mint/settlement,

• match them based on address, timestamp, maybe a memo,

• pray there’s no delay or reorg,

• and maybe fail to match if the dApp changed its pattern.

With Pelagos

Pelagos emits: “bundle started on Ethereum, settled on Arbitrum, all legs committed.”Indexer ingests one record and knows it’s the same operation. No guessing.

A lending protocol integrated with Pelagos can trigger a liquidation on chain A and settle collateral on chain B in one atomic flow.

Indexers hate this kind of thing because it looks like two unrelated onchain actions. On chain A: liquidation. On chain B: transfer. Different blocks, different chains, maybe different timing.

Pelagos can emit:

• Bundle_id

• reason: liquidation

• leg 1: liquidation on Base

• leg 2: collateral payout on Ethereum

• status: committed

Now an indexer can build a “multichain liquidation dashboard” without doing dark magic.

Big indexers sometimes need to rebuild: new schema, new feature, new chain. Replaying 10 chains from genesis is expensive.

Pelagos can serve immutable snapshots of its multichain view: “here is the state as of block X / slot Y / bundle Z.” Then it can serve a delta stream “all changes since bundle Z.”

Indexer flow becomes:

• download snapshot

• store it

• start consuming deltas

• All your wallets across chains view that isn’t lying

• Real cross-chain volume charts

• All aborted bundles and which chain caused it

• All cross-chain liquidations for protocol Y

• Time-to-finality per chain in the real world

That last one is actually useful for infra teams.

If explorers, dashboards, analytics tools, custodians, even wallets start taking Pelagos’ feed, then Pelagos becomes the reference for what actually happened across chains. That locks in Pelagos as infrastructure, not just “another cross-chain thing.”

Pelagos already knows what happened across chains. Indexers don’t. If Pelagos publishes that view, i.e., bundles, legs, status, finality-safe events, snapshots, indexers can stop guessing and just store it. That makes explorers, dashboards, and analytics line up with reality instead of half-merged data from five RPCs.

Once a few indexers use Pelagos as their multichain source, the rest will follow, because nobody wants to maintain 10 different finality paths and brittle cross-chain matching when there’s a single place that already did it.