[Question] How to get the address of redirected transaction

[Gabriel1590]

I'm working in a history, I can receive the history of an address from etherscan provider without a problem, but the transactions are going to a contract address, that receive the eth, and redirects it to another address. Something like this:

function transfer(address payable _to, uint256 _amount, uint256 _comision) public payable returns(bool){
        require(_to != msg.sender, "NOT_ALLOWED_AUTO_TRANSFER");
        require(_amount.add(_comision) == msg.value, "INSUFFICIENT_VALUE_TO_TRANSFER_WITH_COMISION");
        _to.transfer(_amount);
        return true;
    }

I need to parse those transactions sended to this contract address and get the address of the redirected transaction (get address _to). How can I do this?

[zemse]

See #977 :)

[Gabriel1590]

@zemse thanks, I figured that the data of the Tx will give me the the variables I need. I cannot access to those redirected transactions. But the addess is one of the variables that the function is asking, so I just decode the data and it gives me the _to, _amount and _comision variables; that works for me. Tranks for the response.

[zemse]

That is a nice trick that works with this function! However, watchout for the case in which a transaction is reverted. In that you'd get the tx mined (enabling you to decode tx) but state would be reverted (in actuality no funds were transferred). You can check if tx was success in the tx receipt.

If you're on testnet (you can change the solidity code), you can instead add events, which would make your life more easier. If tx reverts then events are also not emitted.

[Gabriel1590]

@zemse If a transaction is reverted, Etherscan will not give me that tx in the history, is't it?

[Gabriel1590]

I found another posible problem, lets say:

Account1 makes a transaction to the contract function that is redirected to Account2

If I want to get the history of Account1 I just ask the etherscanProvider and iterate the array of txs to decode all transactions that are make to the contract address, that way I get the address of Account2 in the txs.

But if I want to get the history of Account2, a redirected transaction from the contract doesnt appear in the history of Account2, so it seems that the balance just increment but there is no record of receiving a transaction in the Account2 history.

How can I get that tx from Account2?

[zemse]

I see reverted transactions in the EtherScan UI https://rinkeby.etherscan.io/address/0x08D85Bd1004E3e674042EAddF81Fb3beb4853a22

So I suppose you might get them in your API call. Probably, they might also be including a parameter that tells if tx was success or reverted.

For the part in which Account2 receives ETH in an internal transaction, I have an example tx that pays test ETH to 3 addresses internally. But on etherscan adress pages of receiptents, you don't see the Ether coming in their account.

Did you give a thought to using events? But this is possible only if it's possible to update the solidity code. Else, probalby you might have to go with your trick + checking tx success or not.

[Gabriel1590]

@zemse sorry for the delay in the response, I was working in another project. in the api call to etherscan, I received the transactions that were reverted, but in the response I see nothing that can indicate me that the response was reverted. I'll leave the responses to you to see it:

Not reverted:
{ "hash": "0xff6d5e5b2978f9565c2f1862851b34ba728f93895583a918f391a122a1b65050", "blockHash": "0x1a92ac505e00c508bacdf088c1b84afffda9b2049a1351a1640d1d19b51999a9", "blockNumber": 7113344, "transactionIndex": 10, "confirmations": 284978, "from": "0x08D85Bd1004E3e674042EAddF81Fb3beb4853a22", "gasPrice": { "_hex": "0x3b9aca00", "_isBigNumber": true }, "gasLimit": { "_hex": "0x02baad", "_isBigNumber": true }, "to": "0x1da7f478683206820DE9C9c76882F93A725A39F2", "value": { "_hex": "0x00", "_isBigNumber": true }, "nonce": 1597, "data": "0x76f5e6da00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000135f90132f86782fb0008a07c218e9c75816891b99e38f56baa48020d67b5dfa126302efd85be5ac946d095a0a91282e5383b9a2218ccb07936c8c3948a17161452c9de680dca18f0fd080dcca03cf3b0e3c2ac10bdb60f63c72d93d944ec4f240a074a3964e98de5cfd7b69e85b8412a302169144d07812560dff765853b1a035361939665bef2c25c301422a465212e91311b0429891d944fd732f087c0e053c7c4720db94a47b082abdc52f31e621bb8410337dd760334e169f78c9f7b5ced05bcf9ca140503733ad4ac7f451c4b9baf3837e76afc78ea55e952428980b43dffd6d1d83b60dd0d9bc046c57a3b14970bc91bb8414a292e5728f5d0f2a04a61dae74202e1900cb8b19215f99480c7cf8e6ebc6e6d7b50234f5bab59fac76ff4d78f925c72ea6981e8c646ec28d110eac02a142af31c0000000000000000000000", "creates": null, "chainId": 0, "timestamp": 1598856012 },

