Updating the “makerRebateRate” logic

The v1.0 Hydro maker rebate logic was a bit ambiguous — it could be used both to reduce the makerFee and/or to perform actual rebates. This double use case was designed to be flexible, but actually was just unnecessarily complex for any realistic use case. When determining a rebate, most systems actually just need a percentage of the taker fee, not a percentage of total trading volume.

The new v1.1 logic assigns a percentage value of the taker fee that should be transferred to the maker’s address. Simply by being present in a trade, the makerRebateRate now prevents the maker from being assigned a trade fee.

The update to logic makes the old contract and new contract incompatible for handling makerRebateRates.

The new order structure will not be backwards compatible with the old contract, or vice versa.

Adding a buyer field into the match event

In v1.0, the Match log does not distinguish which account was the buyer and which account was the seller. In v1.1, a new “buyer” field has been added into the Match event. This new field makes it easy to distinguish which account was the buyer and seller directly from the Match log.

Having the ability to easily distinguish which account was the buyer/seller yields easier and more flexible statistical analysis.

Removing “verifyingContract” and “version” fields from DOMAIN_TYPEHASH (EIP712)

The v1.0 Hydro Contracts used the verifyingContract and version fields from EIP712. The intent behind this was to be transparent with transaction data and to make signing transactions safer. While the intent was good, the EIP712 domain hash actually has a few problems with respect to decentralized exchange contracts.

First, the EIP712 domain hash yields unnecessary friction for upgrading the Hydro exchange contract. Because the domain structure is a part of the order id calculation, if we change the exchange contract, the domain structure will also change — this causes a different order id when compared to older orders.

EIP’s original purpose was to make signing transactions more safe. Its efficacy is questionable though for some contract structures. It requires users to have relevant knowledge about the message they’re signing, which in the case of complex exchange contracts is frankly unrealistic. The message labels received through EIP712 for us actually ended up providing more confusion than help.

With this is mind, we removed the EIP712 Domain structure from the Hydro 1.1 version. These include version and verifyingContract.

It’s worth noting that the intended security benefits from EIP712 are also redundantly guaranteed through the Hydro Proxy Whitelist, so removing these fields will not reduce the level of overall security for our contracts.

Adding a baseTokenFilledAmounts parameter for matchOrders

The v1.0 interface for the matchOrders function is:

v1.0 matchOrders function

This setup is designed to fill as much as it can in each match, without explicitly defining how many tokens will be matched.

Matching engine based relayers such as DDEX functioned correctly without explicitly defining this field, but adding it makes the contract more flexible and adds some potential for additional use cases.

Note that while transaction ordering is guaranteed on Ethereum, this is not necessarily true for other blockchains. So by providing this field we can loosen the dependency on perfect transaction ordering and make Hydro multi-chain ready.

So to make the matchOrders structure a bit more powerful for these use cases, we added a new parameter:

new baseTokenFilledAmount parameter added to matchOrders

Adding isMakerOnly field

From talking with API users, one common request was to add a field to ensure that the order they were placing could never be a taker order. So to provide API users with a bit more flexibility to ensure that their order is always the maker, we added a new “isMakerOnly” field to the build order api. This is like the opposite of a “fill-or-kill” order.

Going Forward

The v1.1 upgrades to our smart contract better prepare us for the future vision of Hydro Protocol. In 2018 we focused on constructing the underlying architecture to one of the most prominent decentralized exchanges in the ecosystem. In 2019, we will build on our success from last year and aggressively push forward to connect with and leverage the DeFi ecoystem.

Lots of exciting things coming this month, stay tuned!

As always, please let us know if you have any questions about the project and the proposed changes.

Happy trading :)