A Detailed Look at How Dolomite Solves the DEX Onboarding Problem

Corey Caplan
6 min readSep 27, 2019

For those familiar with the DeFi space traditional email & password logins are no longer necessary, having been replaced with external wallet applications such as MetaMask or hardware wallets like Ledger. Using Ether as a means to pay for Ethereum network/gas fees to interact directly with DeFi applications comes as second nature to those who have truly imbedded themselves into this space. Token approvals are a feature to these types of users — not a UX hurdle — and the need for WETH is well understood.

For most, just one of these things creates an onboarding/DeFi experience that is impossible to use. Most people see Ether as an investment opportunity, instead of a means to pay for network fees when trading. Many traders on centralized exchanges understand that a 12-word phrase is how they access their wallet, but their understanding stops there. Users are woefully unaware of the use cases of a wallet beyond using it to hold and send Ether and ERC-20 tokens. Our goal with Dolomite is to build a decentralized exchange (DEX) that anyone can easily use and without ever losing custody of their funds. Additionally, there are a massive number of potential users who are using centralized exchanges who could be using Dolomite if it were made simpler to use. Overall, our team believes the learning curve is too large for onboarding the majority of traders into DeFi. We aim to bring this curve down drastically, and here is how:

  • A familiar signup process that anyone with an online bank account would be able to easily grasp.
  • Decentralized trading without any hurdles or confusion.
  • Users do not need to interact directly with the chain. Ever. Thus they do not need an Ether balance to trade.
  • In accordance with the prior point, users do not need to set approvals for tokens.
  • Users do not need to wrap Ether into WETH. Our UI will only show an ETH balance.
  • CEX-like deposits into Dolomite by sending Ether/Tokens to a deposit address.
  • CEX-like withdrawals out of Dolomite, the network/gas fee is paid in the token being withdrawn.
  • Maintain non-custodianship of assets.

Why does a DEX need these accounts?

At the moment, everyone in the DeFi ecosystem is trading with others in the space. There are an incredibly large amount of people who are not using DeFi products, because they deem them too difficult to comprehend or to use. Dolomite aims to capture both audiences and bring DeFi out of the niche it is in and into the broader cryptocurrency trading world. Those traders using MetaMask or a Ledger will be able to trade with users using an email & password login seamlessly.

How it works

When getting started on Dolomite, a user is presented with the option to load an existing wallet (such as MetaMask) or to signup with an email and password. It is important to note that if we detect that a user has Metamask, we recommend they sign in with the more “decentralized” option. However we encourage those without an existing wallet to sign up with an email and password. Those who choose this method of signup enter their email and password and are then shown a “Recovery Phrase” as the next step of the onboarding process. This recovery phrase is a 12 word mnemonic phrase for an Ethereum wallet with the standard Ethereum derivation path. We brand the wallet as a “Recovery Phrase” because 1) it is more easily understood and 2) that’s exactly what it is — users only need this in the event that they forget their password. After being prompted to write the phrase down, warning them about it being the only way to recover their funds if they forget their password, and re-entering the phrase, the user’s account is created.

It is important to note that on account creation, the mnemonic phrase (and associated private key) are generated by our frontend but never sent to our backend server. In fact, at no point does the user’s private key, mnemonic phrase or password ever get shared with our server. Rather, account creation involves the user encrypting their private key and mnemonic with their password, signing a message with the private key to prove ownership of an address, and then hashing their password and sending all of this up to our server.

Login is similar: a user’s hashed password is sent along with their email to login. The encrypted private key is sent down in a JWT if and only if a user is authenticated using their email & (hashed) password and they pass text-message/2FA confirmation. The frontend application uses the un-hashed password entered by the user to decrypt the private key when it is needed to sign for trades and other actions.

So far, we have described how we onboard users and secure their wallet (private key) behind a traditional login system with 2FA security features. But we have not described how this wallet avoids the need for Ether, token approvals and WETH. We do this through the use of a smart wallet and the CREATE-2 opcode.

Dolomite Smart Wallet

The Dolomite smart wallet consists of three smart contracts. A DepositContract to which users send funds, a DepositContractRegistry that acts as a factory that our backend utilizes to create DepositContracts for our users, and the DolomiteDirectV1 (code name) smart wallet contract.

With the new CREATE-2 opcode, addresses for contracts can be made known before they are created, while maintaining a guarantee that the code that can be deployed to this address cannot deviate from what is expected. This allows Dolomite to calculate deposit addresses for users to send funds to without actually paying to create the contract. When a user wants to withdraw their tokens or submit their first trade, Dolomite creates their DepositContract. At any point, a user can interact with the contract directly and create it themselves if they would like to recover their funds without relying on Dolomite to create the contract for them.

The DepositContractRegistry has a function for updating the version of DolomiteDirect that a deposit address is using. This function requires a signed UpdateRequest from the user’s wallet in order for the update to occur. Similarly, there is a transfer function in the DolomiteDirectV1 contract that takes in a TransferRequest that shares the same concept. Both of these actions can be performed by the wallet owner directly without depending on Dolomite. Fees are part of the Request data that is signed by users, and our backend will only submit a transfer to the chain (on behalf of the user) if the fee set by the user is high enough to cover the gas costs.

The common theme with all of the DolomiteDirect actions is that we use signatures computed by the user to seamlessly perform requests on their behalf. From the user’s perspective, our backend abstracts away the complications of talking to the Ethereum blockchain directly and needing ETH to perform transactions. Instead, we take fees that are signed in requests that are of equivalent value (using CoinMarketCap as the price oracle) to the transactions we are performing for the user.

In the eyes of DolomiteDirectV1, Ether and WETH are one and the same. The balanceOf function returns the sum of a user’s deposited Ether and WETH balance. Whenever a transfer is requested, Ether is wrapped into WETH (unless the transfer data specifies that the recipient should receive unwrapped Ether). When signing an order, a user sets the Loopring Protocol broker field to the DolomiteDirectV1 contract and the Loopring Protocol uses the new IBrokerDelegate interface to request approval to transfer a user’s funds from the DolomiteDirectV1 contract. The Loopring Protocol is whitelisted to be trusted by the DolomiteDirect contract, so no approvals are necessary. This is how Dolomite removes the need for Ether, can remove the discrepancy between Ether and WETH, and avoid token approvals.

Lastly, the DolomiteDirectV1 contract also sets the DolomiteMarginProtocol contract as an approved operator for dYdX accounts owned by the user’s DepositContract upon the creation of the DepositContract, removing yet another hurdle faced by those entering the DeFi space of approving a dYdX operator (which is similar to setting individual token approvals).

Final Thoughts

Advanced users and those with a firm grasp of DeFi will still be able to use Dolomite and access it from their preferred Web3 provider, like Fortmatic, Portis, or Metamask. On the other hand, traders who are currently using centralized exchanges can take a step in the right direction by signing up using a familiar and easy-to-use account that removes all of the hurdles faced by newcomers to the DeFi ecosystem. We see this account system as DeFi “training wheels” that will eventually come off as users become more experienced in things like private key management. Most importantly, these two types of users can readily trade amongst each other on one platform that suits the needs of everyone.

--

--

Corey Caplan

Founder of Dolomite, software engineer, and DeFi enthusiast.