# EIP-3074 Threat Models

### Signing a malicious tx

In this threat model, we'll assume that an adversary can trick a user into signing an invalid transaction.

- **EOA**: if a user secures their assets in an EOA and they sign an arbitrary malicious transaction, the worst that can be done is their most valuable asset will be compromised. Generally, there isn't the ability to "batch" actions together so the attacker will should go after the user's most valuable asset. In the future, it's likely that more contracts will support meta-txs and standards for batched actions will emerge **or** that the protocol will support batching for EOAs. This would make it possible for an attacker to appropriate more than one of a users assets.
- **Smart Contract Wallet**: if a user secures their assets with a smart contract wallet, they are vulnerable in a similar way as above. The exact vulnerability is dependent on the implementation of the wallet contract they are using. If the wallet contract mimics the same functionality as the protocol, the user can lose their single most valuable asset. If the wallet supports batching, they can have their account completely emptied. One advantage is that contracts can impose limits for transfers and fallback to multi-sig authentication for large transfers. This would require parsing the calldata to understand *how much* is being transferred (ether is trivial to check, other assets -- not as much).
- **EIP-3074**: in this case we'll assume the invoker contract is bug-free (this is the same assumption made above for smart contract wallets, we'll explore contract bugs later). By bug-free, we mean the user's transaction is not malleable. What the user signs is what will happen. In this case, the worst that can be done is equivalent to that of a smart contract wallet. In the simple case, the user will lose their single most valuable asset. The caveat here is that EIP-3074 does not permit value transfers from the authorized account. Therefore, the attacker would not have access to the user's ether stored in their account balance. If the invoker supports batching, one signature for $N$ actions, the user will lose every valuable asset in their account. Like smart contract wallets, it's possible for the invoker to impose transfer limits on an account -- minimizing the potential damage. EIP-3074 can potentially be made worse though. If a user secures their key with a hardware wallet and the hardware wallet supports arbitrary invoker addresses, an adversary could trick a user into signing an EIP-3074 message to a malicious invoker. This should be combated by the hardware wallet *not allowing* arbitrary invokers to be signed over. Only a trusted list of invokers should be preloaded onto hardware wallets. This could be updated overtime by updating the hardware wallet's firmware (if we can't do this securely, we have other problems). If hardware wallets impose this restriction, the vulnerabilities here are equivalent to using a smart contract wallet.

### Compromised computer

In this threat model, we'll assume an adversary has complete control of a user's computer.

* **EOA (hardware wallet)**: as we've [seen](https://www.coindesk.com/ceo-of-defi-insurer-nexus-mutual-hacked-for-8m-in-nxm-tokens), even if your funds are secured by hardware wallet, you're only as secure as the weakest link in your chain of trust. An attacker can install a malicious version of MetaMask that displays different data than what a user is signing over. This is only viable for smart contract interactions, because ether transfers generally show up clearly on the hardware wallet. This attack's days are likely numbered. Hardware wallets are getting better at displaying calldata in a verifiable way on their devices. Regardless, it's likely an attacker can steal your most valuable non-ether asset with this attack.
* **EOA (hot wallet)**: if the private keys are stored in your computer, the adversary only needs to key log the decryption password once then they'll have full access to your account.
* **Smart contract wallet**: since EOAs secure smart contract wallets, they inherit the same risks as above -- depending on how the key is stored. Fortunately, as noted above, they have some capability of limiting transfers.
* **EIP-3074**: inherits the same issues as smart contract wallets.

### Smart Contract Bug
In this threat model, we'll assume the most valuable contract a user interacts with has a bug.

- **EOA**: in the worst case, the user can lose all assets stored by that smart contract. Defi contracts have seen many hacks over the last few years. Generally, these are the result of an economic flaw in the contract and lack auditing. Often times, the user loses a large percentage of their assets in the contract, but not 100% of their holdings.
- **Smart contract wallet**: in the worst case, the user can lose all assets the contract wallet owns. This would imply the authentication logic is flawed and allows complete malleability of transactions (input values have no relation to values signed over). This is *very* unlikely to occur in a smart contract wallet that has been sufficiently audited. It's more likely that the wallet has a small bug that allows for a small amount malleability (e.g. a subset of the user's transactions can be replayed because of an error in the replay protection logic). There is a many different levels of "compromised" a smart contract wallet could encounter. The neat thing is that its possible (albeit *very* difficult) to create a proof that a smart contract wallet is sound. If this proof is created, then the worst case becomes equivalent to the EOA's worst case.
* **EIP-3074**: the worst case for this EIP is exactly the same as a smart contract wallet. We are *trusting* that an invoker executes its code faithfully because it can send calls as a user. This is equivalent to a smart contract wallet -- when a wallet makes a `CALL`, it by default sets `CALLER` equal to the wallet (aka the user's main address). EIP-3074 provides the same facilities without deploying an additional contract.