Architecture

The Guard Contract owns the security guarantees; the Executor Contract owns the routing logic. Separating these concerns means routing can be upgraded without ever touching the security layer.

The swap pipeline

Guard Contract

The Guard Contract is the sole entry point for every Nordstern swap. Any transaction that does not pass through the Guard is not a valid Nordstern swap. Its responsibilities are:

• Accepts the input tokens from the user.
• Calls the Executor Contract to perform the swap.
• After the Executor returns, checks that the output amount ≥ minOutput.
• If the check passes, releases the output tokens to the user.
• If the check fails (e.g., slippage exceeded), the entire transaction reverts. No funds move.

The Guard Contract address varies by chain. See Contracts for the full list. In the API response this address appears as tx.to and is referred to as the Router Contract. Both refer to the same deployed contract.

Executor Contract

The Executor is called by the Guard and performs the actual multi-hop routing: it calls each pool contract in the route sequence, converting tokens step by step. It has two key properties:

• Interchangeable. The Guard can call different Executor implementations. This lets Nordstern ship routing improvements without touching the security layer.
• Trustless by design. The Executor never controls fund release. Even if an Executor behaved unexpectedly, the Guard's output check would catch it and revert.

Third-party DEX contracts

Each new venue is integrated by extending the Executor Contract to support that pool's interface, ensuring correct handling of pool-specific quirks such as fee tiers, direction flags, and non-standard token behaviours.