[PT1-785] Feature/anchored minimal by ifelsedeveloper · Pull Request #229 · 1inch/fusion-protocol

ifelsedeveloper · 2026-08-14T16:01:12Z

Change Summary

What does this PR change?
Add anchored based order via order registrator and timestamp flag

…time for anchored order, updated solidity

SevenSwen · 2026-09-03T10:39:20Z

  "dependencies": {
    "@1inch/delegating": "1.1.0",
-    "@1inch/limit-order-protocol-contract": "4.3.3",
+    "@1inch/limit-order-protocol-contract": "1inch/limit-order-protocol#c4970e319d309fb605185b65b36162f5ece3abd6",


We need to publish the npm package with the new version.

SteMak · 2026-09-08T18:08:57Z

+    function _anchoredTime(uint256 flaggedTime, bytes32 orderHash) private view returns (uint256) {
+        uint256 announcedTime = _ORDER_REGISTRATOR.announcedAt(orderHash);
+        if (announcedTime == 0) revert OrderNotAnnounced();
+        return Math.max(flaggedTime & _ANCHOR_TIMESTAMP_MASK, announcedTime);


Did not get it. Which role has the flaggedTime here, why using Math.max?

As synced, flaggedTime is not needed; here use return announcedTime;
It would be good if this will not produce one more if, to drop 3 redundant bytes though: calldata is uint32 ts with high bit not set or bytes1 of value 0x80

Use order registrator for 0x80000000 timestamp

SteMak · 2026-09-08T18:12:16Z

+const LOP_COMPILER_SETTINGS = JSON.parse(JSON.stringify(DEFAULT_COMPILER_SETTINGS));
+LOP_COMPILER_SETTINGS.version = '0.8.30';
+
+const LOW_OPTIMIZER_COMPILER_SETTINGS = JSON.parse(JSON.stringify(LOP_COMPILER_SETTINGS));


Won't it compile without this changes?

SteMak · 2026-09-08T18:15:10Z

 ```

-Parameters are read from a `.env` file as `OPS_*` variables. `OPS_NETWORK` and `OPS_CHAIN_ID` are always required; each target validates its own additions, so `deploy-settlement`, for example, also needs `OPS_ROUTER_V6_ADDRESS`, `OPS_ACCESS_TOKEN_ADDRESS`, `OPS_WETH_ADDRESS` and `OPS_SETTLEMENT_OWNER_ADDRESS`. Contracts are deployed through a CREATE3 deployer so that the same address is used on every chain, which needs `OPS_CREATE3_DEPLOYER_ADDRESS` and a salt; zkSync Era does not support CREATE3 and falls back to a plain deployment.
+Parameters are read from a `.env` file as `OPS_*` variables. `OPS_NETWORK` and `OPS_CHAIN_ID` are always required; each target validates its own additions, so `deploy-settlement`, for example, also needs `OPS_ROUTER_V6_ADDRESS`, `OPS_ACCESS_TOKEN_ADDRESS`, `OPS_WETH_ADDRESS`, `OPS_SETTLEMENT_OWNER_ADDRESS` and `OPS_ORDER_REGISTRATOR_ADDRESS`. The OrderRegistrator must implement the `announcedAt(bytes32)` getter introduced in Limit Order Protocol 4.3.5. Contracts are deployed through a CREATE3 deployer so that the same address is used on every chain, which needs `OPS_CREATE3_DEPLOYER_ADDRESS` and a salt; zkSync Era does not support CREATE3 and falls back to a plain deployment.


The OrderRegistrator must implement the announcedAt(bytes32) getter introduced in Limit Order Protocol 4.3.5

Does it make sense to add the text here?

SteMak · 2026-09-08T18:19:17Z

        await weth.connect(alice).deposit({ value: ether('1') });

-        const settlementExtension = await deployContract('Settlement', [lopv4, accessToken, weth, owner]);
+        const settlementExtension = await deployContract('Settlement', [lopv4, accessToken, weth, owner, ethers.ZeroAddress]);


Feels like Gas measurements are not properly updated

SteMak · 2026-09-08T18:28:03Z

+        });
+        orderRegistratorInterface.decodeFunctionResult('announcedAt', result);
+    } catch (error) {
+        throw new Error(`OrderRegistrator at ${orderRegistratorAddress} does not implement announcedAt(bytes32)`, {


The other deploy parameters does not have same-level validations. Is it meaningful to execute such checks for OrderRegistrator?

SteMak · 2026-09-08T18:30:24Z

     *     bytes3 gasBumpEstimate;
     *     bytes4 gasPriceEstimate;
-     *     bytes4 auctionStartTime;
+     *     bytes4 auctionStartTime; // top bit is the anchor flag, see `_ANCHOR_FLAG_MASK`


Comment inside of comment. Declare outside or remove or rename field to be self-explaining

SteMak · 2026-09-08T18:31:15Z

    error InvalidResult(uint256 actual, uint256 expected);

-    constructor(IERC20 accessToken, address weth, address owner) SimpleSettlement(address(this), accessToken, weth, owner) {}
+    constructor(IERC20 accessToken, address weth, address owner) SimpleSettlement(address(this), accessToken, weth, owner, IOrderRegistrator(address(0))) {}


Why hardcoding zero-address instead of meaningful value?

SteMak · 2026-09-08T18:32:44Z

 import { IOrderMixin } from "@1inch/limit-order-protocol-contract/contracts/interfaces/IOrderMixin.sol";
-
+import { IOrderRegistrator } from "@1inch/limit-order-protocol-contract/contracts/interfaces/IOrderRegistrator.sol";
 import { SimpleSettlement } from "./SimpleSettlement.sol";


Broken style: there was a whitespace between module and local imports

SteMak · 2026-09-08T18:34:03Z

    using Math for uint256;

+    /// @dev Top bit of a uint32 timestamp (auction start time / whitelist allowed time) opts the order
+    /// into anchoring: effective time = max(timestamp without the flag, OrderRegistrator.announcedAt(orderHash)).


Why documenting protocol behavior in natspec of random constant?

SteMak · 2026-09-08T18:36:02Z

    error InvalidEstimatedTakingAmount();
+    error OrderNotAnnounced();
+
+    IOrderRegistrator private immutable _ORDER_REGISTRATOR;


Why constants - errors - immutables layout? The errors - constants - immutables would be more consistent

SteMak · 2026-09-08T18:39:10Z

     * @param whitelistData Whitelist data is a tightly packed struct of the following format:
     * ```
-     * 4 bytes - allowed time
+     * 4 bytes - allowed time (top bit is the anchor flag, see `_ANCHOR_FLAG_MASK`)


Comments referring to another comments in another file part is hard to read

SteMak · 2026-09-08T18:53:59Z

            uint80 maskedTakerAddress = uint80(uint160(taker));
            uint256 allowedTime = uint32(bytes4(whitelistData));
+            if (allowedTime & _ANCHOR_FLAG_MASK != 0) {
+                allowedTime = _anchoredTime(allowedTime, orderHash);


The _anchoredTime reassigns 2 different timestamps: whitelist start timestamp and auction start timestamp which potentially are different. Is it intended? If so, that should be explicit

ifelsedeveloper added 2 commits August 14, 2026 16:16

feat: add order registrator

116f8d4

feat: add order registrator and flag in timestamp to get order start …

c484cdd

…time for anchored order, updated solidity

ifelsedeveloper requested a review from SevenSwen August 14, 2026 16:01

ifelsedeveloper changed the title ~~Feature/anchored minimal~~ [PT1-785] Feature/anchored minimal Aug 14, 2026

ifelsedeveloper added 4 commits August 17, 2026 10:24

feat: add tests for native order support

673418d

feat: add new version for LOP

b65761b

Merge branch 'master' into feature/anchored-minimal

0fb1f68

feat: add deploy

1cb5784

SevenSwen requested changes Sep 3, 2026

View reviewed changes

SteMak reviewed Sep 8, 2026

View reviewed changes

Uh oh!

Conversation

ifelsedeveloper commented Aug 14, 2026

Change Summary

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteMak Sep 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteMak Sep 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

SteMak Sep 8, 2026 •

edited

Loading

SteMak Sep 8, 2026 •

edited

Loading