# 0x (ZRX) Protocol: What It Meant and How It Worked
**Summary:** The 0x protocol (ZRX) was an open protocol on Ethereum designed to enable peer‑to‑peer exchange of ERC‑20 tokens via off‑chain order relay and on‑chain settlement. It defined makers, takers and relayers, used standardized message formats and smart contracts for settlement, and incorporated the ZRX token for governance and staking. While influential in decentralized exchange design, the protocol faced regulatory enforcement in 2023, highlighting tradeoffs between permissionless design and compliance.
## Definition & Key Takeaways
## Why It Matters
## Formula & Variables
## Worked Example
## Practical Use
## Comparisons
## Limits & Misconceptions
## Research Notes
## Definition & Key Takeaways
– 0x (zero x) was an open protocol launched in 2017 to enable peer‑to‑peer exchange of ERC‑20 tokens on Ethereum using off‑chain order relay and on‑chain settlement.
– The protocol separated order relay (handled by relayers or off‑chain networks) from settlement (handled by smart contracts), enabling lower gas costs and composable marketplaces.
– ZRX was the protocol’s native token used for governance (DAO voting) and economic incentives such as staking and relayer fees.
– 0x did not operate a single centralized exchange; rather it provided building blocks for decentralized exchanges (DEXs), relayers and wallets to integrate token trading.
– The protocol was influential in DEX design but later faced regulatory enforcement actions that highlighted compliance and operational risk.
## Why It Matters
0x introduced an architecture that became foundational for decentralized finance (DeFi) trading primitives. By decoupling order discovery from on‑chain settlement, it reduced routine gas costs and allowed specialized participants to maintain order books and market discovery infrastructure without custody. That flexibility encouraged wallets, dApps and relayers to embed trade execution directly inside user interfaces rather than routing all activity through a single exchange.
Key innovations included a standard message format for orders, signature‑based trade authorization (so orders could be posted off‑chain but settled on‑chain), and modular smart contract components (known as the Exchange Proxy in later iterations) that other developers could integrate. These patterns influenced later hybrid models (off‑chain matching with on‑chain settlement) and interoperable DEX tooling.
However, 0x’s trajectory also illustrates the regulatory risks of operating market infrastructure in a permissionless environment: design choices that maximize openness can attract scrutiny if operators or interfaces perform activities that regulators treat as exchange or derivatives trading.
## Formula & Variables
To reason about a 0x trade and the economic flows, consider the following simplified variables and a basic fee formula used in maker/taker pricing models.
Symbols and definitions:
– P: trade price in quote token per base token (units: quote/base)
– Q: quantity of base token to trade (units: base)
– G: gas cost for on‑chain settlement (units: underlying gas token, typically gwei converted to ETH)
– f_maker: maker fee rate (fraction of trade value paid to relayer or as protocol fee)
– f_taker: taker fee rate (fraction of trade value)
– V: trade value = P × Q (units: quote token)
– Fee_total = V × (f_maker + f_taker) + G (converted to quote token) (units: quote token)
Notes on scales and units:
– Prices (P) are typically expressed as ERC‑20 token units — e.g., USDC per ETH.
– Gas (G) is denominated in ETH and should be converted to the quote token using spot price before summing into Fee_total.
– Fee rates (f_maker, f_taker) are dimensionless fractions (e.g., 0.001 for 0.1%).
## Worked Example
Scenario: Alice (maker) posts an order to sell 1.0 ETH for 2,000 USDC. Bob (taker) fills the order.
Given:
– P = 2,000 USDC / ETH
– Q = 1.0 ETH
– V = P × Q = 2,000 USDC
– f_maker = 0.000 (maker rebate or zero fee in this example)
– f_taker = 0.003 (0.3% taker fee)
– G = 0.0012 ETH gas for settlement; ETH price = 2,000 USDC → G_in_USDC = 0.0012 × 2,000 = 2.4 USDC
Step 1 — Compute trade value: V = 2,000 USDC.
Step 2 — Compute protocol fees: Fee_total = V × (f_maker + f_taker) + G_in_USDC
= 2,000 × (0 + 0.003) + 2.4
= 6.0 + 2.4 = 8.4 USDC.
Step 3 — Net proceeds: Alice receives approximately 2,000 USDC minus any maker fee (here none) = 1,991.6 USDC after gas (if Alice pays gas) or Bob pays gas depending on settlement arrangement. In many implementations the taker pays on‑chain gas so Bob would net 2,000 − 6.0 − 2.4 = 1,991.6 USDC outflow plus the ETH buy.
This simplified example illustrates how off‑chain order posting reduces repetitive gas use (only settlement incurs G) and how maker/taker pricing affects fee distribution.
## Practical Use
Checklist for integrating or using a 0x‑style protocol:
– Verify the smart contracts and their deployed addresses for the network you intend to use (mainnet vs testnet).
– Confirm the order signature scheme and message format; ensure wallet signing supports the required EIP standards.
– Decide whether to act as maker (post limit orders) or taker (consume liquidity); understand fee schedules for each role.
– Ensure gas estimation and account for ETH volatility for gas conversion when pricing orders denominated in other tokens.
– For relayer operators: implement front‑end protections (rate limits, AML checks where required) and clear terms of service.
Common pitfalls:
– Underestimating settlement gas leads to backfilled or partially filled orders when on‑chain transaction reverts.
– Using the wrong token decimals in price calculations produces off‑by‑orders of magnitude errors.
– Assuming full anonymity: relayers and on‑chain logs can reveal trading activity unless additional privacy layers are added.
– Ignoring regulatory compliance if offering order book services or custodial features — several jurisdictions require registration for exchange services.
## Comparisons
Related systems and when to prefer each:
– Automated Market Maker (AMM) (e.g., Uniswap): AMMs are preferable for continuous liquidity in many token pairs and simple UX. They price assets via constant product curves and do not require off‑chain order books. Prefer AMMs for simple swaps and when liquidity depth is sufficient.
– On‑chain Order Book DEXs: Fully on‑chain order books can be simpler conceptually but are more gas‑intensive. Prefer them when transparency and on‑chain order provenance are paramount and when gas cost is acceptable.
– Centralized Exchange (CEX): Offers order matching, deep liquidity and fast execution. Prefer CEXs when high throughput, fiat rails, or margin/derivative services are required, but accept custody and counterparty risk.
0x is best when developers want flexible, composable trade primitives with off‑chain order relay and on‑chain settlement — a middle path between AMMs and fully centralized matching.
## Limits & Misconceptions
Limits:
– Not fully custodial or custodial: 0x provided settlement smart contracts but the user experience and custody model depend on the integrating wallets and relayers.
– Liquidity fragmentation: multiple relayers and order books can fragment liquidity unless aggregators are used.
– Regulatory exposure: running relayer infrastructure, providing matching services or enabling leveraged products can trigger registration requirements in some jurisdictions.
Common misconceptions:
– “0x is a single decentralized exchange.” No — it is a protocol for building exchanges and relayers; many independent services used the protocol.
– “All trading happens off‑chain.” Order discovery and posting were often off‑chain, but settlement and state changes were on‑chain.
– “ZRX is required to execute trades.” ZRX was primarily a governance and incentive token; trades used ERC‑20 tokens being exchanged and gas was paid in ETH.
## Research Notes
Sources and methodology used to compile this entry:
– Protocol documentation and whitepapers: primary technical specifications for order formats, signatures and smart contracts were taken from the 0x project repositories and documentation.
– Industry analysis and historical reporting: press coverage and industry summaries provide context on fundraising, governance and market adoption.
– Regulatory filings and enforcement notices: public enforcement documents describe legal actions and settlements that affected the protocol’s operators.
Key public sources consulted include the 0x Project website (protocol docs and Exchange Proxy descriptions), published reporting on 0x fundraising and governance, and regulatory communications concerning enforcement actions. Where possible, technical statements were cross‑checked against smart contract source code and archived documentation.
Educational disclaimer: This article is for informational purposes only and does not constitute investment, legal or regulatory advice.
### FAQ
**Q:** What is the difference between a relayer and a relayer operator in 0x?
**A:** A relayer is a service or participant that hosts order books and broadcasts signed orders off‑chain; a relayer operator runs the infrastructure and user interface that makes those orders discoverable.
**Q:** Did 0x execute trades on‑chain or off‑chain?
**A:** Order discovery and matching were typically off‑chain, while settlement — the token transfer and state changes — occurred on‑chain via smart contracts.
**Q:** What was ZRX used for?
**A:** ZRX served as a governance token for protocol votes and was used in incentive/staking schemes for relayers and validators in some protocol versions.
**Q:** Are 0x‑style protocols still relevant after AMMs became popular?
**A:** Yes. Off‑chain order relays remain useful for large limit orders, UX integration, and specialized market venues; many aggregator services combine AMM liquidity with order book liquidity.
**Q:** What regulatory issues did 0x face?
**A:** Regulators have scrutinized operator activities that resemble exchange or derivatives services; in some cases enforcement actions targeted firms operating exchange‑like infrastructure without registration.
### See also
– Decentralized Exchange (DEX)
– Automated Market Maker (AMM)
– ERC-20
– Liquidity Aggregator
– Smart Contract