FOXy claims borked

[purelycrickets]

Overview

Currently in when a user attempts a claim of a withdraw of FOXy, the transaction posts to chain successfully, but no FOX is ever sent to the user. Users will be prompted to continue to perform claim transactions and can continue loose money on gas with no further actions taking place.

References and additional details

This has been reported by at least 2 users and Willyfox today in Product_public_chat: https://discord.com/channels/554694662431178782/885616186623148062/1210961077156839505

Support reported User's address: https://etherscan.io/address/0x6ceac6f65170e432242a34560b1929a48deb34f2 User performed 6 withdraw attempts attempts unsuccessfully. User claimed they were able to finally fix the issue on the final transaction by adjusting the gas manually, " The gas fees were too low during the failed attempts…" and "It was on auto, I just tried it again - at a higher fee - and it worked fine."

Willy's failed attempt: https://etherscan.io/tx/0x95bf354d794409024c908160d7e84ba6b9d23f7ecc8223d8a07d97639b95c98a

Willy's withdraw request: https://etherscan.io/tx/0x7901b5a8d8cd4b27ff334037d2631aeb14548aa3a8d755d9c381ac6029ca7132

I assumed it might have to do with the gelato resolver (task ID: 0x110e5b2aca53da5d1bbaef18dab0c6d384fb3d97f515e40bcf285cbb212eb214) set up for the FOXy contract. It did need to be refunded, but the errors have continued even after the resolver has enough funds to execute calls.

Acceptance Criteria

FOXy withdraw claims successfully send FOX to users who claim them.

Need By Date

No response

Screenshots/Mockups

No response

Estimated effort

No response

[0xean]

Some info on this guy,

Willy tx has to wait until epoch 110

Current epoch is 109

I believe a simple call to rebase() will roll over the epoch which expired on block 19290566 and allow willy's TX to succeed.

I am not super familiar with what the gelato task does (perhaps simply calls rebase?) but most likely this hasn't been happening or was missed.

Before I manually call rebase() and confirm @purelycrickets how can I see they gelato task?

[0xean]

https://etherscan.io/tx/0xa26102457251eeb0a6d1b93fc30eb73b970bf35572444ddd9f7837283721c16b

Went ahead and called rebase, which updated the epoch to 110 which should allow for @willyogo to claim. This makes me pretty confident the bot isn't working to roll over

[0xean]

@purelycrickets - before we close this ticket lets take a look at the bot to determine whats failing.

[purelycrickets]

This is still an outstanding issue with new users reporting the bug every week. Would love to get this prioritized at some point post LP.

[0xean]

@purelycrickets can you please provide information on the bot? As far as I can tell that is currently the point of failure and manually calling rebase solves the problem.

[purelycrickets]

Here is the bot: https://legacy.app.gelato.network/task/0x110e5b2aca53da5d1bbaef18dab0c6d384fb3d97f515e40bcf285cbb212eb214?chainId=1

This resolver was set up by @toshiSat I do not have much more information other than I have seen users report failures when the bot has funds. I have topped off the resolver again. It appears to be going through funds faster than it had previously.

[purelycrickets]

I am aware that it is a legacy function and will need to be migrated before June 30th.

[0xean]

Yea, its pretty clear that something has changed here. Calls were executing every week and are now not executing on any reasonable cadence. Most likely this has to do with the migration going on with Tokemak.

Are you currently in contact with a user who is unable to claim? Can you provide their address in DM so we can debug like we did with willy?

Most likely we will need call rebase on the contract and that should solve the problem again temporarily. The solve might be having the bot call rebase since the functionality with tokemak is actually what is borked at this point it seems.

[purelycrickets]

After directing a user through the manual rebase, they were still unable to receive their FOX.

Most recent attempt: https://etherscan.io/tx/0xae8eb9ae03caee12abed6762e8c802b244d52b930e1b9bd0411db29ccb9476e6

We now have quote a few users stuck in the same scenario and a developing queue of transactions that should be refunded for gas.

Is there anything else Support/Ops can provide in this issue to escalate and address accordingly?

We have MetaMask warning users that try to withdraw FOXy that it is a deceptive request. (not sure if this is due to this underlying issue or not and if there is anything we can do to change that.)

I do not feel confident in sending future users to manually rebase outside of ShapeShift and assuring they have performed the the action successfully.

[0xean]

I dont understand why a user was directed to do this?

[purelycrickets]

Is there anything else Support/Ops can provide in this issue to escalate and address accordingly?

[purelycrickets]

I dont understand why a user was directed to do this?

I guess I misunderstood our DM? I was under the impression that each user would have to rebase manually before they could receive their funds.

I communicated with you that: "I will share this with all of our affected users and keep it handy in a canned response for future issues." when given the communication "<- this is the same issue that willy had. You should be able to manually call rebase on the contract and the user should then be able to claim"

I understood the "you" in your message to be the user or Willy in your example, as I did not perform the manual rebase to unstick Willy's FOX but he was able to get his funds.

[0xean]

Okay.

Let me try to be as clear as possible.

The flow for removing assets from foxy entails normally 2 steps.

1. User calls unstake
2. After waiting an epoch the user than calls claimWithdraw which transfers them back their fox

Currently, the gelato bot is not correctly rolling over the epoch, this can be manually done by anyone by calling rebase which means that occasionally, a user has waited long enough, but still cannot call claimWithdraw and get back their FOX.

The solution to this for the time being is once the requisite time has passed, anyone can call rebase to roll over the epoch and allow the user to claim their FOX.

even when this occurs, a user still then needs to call claimWithdraw to get back their fox.

To debug a users transactions please follow these steps:

1. Did the user already call unstake? A. No - have them call unstake B. Yes - did they already call claimWithdraw?
   1. No - confirm that the cooldown period has expired (instructions below) and that the epoch has rolled over (instructions below), if so then have them call calimWithdraw
   2. Yes - Did they recieve Fox? A. Yes - all done! B. No - confirm that the cooldown period has expired (instructions below) and that the epoch has rolled over (instructions below), if all if that has done, simulate tx in tenderly using recent block to confirm it works and fox is transferred and then ask them to do it again

How to check the epoch and if it can be manually rolled over

Go to https://etherscan.io/address/0xee77aa3fd23bbebaf94386dd44b548e9a785ea4b#readContract Click on epoch and query

Has the endBlock of the epoch passed the current block? if so, then rebase can be called to advance the epoch!

How to check the cooldown period for a user

Go to https://etherscan.io/address/0xee77aa3fd23bbebaf94386dd44b548e9a785ea4b#readContract

and click on coolDownInfo

and type in their address

If they have a pending withdrawal their will be cooldownInfo for their address and the expiry is the epoch that their withdrawal will become available. Refer to above to check if the epoch can be rolled over and their claim made available.

[0xean]

Closing this issue currently as we have manual steps in place to deal with this as we wind down