Transparent couple of burns wallet/main wallet to protect against smart-contract scams

Feature Requests
1

Description:
Make automatically two accounts at creation, one which will be used for spending operations (sending tokens, signing, executing smart-contract operations, …) which would be hidden, and one which will hold the assets.

When the user do sending, signing, smart-contract operations, the amount of tokens required for the operation is automatically and transparently transfered from holding wallet to spending wallet, and used for the operation.
If at the end of operation some tokens remains, enough to be useful to transfer back to holding wallet, then they are automatically and transparently transferred back to holding wallet.

When user need to be paid, then the address that he can copy is the holding wallet address, and for all spending/signing/smart-contract interactions operations, that’s the spending wallet and its address that is visible to the receiver of the operation.

Purpose:
Some cams are operated by making user signing approvals for scamming contracts, generally directly after a legitimate operation (ex: just after a mint).

These kind of scams are exploiting the fact that most of the time users are using one wallet. To avoid that a user can create 2 wallets, a so-called “burns wallet” used for spending operations (sending tokens, signing, …) and a user wallet, which is used only for receiving assets.

This feature aim to automate this good practice of using two wallets, in a completely transparent way and by that automatically protect users of such scam as this way a malicious contract would always find always no token to steal from the spending wallet as it will never hold tokens.

The purpose to make it transparent and automatic is to make it easy to use, but of course advanced users would be able to choose to view and have access to both wallets via an option in the settings of MetaMask.

Extension/Mobile/Both: Both

2

sounds interesting.
is it similar to a privacy account product like zk.money ?

1 Like
3

No, that’s not the same purpose. Here the idea is to make sure the account that holds the assets is never used for spending operations directly and that all spending operations to external accounts/contracts are done only through a specific secondary “spending account” which is never filled more than for the operations themselves, so that if it’s exposed to a scam which give access to the account funds (for example through a malicious smar contract), the scammer.s won’t find any significant assets to steal.

2 Likes
4

To illustrate the idea, let’s take an example of a spending operation you’d like to do with and without this feature implemented, and see what the user will have to do and risk it’s exposed to:

Operation: Mint of a NFT with hidden malicious operation

Without the feature implemented using 1 account:

  1. The user got o the mint page of the NFT
  2. The user click on the Mint button and a MetaMask window open to confirm the mint
  3. The user validate the mint operation
  4. Immediately after a malicious call to setApproveForAll method of the smart-contract is done automatically, and MetaMask ask the user to validate it
  5. Let suppose the user think it’s related to the mint operation he just asked for before and validate it without taking attention that it’s an ApproveForAll operation.

Consequence: The user just gave full access to its assets on its wallet to the smart contract specified in the ApproveForAll operation.

Without the feature implemented using 2 accounts you created yourself:

  1. The user initiate a transaction of the amount + estimated gas fee (which he’ll have to make) to its secondary account
  2. The user make sure to switch to the secondary account before going to mint page of the NFT
  3. Then the user go to the mint page and click on mint button
  4. MetaMask ask for confirmation of the mint operation and the user validate it
  5. Immediately after a malicious call to setApproveForAll method of the smart-contract is done automatically, and MetaMask ask the user to validate it
  6. Let suppose the user think it’s related to the mint operation he just asked for before and validate it without taking attention that it’s an ApproveForAll operation.

Consequence: As the user made sure to use a secondary account for the operation, even if he did validate the malicious approval call, if the malicious smart-contract try to steal assets afterward thanks to the approval the user gave to it, it’ll never find enough funds even to pay the gas fees, so all stealing transactions would fail.

This is the recommended process, but as you see, this requires for now the user to do it itself, which opens to human mistakes and make the process painfull for average joe users.

With the feature implemented:

In that case, MetaMask would have created the secondary “spending account” itself, either at account creation or automatically when the user updates its installed MetaMask to the new version introducing the feature.

In that case the user scenario would be:

  1. The user don’t have to worry about ensuring to switch to the temporary account, Metamaks will use it auomatically
  2. So the user go to the mint page and click on mint button
  3. MetaMask ask for confirmation of the mint operation and the user validate it. Under the hood, MetaMask would have calculated the mint price+gas fees and transfered the required funds to the secondary account automatically and then validated the mint operation using the secondary 'spending" account and not the main account.
  4. After the mint operation done, as the spending account only add the required funds for the mint operation, no more funds are left or at least not enough to pay for fees of any other operation.
  5. Immediately after a malicious call to setApproveForAll method of the smart-contract is done automatically, and MetaMask ask the user to validate it
  6. Suppose the user don’t pay attention and validate it anyway, in that case of course, as its a non-custodial wallet, Metamsk would transfer to spending secondary wallet the funds to pay the fees for the malicious operation, this it can’t protect from it, and so the approval would be made.

But as at the end the remaining funds would be not enough to pay any other operations, if the smart-contract try to initiate a transfer on behalf of the spending wallet owner, as the approval has been made through the spending wallet and as this wallet never holds assets except temporarily and specifically for dedicated operation initiated by the user from the main wallet (and not from the spending wallet directly), then the stealing transaction would fail as the required funds aren’t available on the spending wallet.

4 Likes
5

In a nutshell, the idea is to automate fully transparently the good practice to use a secondary account for all spending operations that never holds funds, and on which you only transfer funds when you need to do a specific operation and only of the amount required for the operation, never more.

1 Like
7

In complement to this idea, the security can even be increased by also adding a mandatory validation through 2FA mechanism (SMS, 2FA authenticator app, …) on each transaction, being initiated manually by a user or automatically initiated by a smart-contract.

In a nutshell, similar process than the one lot of traditional banks are doing when you pay using your credit/debit card on internet (3D Secure like process). This would ensure that even if a smart-contract or unlegitimate user who got hands on the 12 words recovery phrase, initiate a transaction on a wallet, the transaction won’t be sent to the blockchain until a valid 2FA code is entered.