chifra export --accounting: statements don't show the counterpart of transaction

[artur-jablonski]

It would be useful for statements to contain a counterpart of the transaction in question. Now I need to do extra work to find out.

For ETH/WEI I know that the counterpart will be either the top level "from" or "to". For ERC20 transactions I need to somehow match the statement with log entry and get "from" or "to" from there.

Example:

This is one exported transacton from running chifra export --accounting 0x1b5508ce1a657a68054b48e8aebf5c458d9f26db

{
  "hash": "0x1a12d58bc026a1f06b631eb042a399ea34a1af8dd80fd289fb91d68d3a30f75e",
  "blockHash": "0xc0c28697129fe92f8713f3513c4d2911d2bac8287c7b8172a4716baa86ab9870",
  "blockNumber": 13990032,
  "transactionIndex": 499,
  "timestamp": 1641981260,
  "from": "0x11238cd54755895718d03880b6d28d04ab628263",
  "to": "0xdac17f958d2ee523a2206206994597c13d831ec7",
  "value": 0,
  "gas": 94795,
  "gasPrice": 140178017155,
  "maxFeePerGas": 180674089637,
  "maxPriorityFeePerGas": 1500000000,
  "isError": 0,
  "hasToken": 1,
  "receipt": {
    "contractAddress": "0x0",
    "gasUsed": 63197,
    "effectiveGasPrice": 140178017155,
    "logs": [
      {
        "address": "0xdac17f958d2ee523a2206206994597c13d831ec7",
        "logIndex": 574,
        "topics": [
          "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
          "0x00000000000000000000000011238cd54755895718d03880b6d28d04ab628263",
          "0x0000000000000000000000001b5508ce1a657a68054b48e8aebf5c458d9f26db"
        ],
        "data": "0x0000000000000000000000000000000000000000000000000000000005f5e100",
        "articulatedLog": {
          "name": "Transfer",
          "inputs": {
            "_amount": "100000000",
            "_from": "0x11238cd54755895718d03880b6d28d04ab628263",
            "_to": "0x1b5508ce1a657a68054b48e8aebf5c458d9f26db"
          }
        },
        "compressedLog": "{name:Transfer|inputs:{_amount:100000000|_from:0x11238cd54755895718d03880b6d28d04ab628263|_to:0x1b5508ce1a657a68054b48e8aebf5c458d9f26db}}"
      }
    ],
    "status": 1
  },
 "articulatedTx": {
    "name": "transfer",
    "inputs": {
      "_to": "0x1b5508ce1a657a68054b48e8aebf5c458d9f26db",
      "_value": "100000000"
    }
  },
  "compressedTx": "{name:transfer|inputs:{_to:0x1b5508ce1a657a68054b48e8aebf5c458d9f26db|_value:100000000}}",
 "statements": [
    {
      "blockNumber": 13990032,
      "transactionIndex": 499,
      "timestamp": 1641981260,
      "assetAddr": "0x1b5508ce1a657a68054b48e8aebf5c458d9f26db",
      "assetSymbol": "WEI",
      "decimals": 18,
      "prevBlk": 13975562,
      "prevBlkBal": "28778657059623529",
      "begBal": "28778657059623529",
      "endBal": "28778657059623529",
      "amountIn": "",
      "internalIn": "",
      "selfDestructIn": "",
      "minerBaseRewardIn": "",
      "minerNephewRewardIn": "",
      "minerTxFeeIn": "",
      "minerUncleRewardIn": "",
      "prefundIn": "",
      "amountOut": "",
      "internalOut": "",
      "selfDestructOut": "",
      "gasCostOut": "",
      "reconciliationType": "regular",
      "spotPrice": 3256.87367,
      "priceSource": "uniswap",
      "begBalDiff": "",
      "endBalCalc": "28778657059623529",
      "endBalDiff": "",
      "totalIn": "",
      "totalOut": "",
      "totalOutLessGas": "",
      "amountNet": "",
      "reconciled": true
    },
   {
      "blockNumber": 13990032,
      "transactionIndex": 499,
      "timestamp": 1641981260,
      "assetAddr": "0xdac17f958d2ee523a2206206994597c13d831ec7",
      "assetSymbol": "USDT",
      "decimals": 6,
      "prevBlk": 13990031,
      "prevBlkBal": "",
      "begBal": "",
      "endBal": "100000000",
      "amountIn": "100000000",
      "internalIn": "",
      "selfDestructIn": "",
      "minerBaseRewardIn": "",
      "minerNephewRewardIn": "",
      "minerTxFeeIn": "",
      "minerUncleRewardIn": "",
      "prefundIn": "",
      "amountOut": "",
      "internalOut": "",
      "selfDestructOut": "",
      "gasCostOut": "",
      "spotPrice": 1.00000,
      "priceSource": "stable-coin",
      "begBalDiff": "",
      "endBalCalc": "100000000",
      "endBalDiff": "",
      "totalIn": "100000000",
      "totalOut": "",
      "totalOutLessGas": "",
      "amountNet": "100000000",
      "reconciled": true
    }
  ],
  "gasCost": 8858830150144535,
  "gasUsed": 63197,
  "date": "2022-01-12 09:54:20 UTC",
  "ether": 0.000000000000000000
}

