• Part 1: The foundations of decentralized trading;
• Part 2: A deep dive into the top DEX platforms.

Core architecture and AMM model

The constant product formula ($x \cdot y = k$)

• $x$ represents the quantity of one asset in the pool (e.g., ETH).
• $y$ represents the quantity of the other asset (an ERC20 token).
• $k$ is the "constant product" or invariant, which must remain constant during a trade (before fees).

Factory and exchange contract design

1. Factory contract: This served as a public registry and a permissionless deployer for new exchange contracts. Its primary function, createExchange, ensured that there could only be one canonical exchange contract for each unique ERC20 token address. The factory maintained mappings to look up an exchange address from a token address and vice versa (token_to_exchange, exchange_to_token), creating a discoverable on-chain system.
2. Exchange contract: Each ERC20 token had its own dedicated exchange contract, which held the liquidity pool for that token and ETH. These contracts implemented the core AMM logic, exposing functions for liquidity management (addLiquidity, removeLiquidity) and a suite of swap functions with a standardized naming convention (e.g., ethToTokenSwapInput, tokenToEthSwapOutput) to handle different trade directions and whether the input or output amount was fixed.

ETH as a bridge asset

Liquidity provision and LP tokens

Security analysis: vulnerabilities and audits

The ConsenSys Diligence audit (January 2019)

The reentrancy vulnerability (major severity)

• Mechanism: The vulnerability was not in the Uniswap contract code itself but arose from its interaction with non-standard ERC20 tokens, such as those compliant with the ERC-777 standard. If a token contract included an external call within its transferFrom function (e.g., a callback to the sender), an attacker could re-enter the Uniswap exchange contract's swap function before the initial transaction was complete. This re-entry would occur after the token balance in the pool had been updated but before the corresponding ETH had been transferred out, temporarily breaking the $x \cdot y = k$ invariant.
• Exploitation path: An attacker could initiate a tokenToEth swap. During the re-entrancy window created by the token's transferFrom callback, the pool would have an artificially high ETH balance relative to its token balance. The attacker could then execute a second swap within the re-entrant call, draining the inflated ETH reserve at an extremely favorable price.
• Remediation: The recommended fix was to add a mutex, or reentrancy guard, to all trading functions to prevent such recursive calls. This vulnerability highlighted a critical design trade-off: v1's commitment to absolute permissionlessness created a security dependency on the behavior of external, untrusted contracts. The protocol's security was not self-contained.

Front-running and slippage (medium severity)

• Mechanism: Front-running attacks exploit the transparency of public mempools. The audit pointed out that the default ALLOWED_SLIPPAGE constant in the Uniswap frontend was set to a generous 2.5%. This created a guaranteed profit margin for front-runners, who could see a user's pending trade, copy it with a higher gas fee to execute first, and push the price by up to 2.5% against the user, thereby extracting that value.
• Impact: This finding demonstrated the crucial link between on-chain protocol security and off-chain client implementation. The protocol itself was behaving as designed, but the client-side settings created a systemic vulnerability for its users.

Inherent protocol risk: price oracle manipulation

• The vector: The spot price in a v1 pool is calculated simply as the ratio of its reserves ($y/x$). This price could be trivially and cheaply manipulated within a single atomic transaction. An attacker could use a flash loan to execute a large trade, momentarily skewing the reserves and thus the price. They could then call a victim contract that relies on this manipulated price for a critical operation (e.g., determining collateral value), and finally, reverse their initial trade to restore the original price, all at a minimal cost.
• Real-world impact: This was not a theoretical risk. Multiple DeFi protocols that used Uniswap v1 as a price feed, such as bZx and Cheese Bank, were exploited through this exact mechanism, leading to substantial financial losses. This flaw made it clear that a simple spot price from an AMM is not a secure price source for other smart contracts.

Conclusion

Get in touch

FAQ: Uniswap v1: core mechanics