TL;DR
Today, we’re excited to reveal a little hack that we use to save our customers potentially millions in EVM sweeping fees through a Function Overload technique (of sorts). It enables custodians to get rid of the requirement for a per-user address, and as a result, they can process on-chain custodial deposits without paying a penny!
This pattern is implemented on Map3’s Open Source Payments SDK. You can join the Alpha here:
Personal Story Time
In 2019, I spent one of the most fun summers of my life building Monolith.xyz with hackers like @mischat @hiddentao @yanstam and others. Monolith offered at the time a world first: an on-chain smart contract wallet with advanced security features but with a consumer-grade UX. It also links to a Visa card, so folks can spend directly from the Wallet at the point of sale.
We learned a hell of a lot in optimising gas savings. This enabled us to offer the service for free to consumers without compromising on security or the transparency benefits of doing business on-chain.
BUT. Defi Summer came a year later, creating the need for us to keep innovating on gas savings. Since then, I’ve been fascinated by cutting-edge gas-saving hacks that don’t compromise security.
Deposit Sweeps Burn a lot of Money
Every time an end-user sends a crypto deposit to a custodian, they send it to a unique per-user address. This is so that the custodian knows who to credit the money to when they see it on chain. The problem arises after the deposit is credited.
The custodian has to be able to spend that money to be able to fund customer withdrawals. In the case of Ethereum Virtual Machine (EVM) ERC-20 tokens, it requires that address to already have some ETH to pay for gas before sending it out. This makes it so that the custodian has to send some ETH to it in a separate transaction and finally make a third transaction to get it out.
In his recent email to customers, CZ goes over this setup at Binance in detail. We liked it so much that we even reposted it as a blog post.
Two on-chain transfers to claim every deposit
In the case of transferring the native network token (ETH), only one transfer is required. Networks like Bitcoin make this even easier by enabling money to come from different inputs in a single transaction, enabling batching. However, input mixing is not possible on EVM networks.
This problem leads crypto service providers to set high minimum deposit and withdrawal thresholds. It also raises fees for everyone withdrawing money, as they offset deposit sweeping fees with withdrawals. Finally, this leads to network congestion for everyone as, unlike withdrawals, these transactions cannot be batched.
Introducing Gasless Sweeps for EVM
How could we do the same for Ethereum and ask every customer to send money directly to a single holding account shared by everyone? How could we take advantage of the same tools that networks like Ripple, Stellar and Stacks employ for scaling?
The simplest way is, of course, to take advantage of ETH’s input data field by attaching some custom bytes to a transaction. Here’s how it would work for an ETH Transaction:
We can then use those unique bytes to associate the on-chain payment to a customer. Here’s how it would look on-chain.
This is simple for ether plain transfers as they do not require the sender to attach any data. Most explorers end up displaying a ‘0x’ value when there are empty bytes on this field.
Scaling to Contracts via Function OverloadIsh
However, as mentioned, most fees are burned by sweeping ERC20 deposits as they require an additional transaction. So how can we solve this?
Let’s look at the transfer() function on the ERC-20 contract interface.
It turns out that we can also attach a few extra bytes to the transaction in a way that is compliant with processors.
1Function: transfer(address dst, uint256 wad)
2
30xa9059cbb000000000000000000000000d8da6bf26964af9d7eed9e03e53415d37aa9604500000000000000000000000000000000000000000000000000005af3107a4000666f6f6261720d0a
4
Note that we are essentially passing in an extra parameter. The final parameter of the function (666f6f6261720d0a) is the hex representation of the string ‘foobar’.
Using Custom Txs via Payments Protocols
The problem with this method is that it requires Wallets to create a non-standard transaction.
Payments Protocols to the rescue!
At Map3, we take advantage of protocols such as Ethereum Provider to ask the user’s Wallet to perform a signature. Our SDK calls the eth_sendTransaction function, passing in the required data.
In this payload, we attach arbitrary data AT THE END of the ERC-20 transfer function. This is supported by the EVM while remaining compliant with the ERC20 events emitter that processors rely on to identify ERC20 transfers.
Scaling Wallet Interactions
Map3’s open-source payments SDK enables custodians to access this functionality and supercharge their deposit screens. We integrate with the top Wallets to make it easy to process ultra-low-cost deposits securely and with a great User Experience.
If you’re a custodian, you don’t need to worry about maintaining or QA’ing these integrations. In addition, we provide live transaction detection and native asset bridging to let users pay in their preferred chain. All without the need to make any backend changes.
If this is something we can help you with, please let us know by signing up for our Alpha.
Future Work: Making this Work for plain old addresses
We understand that this only works if the sender supports custom payment protocols. Exchange withdrawal forms, for example, would not work for this.
Map3’s Enterprise Plan supports collecting money from the world’s top Exchanges (Binance & Coinbase) via a familiar OAuth interface. We help custodians identify the payment using off-chain tracking.
One thing that we also explored is adding a parameter that is compliant with Eip-681 QR codes and URIs. This could be something like ‘String=MemoToTrack’. While we have not discarded this solution, it would not solve the problem for traditional web forms, so we have defaulted to OAuth.
We are curious to hear your feedback on this! We estimate that this would save hundreds of thousands in daily fees for the entire ethereum network if widely adopted.
Please let us know your thoughts by grabbing some time with us or responding on Twitter or Hacker News!