I recently took part in ETHSingapore with three other engineers (Waihon, Wu Di and Lu Yu) from Rate3. Rate3 aims to bridge enterprises to the blockchain through open protocols for cross-chain asset tokenization and identity management.
From left to right: Lu Yu, Waihon, Me and Wu Di (full stack engineer)
ETHSingapore is ASEAN’s first Ethereum Hackathon and part of the ETHGlobal 2018 series.
Projects were given under 36 hours to collaborate and build decentralized applications using Ethereum as well as the APIs of various other sponsor projects that included Aragon, bZx, Celer, Giveth, Kyber, MakerDAO, NuCypher, Raiden, Set Protocol, Quantstamp and Status.
ETHSingapore was a good opportunity for us to set aside a weekend to focus on a hack that is novel, yet something that people would still use. Armed with our experience with tokenization and identity on Ethereum and Stellar, we were excited to get started.
Day 1, 9.30pm — Ideation
The hackathon officially begins and what follows is the hardest part of a hackathon: deciding the hack.
We managed to secure a cosy work room. Not in picture: whiteboard with lots of drawing.
Here’s a list of ideas from our brainstorming process :
A basket of stablecoins governed by DAO
Set Protocol allows a token abstraction over tokens i.e a “Set” ERC20 token comprising of one or more ERC20 tokens. It works by collateralizing underlying tokens in the ratio determined when the Set is created.
For example, one can create a USD Set with 50% TUSD and 50% Dai. To obtain 1 USD Set token, you will need to collateralize 0.5 TUSD and 0.5 Dai.
This is really useful for projects to develop their own Set to group tokens together by function or just to manage multiple tokens easily. More complex use cases revolve around “Rebalancing Set” are Set Brokerages, fund management, robo advisor, etc.
The most interesting idea we had was to have a decentralized USD Set. This could be achieved by decentralizing the authority (with help of Aragon) on what tokens should go in a USD Set, the composition ratio of the Set and choosing when to rebalance the USD Set by conducting dutch auctions.
DAICO with on-chain KYC claims
DAICO (Decentralized Autonomous Initial Coin Offering) is an idea to improve the ICO model by combining benefits of DAOs to minimize complexity and risk. (Read more at Vitalik Buterin’s topic thread)
One of the main features is taps which determine the amount of wei per second that the developer can take out of an initial contribution to a DAICO contract. Token holders can then vote on two kinds of resolutions:
- Increase the tap: allow the team to withdraw more ethers
- Shutdown and refund — Permanently self-destructing the contract (or, more precisely, putting the contract into withdraw mode where all remaining ETH can be proportionately withdrawn by the token holders)
DAICO mechanisms have since then been widely discussed. We thought of trying to implement a DAICO-KYC sale utilising the new and simplified ERC725 Simple Identity Proxy, ERC734 Key Management and ERC735 Claim Holder. The identity proxy would hold KYC claims from the project team or third-party attesters and their token sale cap would be dynamic.
Imagine a situation where you hold multiple tokens (utility tokens, asset-backed, crypto-backed, etc) and of course, ethers. It is currently quite challenging to trade multiple assets seamlessly with one wallet.
How I imagine one might currently try to do this — shift the assets out of your wallet (or approve token transfers) to respective platforms where the tokens are traded, do the trade and deposit back into the account. The complexity and friction is multiplied by the number of tokens one holds and the platforms that each token supports. Now, on top of that, how about adding trying to get the best rates for the trade between tokens and between platforms into the picture?
The idea we had was to allow an individual to specify the end state of tokens and their balances, then do the necessary trades in one transaction. This could be possible by relying on decentralized liquidity providers like 0x or Kyber Network to do multiple swaps in a single transaction. A naive way will be to swap “top down” token by token from current balance to target tokens in the specified end-state until the original token runs out. A more complex multi-trade, the 0x-Kyber optimization system, is also a potential extension.
This idea draws inspiration from the ease of card payments for senders and recipients to send and receive in any supported currencies.
It would be useful if we could send any token or ether we have in our wallet and the recipient is able to receive the value in any support token or ether. Again, this will rely on smart contract swaps for an atomic transaction.
MakerDAO’s Collateral Debt Position (CDP) is a record of collateralized asset (ethers) and Dai (USD stablecoin) issued. CDP owners can use the borrowed Dai to open more recursively-leveraged CDPs.
Relying on decentralized liquidity protocols again, we could create an easy-to-use UI to allow users with ethers to create any amount of recursive CDPs and choose the amount of ETH/token remaining balances.
(Check out https://mkr.tools to view the network statistics)
Gas-less Dai payments
Imagine an app that allows you to send Dai to any wallet without paying for gas directly via a delegate (someone paying the gas for you).
Why Dai? Well, it is a USD stablecoin — great as a store of value and as a medium of exchange. Why go through the hassle of getting a delegate to pay the gas for you? Consider asking your friends to install your favourite Ethereum wallet just because you want to give them an early Christmas gift of 200 Dai. You probably will not have issues doing that because you are already familiar with the ecosystem. Now, what can your friend actually do with the Dai? Hypothetically speaking, they could use it for payments if Dai could be used like real USD, but your friend would not be able to do anything without ethers to pay for transactions.
Gas is crucial for the Ethereum ecosystem as it acts as the native currency to incentivize miners but until an easy way for people not familiar with cryptocurrency to get ethers is created, it serves as an obstacle for wider Ethereum adoption.
How it works is through the implementation of ERC865. A sender (without ethers) will sign a Dai transaction off-chain and pass it to the delegate to submit to the network. Part of the agreement is that the delegate will take a cut of Dai to pay for gas and fees, if any. Delegates will be able to slowly convert their ethers to Dai, choose to hold, or trade with another asset.
Yes we considered ERC965 but this means we also have to implement a ERC777 Dai
This idea has a beer backstory. It all began with the MakerDao happy hour event after a pre-hackathon meetup in town. The MakerDao team was giving out 5 free Dai and attendees could exchange 1 Dai for a craft beer coupon. There were two main issues:
UX The Dai redemption process involved the application of a promotion code on Kyber Network website, where they gave you a web wallet with tokens to be swapped for Dai via — you guessed it — Kyber Swap, and some ethers to do the swap and send tokens out.
At which process did users face the most trouble?
It was actually the scanning of the QR code — which means scanning the code for Kyber website (https://kyber.network/swap. Takes more time to open a QR code scanner than to type it out) and sending the payment to the team’s wallet. QR codes should work great on a mobile setting right? Well, that works only if the website and apps have the QR code scanner function.
CostIt can be quite costly and complicated to generate many one-time addresses (think thousands) and airdrop ethers to these wallets, monitor the wallets for inactivity and consolidate unused ethers. It would be more convenient and cheaper if an organization sets up their own delegates and pay the gas on behalf of wallets managed by them
Hence, the idea for a Dai-only wallet. It needs to be easy-to-use and should provide a familiar mobile UX, topped off with a QR code scanner ;)
People learning how to use Kyber Swap and sending Dai :)Beers worth the wait! Right outside Esplanade stationEtherstellar
Extension that is similar to Metamask but which bridges the Stellar ecosystem.
Etherstellar’s key characteristics:
- Allows management of Ethereum and Stellar accounts through a single application
- Acts as a dApp bridge in Stellar
- Acts as a direct bridge to liquidity platforms on Ethereum and anchors in Stellar (SEP-0006)
- Allow users to interact with Ethereum and Stellar dApps freely
- Allow users to swap tokens between Ethereum and Stellar freely (centralized swaps or Hashed Timelock Contracts)
- Allow users to trade tokens in respective network via decentralized liquidity protocols (Ethereum) or native DEX (Stellar)
Singapore-related (payments, ID, etc)
Since it’s ETHSingapore, why not consider some hacks unique to Singapore?
It could range from integrating payments API (PayNow, DBS, OCBC, etc) to providing an easy crypto-fiat bridge (from a tech standpoint only). Think of it as expanding the Ethereum wallet with fiat SGD. We even thought of creating an SGD stablecoin to act as the transaction layer while an on/off ramp could be implemented with DBS API integrations. GrabPay on blockchain? Create a Singaporean Venmo on blockchain?
We were pretty stoked about our ideas but unfortunately we pretty much spent half of the 36 hours ideating and deliberating (until 4am and continued over lunch the next day).
Given our initial objective of building something that people would use and with the clock ticking, we were left with: Wallet Balancing, Universal Payments, Gas-less Dai payments, Singapore-related hacks.
We had to eliminate Singapore-related hacks because DBS Developers playground did not work for us when we tried to play around with it and there’s no way to sandbox PayNow API (payment by phone or ID number registered with banks) without going through one of the banks ¯\_(ツ)_/¯ (An open Singapore payment protocol — maybe another project for another time)
Gas-less Dai was ultimately chosen because every success story needs a backstory. We also felt more motivated to build a hack to solve a problem we personally faced just two days ago.
The name for the hack came to us effortlessly too: Dai.ly — daily Etherless payments with Dai.
Day 2, 4.30pm — Implementation
With the idea in place, we started to plan our implementation scope and task allocation.
One of the three hacker zones. We picked this one because of the Christmas tree, obviously.
Here’s the rundown:
The UI should be a web app so that it can be used on mobile and computers. The app should also be simple enough to build and use, yet also be appealing to users who try it out. We decided to use Google’s Material Design in our React app to give that sleek look and feel and added in some animation to spice it up.
Presenting the Dai.ly appSmart Contracts
Implement ERC865. This means adding the proposed interface to current Dai token code and writing tests to make sure that it actually worked. There is already an implementation reference which we found tremendously useful. We also wanted to integrate it with MakerDao and Kyber APIs.
However, in the course of implementation, we faced several issues. The implementation code had compile errors, ecrecover code was outdated, some of the method’s hash was wrong. ERC865 forces existing ERC20 tokens to upgrade their tokens too. This prevented us from having complete working integrations with intended Makerdao and Kyber Swap APIs (CDPs and swaps) on Ropsten testnet. If we had more time, we could have deployed their contracts to support our custom token.
Look Ma, no ethers! 1 Dai is sent to delegate 0xbf7… as feesBackend:
We needed a web server to act as an off-chain matching of senders and delegates and to keep track of signed transactions that were not submitted to the network yet. We implemented transactions monitoring and retries with geth library since we were using Go.
Autogenerated Go wrappers for contract methods can still be painful to use for simple transactions and queries. Go Ethereum Book is an awesome guide book to develop Ethereum applications with Go. We have been relying on web3.js or in some rare instances, Etherscan API, to submit and query transactions, manage events when building technical demos. This hands-on experience gave us greater insights and knowledge on using Go server as a Ethereum transactions manager.
All code can be found at https://github.com/rate-engineering/dai-ly
Day 3, 9.30am — The submission
After hours and hours of consuming great food catered by Grain, snacks, Tiger Beer/Milo/Red Bull/100 Plus, we managed to complete our MVP.
We hosted the client on IPFS and the server was hosted on my machine with good old ngrok. After we handed in our submission, had it judged, we finally managed to catch some shuteye until the closing ceremony at 1.30pm.
Sharing our idea with guys from Kyber NetworkThankfully we were one of the first to be judged. More rest time!
Day 3 1.30pm Closing Ceremony
As the hackathon neared its conclusion and before the closing ceremony started, we received a message that we were selected as one of the finalists! We were too tired to celebrate and instead channelled all the energy we had left into testing our app to make sure everything was alright.
The Demo Gods smiled on us that day. It was definitely a memorable moment to demo a hack in front of Vitalik Buterin. We also managed to win one of the prizes from MakerDao (maybe we hit the right note with their community development efforts), and received an ERC721 from the Gitcoin team.
Looking back, we made many fond memories and friends who are equally passionate into developing the Ethereum ecosystem. Among all the hackathons we have participated, we dare say ETHSingapore is the best organized with the best atmosphere and experience too!
Hopefully, we will see more blockchain hackathons of such quality in ASEAN in the near future.
Davis Gay is the CTO and co-founder of Rate3.