AlsoSwap
Create Pool

Stack overview

AlsoSwap separates market state from control state. Pools are the market. Governance is the control plane. This separation improves auditability and gives operators a disciplined path to change critical parameters.

Conceptually, the stack has three layers: market execution (Router → Pool), treasury + oracle (fees + TWAP), and control (timelock governance + pause + caps).

This is a two-plane model: the execution plane runs swaps and liquidity, while the control plane changes global behavior through a timelocked governance executor.
Diagram is conceptual, not bytecode-level.

Core modules

The architecture is intentionally explicit. Each module has a narrow responsibility:

View contracts directory
  • PoolFactory Pool registry + global config (fees, pause, limiter settings).
  • LiquidityPool Reserves + LP accounting + swap math + cumulative prices.
  • Router User-facing entrypoints for add/remove liquidity and swaps.
  • RouterV2 Optional route selection (direct vs 2-hop) executed through Router.
  • FeeCollector Receives protocol fee share and routes to treasury.
  • PriceOracle Pull-based TWAP quotes sourced from cumulative prices.
  • FlashLoanLimiter Policy layer for flash swap max-out caps (global + per pool).
  • DEXGovernance Timelocked executor for critical PoolFactory actions.

Control plane

The control plane is about changing system-wide behavior safely: fee settings, pause state, treasury routing, and risk caps. These actions are privileged by design.

Governance is timelocked. Changes are queued, visible, and only executable after the delay. This reduces surprise risk for LPs and traders.

Execution paths

User execution is straightforward: Router transfers assets into the pool and triggers pool logic. The pool updates reserves and cumulative prices. Protocol fee share, if enabled, is routed to FeeCollector.

User → Router / RouterV2
  → PoolFactory (resolve pool)
  → LiquidityPool (swap / add / remove)
    → FeeCollector (protocol fee)
    → cumulative prices (oracle source)

Upgrade model

In AlsoSwap v1, the system modules are upgradeable (behind proxies), while pair pools are immutable market instances. Upgrade authority is a major trust boundary.

Safe upgrade policy requires storage compatibility checks, staging rehearsal, and post-upgrade verification. Treat upgrades as governance events with explicit review notes and rollback planning.

Safety controls

Safety is operational. The protocol supports emergency pause and flash swap caps. When something is wrong, operators can stop the bleeding first, then fix.

Slippage and deadline guards protect users from bad execution and protect markets from accidental fills in volatile blocks.

Events & indexing

You can run the dApp without an indexer: pool discovery and reserves come from on-chain reads. But historical analytics (swaps/volume by day) requires indexing or off-chain aggregation.

The recommended approach is subgraph-based: pool creation events, swaps, sync/reserve updates, fee events, and oracle updates become the index source of truth for UI history.

Trust boundaries

Trust-minimized parts: swap math, reserve accounting, LP share mint/burn, and execution constraints once a call is valid. Admin-trusted parts: parameter tuning, pause/unpause, dependency rewiring, and upgrades.

Production maturity depends on reducing single-key assumptions and publishing these boundaries transparently to users.