0x Protocol Documentation

The @0x/contracts-erc20 package provides implementations of various ERC20 tokens used within the 0x ecosystem, including:

• WETH (Wrapped Ether)
• ZRX

Deployed contract addresses can be found in the DEPLOYS.json file within this package or via the 0x cheat sheet guide.

The protocol follows a tiered response strategy for emergencies:

The 0x bug bounty program is strictly limited to vulnerabilities found in the 0x smart contracts deployed on the following EVM-compatible networks:

• Ethereum mainnet
• Binance Smart Chain
• Polygon
• Avalanche
• Fantom
• Celo
• Optimism
• Future EVM-compatible networks announced via official 0x communication channels.

Ineligible Reports

• 0x API and Web Interfaces: Reports regarding UI/UX, servers, or infrastructure for 0x API or web interfaces (such as Matcha or 0x.org) are not eligible.
• Duplicate Findings: Only the first reporter of a specific contract vulnerability is eligible for a reward.
• Audit Findings: Vulnerabilities already identified during formal audits (conducted by Consensys Diligence, Trail of Bits, or ABDK) are ineligible.

The 0x governance system is designed to fully decentralize the management of the 0x Protocol and the Treasury. It utilizes a wrapped ZRX token (ZRXWrappedToken) and a Compound-like governor design.

Governance is split into two distinct domains:

1. Protocol Governance: Managed by ZeroExProtocolGovernor and a dedicated ZeroExTimelock instance.
2. Treasury Governance: Managed by ZeroExTreasuryGovernor and a separate ZeroExTimelock instance.

While the governors themselves are non-upgradable, the underlying voting implementation (ZeroExVotes) is upgradable via an ERC1967Proxy.

The Flash Wallet is a sandboxed escrow contract designed to hold funds for Transformers to operate on. It acts as a trustless intermediary: a Feature contract transfers tokens to the Flash Wallet, which then uses delegatecall to allow a Transformer to perform operations on those escrowed funds.

Key characteristics:

• Sandboxed Security: Transformers only have access to the funds deposited into the Flash Wallet; they do not have access to user allowances.
• Current Scope: It is currently used by the TransformERC20 feature for ERC20 tokens, though it is architected to support other standards like ERC1155 or ERC223 via fallback implementations.
• Deployment: It is deployed via the createTransformWallet() function on the feature contract, which is restricted to the owner/governor.

The ZeroExGovernor is a time-locked multi-signature wallet designed for Exchange V4. It holds administrative permissions to perform critical functions within the 0x Protocol.

Key characteristics include:

• Multi-signature: Requires 2/3 signatures to execute functions.
• Timelocks: Most administrative actions are subject to a delay (timelock) before they become active, allowing users to react to changes. However, emergency functions (e.g., those used to mitigate vulnerabilities) may have a 0-day timelock to allow for immediate action.
• Ownership & Authorization: It can transfer ownership of contracts and manage authorized addresses in the Exchange and Staking systems.

Tokens that implement fees on transfer do not strictly follow the ERC20 specification. The protocol expects a transfer to move the exact specified amount or revert. Because fee-on-transfer tokens result in the recipient receiving less than the specified amount, the protocol's behavior is unspecified.

In most scenarios, attempting to use these tokens will result in an overall transaction failure triggered by the protocol's slippage protections.

The nonce is a unique identifier for an order.

Warning: If two orders signed by the same maker have the same nonce, filling or cancelling one can result in the other becoming unfillable. Note that while two ERC721 orders with the same nonce cannot both be filled, two ERC1155 orders with the same nonce can both be filled as long as the orders are not identical.

Best Practices:

• Use the most significant 128 bits of the nonce as an application/marketplace identifier.
• Use the least significant 128 bits of the nonce to increment from 0 for each order created by a particular maker.
• You can also use a pseudorandom value or the current timestamp.

The ZeroEx contract (also known as the Exchange Proxy or EP) acts as a central router for asset exchanges. It uses a per-function proxy pattern where the main contract maintains a mapping of function selectors to specific implementation contracts (called "features").

When a function is called on the ZeroEx contract, it uses a fallback mechanism to delegatecall the request to the corresponding feature implementation. This allows the protocol to upgrade individual functions independently without redeploying the entire system.

/* The ZeroEx contract's sole responsibility is to maintain a mapping of "features" to implementation contracts and route (delegate) calls to per-function implementation contracts through its fallback mechanism. */

Transformers are trustless extensions to the core protocol used to perform specialized operations during order fulfillment. They are permissioned by the Transformer Deployer and are identified by the specific nonce of that deployer.

Crucially, Transformers are executed via delegatecall within the context of the Flash Wallet. This means they can operate on the state and funds held by the Flash Wallet during the transaction lifecycle.