Why AlsoSwap?

The problem

Community and DAO tokens fail for boring reasons: liquidity is thin, pricing is easy to manipulate, and teams get stuck between “ship now” and “build a full exchange”.

Most DEX UIs look like markets exist by default. They don't. A market exists only when a pool exists and reserves are there to execute trades. If reserves are tiny, execution is bad even if the UI looks pretty.

What AlsoSwap is

AlsoSwap v1 is a constant-product AMM with an upgradeable on-chain stack. Pools are immutable instances per pair, while the surrounding modules can evolve: routers, oracle, fee plumbing, limiters, and governance.

This split matters. It lets you improve execution and operations without “migrating the market” or forcing users to chase new pool addresses. You ship a market once, then you iterate.

Pool-first markets

A pool is a market object. It defines the pair, the reserves, the fee math, and the executable price. If a pool does not exist, swaps are impossible. If it exists but reserves are tiny, swaps are technically possible but practically unsafe.

AlsoSwap embraces that reality: the Swap UI is pool-centric. You select a pool, then select direction. That sounds simple, but it prevents a lot of user confusion and “phantom market” behavior.

Fees & alignment

AlsoSwap splits fees into two parts: an LP portion that stays in the pool and increases reserves, and an optional protocol portion routed to treasury via FeeCollector.

This creates clean incentives: LPs earn by making the market deeper, while the protocol can fund grants, maintenance, or community programs without pretending fees are “free”.

Upgradeable periphery

The protocol treats pools as stable market instances, while periphery modules are upgradeable. This is a practical approach: pools represent “the market address” and should not change casually, but execution tooling should improve.

• Routers can add better routing without touching pools.
• Fee routing can evolve without migrating liquidity.
• Oracle logic can evolve as integrations grow.
• Safety policy (flash caps, pauses) can be tuned operationally.

Execution guards

DEX safety is mostly about protecting users from bad execution. AlsoSwap uses the standard pattern: slippage limits and deadlines. The important part is that these are not “UI decorations” but execution constraints.

amountOut >= amountOutMin
block.timestamp <= deadline

When the chain is volatile, these guards protect the trader. When liquidity is thin, they protect users from accidental bad fills.

Routing (RouterV2)

RouterV2 is a pragmatic optimizer: it compares direct execution versus a 2-hop route across candidates and then executes through the base router. It's designed for real UX wins without turning routing into a research project.

The core principle: make the “better output” path available when it exists, while still keeping the UI understandable and deterministic.

TWAP oracle

Many DEX stacks bolt oracle support on later. AlsoSwap ships a PriceOracle for TWAP-based quotes. This is important for integrations that should not trust a single-block spot price.

TWAP does not require indexing. It requires periodic updates, so the oracle has observations to consult. That keeps freshness explicit and operationally manageable.

Safety controls

Advanced flows like flash swaps are powerful and risky. AlsoSwap includes a FlashLoanLimiter policy layer to cap max-out amounts (global and per-pool). This gives operators a real lever to reduce blast radius.

There is also a pause/unpause surface for incident response. In other words: when something is wrong, operators can stop the bleeding first, then fix.

Governance & timelock

AlsoSwap governance in v1 is intentionally operational: it is a timelocked executor for critical PoolFactory actions. That means changes are queued, visible on-chain, and only executable after a delay.

This design reduces surprise risk. If a fee configuration changes, LPs and traders have time to react. Protocol control becomes a discipline, not a hidden switch.

Indexer optional

Discovery is on-chain: pools and reserves can be read directly from PoolFactory and LiquidityPool. That is enough to trade and to show real pricing.

History is a different product. “Total swaps”, “volume by day”, and time-series charts require indexing (subgraph) or off-chain aggregation.

Who it’s for

This is a product narrative, not a brochure. Switch perspective and see what AlsoSwap gives you.

Get started

Use AlsoSwap like a real AMM: create a pool (once), add liquidity (anyone), then trade through that pool.

1. 1Connect wallet and make sure network matches the dApp chain.
2. 2Wrap ETH if your pool uses WETH and you want to provide WETH liquidity.
3. 3Create a pool for tokenA/tokenB (only if it doesn't exist).
4. 4Add liquidity by depositing both assets, receive LP shares.
5. 5Trade by selecting the pool and direction. Set slippage + deadline.