AM AMM: The Auction Managed Automated Market Maker Explained
AM AMM reimagines liquidity provision by auctioning pool management rights, reducing MEV losses and improving capital efficiency for DeFi traders and liquidity providers.
AM AMM reimagines liquidity provision by auctioning pool management rights, reducing MEV losses and improving capital efficiency for DeFi traders and liquidity providers.
If you have ever provided liquidity on Uniswap and watched your position bleed value during volatile sessions, you already understand the core frustration with traditional automated market makers. Enter AM AMM — an Auction Managed Automated Market Maker — a design that fundamentally rethinks who controls fee rates and liquidity parameters. Instead of hardcoding these values into a smart contract and leaving them static forever, AM AMM auctions off the right to manage a pool, creating competitive pressure that benefits everyone except the arbitrageurs who currently extract value from passive LPs without contributing anything back.
To understand AM AMM and why it improves on what came before, you need a clear baseline on what is an automated market maker and where its weaknesses lie. A traditional AMM like Uniswap v2 uses a constant product formula — x multiplied by y equals k — to price assets algorithmically without needing a central order book or counterparty matching. Liquidity providers deposit token pairs into pools, and traders swap against that pooled liquidity paying a fixed fee, typically 0.3%. The AMM adjusts prices automatically based on the ratio of tokens remaining in the pool after each trade. Binance operates a central limit order book where buyers and sellers are matched directly in real time, but a decentralized AMM has no counterpart — just a smart contract enforcing a pricing curve. Platforms like Bybit and OKX have both centralized spot markets and increasingly integrate with DeFi protocols that rely on AMM mechanics for their on-chain liquidity layers. The critical weakness in all of these traditional designs is that fee rates are static, pool managers have no ability to react to changing market conditions, and arbitrageurs systematically extract value from LPs through a mechanism called MEV — Maximal Extractable Value — without any compensation flowing back to the people whose capital makes the pool possible.
In any market with meaningful price volatility, arbitrageurs monitor AMM pools and act the moment the pool price diverges from the true reference price on Binance or Coinbase. They execute a corrective trade that brings the pool price back in line — but that trade extracts value directly from LP positions. This is called Loss-Versus-Rebalancing, or LVR, and academic research from Columbia and Stanford shows it can consume 50 to 80 percent of fee revenue earned by LPs in high-volume pools. The AMM charges a fee on every swap, but arbitrageurs capture so much through predictable price corrections that fee income barely covers LP losses over time. Static fees compound the problem: a 0.3 percent fee designed for calm conditions is dramatically insufficient during high-volatility periods when arbitrage profit margins are large and the gap between pool price and true market price widens rapidly.
AM AMM — an Auction Managed Automated Market Maker — was formalized in research by Austin Adams, Ciamac Moallemi, Sara Reynolds, and Dan Robinson at Paradigm. The core insight is elegant and economically sound: if arbitrageurs are going to extract value from the pool anyway, why not let a competitive market determine who gets to manage the pool and capture that arbitrage profit? In an AM AMM, the right to control a pool's fee rate and execute priority trades against the pool is auctioned continuously. The winning bidder — the manager — pays a recurring rental fee directly into the pool, which flows to liquidity providers. In exchange, the manager earns the right to set the pool's fee rate and execute trades at the current internal price before any external arbitrageur can act. This transforms MEV from a pure drain on LPs into a structured revenue stream. The manager has every rational incentive to set fees high enough to capture arbitrage value during volatile periods but low enough to attract legitimate trade volume that generates fee income. It is a competitive mechanism that aligns incentives far more effectively than any hardcoded parameter ever could.
Key insight: In AM AMM, the auction winner pays LPs rent for the right to manage the pool. They profit by being first to arbitrage price discrepancies before external bots can. LPs collect both trade fees AND auction rent — a fundamentally better economic deal than passive AMM positions.
The auction operates as a continuous rent commitment rather than a one-time sale. Would-be managers deposit tokens and commit to a rental rate per block. If a competitor bids higher, they take over pool management after a short notice period, preventing abrupt destabilizing takeovers. This ensures the pool always has the highest-bidding, most economically motivated manager. The manager profits only if they can capture more from managing the pool than they pay in rent — a clean alignment of incentives that makes the entire system self-regulating.
Understanding the theory is one thing — building tooling around it is where real edge comes from. The code below connects to an Ethereum-compatible node, reads an AM AMM pool's auction state, and tracks rent payments and manager changes on every block. You would feed this data into your strategy engine to decide when to bid for management. Tools like VoiceOfChain provide real-time volatility signal feeds that can inform when pool conditions justify a bid versus when potential profit is too low to bother.
import time
from web3 import Web3
RPC_URL = 'https://mainnet.infura.io/v3/YOUR_PROJECT_ID'
AM_AMM_POOL_ADDRESS = '0xYourPoolAddressHere'
POLLING_INTERVAL = 12 # ~1 Ethereum block
POOL_ABI = [
{
'name': 'getAuctionState',
'type': 'function',
'inputs': [],
'outputs': [
{'name': 'currentManager', 'type': 'address'},
{'name': 'rentPerBlock', 'type': 'uint256'},
{'name': 'managerDeposit', 'type': 'uint256'},
{'name': 'feeRate', 'type': 'uint24'}
],
'stateMutability': 'view'
},
{
'name': 'getPoolReserves',
'type': 'function',
'inputs': [],
'outputs': [
{'name': 'reserve0', 'type': 'uint256'},
{'name': 'reserve1', 'type': 'uint256'}
],
'stateMutability': 'view'
}
]
def connect_to_pool(rpc_url: str, pool_address: str):
w3 = Web3(Web3.HTTPProvider(rpc_url))
if not w3.is_connected():
raise ConnectionError(f'Failed to connect to RPC: {rpc_url}')
pool = w3.eth.contract(
address=Web3.to_checksum_address(pool_address),
abi=POOL_ABI
)
return w3, pool
def monitor_auction_state(pool_contract) -> dict:
manager, rent_per_block, deposit, fee_rate = \
pool_contract.functions.getAuctionState().call()
reserve0, reserve1 = \
pool_contract.functions.getPoolReserves().call()
price = reserve1 / reserve0 if reserve0 > 0 else 0
return {
'current_manager': manager,
'rent_eth': rent_per_block / 1e18,
'manager_deposit_eth': deposit / 1e18,
'fee_rate_bps': fee_rate / 10000,
'implied_price': price,
'reserve0': reserve0 / 1e18,
'reserve1': reserve1 / 1e18
}
if __name__ == '__main__':
w3, pool = connect_to_pool(RPC_URL, AM_AMM_POOL_ADDRESS)
print(f'Connected at block {w3.eth.block_number}')
while True:
try:
state = monitor_auction_state(pool)
print(f'Manager : {state["current_manager"][:10]}...')
print(f'Fee : {state["fee_rate_bps"]:.2f} bps')
print(f'Rent/blk: {state["rent_eth"]:.8f} ETH')
print(f'Price : {state["implied_price"]:.6f}')
print('-' * 40)
except Exception as e:
print(f'Error: {e}')
time.sleep(POLLING_INTERVAL)
The real edge comes from knowing when to bid for pool management and how much to pay. The profit model is clean: you earn from setting adaptive fees and executing priority arbitrage trades before external bots can act. Your net profit equals arbitrage captured plus fees earned minus rent paid. The script below estimates expected arbitrage profit using the LVR formula and price divergence data, then decides whether to submit a management bid. Feeding real-time price data from Binance or OKX alongside VoiceOfChain signal feeds gives you the most accurate profitability estimates before committing capital.
import requests
from dataclasses import dataclass
from typing import Optional
@dataclass
class BidStrategy:
min_daily_profit_eth: float = 0.005 # minimum expected daily profit
max_rent_multiplier: float = 0.70 # bid at most 70% of expected profit
safety_buffer: float = 0.85 # conservative estimate discount
def fetch_cex_price(symbol: str = 'ETHUSDT') -> float:
url = f'https://api.binance.com/api/v3/ticker/price?symbol={symbol}'
r = requests.get(url, timeout=5)
return float(r.json()['price'])
def estimate_daily_arb_profit(
pool_price: float,
cex_price: float,
pool_tvl_eth: float,
vol_24h: float
) -> float:
# LVR formula: expected arb ~ 0.5 * sigma^2 * TVL per rebalancing epoch
# Assumes 24 potential arbitrage windows per day
arb_from_vol = 0.5 * (vol_24h ** 2) * pool_tvl_eth * 24
# Immediate opportunity from current price divergence
divergence = abs(pool_price - cex_price) / cex_price
arb_immediate = divergence * pool_tvl_eth * 0.10
return arb_from_vol + arb_immediate
def should_bid(pool_state: dict, strategy: BidStrategy) -> Optional[float]:
cex_price = fetch_cex_price('ETHUSDT')
pool_price = pool_state['implied_price']
pool_tvl = pool_state['reserve0'] + pool_state['reserve1'] * pool_price
vol_24h = 0.03 # replace with live vol from VoiceOfChain or Binance klines
expected_profit = estimate_daily_arb_profit(
pool_price, cex_price, pool_tvl, vol_24h
)
if expected_profit < strategy.min_daily_profit_eth:
print(f'Expected profit {expected_profit:.4f} ETH below threshold — skip')
return None
blocks_per_day = 7200
max_rent = (
expected_profit
* strategy.max_rent_multiplier
* strategy.safety_buffer
) / blocks_per_day
current_rent = pool_state['rent_eth']
bid = max(max_rent, current_rent * 1.01) # outbid current manager by 1%
if bid <= max_rent:
print(f'Profitable bid: {bid:.8f} ETH/block')
return bid
print('Current rent too high — not profitable to outbid')
return None
# --- Usage ---
# strategy = BidStrategy(min_daily_profit_eth=0.005)
# pool_state = monitor_auction_state(pool)
# bid = should_bid(pool_state, strategy)
# if bid:
# submit_bid_tx(w3, pool_contract, my_address, private_key, bid)
Once you win the auction, the core operational loop is straightforward: monitor the gap between the pool's implied price and the true market price on reference exchanges like Binance or Gate.io, and execute a manager swap whenever the divergence exceeds your cost of gas plus desired profit margin. This transaction must land early in a block — before external arbitrageurs submit their own corrections — which means aggressive gas pricing using EIP-1559 priority fees. The code below builds and submits a manager swap with priority gas to maximize block-inclusion probability.
from web3 import Web3
from web3.types import TxParams
MANAGER_SWAP_ABI = [
{
'name': 'managerSwap',
'type': 'function',
'inputs': [
{'name': 'zeroForOne', 'type': 'bool'},
{'name': 'amountIn', 'type': 'uint256'},
{'name': 'minAmountOut', 'type': 'uint256'}
],
'outputs': [{'name': 'amountOut', 'type': 'uint256'}],
'stateMutability': 'nonpayable'
}
]
def calc_rebalance_trade(
pool_price: float,
target_price: float,
reserve0: float,
reserve1: float
) -> tuple:
if pool_price < target_price:
ratio = target_price / pool_price
# Trade 30% of the divergence — avoids over-correcting
amount_in = reserve1 * (1 - (1 / ratio) ** 0.5) * 0.3
return False, amount_in # sell token1, buy token0
else:
ratio = pool_price / target_price
amount_in = reserve0 * (1 - (1 / ratio) ** 0.5) * 0.3
return True, amount_in # sell token0, buy token1
def execute_manager_swap(
w3: Web3,
pool_contract,
manager: str,
private_key: str,
zero_for_one: bool,
amount_in_wei: int,
slippage_bps: int = 50
) -> str:
min_out = int(amount_in_wei * (1 - slippage_bps / 10_000))
base_fee = w3.eth.get_block('latest')['baseFeePerGas']
priority_fee = w3.to_wei('5', 'gwei')
tx: TxParams = pool_contract.functions.managerSwap(
zero_for_one,
amount_in_wei,
min_out
).build_transaction({
'from': manager,
'gas': 250_000,
'maxFeePerGas': base_fee * 2 + priority_fee,
'maxPriorityFeePerGas': priority_fee,
'nonce': w3.eth.get_transaction_count(manager),
'type': 2
})
signed = w3.eth.account.sign_transaction(tx, private_key)
tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)
print(f'Manager swap: {tx_hash.hex()}')
return tx_hash.hex()
| Feature | Traditional AMM | AM AMM |
|---|---|---|
| Fee Rate | Fixed (e.g. 0.3%) | Dynamic — set by auction winner |
| MEV / LVR | Extracted by external arbitrageurs | Captured by manager, shared with LPs |
| LP Revenue Sources | Trade fees only | Trade fees + auction rent payments |
| Pool Management | None — purely algorithmic | Active manager with economic skin in game |
| Arbitrage Access | Open race — first transaction wins | Manager has priority before external bots |
| Fee Adaptability | Cannot respond to volatility | Manager raises fees during volatile periods |
| LP Capital Efficiency | Lower — static parameters bleed value | Higher — adaptive management reduces LVR |
AM AMM represents one of the most intellectually satisfying advances in DeFi infrastructure in years. It takes a well-understood structural problem — MEV extraction and systematic LP value drain — and solves it through market design rather than technical patches or band-aids. For developers and algorithmic traders, the opportunity is concrete: building robust auction monitoring bots and bidding strategies positions you ahead of the curve as AM AMM implementations move from research into production deployments on Ethereum and Layer 2 networks. For passive liquidity providers, the promise is straightforward — meaningfully better returns with the same risk exposure. Whether you are tracking market signals on VoiceOfChain, providing liquidity into next-generation pools that integrate AM AMM mechanics, or building the management infrastructure yourself, understanding this mechanism is rapidly becoming essential knowledge for anyone operating seriously in the DeFi ecosystem.