Hydro Protocol v1.1

Hydro Protocol 1.1 Change Logs

Hydro Protocol 1.1 makes some improvements that will help simplify logic in some cases and adds some minor quality of life improvements for users of the contract. The changes to the contract have been fully audited and will be deployed shortly, once we complete the proper procedures.

The update includes the following changes:

Update matchOrders function to specify fill amounts

function matchOrders(
    OrderParam memory takerOrderParam,
    OrderParam[] memory makerOrderParams,
+   uint256[] memory baseTokenFilledAmount,
    OrderAddressSet memory orderAddressSet
) public;

We've updated the main matchOrders function of the contract to specify the exact fill amounts from each maker order submitted. While this does increase the calldata size, it has a number of benefits:

1. The contract will behave much more explicitly, instead of the relayer having to make assumptions about how an order will be filled once the transaction is executed.
2. Less math is required in the contract itself. Instead the proper amounts can be calculated off chain and the contract will still simply validate that the amounts it needs to fill are still available.
3. Perhaps most importantly, since maker orders can fill multiple taker orders, the order that matches are submitted could produce different results. While Ethereum uses nonces to ensure transactions will be performed in order, not every chain has the same guarantees in place. This change gives us added resilience as we explore expanding Hydro Protocol beyond the Ethereum chain.

Update rebate rate logic

Our old logic was designed to be flexible, allowing a rebate rate to be defined for the maker depending on the volume of the trade. This rebate could reduce the fee paid by the maker, even to a negative amount up to the amount of the fee paid by the taker. Unfortunately this flexibility also caused some strange ambiguity, and quite simply doesn't act in the way most makers would expect. Because of that we have simplified the way the logic works.

The new logic no longer depends on both the maker fee and the rebate at the same time. If makerRebateRate is set to any number greater than zero, then the maker fee will be ignored. The value in makerRebateRate is now interpreted as a percentage, so should be set to a number between 0-100. Whatever percentage is set, the maker will receive that percent of the taker fee back as a rebate upon a successful match.

This again simplifies the logic, and doesn't really remove flexibility to a significant degree since the maker fee can still be set to whatever the relayer wishes in the order data.

Note that due to this change, we have bumped the version number used in Order structs from v1 to v2. The Hydro Protocol v1.1 contract will no longer accept any v1 orders to prevent any ambiguity in how fees and rebates will be applied.

	Hydro 1.0	Hydro 1.1
Order v1	✓	✗
Order v2	✗	✓

Add buyer to Match event

The Match event in Hydro Protocol v1 provides much of the data about the two matched orders, but it omitted which of the two parties was the "buyer" (is receiving base token in exchange for quote token). To remedy this, we have included a buyer field into the event, which will be set to either the maker address or the taker address.

Update EIP712 hash for more flexibility

One of the benefits included in Hydro Protocol was inclusion of the EIP712 signing strategy, allowing much more structured information to be presented to the user upon signing an order. Part of this includes defining the domain separator in order to give identifying information to the user about the contract that will be eventually receiving the signed order. We originally included 3 fields in the domain: the protocol name, version, and the address of the contract itself. Unfortunately, the current domain causes unnecessary friction with dubious benefits.

Because the version and the contract address are encoded into the hash of the order, if we upgrade the contract or change the version number for orders, it means all old orders must be invalidated and can no longer be matched. While this is good in some situations, we believe it makes more sense to do this invalidation within the contract itself instead of automatically. Because of this, we are removing both of those fields from the domain, to allow for a more seamless upgrade process when possible.

The potential downsides for removing these fields are minimal. Orders will still be presented with the name "Hydro Protocol" in the domain. Relevant identifying information, such as the address of the relayer who may submit the order, is still available in the order data itself. Beyond that, knowing the validating contract address provides a minimal security gain since the order may only be fulfilled by valid Hydro Protocol contracts. This is already guaranteed through a maintained whitelist of valid contract addresses.

Add support for "maker only" orders

In order for a market maker to realize their rebates, their order must be used as a maker order in a match. If the isMakerOnly field is set in the order data, then that order may only be used as a maker order, and will revert if it is submitted as a taker order. It is the relayer's responsibility to maintain a valid orderbook by rejecting "maker only" orders that would be matched and filled as taker orders.

Hydro Protocol v1.0

Merge pull request #3 from HydroProtocol/features/update-readme

updated README