Presale Purchase Issue: Negative Balance Due to Transferless Acquisition of BAT Tokens

[arberiii]

During the BAT token presale, transactions were conducted without involving a transfer process. For instance, in the transaction link, wallet 0x75D27075d8d9Aa87E54f05A07A52c5a117436Cc7 interacted with the BAT contract using the Create Tokens method, which unfortunately did not generate an ERC20 event log. Consequently, when attempting to reconcile the token transfer out in subsequent transactions such as link, the lack of this log poses challenges from an accounting standpoint.

What would be the optimal strategy for accurately recording transactions of this nature, ensuring seamless reconciliation of BAT (or similar tokens utilizing analogous methods such as Envion Token)?

In transaction 0x563854a38cedf07839239c46d79373c3334430f9831c3c37204ac92af96e6e4b's logs, there's a creation of 640,000 BAT tokens, as also be seen by chifra's articulated logs response:

chifra transactions --fmt json --articulate 0x563854a38cedf07839239c46d79373c3334430f9831c3c37204ac92af96e6e4b

{
  "data": [
    {
      "articulatedTx": {
        "name": "createTokens",
        "stateMutability": "payable"
      },
      "blockHash": "0x32d1360a33eb4983dde335ed71acbd864cdaf95f318f6cb8324c6baa27155baa",
      "blockNumber": 3798641,
      "date": "2017-05-31 14:24:50 UTC",
      "ether": "100",
      "from": "0x75d27075d8d9aa87e54f05a07a52c5a117436cc7",
      "gas": 88488,
      "gasCost": 2663323400685942,
      "gasPrice": 53312316606,
      "gasUsed": 49957,
      "hash": "0x563854a38cedf07839239c46d79373c3334430f9831c3c37204ac92af96e6e4b",
      "input": "0xb4427263",
      "isError": true,
      "nonce": 68,
      "receipt": {
        "contractAddress": "0x0",
        "effectiveGasPrice": 53312316606,
        "gasUsed": 49957,
        "logs": [
          {
            "address": "0x0d8775f648430679a709e98d2b0cb6250d2887ef",
            "articulatedLog": {
              "inputs": {
                "_to": "0x75d27075d8d9aa87e54f05a07a52c5a117436cc7",
                "_value": "640000000000000000000000"
              },
              "name": "CreateBAT"
            },
            "data": "0x00000000000000000000000000000000000000000000878678326eac90000000",
            "date": "2017-05-31 14:24:50 UTC",
            "logIndex": 66,
            "timestamp": 1496240690,
            "topics": [
              "0xb33527d2e0d30b7aece2c5e82927985866c1b75173d671c14f4457bf67aa6910",
              "0x00000000000000000000000075d27075d8d9aa87e54f05a07a52c5a117436cc7"
            ]
          }
        ],
        "status": null
      },
      "timestamp": 1496240690,
      "to": "0x0d8775f648430679a709e98d2b0cb6250d2887ef",
      "traces": [],
      "transactionIndex": 71,
      "value": "100000000000000000000"
    }
  ]
}

[tjayrush]

Closing for now but will re-open.

[tjayrush]

This is a well-known issue with the way tokens work, especially air-drops that do not render a Transfer log. This is actually okay according to the standard which only says that an ERC-20 contract SHOULD (not MUST) generate logs during minting.

Because of the way the Unchained Index works, we actually see these appearances. The addresses who receive tokens during an air drop do actually appear in the input data (many times). If we see an address in the input data and the to address is a smart contract, we query the getBalance routine of the contract. If we get a balance, we use it.