0xef37ad2b…5fc4sent to0x40a2accb…130d·#24,668,591·view on Etherscan
# 0x Cross-chain Intent Settler\n\n[0x](https://0x.org/)'s settlement contracts for cross-chain intents 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`CrossChainIntentSettler` does not hold allowances, nor does it hold token\nbalances between swaps. This provides an enhanced security posture.\n`CrossChainIntentSettler` relies on the aforementioned `Permit2` contract to\nhold allowances.\n\n`CrossChainIntentSettler` allows arbitrary calls to other contracts. Therefore\nit is of the utmost importance that _**settler does not hold token balances or\nallowances**_.\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 Cross Chain Intent Settler settles swaps by performing a sequence of actions\nencoded in calldata. Actions are ABIEncoded with a selector. See\n`ICrossChainIntentSettlerActions` for the available options. Typically, actions\nare parametrized by the `recipient` where tokens are sent after the trade and\nthe `bps` specifying a proportion of the `Settler` contract's token balance to\nbe 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 `ICrossChainIntentSettlerActions` for 2\nreasons: 1) to gas-optimize a high-volume settlement path; 2) to provide\ncompatibility with a liquidity source that does not support typical\n`ERC20.approve`...`ERC20.transferFrom` flows.\n\n## Cross-chain Intents\n\nThis instance of `Settler` supports swaps where the received token may be\nlocated on a different network than the sent token. Furthermore, the execution\npath is not dictated in the encoded calldata, and is instead decided by the\nsolver. A solver may decide to use other instances of `Settler`, or any other\nway. It also supports swaps where the tokens are located on the same network.\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 facilitated 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.\n\nSettlement of cross-chain intents is permissioned, as it requires the action of\na new actor, i.e. permissioned `relayers`. These relayers have the task of\nverifying the intent is executable, and monitoring onchain (i.e. by monitoring\nof `CrossChainIntentSettler` events) or offchain (i.e. signed intents via API)\nuser-generated intents, and prompting an auction to notify the solvers. These\nrelayers are also compensated by a relayer-pre-set `amount` or `bpsAmount`. The\n`Settler` instance will initially retain 0% of this fee, but may activate an up\nto 30% fee share. Integrating frontends may act as a `relayer`. Furthermore,\nthey also have the task of moving the source token to the destination chain, and\nare encouraged to use the `BridgeSettler` instance.\n\nThe list of active `relayers` is updated by the 0x DAO, and is adjusted based\non, in order of importance:\n\n1. delegated ZRX/WZRX stake\n2. speed in relaying orders\n\nIntents go through an auction for the winning solver to be able to fill the\norder. An intent may specify a selected `solver`, thus giving priority to a\nparticular solver to execute the swap (i.e. a prearranged agreement between the\nuser and the solver). Once an intent is filled on the destination chain, source\ntokens are sent to the `relayers` by submitting a ZK proof. Proofs are submitted\nin batches, but a relayer may decide to self-generate and submit it to unlock\nthe tokens faster.\n\nThe restriction of participants to relayers and the winning solver avoids\nleakage of surplus value to MEV. Obviously, the settlement of the order for *at\nleast* the specified amount to be received is guaranteed by the\ncontracts. Cross-chain intent settlement is permissioned so that in the case\nthat it is possible, the taker receives more than the minimum specified in the\nsignature, up to the value that the market supports. `Permit2` allows the\ncombination of the authorization of the token transfer as well as confirming the\nuser's intention to receive the specified amount of the other token. This\nresults in the taker signing a single\n[EIP712](https://eips.ethereum.org/EIPS/eip-712) struct.\n