Clarification for Transaction

Hi,

Just want to get some clarification for transaction schema.
In the doc, it says all Operations in Transaction are one-sides. Does it mean, a simple token transfer transaction(Alice send Bob 100 Token), should contain 2 Operations, one for Alice with amount of -10 token and one for Bol with amount of 10 token?

Thank you!

Yes that is exactly right, @Yutong.

This may seem verbose for simple transfers in some blockchains (especially ones that are account-based). However, this one-sided nature of operations allows for representing complex blockchain interactions more easily than would otherwise be possible (imagine a smart contract invocation that affects 3 accounts).

Let me know if you’d like more examples of why this representation is useful!

Thank you very much for the explanation, Patrick.
One more question related to the transaction. For a chain with gas fee, should the gas fee be included in the negative amount of the sender side operation?

We recommend breaking out any fees into unique operations instead of overloading the negative amount on the sender side of a simple operation. Although the balance change effects would be the same, separating fees makes the representation much clearer. I wrote briefly about this here.

Example of Simple Send Transaction

{
  "transaction_identifier": {
    "hash": "TX_HASH"
  },
  "operations": [
    {
      "operation_identifier": {
        "index": 0
      },
      "type": "fee",
      "status": "success",
      "account": {
        "address": "addr1"
      },
      "amount": {
        "value": "-100000",
        "currency": {
          "symbol": "CURR",
          "decimals": 18
        }
      }
    },
    {
      "operation_identifier": {
        "index": 1
      },
      "type": "transfer",
      "status": "success",
      "account": {
        "address": "addr1"
      },
      "amount": {
        "value": "-10000000000",
        "currency": {
          "symbol": "CURR",
          "decimals": 18
        }
      }
    },
    {
      "operation_identifier": {
        "index": 2
      },
      "related_operations": [
        {
          "index": 1
        }
      ],
      "type": "transfer",
      "status": "success",
      "account": {
        "address": "addr2"
      },
      "amount": {
        "value": "10000000000",
        "currency": {
          "symbol": "CURR",
          "decimals": 18
        }
      }
    }
  ]
}

Note the use of the related_operations field to associate operations. Populating this field makes it much easier for developers to parse your implementation. The blog post I wrote contains more examples of this.

1 Like

got it! thank you very much @patrick.ogrady!

is it MUST DO ?
If the sender always pays the fee in my blockchain, do we need to separate fee as a new operation ?

https://www.rosetta-api.org/docs/low_level_ops.html#transaction-fees-are-just-operations
I’m asking because it said that
For blockchains where there is no explicit fee payer, where there are multiple fee payers ...

Sorry for the confusion on wording here, @nguyennguyen. If possible, you MUST create a distinct Operation for FEE payments (from the sender). This can be a little more nuanced in UTXO-based blockchains (where not including a fee operation is usually most correct).

You may find that you also need to create an Operation for block producer fee reward if this is not included as part of the normal block reward. For example, Bitcoin includes all fee payments in the coinbase so including a fee reward op would be “double-counting”.