Hub-and-spoke architecture

What it refers to

Hub-and-spoke architecture is a system design pattern where a single central component (the Hub) coordinates state and decision-making, while distributed endpoints (Spokes) handle local execution on individual networks.

In the SODAX system, the Hub lives on Sonic and serves as the coordination layer for all cross-network activity. Spokes are deployed on each supported network, acting as local interfaces for user actions.

This pattern is common in logistics and network design, but in multi-network DeFi infrastructure (often searched as cross chain architecture or cross chain hub and spoke), it solves a specific problem: how to maintain a unified view of system state when execution happens across many independent networks.

Why this concept exists

As blockchain ecosystems expanded from a few networks to dozens, systems faced a choice: build peer-to-peer connections between every network pair, or centralize coordination through a shared layer.

Peer-to-peer approaches (often called mesh architectures) scale poorly. Each new network requires connections to every existing network, and state synchronization becomes exponentially complex.

Hub-and-spoke avoids this. Each new network requires only one connection: to the Hub. The Hub maintains the canonical view of system state, including user accounts, liquidity positions, and intent lifecycle. Spokes handle local interactions and relay events to the Hub for coordination.

This means:

• Adding a new network is a Spoke deployment, not a system-wide upgrade
• All coordination decisions happen in one place, reducing inconsistency
• Liquidity can be managed and redistributed through the Hub rather than across fragmented peer connections

What this changes for system design

Hub-and-spoke architecture concentrates coordination risk on the Hub. If the Hub is unavailable, cross-network actions cannot be coordinated.

System design must:

• Ensure the Hub network is reliable, performant, and cost-effective
• Design Spoke operations to degrade gracefully if Hub connectivity is interrupted
• Avoid requiring users to interact with the Hub directly, keeping the Hub as a backend coordination layer
• Manage the tradeoff between coordination centralization and system resilience

The architecture is a deliberate choice: accept coordination centralization to gain scalability, simplicity, and consistent state management across all supported networks.