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.
Related
I want to perform an atomic token swap without a pre-deployed smart-contract and I am wondering how to do that in Solidity.
The most common approach to do atomic swaps between tokenA and tokenB is the P2-SC-2P (Peer-to-Smart-contract-to-Peer) approach:
deploy a token swap smart-contract
alice deposits tokenA in the smart-contract
bob deposits tokenB in the smart-contract and receives tokenA in exchange
I want to get rid of step 1 to have a truly P2P mechanism. The main idea would be that Alice signs a transactions that transfers X tokenA to the person propagating the transaction, only if that person transfers Y tokenB to Alice in return.
Is it even possible to implement something like this?
Technically speaking, my first thought was to have Alice sign a transaction that deploys a smart-contract would take care of making the atomic swap between the signer and the caller before self-destructing.
I am not a good Solidity dev (to say the least) so here is the pseudo Solidity code I had in mind that could perform the atomic swap without requiring a pre-deployed smart-contract:
contract AtomicSwap {
sellerSignedApprovalTx = "<RawSignedTxData>"
constructor() public {
buyer = caller
seller = verifySignature(sellerSignedApprovalTx)
TokenB.approve(buyer,sellerSignedApprovalTx.askPrice)
delegateCall(sellerSignedApprovalTx.data)
safeTransferFrom(TokenB,buyer,seller,sellerSignerApprovalTx.askPrice)
safeTransferFrom(TokenA,seller,buyer,sellerSignerApprovalTx.tokenAmount)
selfdestruct()
}
}
As you can see, the idea is that the smart-contract has only 1 use: it performs the swap and then self-destructs (hence the notion of "disposable" smart-contract).
What do you think? Is this even technically possible?
If yes, would it work a bit like my pseudo code or am I completely off?
I got the answer to my question via another channel: it's not recommendable to use this technique because the seller needs to sign the transaction for execution without knowing the contract address which will be executing the trade. So it would be like writing a blank check and comes with many security issues.
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
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.
I am building a scraper to get all Swap data from Uniswap using web3js.
So far I subscribe to the log and filter topics by Swap() event.
then I decode the data and get amount0In, amount1In, amount0Out, amount1Out.
My problem is in the swapExactETHForTokensSupportingFeeOnTransferTokens() function.
Normally a swap has token0 in and token1 out, but this function gives me values for 3 of the 4 and I can not seem to understand how to handle that. eventually what I want is to know what they spend, what they got and what I need to update the new reserves of that pair.
If someone has the understanding of the Uniswap RouterV2 contract swap functions, I would like to get some pointers on how to handle the data to get my calculations right.
I found the solution here ethereum.stackexchange Anyone with the same question gets a very detailed answer there.
some contracts actually transfers to recipient specified amount of tokens minus 10% (5% tax fee and 5% liquidity fee) 208940457743532637 - 10% = 188046411969179375 and emits Transfer event. Then, PancakePair _swap function emits Swap event with base value of Amount0Out 208940457743532637
Amount0In is greater than zero because the token contract returns part of tokens as a liquidity pair on Pancake Swap.
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