memoscan

0xf36b…2f51

All memos sent from and to 0xf36b…2f51.
0xef37ad2b…5fc4sent to0xf36b9f50…2f51·#23,098,009·0x1600dfbc…834753
# 0x Bridge Settler\n\n[0x](https://0x.org/)'s settlement contracts for cross-chain operations\nutilising [Permit2](https://github.com/Uniswap/permit2) patterns to perform\nswaps without any passive 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`BridgeSettler` does not hold allowances, nor does it hold token balances\nbetween swaps. This provides an enhanced security posture. `BridgeSettler`\nrelies on the aforementioned `Permit2` contract to hold allowances. Some\ntaker-submitted actions are made using a gas-optimized allowance contract,\n`AllowanceHolder`, which can be found at\n0x0000000000001fF3684f28c67538d4D072C22734.\n\n`BridgeSettler` allows arbitrary calls to other contracts. Therefore it is of\nthe utmost importance that _**bridge 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\nBridge Settler **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 (which we\nrefer to as a coupon) be submitted with every transaction.\n\nThis provides enhanced security at the cost of some gas and inconvenience. For\nthose users/integrators for whom this is too much of a cost, an alternative\nallowance target, `AllowanceHolder` is provided (see above).\n\n### Actions\n\n0x Bridge Settler settles bridging operations by performing a sequence of\nactions encoded in calldata. Actions are ABIEncoded with a selector. See\n`IBridgeSettlerActions` for the available options. Typically, actions are\nparametrized to match the parameters required by the underlying bridge going to\nbe used.\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 `IBridgeSettlerActions` for 2 reasons: 1)\nto gas-optimize a cross-chain path; 2) to provide compatibility with a bridge\nthat does not support typical `ERC20.approve`...`ERC20.transferFrom` flows.\n
0xef37ad2b…5fc4sent to0xf36b9f50…2f51·#22,003,682·0xf81e792c…8eeb34
# 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
0xef37ad2b…5fc4sent to0xf36b9f50…2f51·#19,920,620·0x7392c22c…696407
# 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## Metatransactions\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 metadata is not\nmalleable. Metatransactions are faciliated by the `executeMetaTxn` entry point\nand use the \"witness\" functionality of `Permit2` to ensure that the taker's\nsignature is over the tokens being sent _and_ the `bytes[]` actions that\n`Settler` will execute. `Permit2` combines all this together into a single\n[EIP712](https://eips.ethereum.org/EIPS/eip-712) struct that the taker signs.\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
0xef37ad2b…5fc4sent to0xf36b9f50…2f51·#19,920,183·0xae4f6e68…5b6537
# 0x Settler\n\n[0x](https://0x.org/)'s settlement contracts utilising\n[Permit2](https://github.com/Uniswap/permit2) patterns to perform swaps without\nany passive 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 allowance, nor does it hold token balances between\nswaps. This provides an enhanced security posture. `Settler` relies on the\naforementioned `Permit2` contract to hold allowances. Some taker-submitted swaps\nare made using a gas-optimized allowance contract, `AllowanceHolder`, which can\nbe found at 0x0000000000001fF3684f28c67538d4D072C22734.\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. For\nthose users/integrators for whom this is too much of a cost, an alternative\nallowance target, `AllowanceHolder` is provided (see above).\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## 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
0x7f88741c…b324sent to0xf36b9f50…2f51·#19,582,256·0x8ae0195f…359fa3
# 0x Settler\n\n[0x](https://0x.org/)'s settlement contracts utilising\n[Permit2](https://github.com/Uniswap/permit2) patterns to perform swaps without\nany passive 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 allowance, nor does it hold token balances between\nswaps. This provides an enhanced security posture. `Settler` relies on the\naforementioned `Permit2` contract to hold allowances. Some taker-submitted swaps\nare made using a gas-optimized allowance contract, `AllowanceHolder`, which can\nbe found at 0x0000000000001fF3684f28c67538d4D072C22734.\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. For\nthose users/integrators for whom this is too much of a cost, an alternative\nallowance target, `AllowanceHolder` is provided (see above).\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## Metatransactions\n\n`Settler` supports swaps where the submitting address is not the taker. This\nmeans that we provide an alternative mechanism for authorizing a swap that\nensures the signed-over metadata is not malleable. Metatransactions are\nfaciliated by the `executeMetaTxn` entry point and use the \"witness\"\nfunctionality of `Permit2` to ensure that the taker's signature is over the\ntokens being sent _and_ the `bytes[]` actions that `Settler` will\nexecute. `Permit2` combines all this together into a single\n[EIP712](https://eips.ethereum.org/EIPS/eip-712) struct that the taker signs.\n\n## OTC/RFQ\n\nOTC/RFQ 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