It is possible to transfer tokens to multiple addresses in a single Ethereum transaction using a smart contract.
This transaction is more expensive than a single transfer, but contains multiple, so the cost is shared and (hopefully) lower.
Batch transaction: 4,276,346 gas for 300 -> 14,254 gas / transfer (-61%)
It appears that adding multiple transfers in a batch reduces the transaction fees by around 50%.
I was honestly expecting a much larger difference (like 1/10th the cost), but 50% is not bad.
However, I don’t think this is a viable long term solution (considering how fast the fees changed in the last 2 months), as the fees would still be quite high even then.
Good research! TBH, I would a priori expect the cost to half under assumption that roughly half of the time is spent on processing input, half on the output of a 1-to-1 transaction. Also, this would be the case in BTC, which I am more familiar with.
Still, I suspect that even halving the cost might be worth it given the scale of payments so far. December payments were roughly equivalent to about 75kUSD, and if the threshold of 25% is maintained, that would be additional 12.5kUSD in transaction costs monthly.
I had a multisend contract as a PR open. The savings are actually comming from the 21K base gas for a transaction. If you batch 2 STORJ transactions into one transaction you pay the base gas only once and not twice.
Don’t ask me why we are not doing it. All I know is that zkSync is way cheaper. That might play a role here. With a multisend contract we still end up paying too much.
Still going to ask you
Maybe someone who knows the answer will see and comment.
Making zkSync work will take some time, then there will be an opt-in period, and then some people will opt out regardless because of L2->L1 withdrawal fees. There’s no reason to not go with batched payments in the mean time.
It is quite the oposit. Integrating zkSync is easy. We just generate a second CSV file and hand that over to zkSync. They can process that. In parallel we are also looking into Loopring. The implementation on our end is generic and we could work with both solutions.
For a multisend contract we would have to change our transaction handling. Geth and Parity are just a nightmare when it comes to that. We have to deal with some amazings bugs that we haven’t even thought about. I am very happy that our current payout script can handle these bugs. Changing the payout script would take some development time and that can get more expensive then the expected costs savings.
The best chance I see is when we would have some kind of third party payment processor that can handle it for us. We hand over our CSV file and don’t have to deal with all the bugs. That is something that might work.
Batched transactions could keep the min payout at January levels. On top of that, if there’s some timing and payout happens when gas price goes down a bit, you could bring the cost of individual payment from $16.2 to $3.9.
