Automated Contract Wrapping and Unwrapping of ETH

Used under creative commons license from Flickr.

At STK, our priority is making cryptocurrency and blockchain accessible and easily adoptable by the masses. User experience is extremely important for mass adoption. Our latest development in the smart contracts can dramatically improve the UX by abstracting the wrapping and unwrapping of ETH.

In the blockchain space, the number of users using Decentralized applications are relatively low. There are a number of factors influencing this, including the unfamiliarity of the new type of technology. The flow for everyday applications and Decentralized applications are simply different, as Dapps require signing and authorization of transactions. In many cases, the difference in execution makes the user flow cumbersome and clunky.

It is incredibly important to think about the user experience in all facets of building out technology — from the frontend to the set of smart contracts. Just because ETH and ERC20 Tokens are structurally different, doesn’t mean users need to know about the difference. From our point of view, the end-user should be able to interact with ETH the same way they would any ERC20 token.

The User Experience Effect on a Multi-token Payment Channel

Back in August, when we released our Multi-token Payment Channel, it allowed dynamic instantiation of any ERC20 tokens. For all intents and purposes, this functionality allowed us to reuse the channel for any number of tokens as needed. Considering most of the tokens followed the ERC20 standard, this would sufficiently cover our needs. Implementing such a channel not only ensured reduced gas costs, but ensured a uniform and consistent user experience, as the underlying contracts would remain unchanged.

There was one need, however, that was not met: ETH.

With the existing codebase, the contract would reject any ETH sent to it. A user would not be able to transact and exchange with ETH, due to the syntactical difference in transfer functions.

To transfer ERC20 tokens between addresses, the syntax is: tokenAddress.transfer(dstAddress, amountToSend). Contrarily, to transfer ETH to another address, the syntax is: dstAddress.transfer(amountToSend). This website goes into a bit more detail on the nonconformity of ETH — but here’s the point:

ETH DOESN’T CONFORM TO ITS OWN ERC20 STANDARD.

Due to the underlying difference, updating state to an ETH channel would not be able to use the same functions as an ERC20 token channel would.

Even though a unified token standard exists, ETH does not meet these standards. As a developer, working within these bounds is very limiting.

From a user perspective, I find this overly tedious. To use decentralized exchanges, the exchange will take you through a series of steps in order to ensure that you can then trade your ETH for ERC20 tokens.

1. Send your ETH into a contract which will convert it into WETH and assign it to the your address
2. Send WETH to decentralized exchange address to trade other tokens

Given the number of additional steps to be able to simply convert ETH to WETH and use it in a Dex, the user experience is often awkward and cumbersome. The additional number of steps just to make ETH conform to ERC20 specifications is over-the-top. Not to mention, the complex number of steps required to convert and send increases the chance of human error.

Achieving Automated Wrapping and Unwrapping of WETH

Note: These set of smart contracts are still undergoing audits, thus are not guaranteed to be safe. Use at your own risk.

This is why STK started to look into wrapping tokens on behalf of the user. Instead of having to manually convert WETH, or make the user do it, it can be done through functions in the contract. This allowed us to simplify the process:

1. A user can send funds into the contract at any time they wish through a fallback payable function
2. At any point after ETH has been sent into the contract, call deposit() to tokenize ETH to WETH
3. The close, contest, and settle functionality is identical due to the wrapped ETH being an ERC20 token
4. In the settle, it uses the WETH version of transfer, which decreases the balance of the channel, and sends ETH.

Our new smart contract redesign abstracts the entirety of the wrapping experience, so from a user standpoint, transacting with an ERC20 token and ETH is the exact same.

Benefits of Wrapped ETH

There are a few benefits of implementing it in this way as opposed to the more traditional way.

Firstly, STACK does not own the funds inside the state channel. The funds are deposited into the state channel then deposited into the WETH contract. It uses the deposit() function in the WETH contract, which assigns it to msg.sender. In this case, it would be the state channel address. As both users and STK can call functions in the smart contract, both users have full control over the over the changing of state and thus, the distribution of funds in the state channel.

Second, the ETH can perform and behave as if it was an ERC20 function. As long as the WETH contract supports functions like balance() or transfer(), the function is overridden in the WETH contract.

For instance, in transfer of the ERC20 function, when the contract calls ERC20Token.transfer(dst,amount), it makes use of the following transfer function, which transfers tokens:

Similarly, in our WETH contract, when the contract calls WETH.transfer(dst,amount), it makes use of the following transfer token function. This functionality is essentially the unwrapping of wrapped ETH to ETH. The function reduces the balance of WETH tokens the smart contract owns, and sends out ETH to the destination address.

That way, in our settle function, the code for transferring tokens can remain the same. It was not necessary to update anything specifically for a WETH channel functionality. If Solidity detected the function being non-existent, the fallback would be invoked; but if it detected a transfer() function present, it would execute the function of the code in the respective contract address.

Thirdly, a user would never have to worry about the process of unwrapping and wrapping ETH. From a user standpoint, loading a wallet with ETH is the same thing as any ERC20 token. The contract performs the entirety of the wrapping and unwrapping process, thus is not subject to human error throughout its execution.

There’s a wrap to our latest development in our smart contracts — with Multi-token Payment Channels with Automatic Wrapping and Unwrapping of WETH! If you’d like to check out our code in its entirety, visit us here: https://github.com/STKtoken/Multi-Token-smart-contracts!