Wallet-to-wallet trading is a feature of decentralized exchanges where an asset can be transferred directly from one user’s wallet to another user’s wallet within a single transaction. This is an important feature, but, I believe, often misunderstood. Rather than being primarily about security of funds (since this can be achieved in other ways), the true benefit lies elsewhere.
Approvals
The ERC-20 token standard is an interface to tokens on the Ethereum blockchain. It specifies the functions that a token must implement in order to be compatible with the Ethereum ecosystem.
The totalSupply() , balanceOf() , and transfer() functions allow users to, respectively: read the total number of tokens that exist, check how many of these tokens an address owns, and send a portion of their tokens to another address.
In this article we’ll focus on the other set of ERC-20 functions: approve() , allowance() , and transferFrom() . While transfer() provides a way to “push” funds to another address, sometimes instead you would like to authorize someone to “pull” funds from your address using transferFrom(). This can be accomplished by calling approve() with the address you are allowing to pull, and an “allowance” of how much they are allowed to pull (but be careful about double withdrawal attacks).
If you approve() a regular Ethereum Externally Owned Account (“EOA”), it is entirely up to the owner of that account’s private key if they would like to pull funds. At any time they could withdraw some or all of the allowance, and you don’t necessarily have any insight into why they are doing this, or have any ability to add extra conditions or restrictions on them. Effectively, this is the same as if you had just sent them the funds with transfer() , except that you have a possibility to “claw back” the funds by reducing their allowance — so long as you get to it first!
Smart contracts
Ethereum is used to its full potential when we approve a smart contract address, rather than an EOA. By using a contract, rules and conditions can be added. For example, the EtherDelta token exchange requires that you approve() its smart contract to grant it access to your tokens prior to making an order or trade.
Before approving it, you should carefully review its verified source code. When you do, you will see that (excepting any bugs or backdoors) it is impossible for the contract, or anyone else, to pull your tokens without in turn providing you another amount of tokens in exchange, and the terms of this exchange are controlled by off-chain signed messages that you and only you are able to create.
So, as long as you are confident in the smart contract’s implementation, despite approving another address you still haven’t given up control over your tokens. If an issue is noticed with the smart contract, you can always send an Ethereum transaction to reduce your approval and hope that your transaction is mined before the issue is exploited.
So this is great, right? No third party ever has custody of funds, and token exchange can only happen given certain rules encoded in a smart contract. Yes, but this is only incidentally related to wallet-to-wallet trading, as we will explain in the next section.
Deposit contracts
Our SportCrypt smart contract has on occasion been criticized because users must deposit their ETH into our contract, rather than allowing it to be traded wallet-to-wallet, which is assumed to be more secure.
The reason we built it this way is because ETH is not an ERC-20 token, so it doesn’t support approvals, and our contract was created and deployed before Wrapped ETH came into common use.
But is the way SportCrypt does it actually less secure? As with wallet-to-wallet trading, before you deposit to SportCrypt you should carefully review its verified source code. You will see that (again, assuming no bugs/backdoors) users can deposit/withdraw their balance at any point in time by sending Ethereum transactions, and that any access to their balance by other parties can only be via signed messages, similar to EtherDelta.
So in summary, with both wallet-to-wallet and deposit contracts:
- You must review that a smart contract is written securely, with no bugs or backdoors
- At any time you can credit your balance, either by approving (wallet-to-wallet contracts), or depositing (deposit contracts)
- Nobody can stop you from getting sole access to your funds, either by reducing the approval (wallet-to-wallet contracts) or by calling withdraw (deposit contracts)
- Funds can only be transferred between users according to rules set out in the smart contract
An actual benefit of wallet-to-wallet trading is that you can see your token balances in your wallet software, up until the time they are “pulled” by an approved contract. But even this is sort of an illusion. ERC-20 token balances don’t actually live in your wallet, they are just entries in a smart contract, similar to a deposit contract. Your wallet software has been specially implemented to check balances in various token contracts, and in principle it could do that for any type of contract, including a deposit contract like SportCrypt, although of course with standards tools like wallets can work together more easily.
Contract upgrades
Some contracts, notably 0x protocol version 2+, support upgrading the contract without requiring users to approve() the new code. To some extent this negates the trust-less purpose of smart contracts: Even though 0x’s contract implements wallet-to-wallet trading, the 0x development team has the ability to modify the contract without your permission. In principle, even if you diligently reviewed the 0x source code at the time of approval, they could later add a backdoor, defeating the no-custody feature that makes smart contracts so special.
That said, the 0x protocol contract requires that the developers give at least a 2 week warning prior to upgrading, which is a balance between granting developers the ability to improve the protocol, and giving users a chance to review the proposed modifications. The down-side for security-conscious users is that they need to constantly monitor the 0x contracts to see if new code updates have been proposed.
The true benefit
So, wallet-to-wallet trading is not inherently more secure than depositing into a smart contract (in fact, a token is a smart contract), and does not necessarily guarantee that third parties cannot steal your tokens (if an approved contract has a bug or backdoor, or is upgraded to one that does).
The real reason that wallet-to-wallet trading is important is that multiple smart contracts can be simultaneously approved access to the same funds.
Although not perfect, the ERC-20 standard is implemented by many tokens, and used by diverse sets of smart contracts. So, as a user, you can use the same tokens to participate in several systems at the same time.
Why would you want to do this? Capital efficiency. Suppose you would like to make markets in 5 different illiquid markets, by offering to either buy or sell up to 100 DAI on each. If every order required full capital commitment, you would need to lock up 2*5*100 = 1000 DAI for as long as you want to keep these markets open, even if trades happen very infrequently. However, if a system is designed to allow collateral to be shared between all orders, you only need to lock-up 100 DAI, with the understanding that if somebody fully takes one of your orders, all the others will be suspended due to lack of funds.
By taking advantage of the ERC-20 approval mechanism, you can even share collateral between different smart contracts. For example, suppose you wanted to make markets on both EtherDelta and 0x protocol. Rather than being forced to lock-up collateral on each system separately, as you would with a deposit contract, wallet-to-wallet trading allows you to use a single base of collateral for both, even though the two smart contracts are implemented quite differently.
Degens and SportCrypt
As described above, SportCrypt uses a deposit contract. With the next iteration of our system, called Degens, we are switching to a wallet-to-wallet model. This is not for security reasons — both SportCrypt and Degens will have equivalent custody-free security properties — but for the capital efficiency reason described above.
In addition, SportCrypt and Degens both have features to make collateral even more flexible, some of which we wrote about previously. The Degens protocol will also support something we call order groups, which gives market makers more control over how their collateral is allocated. We will be releasing full details on this shortly, stay tuned!
