[1IP-43] Optimizing Fusion Mode: Smart Contract-Enforced Gas Fee Limit and Lowered Unicorn Power Threshold

2.1 General Proposals
1

Simple Summary

  • Enforce an Ethereum gas fee limit in the 1inch Fusion mode smart contracts, setting a priorityFee cap based on the block’s baseFee.
  • Implement a penalty system, in which violators are barred from filling Fusion mode orders.
  • Reduce the Unicorn Power (UP) requirement for Resolvers from 10% to 5%.

Abstract

The proposal aims to both decrease operational costs for Fusion Mode Resolvers and encourage broader participation by introducing a smart contract-enforced priority gas fee limit and a penalty system. Furthermore, by lowering the UP requirement for Resolvers, the Fusion Mode ecosystem will be more accessible.

Motivation

Currently, Resolvers face discouragingly high operational expenses, primarily due to inflated gas fees during auctions. This issue is exacerbated due to resolvers competing with each other, leading to “resolver gas wars”. The costs of these wars are ultimately borne by participants in the 1inch Network, either through resolvers making smaller profits on filling orders or Fusion Mode users getting worse rates on their trades.

In addition, new resolvers are deterred by the high UP requirement for participation. These proposed changes directly address these issues by regulating gas costs and reducing entry thresholds.

Specification

  1. Smart Contract-enforced maximum gas fee: Implement a rule on the 1inch Fusion mode smart contracts that caps priority gas fees. All attempts to circumvent this restriction, including direct payment to a block builder’s coinbase, will result in a violation. Violations of this limit should trigger the enforcement of penalties.

    • For blocks with baseFee <10.6 gwei – the priorityFee is capped at 70% of the baseFee.
    • For blocks with baseFee between 10.6 gwei and 104.1 gwei – the priorityFee is capped at 50% of the baseFee.
    • For blocks with baseFee >104.1 gwei – priorityFee is capped at 65% of the block’s baseFee.

  2. Penalty mechanism: Offending resolvers will be barred from filling Fusion mode orders.

    • First offense – official warning
    • Second offense – one (1) day block from filling orders
    • Third offense – seven (7) day block from filling orders
    • Fourth offense – thirty (30) day block from filling orders
    • Fifth offense – three-hundred sixty-five (365) day block from filling orders

  3. Decrease in UP threshold: Propose to lower the UP requirement for Resolvers from 10% to 5% via an alteration in the DAO’s governance smart contract.

Implementation:

  • If successfully passed, this proposal will be implemented on October 16th.
  • This proposal signals to the 1inch Foundation and 1inch Labs to implement this proposal:
    • 1inch Labs should deploy the changes described in this proposal
    • 1inch Foundation should change the public Fusion Mode Terms of Use for Resolvers and communicate these changes with Resolvers
    • The 1inch Foundation should help enforce the penalties described in this proposal

Rationale

Restricting the priority gas fee protects resolvers from excessive operational costs, thus maintaining long-term sustainability. The baseFee ranges described in the specification section are based on historical data and aim to allow 99.99% of transactions to get included within 15 blocks.

A penalty mechanism reinforces compliance amongst the participants while preserving fair competition.

Lowering the UP requirement expands the number of resolvers, promoting diversity and robustness in the Fusion Mode ecosystem.

Considerations

Enforcing these changes would entail updates to the Fusion mode backend and should be thoroughly tested.

6 Likes
2

Franklin DAO supports this proposal as it provides the means to directly address the issue of high operational expenses faced by Resolvers which is even further exacerbate by their competition leading to “resolver gas wars” , leading to smaller resolver profits on filling orders and worse trade rates for Fusion Mode users. The max gas fee and penalty seem like a good duo to incentivize participants.

4 Likes
3

Would this not penalise resolvers who are more gas efficient since a lot of builders order transactions by total ETH paid on gas?

4

Gas prices are quoted in gwei, which is a denomination of ETH. Each gwei is equal to one-billionth of an ETH (0.000000001 ETH or 10-9 ETH). The cost to execute a transaction is equal to the the gas price multiplied by the amount of gas used. This proposal is only regulating the gas price, not the amount of gas that a resolver can use.

Would this not penalise resolvers who are more gas efficient since a lot of builders order transactions by total ETH paid on gas?

It shouldn’t have that effect. Builders are incentivized to fill blocks and get the maximum amount of fees for filled blocks. Efficient transactions that use less gas fill less of the block (so there is room for builders to add other transactions).

1 Like
5

Unfortunately, this proposal was missing a necessary onchain transaction. The DAO’s treasury is the admin of the 1inch Fusion Mode whitelist, so decreasing the UP requirement for Resolvers from 10% to 5% requires a transaction.

In light of this, I am going to re-run this proposal with the necessary transaction data so that part of the specification can be implemented. I will use the “re-run” suffix.

Transaction to reduce resolver UP threshold from 10% → 5%

{"version":"1.0","chainId":"1","createdAt":1697025263747,"meta":{"name":"Transactions Batch","description":"","txBuilderVersion":"1.16.3","createdFromSafeAddress":"0x7951c7ef839e26F63DA87a42C9a87986507f1c07","createdFromOwnerAddress":"","checksum":"0x979269626b3a2fd6d8412bf88d153972a5b9c81eee3547876e11bd1d9fed2652"},"transactions":[{"to":"0xF55684BC536487394B423e70567413faB8e45E26","value":"0","data":null,"contractMethod":{"inputs":[{"name":"resolverPercentageThreshold_","type":"uint256","internalType":"uint256"}],"name":"setResolverPercentageThreshold","payable":false},"contractInputsValues":{"resolverPercentageThreshold_":"500"}}]}

Tenderly simulation: Tenderly Dashboard

6

ioop