NEXUS
Multichain Infrastructure
One infrastructure layer for multichain applications.
Build multichain applications without rebuilding provider failover, reorg-safe indexing and per-chain finality logic every time.
- RPC routing
- Reorg-safe cursors
- Finality normalisation
- At-least-once delivery
- 5 networks
RPC management, indexing, contract event streams and network monitoring across five chains behind a single API surface.
What the product is built around.
NEXUS is the boundary between an application and the chains it depends on. It normalises finality, guarantees at-least-once event delivery with a reorg-safe cursor, and fails over between providers without the application knowing a provider exists.
Failover is invisible
Requests route by health and latency across multiple providers per chain. The application sees one endpoint with one latency profile.
Reorg-safe by construction
Indexed state is derived from a confirmed cursor and rolled back deterministically, so a reorg is a handled event rather than a data corruption incident.
One mental model per chain
Finality, confirmations and gas semantics are normalised into a single abstraction, so supporting a sixth chain is configuration rather than a rewrite.
What makes this hard.
Every multichain team rebuilds the same layer: provider failover, an indexer that survives reorgs, event streams that do not skip, and enough observability to know which of five chains is currently lying to you. It is undifferentiated work that fails in production at the worst possible time.
- 01
A single RPC provider outage takes the whole application down
- 02
Each chain has different finality semantics and the app code absorbs the difference
- 03
Reorgs corrupt indexed state and nobody notices until balances are wrong
- 04
Event handlers silently miss logs during provider switches
- 05
There is no shared view of which chain is degraded right now
What the system does.
NEXUS sits between an application and the chains it depends on. It routes requests across multiple providers per network by health and latency, normalises finality into named levels the application chooses from, and guarantees at-least-once event delivery against a reorg-safe cursor. A reorg becomes an explicit rollback with an affected range rather than silent data corruption.
Provider failover the application never sees, with gradual weight draining
One finality abstraction across EVM chains and Solana
Indexers that roll back deterministically when a chain reorganises
Event delivery resumed from a committed offset, so failover duplicates rather than gaps
Per-chain health, latency and error rate in one operational view
NEXUS, as working interface.
Rendered UI, not a mockup — real tables, charts, filters and states. Try ⌘K for the command palette.
Requests (24h)
412.8M
p99 latency
84ms
Error rate
0.021%
Indexer lag
2 blocks
Network health
| Network | Block height | Finality lag | Gas | p99 | Providers | 24h | Status |
|---|---|---|---|---|---|---|---|
| EthereumchainId 1 | 21,482,914 | 13s | 8.4 gwei | 96ms | 4/4 | Healthy | |
| Arbitrum OnechainId 42161 | 284,016,772 | 1.2s | 0.01 gwei | 62ms | 3/3 | Healthy | |
| BasechainId 8453 | 24,908,441 | 2.0s | 0.04 gwei | 71ms | 3/3 | Healthy | |
| Polygon PoSchainId 137 | 68,142,309 | 4.8s | 31 gwei | 148ms | 2/3 | Degraded | |
| Solanamainnet-beta | 312,884,105 | 0.6s | 5000 lam | 48ms | 3/3 | Healthy |
Finality lag is normalised per network · provider counts reflect healthy endpoints in the demo environment
Request throughput
24H · req/sRequests by network
- Ethereum35.9%
- Base23.3%
- Arbitrum20.4%
- Solana12.6%
- Polygon7.8%
Provider routing topology
live routing- Gateway
- Healthy provider
- Draining
- Ejected
Indexer status
- apex-positionsethereum · head −0 · 41.2M eventssynced
- flowpay-transferspolygon · head −2 · backfilling2 blk
- atlas-registryethereum · head −0 · 1.8M eventssynced
- predict-marketsbase · head −0 · 8.4M eventssynced
- vault-approvalsarbitrum · head −0 · 612K eventssynced
- meridian-flowssolana · reorg rollback 3 slotsrecovering
Error rate by network / hour
Infrastructure events
- Provider ejected — polygon/us-311:04:22
5 consecutive health check failures · traffic shifted to eu-3 and eu-1
- Latency breach — polygon/eu-311:04:19
p99 412ms exceeded 250ms threshold · weight reduced to 0.3
- Reorg handled — solana10:41:07
3-slot rollback applied to meridian-flows · 412 events replayed
- Indexer deployed09:58:44
vault-approvals v4 · backfill from block 284,001,000 completed in 6m
- Quota raised08:12:30
key_prod_4 raised to 12k rps after sustained 94% utilisation
Active alert
- Alert
- polygon.provider.degraded
- Severity
- Warning
- Opened
- 11:04:19 UTC
- Affected
- 1 of 5 networks
- Blast radius
- 7.8% of traffic
- Mitigation
- Auto-failover active
- Customer impact
- None observed
Unified API — one key, five chains
typescriptimport { Nexus } from "@nexus/sdk";const nexus = new Nexus({ key: process.env.NEXUS_KEY });// Finality is normalised — no per-chain branching.const receipt = await nexus.tx.waitForFinality({ network: "polygon", hash: "0x9c4f…", level: "safe",});// At-least-once delivery with a reorg-safe cursor.nexus.events.subscribe({ network: "base", address: "0x7a21…", event: "MarketSettled(uint256,address,uint256)", fromBlock: "cursor", onLog: async (log) => { await handle(log); }, onReorg: async ({ rolledBack }) => { await revert(rolledBack); },});Interface states
UI statesNo networks configured
Add a chain to start routing requests and deploying indexers.
Add networkEmpty stateAll providers unhealthy
Every configured Polygon provider failed health checks. Requests are being queued rather than dropped.
How it is put together.
The confirmed-cursor abstraction is the load-bearing idea: every downstream consumer reads from it rather than from a chain head.
- 01
Control Plane
Network configuration, indexer deployment, API keys, quotas and alerting.
- Next.js
- TypeScript
- PostgreSQL
- 02
RPC Gateway
Latency-aware routing, health checks, circuit breaking and request caching.
- Go
- Consistent hashing
- Circuit breaker
- 03
Normalisation Layer
Per-chain finality, gas and confirmation semantics mapped to one abstraction.
- TypeScript
- Adapter pattern
- 04
Indexing Engine
Reorg-safe cursors, deterministic rollback, backfill and typed log decoding.
- Rust
- ClickHouse
- ABI decoding
- 05
Delivery
At-least-once event delivery with ordered partitions and consumer offsets.
- Kafka
- Webhooks
- WebSocket
- 06
Networks
Ethereum, Arbitrum, Base, Polygon and Solana across multiple providers each.
- EVM
- Solana
- Multi-provider
What the product does.
The capability set the demonstration is built around.
RPC management
Multi-provider routing with health checks, latency-based selection and automatic failover.
Network monitoring
Per-chain block height, finality lag, gas and provider health in one view.
Wallet activity
Address-level activity streams with label enrichment and cross-chain grouping.
Contract events
Declarative event subscriptions with typed decoding and delivery guarantees.
Transaction tracking
Submission through finality with replacement, cancellation and reorg handling.
Indexing
Reorg-safe indexers with deterministic rollback and backfill from any block.
Unified API
One API and key across all supported networks with per-key quotas and scopes.
Challenges, and the MaatX approach.
The problems that actually decide whether a system like this survives production — and how we address each one.
Five chains, five different definitions of 'confirmed'
Finality is normalised into named levels the application chooses from. Chain-specific confirmation maths lives in one adapter per chain, not scattered through product code.
A reorg silently corrupts indexed state
Indexers write against a confirmed cursor and keep the rollback window addressable. A reorg emits an explicit rollback with the affected range so consumers compensate deterministically.
Provider failover usually loses events
Cursors are stored per stream, not per connection. A failover resumes from the last committed offset, so switching provider produces duplicates — which consumers handle — rather than gaps, which they cannot.
One slow provider degrades everything behind it
Health is scored on latency and error rate continuously. Weight drops before ejection, so traffic drains gradually instead of cliff-edging onto the remaining providers.
Cost scales with request volume unless reads are shared
Immutable results are cached aggressively by block height. Only tip-of-chain reads reach a provider, which removes most duplicate traffic.
The stack behind it.
RPC gateway
- Go
- Redis
- Consistent hashing
- Circuit breaker
- Latency-aware routing
- Health scoring with weight draining
- Block-height response cache
Finality normalisation
- TypeScript
- Adapter pattern
- Named finality levels
- Per-chain confirmation maths
- Gas semantics mapping
- Slot-to-block-height mapping
Indexing engine
- Rust
- ClickHouse
- ABI & IDL decoding
- Reorg-safe cursors
- Deterministic rollback
- Addressable rollback window
- Backfill from any block
Event delivery
- Kafka
- Webhooks
- WebSocket
- At-least-once delivery
- Ordered partitions
- Per-stream consumer offsets
Control plane
- Next.js
- React
- TypeScript
- PostgreSQL
- gRPC
- Per-key quotas and scopes
- Declarative indexer deploys
Networks & providers
- Ethereum
- Arbitrum
- Base
- Polygon
- Solana
- EVM
- Multi-provider pools per chain
Observability & deployment
- Kubernetes
- Prometheus
- Grafana
- OpenTelemetry
- Synthetic provider probes
- Blue-green gateway rollouts
How it grows with the business.
The same system at three stages. Most products should not start at the third — but the architecture should not have to be thrown away to get there.
Two networks behind one endpoint, with health-based routing.
- Two chains, multiple providers each
- Latency-aware routing and failover
- Basic event subscriptions
- Per-key quotas
Five networks with reorg-safe indexing and delivery guarantees.
- Normalised finality levels
- Reorg-safe indexers with rollback
- At-least-once delivery with cursors
- Cost reduction through block-height caching
Self-hosted and compliance-ready deployment.
- Self-hosted gateway for data residency
- Declarative indexers compiled from ABIs and IDLs
- Cost attribution per key and contract
- Transaction simulation against forked state
Where it could go next.
Directions this system would extend into.
- 01
Self-hosted gateway for teams with data-residency requirements
- 02
Declarative indexer definitions compiled from ABIs and IDLs
- 03
Cross-chain state queries with consistent read semantics
- 04
Simulation endpoint for pre-flighting transactions against forked state
- 05
Cost attribution per API key, contract and event stream
Reading several chains and needing one finality model your application can trust?
We built NEXUS to work through exactly this. Tell us where you are and we will tell you what we would do differently for your constraints.