Lower Gas by Removing COMP Auto Distribute!

Ideas
1

We’ve kicked around this idea before (Robert suggested it) and I think it’s time to do it.

My understanding is removing COMP auto distribute would save approximately 40k gas. That’s a meaningful amount! I can’t think of any dependencies removing this would break so downsides are ???

@jared do you have any thoughts on how difficult or risky it might be to make this change?

Mostly I think we just need to pay someone to do the work! Assuming it is fairly simple perhaps we consider a $2,500 bounty?

Right now we are averaging ~800 deposits / withdrawals per day (as evidenced by Comptroller COMP daily transfers). So 800 x 40,000 gwei = 0.032 ETH per day that would be saved by removing this function.

1 Like
2

The easiest thing to do is just raise the threshold from .001 COMP to e.g. 1 COMP. It’s a constant, so it would require a Comptroller upgrade, but otherwise should be extremely safe and easy as an isolated change. Some tests may require updating.

2 Likes
3

This is a joke, isn’t it? So there is a plan to remove COMP autodistribute so user can save 40k GAS per transaction, so in order to actually claim COMP user would need to pay 500k+ GAS by utilizing collect function instead of much much cheaper supply/borrow transaction? So much for savings indeed. Unless claiming COMP function would use like 100k GAS i think removing auto-claim doesn’t really sound awesome.

800 x 40000 metric is useless, as what matters is savings per user. If every user saves very little per transaction, but probably would end up paying more by having to use more gas-intensive function, and protocol itself isn’t actually gaining anything, doesn’t sound like much of optimisation to me.

On the other hand, raising threshold from 0.001 to at least 0.01 and maybe even something between 0.01 and 0.1 to not really waste a gas on every penny of COMP able to be claimed, sounds reasonable.

I guess there’s pretty much nobody wanting to pay 40k gas additional to claim 0.001x100 = aprox about 0.1$ valuation of COMP, as user actually lose money on that operation. 1 COMP threshold might be too big for many users though, i’d suggest something lower, like 0.1 COMP or maybe even 0.05 COMP.

EDIT: What would be really nice though, if there would be a checkmark for user to include auto-claim in transaction or not. Like if switch is TRUE, then include autoclaim, if it’s FALSE, then skip it and proceed without auto-claim. I think that solution would be the best way to go.

4

Claiming COMP in general does not cost 500k Gas. I recently claimed COMP on one of my addresses for 150k gas. I believe that the gas savings for completely removing COMP auto-claim would be well worth it.

The incredibly gas intensive claimComp operation claims COMP for all Compound markets. An optimized frontend would not call that function–rather it would call more specific claimComp functions which can only claim COMP for certain markets.

1 Like
5

Well, maybe it cost 150k gas for you, but when you press claim it requests gas limit of over 900k, which while might not use all 900k, but it’s definetly cost multiplies of what it cost by using auto-claim via supply/borrow transactions. So in general, it will surely cost more for pretty much every average Joe out there.

And yes, i’m against removing that feature, because with it being absent it becomes more expensive to claim COMP. And while it might be less efficient for me, as not every interaction with compound actually need to use gas for claiming, it’s still cheaper overall, than what original post suggest by completely removing it.

Again, if someone thinks he would be better without, fine. But there are other people who think they are better with, and i bet there are more of the second ones.

Of course, it doesn’t mean that threshold shouldn’t be changed, as claiming dust amounts of COMP benefit nobody and it was set too low indeed. Optional claim would be best feature here really. Or separate function which could be called for individual market, as you mentioned. But that thing isn’t there yet, so that talks about let’s remove cheap way of claiming right now is actually sounds like let’s reduce COMP distribution rate, because we might use it for something else in future. Ok, COMP distribution reduced, nothing appeared. :slight_smile: Don’t anybody think it’s strange way of making changes? Why not implementing certain market claim function first, and then can remove auto-claim as not anymore needed feature. Cause right now i prefer paying little extra gas for every transaction, rather than having to use claimComp function and paying several times more. And hoping that some day, over a horizon, might come a time, where a cheaper claim function would exist. And all of that for mighty savings of like 0.5$ per compound interaction transaction.

Don’t get me wrong here, though, i might sound a bit saulty as that suggestion planning to make interactions with Compound more expensive for me, rather than cheaper, but i’m all for improvements, when it’s actually an improvement. That idea, isn’t a clear improvement. At least not yet, not here and now as protocol and frontend exist today.

6

The protocol already has the code implemented for cheap COMP claims. Look at this function. It costs about 150k gas to call it for one market right now. I’m sure that if we remove the auto claim feature, the compound frontend would quickly implement an optimized version of the claim button.

2 Likes
7

Thanks for link. It’s good news for me, indeed.

That solves major objection, but you see, thing is it’s still 150k, vs 40k addition to regular transaction. Which surprisingly makes auto-claim feature more efficient option when it is desired. Now if we could have this auto-claim code execute optionally, rather than always, with default being disabled, that would be a nice improvement and a middle-ground. Cause surely, if you plan to do supply and claim transaction and can pay additional 40k to do it in one transaction, rather than making separate transaction it would be more cost effective.Don’t you think removing existing, but useful for certain users in certain situations code might be not exactly best way in the end?