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 ...


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.


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.


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