In regard to Jump Counter-Exploit, please upgrade Token contract to allow rescuing of ERC20 like USDC

[BlurayDisc]

Description and context

First and foremost, congratulations on successfully recovering $225M of assets in stolen funds using an upgradable proxy contract on Oasis AutomationBot contract.

A similar approach of using upgradable proxy contract can be implemented here to rescue assets trapped on wormhole contracts, for example ERC20 tokens.

Implement a rescueERC20 function with appropriate AccessControl (i.e. assigning 'rescuer' role to the deployer or owner) and upgrade exiting Token contracts.

Main take aways being:

• Jump Crypto used similar approach when itself was at stake or being the party with assets stolen or trapped, therefore users should share equal rights over their prvilledge and ownership of their assets like Jump.
• During the counter-exploit, out of the 5 address (Oasis Multisig, Holder, Sender, Jump1 and Jump2) has 3 addresses owned and controlled by Jump crypto, therefore the previous take on the 'decentralized nature' of Token contract is now completely nulled: reference
• During the counter-exploit, "The Sender was an eligible signer for just 1 hour and 53 minutes", exact same approach can be used here to only temporarily assign the role to a particular address then revoke its permissions.
• Obtaining a court orders for all retail users is not something realistic, especially when the fund trapped in question is less than the legal proceeding fees.

The immdiate contract in question is: UST (Wormhole) on Polygon

• Implement rescueERC20() function and upgrade existing contracts.

• Perform the rescue function on the USDC token and send it back to the From address, for example in the following transaction: https://polygonscan.com/tx/0xebfd49c3e07318fdd42e9cba2cbb84f416848d1f727d4d2e936c707a99dbe866
• Try recovering the trapped 2908 USDC tokens for the 0x079889be5712906ed6d4b745b6bd4d9cf683b81f address.

Definition of done

Token contract allows trapped funds/assets to be recovered.

Lastly, congrates again on recoving of the stolen funds. Hope you will demonstrate professionalism and good will here for other users in the same situation.

[kcsongor]

Hey, thanks for the detailed writeup and providing context!

I'm going to focus on the technical content of your proposal, as I'm not familiar with the details of the Oasis protocol or any ongoing litigation.

Jump Crypto is one of 19 guardians that govern the Wormhole protocol, and any protocol change requires a supermajority (i.e. 2/3+) consensus of the guardians, so any potential way forward will require the guardians to agree, and not something that an individual entity can single-handedly decide.

With that being said, here are my personal thoughts on the proposal:

• Currently there's no precedent for an individual having special permissions within the protocol. All functions are either permissionless (callable by anyone) or gated by governance (require the guardian multisig). To maintain these assumptions, the rescuer would need to be the guardian multisig.
• Rolling out non-trivial changes to critical components typically requires external audits (here's a list of previous/ongoing security audits https://github.com/wormhole-foundation/wormhole/blob/main/SECURITY.md), so we need to understand the relation between the recoverable funds and the security cost of external audits + maintenance burden.
• The proposal talks about adding this functionality to the token contracts specifically because that's where funds have erroneously been sent to, but in general it sounds it would be desirable for any contract to support something like this. The issue is that for contracts that otherwise expect to hold a particular token, it would not be good to allow an individual to arbitrarily send those funds elsewhere. Instead, it sounds like this is something that would be better suited for an ERC proposal.

[BlurayDisc]

Thanks for your response.

A few more examples I should have provided:

• https://etherscan.io/address/0x418d75f65a02b3d53b2418fb8e1fe493759c7605#tokentxns
• https://etherscan.io/address/0xd31a59c85ae9d8edefec411d448f90841571b89c#tokentxns
• https://etherscan.io/address/0x85f138bfee4ef8e540890cfb48f620571d67eda3#tokentxns
• https://etherscan.io/address/0xa693b19d2931d498c5b318df961919bb4aee87a5#tokentxns
• https://etherscan.io/address/0xbd31ea8212119f94a611fa969881cba3ea06fa3d#tokentxns

This should answer your point in regard to security audits, afaik security audits cost a few k(s) and up but the above token addresses have more than 1 million worth of retail user worth of tokens/assets trapped under wormhole's Token addresses.

Yes, you could argue both meta mask and ERC20 should have prevented this from happening, more discussion here:
WETH10/WETH10#94

Back to the topic of the existing fund being stuck on Token contracts which are upgradable proxy contracts. Yes, the rescuer would be the guardian multi-sig from the sound of it. On cheaper chains like polygon pos where the rescue operation is relatively low cost, you guys should just send the trapped tokens back to each address to show a form of goodwill after the Jump incident. For the Ethereum blockchain, there should be a type of form (Tally or Typeform) for retail users to fill and forfeit a percentage of the trapped fund as rescue operation cost, how ever you guys deem it's sensible to charge the fees.

[BlurayDisc]

Hi @kcsongor,

Coming back to this topic, USDC appears to have implemented a FiatTokenV2_1 upgrade (on Jan 26, 2021) here:
circlefin/stablecoin-evm#317

The solution seems rather simple, it performs a one-time 'rescue' operation to existing token addresses, sends the 'stuck' fund to a nominated address and you do not need to deal with things like rescuer role which is counter-intuitive to the decentralised natural of wormhole.

It also prevents future funds being miss-sent to the token contract by using it's internal 'blacklist' mechanism, again it's rather neat + straightforward.

I hope your team can go through the old and existing wormhole smart contracts deployed on all major chains and analyse the sum of all stuck / miss-sent funds, because the amount is substantial:

1. CRV tokens worth $601,449.40 on date of transfer:
   https://etherscan.io/tx/0x7bffde888c21b10a724afc848da0f571bddba4a35c0cb9982121d1beb69eb948

2. USDC tokens worth $99,974.30:
   https://etherscan.io/tx/0x34774a3226043810a2c54d95d0ed7dff0fb200f312f56f8260a71af672cdafff

It is very risky to leave the stuck tokens in an abandoned token contract (UST) which had already depegged, please consider this alternative approach.

[BlurayDisc]

Congratulations on the $W token launch.

Are there any plans to use some of the resource from the token launch to work on old/backlog issues like these?
Revisiting this again after 1 cycle 😴

Kind regards.