3

Developer @ Aave here, good questions. It depends on your contract. But a simple one would be: Contract A has funds and the executeOperation() Contract B calls flashloan(), passing in Contract A as the receiverAddress Contract A now executes executeOperation() Contract A repays the flash loaned amount and debt as designed The attack would be an attacker ...


2

The owner of a specific token can maintain a "blacklist" in the context of his token's contract. In relation to the whole Ethereum, the implementation of this is unlikely, if only due to the absence of a owner from the public Ephereum.


1

Funnily enough I just came searching for an answer to this myself. As I understand it, there is no reentrancy vulnerability in a conventional sense because a view member cannot modify state.


1

Nothing really. An authorized account can make an upgradable contract do anything they want. On the other hand projects have created Governance contracts that impose certain restrictions on upgrades. A period of time to validate the upgrade, or withdraw if they don't agree on it.


Only top voted, non community-wiki answers of a minimum length are eligible