I'm looking at this transaction, where 0.01 ether is sent to the ExchangeETHforTokenMannual() function from this contract.
You can tell from the contract code (line 244) that there is a require() call enforcing a minimum amount of 0.081 ether. Since the transaction only sent 0.01 ether, in theory, the require call should fail and all state changes should be undone (including the 0.01 ether sent); however, the transaction shows up as successful.
Why is this?
The field minContribution is 0.001, not 0.081.
Check it here:
https://etherscan.io/address/0x048c2eb8dfb1eb5dcf7ecfef9cf027ba85ea6cf7#readContract
Related
The USDC smart contract on Ethereum has a transferWithAuthorisation that any address can call if they have a signature.
However, the method seems to be inconsistent and often fails.
What is the reason for this?
https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48?method=0xe3ee160e
Most of the failures are due to: "Warning! Error encountered during contract execution [execution reverted] "
I debugged some of the failing transactions with Tenderly and learned that they all (or at least those that I debugged) fail on insufficient gas limit.
Each EVM operation costs some predefined amount of gas units. The transaction sender specifies gas limit, and then buys this amount (times gas price) for ETH. If the transaction consumes less gas units than the limit, the difference is refunded.
The transferWithAuthorisation() function seems to cost between 72k and 82k gas units depending on internal code logic (successful transactions: 0x7e..., 0x32..., 0xec...).
However the failing transactions supplied lower gas limit between 59k and 62k (0xd3..., 0xf1..., 0x54...).
So the sender possibly used an incorrect estimation of gas usage, and specified an insufficient limit.
Here is an example of such transaction:
etherscan
It was 569730199030000 Wei on a balance,
I used current gas price(by web3.eth.getGasPrice()) 19888345864 Wei.
So my estimated fee was (19888345864 * 21000) 417655263144000 Wei.
I was trying to send (balance - estimated fee) = 152074935886000 Wei.
The result as you can see "out of gas".
Why it is possible that regular send was required more than 21000 gas? If I understand properly in case if gas price is not enough then miners simply must ignore this tx, but in case if they are agree with the gas price they have to run this transaction normally, and normally sending eth requires gas limit 21000. Where is mistake in my calculations and how to execute such tx properly?
Generally, this often happens when you're trying to send ETH to a contract that either doesn't implement a special function to accept the ETH - or the contract does implement the function but it explicitly rejects the incoming transfer.
Specifically, the first-hand recipient of your transaction is a proxy contract deployed at address 0xB233903ACec807C61eeeCc4F69dd795A617a1732, that redirects the request to a target contract deployed at address 0xd332254f274cc65aa11178b74734e2992b8f349e.
Author of the target contract has not shared its source code, but from the decompiled bytecode it seems to accept incoming ETH transfer only if series of conditions (depending on the payload of the incoming transaction and the state of another contract) is met. Otherwise it rejects the transaction with the revert statement.
def _fallback() payable: # default function
require ext_code.size(0xa24787320ede4cc19d800bf87b41ab9539c4da9d)
static call 0xa24787320ede4cc19d800bf87b41ab9539c4da9d.0x4fef8ec4 with:
gas gas_remaining wei
if not ext_call.success:
revert with ext_call.return_data[0 len return_data.size]
require return_data.size >= 32
delegate ext_call.return_data[0] with:
funct call.data[0 len 4]
gas gas_remaining wei
args call.data[4 len calldata.size - 4]
if not delegate.return_code:
revert with ext_call.return_data[0 len return_data.size]
return ext_call.return_data[0 len return_data.size]
I am using web3-eth-contract package to connect to contract on Ethereum. I am executing it's methods by:
contract.methods
.methodName(ids)
.send({
to: address,
from: address
})
The problem is that I get:
After that I tried to add gasLimit there:
contract.methods
.methodName(ids)
.send({
to: address,
from: address,
gasLimit: 300000,
})
and it worked fine when I use methods that require only simple arguments. When I use methods where I pass array of arguments and there are more arguments than 2 transactions are being cancelled. What should I pass to gasLimit or how can I estimate it so it will work every time?
The gas used to execute the transaction may depend on your parameters, so what you experience is totally reasonable.
Now, to know what gasLimit to set you need to know what the transaction is doing and how much gas it is expected to burn. You can take one of the following approaches:
set the gasLimit very high, so that your transaction is always executed
check the older transactions to the same contract and see how much gas they burnt
use the transaction format after the London Uprade and specify max ETH you are willing to pay for the transaction (maxFeePerGas) instead of setting gasLimit
I'd like to verify programmatically that a transaction was successful - that is the Etherum network itself recognizes that for a given transaction hash, it was valid.
Using web3.eth.sendSignedTransaction returned a promise, there's two events - one 'confirmation', the other 'receipt'.
Can I rely on the 'receipt' callback to ascertain that a transaction truly occurred? Or do I have to rely on the 'confirmation' call back as well? If so - how?
Similarly, reading getTransactionReceipt it mentions that -
The receipt is not available for pending transactions and returns null.
So, if I do get a receipt then - it means the transaction is no longer 'pending' ? That is, was successful?
_So, if I do get a receipt then - it means the transaction is no longer 'pending' ? That is, was successful?
When the receipt becomes available (or the event is handled in your case), it means that the transaction was mined into a block.
But the tx could have been reverted (if it was a tx to a smart contract that reverted it for some reason). Check the receipt field status
true means that the transaction was successful
false means it was reverted
Mind that the status is not included in pre-Byznatium (October 2017) transactions and can also be missing in some future transaction types. See more about the transaction types in this answer.
The transaction does not go through, each attempt deducts a gas commission!
I'm trying to stake DNXC coins (https://portal.dinox.io/staking/gen-0-eth#), it is clear that according to the contract that others get it, why do I get it?
Here are all my attempts:
https://etherscan.io/tx/0x52c809e81eb7e4207213322fb77d7485d60df6dda6d77b4f294aaae2a66d2554
https://etherscan.io/tx/0xda781add7ac0006ee1d6e5f818ffa47368dd1a902d8a9c4b1a59d89e19be05ac
https://etherscan.io/tx/0x037826c6074cfba548ebc93c673312cbc21be476fa96598ecdef9933ac499eaf
https://etherscan.io/tx/0x18d87decbf11da799852c9030e787bc552f28eb2372b914b68c54728cc99bc16
https://etherscan.io/tx/0x35cfe1d7f66bf6ef2e666ebde0c74c6512a503473783125eb66bf6146ba1b33f
What is the problem and can the lost money be returned?
contract adress: 0xB2643342434a46B5088E17C7606cF81f6911647e
If you look at the transactions under the contract, you will notice that the problem is quite common.