reverted:
{ hash: '0xff6d5e5b2978f9565c2f1862851b34ba728f93895583a918f391a122a1b65050', blockHash: '0x1a92ac505e00c508bacdf088c1b84afffda9b2049a1351a1640d1d19b51999a9', blockNumber: 7113344, transactionIndex: 10, confirmations: 284978, from: '0x08D85Bd1004E3e674042EAddF81Fb3beb4853a22', gasPrice: BigNumber { _hex: '0x3b9aca00', _isBigNumber: true }, gasLimit: BigNumber { _hex: '0x02baad', _isBigNumber: true }, to: '0x1da7f478683206820DE9C9c76882F93A725A39F2', value: BigNumber { _hex: '0x00', _isBigNumber: true }, nonce: 1597, data: '0x76f5e6da00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000135f90132f86782fb0008a07c218e9c75816891b99e38f56baa48020d67b5dfa126302efd85be5ac946d095a0a91282e5383b9a2218ccb07936c8c3948a17161452c9de680dca18f0fd080dcca03cf3b0e3c2ac10bdb60f63c72d93d944ec4f240a074a3964e98de5cfd7b69e85b8412a302169144d07812560dff765853b1a035361939665bef2c25c301422a465212e91311b0429891d944fd732f087c0e053c7c4720db94a47b082abdc52f31e621bb8410337dd760334e169f78c9f7b5ced05bcf9ca140503733ad4ac7f451c4b9baf3837e76afc78ea55e952428980b43dffd6d1d83b60dd0d9bc046c57a3b14970bc91bb8414a292e5728f5d0f2a04a61dae74202e1900cb8b19215f99480c7cf8e6ebc6e6d7b50234f5bab59fac76ff4d78f925c72ea6981e8c646ec28d110eac02a142af31c0000000000000000000000', creates: null, chainId: 0, timestamp: 1598856012 }
It seems normal to me, I don't know if I'm missing something.

The thing with the events is that I already deployed the contract. And not only that, that contract is made with the intension that is as cheaper as it can, so adding the events may increase the costs.

I don't find a way to get the transactions received internally by a contract operation. except recorring all the history of the contract and parsing the data, but in the time that is really time consuming

[zemse]

This looks like the transaction object, the execution status of a transaction is available in receipt.

You just need to extract every tx hash and query it's receipt like following:

const receipt = await providerETH.getTransactionReceipt('0xff6d5e5b2978f9565c2f1862851b34ba728f93895583a918f391a122a1b65050')

receipt.success // is 0 if reverted, is 1 if execution success

[Gabriel1590]

@zemse Okay I understand, thanks. Now what about getting the history of transactions received of an Address that just get some funds from an internal transaction?

[zemse]

Now reading internal transactions is something that is not standardized in Ethereum's RPC spec. You will need to use some custom rpc calls of some client like trace API on a parity/openethereum node. To avoid this you can first recheck if etherscan gives that data.

[Gabriel1590]

@zemse okay okay, I thought in another possible answer, what if I store all the transactions in an hexString in my database, that could be possible? and how much would that cost in space?

[zemse]

Though you could store the transactions in your database (as you get in transaction and receipt), but these alone don't contain information internal transfers of ether. To get that info you really need an EVM to simulate the tx to see what an internal transfers are and nodes that have exposed their trace API can do that for you (infura feature request). Yeah, that sounds not cool or convenient, this all hard work is in the cases of internal ether transfers which happens to be your case. Use of events bring down the work required, but as you have mentioned the contract is already deployed. AFAIK trace/debug API is the only way to go if Etherscan doesn't provide you internal transactions data in a tx.

[ricmoo]

(please feel free to continue the conversation; moving to discussions)