In this statement:

{
      "blockNumber": 13990032,
      "transactionIndex": 499,
      "timestamp": 1641981260,
      "assetAddr": "0xdac17f958d2ee523a2206206994597c13d831ec7",
      "assetSymbol": "USDT",
      "decimals": 6,
      "prevBlk": 13990031,
      "prevBlkBal": "",
      "begBal": "",
      "endBal": "100000000",
      "amountIn": "100000000",
      "internalIn": "",
      "selfDestructIn": "",
      "minerBaseRewardIn": "",
      "minerNephewRewardIn": "",
      "minerTxFeeIn": "",
      "minerUncleRewardIn": "",
      "prefundIn": "",
      "amountOut": "",
      "internalOut": "",
      "selfDestructOut": "",
      "gasCostOut": "",
      "spotPrice": 1.00000,
      "priceSource": "stable-coin",
      "begBalDiff": "",
      "endBalCalc": "100000000",
      "endBalDiff": "",
      "totalIn": "100000000",
      "totalOut": "",
      "totalOutLessGas": "",
      "amountNet": "100000000",
      "reconciled": true
    }

There is no indication who send the token. The only solution I can see is to match this statement to this log:

{
        "address": "0xdac17f958d2ee523a2206206994597c13d831ec7",
        "logIndex": 574,
        "topics": [
          "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
          "0x00000000000000000000000011238cd54755895718d03880b6d28d04ab628263",
          "0x0000000000000000000000001b5508ce1a657a68054b48e8aebf5c458d9f26db"
        ],
        "data": "0x0000000000000000000000000000000000000000000000000000000005f5e100",
        "articulatedLog": {
          "name": "Transfer",
          "inputs": {
            "_amount": "100000000",
            "_from": "0x11238cd54755895718d03880b6d28d04ab628263",
            "_to": "0x1b5508ce1a657a68054b48e8aebf5c458d9f26db"
          }
        },
        "compressedLog": "{name:Transfer|inputs:{_amount:100000000|_from:0x11238cd54755895718d03880b6d28d04ab628263|_to:0x1b5508ce1a657a68054b48e8aebf5c458d9f26db}}"
      }

Where you can now take the from address as the counterpart of this transfer.

However it's not necessarily obvious how to match a statement with corresponding log entry. One could use the asset address and perhaps a value but it feels rather brittle.....

[tjayrush]

Help me better understand. Do you think this is true?

1. For the ETH statements, the "counterparty" is always the 'from' to the 'to' or the 'to' to the 'from'? Is that correct?
2. For the token statements, the 'counterparty' is the same and in the event. (So, 'from' is counterparty to 'to' and visa-versa).

Or, do you think it's more complicated than that?

[artur-jablonski]

Help me better understand. Do you think this is true?

1. For the ETH statements, the "counterparty" is always the 'from' to the 'to' or the 'to' to the 'from'? Is that correct?
2. For the token statements, the 'counterparty' is the same and in the event. (So, 'from' is counterparty to 'to' and visa-versa).

Or, do you think it's more complicated than that?

I think these two rules should cover a lot of ground. One "corner case" I found is with WETH where chifra reports statements that correspond to Withdraw and Deposit events as opposed to ERC20's Transfer. I think logically in these two cases the "counterparty" is the same address that withdraws or deposit as the token doesn't change the owner..... Maybe there's other cornercases... if I bump into them I will report here

[tjayrush]

Hi @artur-jablonski we are going to be starting this week to address this issue. It's an important one. I'll close this issue once it works as it should. Perhaps you'll review the effect of that change once this issue closes?

[tjayrush]

This has been implemented in the issue_2203/counterparties_second branch. The fix will appear in develop as soon as this is merged.