Ordellum AnalyticsLaunching
Networks and coverage
A growing multi-chain catalogue, where a network joins general availability only after it proves itself.
- EVM mainnets
- 20
- Non-EVM ecosystems
- 5
- Solana, Starknet, Aptos, Sui and Cosmos
- Layer 2 and Layer 3 networks
- 15+
- Cosmos IBC chains
- 50+
- Bridge protocols
- 25+
The catalogue grows towards more than 200 networks. The first production version targets EVM-compatible networks.
Not every network carries the same guarantees. Each one sits at a clearly stated level.
Adapter R&D
Proof-of-concept support for a new virtual machine or protocol.
- Guarantee
- No security or scale evidence yet
- EVM
- Ethereum, Polygon PoS, BNB Chain, Arbitrum One, Optimism, Base, Avalanche C-Chain, zkSync Era, Polygon zkEVM, Linea, Scroll, Blast, Mantle, Gnosis, Fantom, Celo, Moonbeam, Cronos, Aurora and Metis.
- Solana
- Fast slots with token and protocol parsers, including SPL tokens and NFT standards.
- Starknet
- A ZK rollup with native account abstraction and batched proofs.
- Move (Aptos and Sui)
- Resource- and object-based networks with dedicated adapters.
- Cosmos
- Cosmos Hub, Osmosis, Juno, Injective, dYdX, Sei and others, including IBC transfer tracking.
Step 1: Finality and reorganisation
Finality transitions are tested and chain reorganisations are simulated.
Step 2: Addresses and keys
Address validation and deterministic event keys are confirmed.
Step 3: Replay
A reference data set is replayed to prove identical results.
Step 4: Malformed data
The adapter is tested against malformed provider responses.
Step 5: Providers
At least two independent data providers are certified.
- EVM onboarding
- 1–3 days
- Non-EVM onboarding
- 2–4 weeks
- With a canary release
Transfers through bridges such as Wormhole, LayerZero, Axelar, Stargate and Circle CCTP are matched between the source and destination chains using amount, timing and message identifiers. The result is a flow graph that shows multi-hop paths and net flows per chain — the basis for cross-chain risk scoring.
Events are only treated as final once the chain confirms them. If a chain reorganises, affected events are corrected automatically, and events invalidated by a reorganisation are never billed.