0xef37ad2b…5fc4sent to0xf36b9f50…2f51·#22,003,682·view on Etherscan
# 0x Settler\n\n[0x](https://0x.org/)'s settlement contracts utilising\n[Permit2](https://github.com/Uniswap/permit2) to perform swaps without any\npassive allowance. Full source code and audits are found at\n[0xProject/0x-settler](https://github.com/0xProject/0x-settler).\n\n## Bug Bounty\n\nIf you've found a bug, you may be eligible for a bounty under the 0x [bug bounty\nprogram](https://0x.org/docs/developer-resources/bounties). Please see that link\nfor eligibility requirements as well as the advertised payout tiers. If you have\nany findings, send an email to [mailto:security@0x.org](security@0x.org) with\nthe subject line \"BUG BOUNTY\". Please describe the bug that you've found **in\ndetail** and ideally provide a proof-of-concept exploit.\n\n## Architecture\n\n### Allowances\n\n`Settler` does not hold allowances, nor does it hold token balances between\nswaps. This provides an enhanced security posture. `Settler` relies on the\naforementioned `Permit2` contract to hold allowances.\n\n`Settler` allows arbitrary calls to other contracts. Therefore it is of the\nutmost importance that _**settler does not hold token balances or allowances**_.\n\n### `ISignatureTransfer` vs `IAllowanceTransfer`\n\nIn order to remove the risk that passive allowances could be exploited, 0x\nSettler **does not** support the typical `Permit2` pattern of time-bound,\nvalue-bound allowances set via an ECDSA or\n[ERC1271](https://eips.ethereum.org/EIPS/eip-1271) signature. This is the\n`IAllowanceTransfer` half of `Permit2`. Instead, 0x Settler only supports the\n`ISignatureTransfer` interface, which requires a single-use signature (called a\ncoupon) be submitted with every transaction.\n\nThis provides enhanced security at the cost of some gas and inconvenience.\n\n### Actions\n\n0x Settler settles swaps by performing a sequence of actions encoded in\ncalldata. Actions are ABIEncoded with a selector. See `ISettlerActions` for the\navailable options. Typically, actions are parametrized by the `recipient` where\ntokens are sent after the trade and the `bps` specifying a proportion of the\n`Settler` contract's token balance to be liquidated in the action.\n\n## Action encoding\n\nThe action encoding is not stable. Do not rely on the action encoding being\npreserved between 0x Settler instances. See [0x's developer\ndocumentation](https://0x.org/docs/developer-resources/settler) for a detailed\nexplanation.\n\nTypically, actions are only added to `ISettlerActions` for 2 reasons: 1) to\ngas-optimize a high-volume settlement path; 2) to provide compatibility with a\nliquidity source that does not support typical\n`ERC20.approve`...`ERC20.transferFrom` flows.\n\n## Intents\n\nThis instance of `Settler` supports swaps where the submitting address is not\nthe taker. This means that we must provide an alternative mechanism for\nauthorizing a swap that ensures the signed-over swap is not\nmalleable. Settlement of intents is faciliated by the `executeMetaTxn` entry\npoint and uses the \"witness\" functionality of `Permit2` to ensure that the\ntaker's signature is over the tokens being sent and the tokens being\nreceived. In contrast to the \"metatransaction\" flow, the taker *ONLY* signs the\ntokens to be sent and the tokens to be received. In a way, settling an intent is\nanalogous to a short-lived limit order. Settlement of intents is permissioned\nand limited to a whitelist set of \"solvers\" to avoid leakage of surplus value to\nMEV. Obviously, the settlement of the order for *at least* the specified amount\nto be received is guaranteed by the contracts. Intent settlement is permissioned\nso that in the case that it is possible, the taker receives more than the\nminimum specified in the signature, up to the value that the market\nsupports. `Permit2` allows the combination of the authorization of the token\ntransfer as well as confirming the user's intention to receive the specified\namount of the other token. This results in the taker signing a single\n[EIP712](https://eips.ethereum.org/EIPS/eip-712) struct.\n\n## RFQ\n\nRFQ is 0x Settler's \"native\" settlement mechanism. It relies on a\n\"witness\"-signed `Permit2` coupon from a market maker where that entity agrees\nto trade a fixed amount of tokens at a fixed price with a taker. `Permit2` is\nresponsible for verifying the nonce, signature, amount of tokens to be traded,\nand deadline for settlement (but not the price). 0x Settler atomically moves\nthose tokens from taker to maker and maker to taker. This is the only time that\n0x Settler emits an event. In this settlement scheme, responsibility for setting\nprices is delegated off-chain to sophisticated market participants who do so in\na risk-adjusted manner. This is typically referred to as \"over the counter\"\ntrading.\n