Hydro Protocol v1.1 — Smart Contract Updates

Published in

Hydro Protocol

5 min readMar 18, 2019

Back in December 2018, we launched v1.0 of the Hydro Protocol Smart Contracts. Since then, DDEX has utilized the Hydro contracts to perform:

60,000+ transactions (over 700 tx/day)
$25,000,000+ USD of transaction volume
125+ unique tokens traded

Through looking at our transaction data from the last couple months, talking with our users, and preparing for future development, we found a number of improvements that should be implemented to make our smart contracts more effective and robust.

Most of these changes are based on quality of life and logical improvements to amplify the power of #DeFi and better allow for a thriving ecosystem of Hydro Relayers.

We will be switching the Hydro v1.0 contracts to v1.1 on Wednesday, March 27. This article will detail the specific contract updates, along with some brief discussion of the rational behind the changes.

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:

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 :)