Liquidity

Provide liquidity to Blazpay pools and earn a share of the trading fees they generate.

Not shipped

/defi/liquidity and /defi/pools both render ComingSoon. The home page product card carries a badge: 'Soon', which is accurate. Backend routes and a transaction model exist; there is no working user flow.

What is built

Piece	State	Location
Liquidity routes	Present	bz-backend/routes/liquidityRoutes.js, mounted at /api/liquidity
Transaction model	Present	bz-backend/models/liquidityTransactions.js
Service layer	Present	bz-backend/services/liquidity-service/
History route	Reserved	DashboardPath.defi.liquidityHistory = /defi/liquidity-history
Pool UI	Not shipped	defi-dex/src/pages/defi/pools.tsx → <ComingSoon />
Liquidity page	Not shipped	Route resolves to ComingSoon
Legacy on-chain DEX state	Present but deprecated	defi-dex/src/state/swap/ + blazpay-sdk

The legacy path

There is an older native Blazpay DEX implementation still wired into the frontend: defi-dex/src/state/swap/ holds Redux state for a direct on-chain swap path backed by blazpay-sdk (github:blazpay/blazpay-sdk#1.0.9), and @uniswap/v2-core is a dependency.

That is where pool primitives would come from if the product resumed on the same foundation. It predates the aggregator architecture and is not the direction of travel — new work should not extend it.

Why liquidity is architecturally awkward here

Blazpay's trading core is an aggregator, not an AMM. It routes to other people's pools. Adding first-party pools means becoming a venue as well as a router, which changes the economics (Blazpay would earn LP fees rather than a 0.1% routing fee) and adds a genuine impermanent-loss surface for users. That is a product decision, not a sprint.

What needs to happen to ship it

1. Decide the venue model. Either deploy Blazpay AMM pools (a new contract surface, new audit) or wrap an existing DEX's positions (e.g. Uniswap v3 position management, which iZiSwap plumbing in trade.ts partially covers).
2. Contracts and audit. A first-party AMM is the single largest new contract surface in the platform. It needs the same treatment the Autopilot vault got — Slither plus an adversarial audit.
3. Chain scoping. Which chains get pools, and fail fast elsewhere.
4. Position lifecycle UI. Add, remove, collect fees, and an impermanent-loss display honest enough that users understand the risk.
5. Own the aggregator relationship. If Blazpay runs pools, those pools should be quotable by Blazpay's own aggregator — which means a blazpay entry in the AGGREGATORS enum, not a special case.
6. History surface. liquidityTransactions exists; wire /defi/liquidity-history.

Lend / borrow

Also unbuilt. DashboardPath.defi.borrow (/defi/borrow) is reserved in the path model with no route, no page and no backend. There is no implementation to document.

Known limits

Everything above. For a support conversation: liquidity provision is not available yet; the page says so.

The one thing worth watching is that the marketing feature inventory lists "Liquidity pools (add/remove) — In progress" and "Lend/Borrow — In progress". "In progress" overstates both; neither has an active workstream.