1inch Limit Order Protocol

Permit2Proxy is a proxy contract designed to enable the use of Uniswap's Permit2 permitTransferFrom within the 1inch Limit Order Protocol. It allows limit orders to use Permit2 assets as maker assets by mimicking the IERC20.transferFrom interface.

Critical Limitation: Permit2's SignatureTransfer nonces are single-use. Once a nonce is consumed during the first fill, any subsequent attempt at a partial fill will revert. This means orders using this proxy are effectively 'all-or-nothing' regarding the specific nonce used.

The SafeOrderBuilder contract is used to build and sign limit orders specifically for a Gnosis Safe.

To protect against market volatility, the contract uses oracles to automatically adjust the order's taking amount based on the volatility of both the maker and taker assets. Once an order is built, it is signed by the Gnosis Safe and registered within the orderRegistrator.

The ERC721Proxy is a specialized proxy contract used to facilitate NFT transfers within the protocol. It implements a proxy transfer method designed to mimic the IERC20.transferFrom selector for compatibility, while specifically handling IERC721 tokens.

Security Note: The amount parameter in the function call is intentionally unused to prevent security vulnerabilities related to partial fills that could lead to unintended ERC-721 token sales.

// The proxy method signature used for IERC721.transferFrom
function func_60iHVgK(address from, address to, uint256, uint256 tokenId, contract IERC721 token) external

When using fillOrderArgs or fillContractOrderArgs with ARGS_HAS_TARGET set, the args parameter must contain packed calldata. The sequence depends on the takerTraits settings.

Packed Parameter Order

1. target (20 bytes): The address to transfer maker funds to (only if ARGS_HAS_TARGET is set).
2. extension (variable length): The order's extension calldata. The keccak256 hash of this data must match the lower 160 bits of the order's salt.
3. takerInteraction (variable length): The taker interaction to execute during the fill.

Note: The lengths of extension and takerInteraction are defined by the ARGS_EXTENSION_LENGTH and ARGS_INTERACTION_LENGTH fields in takerTraits.

Since proxy contracts do not hold private keys, they use the ERC-1271 standard to validate signatures. When the Limit Order Protocol (LOP) requests a signature validation, the proxy performs the following:

1. Address Verification: It calculates the expected proxy address from the order hash and checks if it matches the current contract address.
2. Maker Patching: If the address matches, it patches the order maker to the proxy address.
3. Hash Verification: It recalculates the order hash and verifies it against the provided signature.
4. Validation: If all checks pass, it returns the valid signature selector, allowing the order to be processed as if signed by a standard EOA.

The RemainingInvalidatorLib provides a mechanism to invalidate orders using the remaining amount of the order as a nonce. This allows for granular invalidation based on how much of an order has been filled.

Lifecycle of the invalidator:

• Order Creation: When an order is first created, the remaining invalidator is 0.
• Order Filling: As an order is filled, the remaining invalidator is updated to the inverse of the remaining amount.

This mechanism ensures that once an order's remaining amount changes (due to a fill or manual invalidation), the previous state becomes invalid.

The ITakerInteraction interface provides a callback mechanism used during the order filling lifecycle. This callback is triggered after the maker's funds have been transferred to the taker, but before the taker's funds are transferred to the maker.

It is designed to allow interactive handling of maker assets to produce taker assets (e.g., interacting with a DEX or a vault).

Important Limitations:

• It does not support ETH as taker assets.

// The order filling lifecycle sequence:
// preInteraction => Transfer "maker -> taker" => Interaction => Transfer "taker -> maker" => postInteraction

The FeeTaker is an extension for the 1inch Limit Order Protocol used to manage fees (integrator and resolver fees) during order execution. It provides methods to calculate the required makingAmount or takingAmount when fees are involved and handles the actual fee collection via postInteraction.

Data Format for extraData

Most FeeTaker functions require an extraData byte array. The structure of this array is critical for correct calculations:

• 2 bytes: Integrator fee percentage (scaled by 1e5)
• 2 bytes: Resolver fee percentage (scaled by 1e5)
• 1 byte: Taker whitelist size (N)
• (bytes10)[N]: Taker whitelist (N entries of 10 bytes each)
• 20 bytes: Fee recipient (used in postInteraction)
• 20 bytes: Receiver of taking tokens (optional, used in postInteraction; if omitted, the maker is the receiver)