Liquid AMM introduction — 2x mint, star topology, zero fees

Magicians Primordial Soup
, , ,
1

Liquid: Zero-Fee ERC-20 AMM via 2x Mint and Star Topology

I’m posting to share a novel AMM design for feedback on its core primitives: a 2x mint wrapping mechanism, a star topology pool structure, and hardcoded zero fees. The contracts are experimental and unaudited. Hub is deployed at 0x429a58602817Fa79Bbdcf56d8986Fa66CFC44F8a on mainnet. Docs: uniteum.one/liquid.

The Problem

Standard ERC-20 AMMs require two-sided liquidity provision: a liquidity provider deposits token A and token B, receives LP shares, and earns fees as compensation for impermanent loss. This works, but it requires an existing market for both assets and active LP management.

Can you bootstrap tradeable liquidity from a single-sided deposit, without LP tokens, without a fee mechanism, and without governance?

Mechanism

2x Mint. Liquid wraps any ERC-20 via make(token), creating a permissionless pool. When a depositor wraps n tokens (the “heat” operation), the protocol mints 2n wrapped tokens: n to the depositor, n to the pool. Unwrapping (“cool”) burns proportionally from both the caller and the pool, returning backing tokens based on the redemption ratio.

This collapses wrapping and liquidity provision into a single atomic operation. There are no separate LP shares.

Constant-product invariant. Each pool maintains pool × lake = k, where pool is the wrapped token balance held by the pool and lake is the hub token balance. Price is lake / pool. This is the standard Uniswap v2 invariant, applied within each spoke.

Star topology. All pools connect through a single Hub contract rather than forming pairwise pools. Trading between token A and token B routes through Hub: sell wrapped-A into its pool to receive Hub tokens, then buy wrapped-B from its pool using those Hub tokens. This gives n pools instead of n², at the cost of two-hop routing and Hub-token slippage on every cross-asset trade.

Zero fees, hardcoded. There is no fee parameter, no fee switch, and no governance mechanism to introduce one. The zero-fee constraint is structural.

Equilibrium and Arbitrage

At equilibrium, the pool holds exactly 50% of total wrapped supply (pool / total = 1/2), and wrapped tokens trade 1:1 against their backing. Disequilibrium is self-correcting:

  • If pool / total < 1/2 (supply scarce): wrapping yields bonus wrapped tokens that can be sold at a premium, restoring the ratio.
  • If pool / total > 1/2 (supply excess): wrapped tokens trade at a discount; buying and then unwrapping at fair value is profitable.

The math constrains wrap→sell→buy→unwrap cycles to be loss-making due to AMM slippage and proportional burn, which prevents exploitative arbitrage loops.

Design Tradeoffs I’d Like Feedback On

  1. Zero-fee sustainability. Without fees, there is no direct compensation for impermanent loss. The protocol relies on arbitrage to maintain equilibrium rather than LP incentives. Is there prior work modeling zero-fee AMM stability over time?

  2. Star topology vs. pairwise pools. The two-hop route through Hub introduces Hub-token slippage on every cross-asset trade. Under what liquidity conditions does this become worse than a pairwise pool? Are there composability implications for contracts that expect single-hop ERC-20 swaps?

  3. 2x mint security surface. The simultaneous mint to depositor and pool is unconventional. Are there known attack vectors — flash loan interactions, re-entrancy patterns, or token-supply manipulation — that this pattern introduces beyond standard constant-product AMMs?

  4. Interface standardization. make(token) is a permissionless pool factory. Does this pattern overlap with or conflict with any existing or draft ERC for AMM factory interfaces?

The contracts are experimental and unaudited. I’m sharing the design now to surface failure modes early, not to claim production readiness.