DAI in the hands of all— You can now send DAI without paying Ether gas fees.
TL;DR: We built a gasless non-custodial DAI wallet that allows you to send DAI and pay transaction fees in DAI instead of Ether. You can get it on Android below or follow @LamarkazLab on Twitter to be notified of the iOS release.
Ether gas fees are every token holder’s problem.
Different proposals attempted to solve this problem for years. One popular method to achieve gasless (without Ether gas fees) token transfers is known as meta-transactions, a layer 2 architecture that allows you to delegate the payment of Ether gas fees to someone (called a relayer) while you pay them in any token.
While this sounds great in theory, in practice, proposed meta-transaction architectures have lacked the ability to on-board users without a first step that would still require Ether. To work around this problem, EIP proposals created new token standards that support meta-transactions natively but require token contracts to be migrated.
Ideally, we can have a solution that:
- works with existing ERC20 token contracts
- requires no user on-boarding process or UX trade-offs
- doesn’t expect users to own Ether, or even know of its existence
- keeps users in custody of their tokens
Thanks to the recent Ethereum Constantinople upgrade, we have found an architecture that checks every item on the list! And we’ve implemented it on the mainnet in Metacash — a gasless mobile DAI wallet.
Smart Wallets + Meta-transactions
Back in January, we published a proposal on EthResear.ch describing an alternative wallet architecture that combines meta-transactions, smart contract wallets, and the new Ethereum Constantinople CREATE2 opcode to replace the Ethereum external account model (i.e. accounts controlled by private keys).
The problem with external accounts is that they’re not programmable unlike smart contracts. Consequently, users cannot set custom rules for their accounts. Replacing external accounts with smart contract wallets (we’ll call them smart wallets, for short) allows the full flexibility of smart contracts at the account holder level. The smart wallet would only execute its owner’s commands via signed messages from the owner’s external account. Additionally, we can set new rules. Think daily withdrawal limits, two-factor authentication, account recovery mechanisms, Last Will distribution mechanisms, privacy through account mixing, and more features that we may have not yet imagined!
And if a smart wallet holds your tokens, then we can also put meta-transaction functionality at the wallet layer instead of the token contract layer. In this case, relayers interact with each user’s contract to execute their transfers, instead of interacting with token contracts. This allows Metacash to work without upgrading existing token contracts or replacing the ERC20 standard, fulfilling the first requirement on our checklist.
‘Who deploys the smart contract that represents "you"?’ — u/Fermi_Amarti
The idea of smart contract wallets isn’t new. Projects such as Gnosis Safe and Parity Wallet already use this model to provide safety features for Ether and tokens that are simply not possible under the external account model. The one big problem with smart wallets is: who deploys them? Of course, users could do it directly, but they have to pay Ether gas fees, which defies the purpose of meta-transactions.
Meta-deployments
There needs to be a way not only for users to use meta-transactions after their smart wallet is deployed on-chain, but first to be able to deploy the smart wallet itself through a meta-transaction. Ideally, this meta-deployment architecture should make no trust assumptions about both the user and the relayer.
This is where Ethereum Constantinople’s new CREATE2 opcode comes in. In a nutshell, CREATE2 allows smart contract addresses to be generated off-chain before they’re deployed. You also get a guarantee that only a contract with a specific bytecode can be deployed to this address in the future, whether by you or someone else (a relayer, maybe).
In our architecture, the user generates their smart wallet addresses off-chain in the wallet client. And thanks to CREATE2, the user can assume that it is safe to receive tokens at this address even before the smart wallet is deployed on-chain. After receiving tokens at their smart wallet address, the user can then send their first token meta-transaction AND meta-deploy their smart wallet in a single action through a relayer. Each user’s first transfer goes to a previously-deployed smart wallet factory contract which executes the following:
- Creates the smart wallet contract on behalf of the user
- Requires the smart wallet to send the user’s transfer to the recipient
- Requires the smart wallet to pay a fee from the user’s tokens to the relay
Beyond this point, future meta-transactions interact directly with the newly-deployed smart wallet. This is the reason why you’ll find that the first transaction on Metacash is always a little more expensive in terms of DAI fees than each time afterwards.
Since this entire process is done without the user ever obtaining Ether and without changing the user behavioral model, requirements 2 & 3 are now checked off on our list.
Relayer trust model
You can’t try Metacash for the first time without feeling at least a little skeptical about it. After all, custodial wallets and exchanges already allow their users to send DAI and many other ERC20 tokens while taking their fee in the token itself instead of Ether. And the Metacash user experience can feel similar, if not identical, to a custodial wallet. So is it really non-custodial or is there a catch?
The factory and smart wallet contracts regulate the relationship between you and the relayer. Both are open source and verified on Etherscan.
The factory verifies your digital signature provided by the relayer in order to make sure that the relayer doesn’t deploy your smart wallet without your permission. It also ensures that the relayer fee and the gas price were authorized by you.
The smart wallet verifies your digital signature provided by the relayer in order to ensure that the token address, the amount, the recipient, the relayer fee, the gas price and the transaction order (nonce) were all approved by you.
What happens if the relayer decides to censor you or simply goes down? Both the factory and the smart wallet allow a direct transaction option. In case of censorship or relayer downtime, you can still access your funds by sending a normal Ethereum transaction and paying fees in Ether. The relay cannot freeze your assets or censor your access, it can only censor convenience.
Since the relayer cannot use your wallet or tokens without your permission or censor you/freeze your tokens, then we’ve checked off the last requirement on our checklist.
1 user = 1 contract? Wouldn’t that bloat the Ethereum storage?
Deploying the entire smart wallet bytecode for each user would be very storage-redundant. It would also add significant gas cost to the initial smart wallet deployment for each user.
We solve this problem by using the DELEGATECALL opcode. This allows us to deploy a singleton smart wallet implementation contract that is used by all users.
Each user only deploys a significantly smaller contract that inherits its functionality from the singleton implementation contract, reducing most of the Ethereum storage redundancy and deployment gas cost for each user.
Built-in upgradability: No more token standards
In Metacash, smart wallet contract upgradability comes as a by-product of using DELEGATECALL. Each user can change the address of the singleton implementation contract that their smart wallet is using, which allows them to upgrade for new features. No smart wallet address change, no contract deployment costs and no token swaps. Of course, upgrading can also be done in a gasless meta-transaction.
This creates a new standard for token standards that follows a principle of user-activated upgradability rather than developer-activated upgradability.
Instead of having no choice but to wait for each token’s developers to implement a feature, we can have permissionless improvements.
Instead of new token proposals going through governance processes and lengthy debates among every token’s community, we can have individual opt-ins for improvements.
Instead of creating token standards, we can create smart wallet standards.
Almost every feature that a token standard can add to a token, a smart wallet can add to every token — regardless of whether it was implemented by the token’s developers. Individual users can opt-in for different smart wallet implementations that follow different standards.
Third-party developers can add new token features that users can instantly use with all of their favorite tokens, without taking anyone’s permission.
What the future may carry
The potential benefits of the smart wallet architecture greatly over-weigh simple gasless meta-transactions. We argue that this new ability to program wallet accounts in the form of smart contracts has the potential to create completely new possibilities, and especially, in the context of wallets.
We have a few ideas on our list for DAI:
- Custom daily withdrawal limits to minimize risk of theft
- Timelocked social recovery mechanisms against theft, client attacks & wallet loss
- Timelocked proof of death to enable Last Will distribution
- Ethereum subscriptions
If any of these ideas sounds like a must-have for you in a Metacash update, or if you have a better idea, let us know on Telegram.
Download Metacash
Metacash is fully-functional on the Ethereum mainnet today. You can use it to send DAI to anyone while paying transfer fees in DAI itself, instead of Ether.
The app is currently available on Android below. If you’d like to be notified of the iOS release (coming soon), stay updated using the links below.
Get in touch
Metacash is still in its infancy, and we’re very eager to know everyone’s feedback, ideas, comments & feature requests.
Please feel free to get in touch with us here:
