7

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


6

the above answer is perfect, just notice the change in syntax in the latest version of Solidity. someAddress.call{value: 1 ether}('');


5

As we work on flash loan attack debriefs we can gather a lot of information about what could have been taken as preventative measures. It's important to understand how these flash loans work before diving into root causes and analytics. Flash loans are loans given out without collateral and returned in the same transaction that they were lent out. This is ...


5

Is there any way that generalized sandwich attackers can defend against this, or does this actually stop generalized sandwich attacks? It's important to note that these are not two zero-sum options. They could be impossible to defend against, and still not stop sandwichers. One reason would be if sandwichers are still earning (significantly) more than they'...


5

Which is the problem of letting SCs being upgraded? Costs? Security? The trust. Public blockchains aim to provide a trustless system by removing intermediaries and central authorities between the sender and recipient of the transaction. If the smart contract code could be changed after deployment by the deployer, users should trust them completely. Would ...


5

I would claim it's a combination of a few things. The first two are closely interconnected: New ecosystem and new language. Everything is new and most things are still rather experimental. Developers adopting a new language and new ecosystem. Nobody has much experience yet. Developer tooling is still quite rudimentary. Online resources are either outdated ...


4

If you are calling a view function locally, the information is not propagated to the blockchain at all. So you can call it with whatever parameters and nobody will know what parameters you used. But if you call the view function as part of a transaction, all of the data is visible in the blockchain and there are no easy ways to hide the data. Not only miners ...


3

If I create a wallet I get one seed phrase, one account and one private key. Nearly. You get one seed phrase, but that can translate into multiple private keys, and therefore multiple accounts. If I push another private key in my wallet then it has two private keys (two accounts) then the seed phase has to change then I can recover my wallet with two ...


3

Generally, you should always only use the latest released version available, no prior version whatsoever. As far as I know, there has not been major exploits caused by a Solidity compiler error ever. Thus, the only non-subjective historic data point we have is that "any Solidity compiler version has always been safe." Personally I prefer the major ...


3

Primarily to protect against phishing contracts. tx.origin is the original user that initiated the transaction. So if contract has some method like this (in Vyper): def burnBalance(): assert tx.origin == owner, "You are not the owner" balance[tx.origin] = 0 Then another smart contract can "phish" you with a proxy function - If ...


3

Flash loans violate two common intuitive assumptions. 1. "Nobody has that much ETH" Problems can arise when for example: Your contract uses a non-linear formula with an ETH amount as parameter Your contract relies on nobody having more than a certain amount of ETH to prevent integer overflow 2. The balance of an address (and ETH received from an ...


3

Generally speaking, if your system gives the users different terms under different scenarios, then you need to remember that a user can issue a flash-load attack on it. For example, if your pool gives the users a better conversion-rate when the pool is deeper (higher reserve balances), then a user can attack it by executing atomically: Add liquidity and ...


3

It is a matter of jurisdiction and recourse as well as expectations and reasonableness of expectations. Example: a bank (assuming paper cash, physically deposited) If you put money in a bank, you hope and expect that you can withdraw that money later. To be clear, the bank has agency here. There is no amount of force that can require a bank to pay you back. ...


3

In PR #2669 where those changes were made they mention Issue #2665. In that issue a comment by vladyan18 points that using unchecked reduces gas usage at deployment by 1723.


3

TL;DR never disclose your private key or your seed. There's almost no chances to revert seed from a private key but it's not mathematically impossible. Indeed your seed is probably a bip32 word list seed and the derivation path of your private key is probably one of the first (account 0) see Can someone explain the meaning of derivation path in wallet in ...


2

There is nothing secret in Ethereum blockchain. So, yes, it would be an extremely bad idea to store password there. Even if a variable is private it only means it can't be read directly by other smart contract. But everyone outside the blockchain can get the data if they want to. There are two approaches: See what transactions the contract has received and ...


2

tl;dr: you should use both (and more) :) Different FV/static analysis tools often have different features and pros/cons which might complement each other and give you better coverage. In this case, for example, Manticore targets EVM bytecode whereas SMTChecker targets Solidity code. Targeting Solidity is better for high level properties, contract invariants ...


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.


2

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.


2

Calls through view members of interfaces are done through STATICCALL opcode. As my experiment confirmed Solidity 0.6.0 does use STATICCALL in this case. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-214.md To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any ...


2

There are many possibles reasons that this happened and I will try to list them all. First of all, the problematic transaction called the transfer() function on the POLS token contract, not the transferFrom() function. It means that this fraud has nothing to do with the approval you made earlier to Uniswap. The transaction must have been signed either by ...


2

As mentioned in the question you linked, the mnemonic phrase was set to undefined. Another user was likely running into the same issue, causing the same mnemonic phrase to be used multiple times. This was not a collision in a randomly generated mnemonic phrase. 24 word long mnemonic phrases are generated from 256 bits of entropy, which is the same length as ...


2

If you do not have ABI you can interact with the smart contract by hand-crafting the Data payload for the transaction yourself. Here are instructions how to construct the data field payloads by hand. If your question is only "How to approve token" then you can use generic ERC-20 ABI.


2

To start with, sometimes a separate provider is not needed at all. If you expect users to have a browser wallet (such as Metamask), that wallet has its own connection already, and you can simply utilize that for at least reading blockchain data. If you don't expect (all) users to have (or enable) a browser wallet and/or wish to use a separate background ...


2

Looks like a horrible example. To begin with, there is zero talk about how much Ethers the users are sending with their transactions. That's what matters, because the code makes checks against msg.value. It simply looks like the writer has mixed up msg.value with the price (or new_price) parameter. I'm not sure if you can call anything in the blockchain a ...


2

I recommend you read OpenZeppelin's article on Access Control in Solidity. In your case, you would inherit from Ownable.sol and add the onlyOwnable modifier to the mint function. Here's an example for one of my contracts which does that: function setMinGasReserve(uint256 newMinGasReserve) external override onlyOwner { minGasReserve = newMinGasReserve; }


2

Looks like you have been following Twitter today. The user in question actually had their private keys compromised by a fake OpenSea email spam. However attack vectors can be launched on smart contracts, so that when you interact with them or approve them they are given access to your wallet. Not sure exactly how it happens but it is through malicious code. ...


1

HD Wallets refer to Hierarchical Deterministic wallets. These wallets can generate multiple "child" keys from a master seed using a derivation algorithm. The seed is generated from a collection of words, usually 12 or 24. A keystore file contains an encrypted private key. MEW Wallet is the mobile application.


1

A relayer cannot steal money, as the Tornado smart contract will not allow this. Here is what Tornado FAQ say: Relayers are used to withdraw to an account with no ETH balance. The relayer sends a withdrawal transaction and takes a part of the deposit as compensation (the protocol itself does not collect any fees). The relayer cannot change any withdrawal ...


1

View functions cannot modify the state, as specified here. It means that they cannot make any permanent change to the blockchain such as changing the ether or tokens balances. Therefore, reentrancy is not an issue with View functions.


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