Fee Visibility

[leighmcculloch]

There was a discussion on the stellar-rpc about exposing some information about fees in its getTransactions API:

• Provide inclusion_fee in the getTransaction / getTransactions responses stellar-rpc#411

In general there is lacking visibility into the fees of transactions that invoke contracts.

What would be the best way to create more visibility of fees to developers?

Adding it to the RPC API is an easy way to default doing this, but it positions RPC as a transformer of data which is something that Horizon was used for in the past, and in general has been a non-goal of RPC. We must tread with care when adding more information to the RPC because it will be create a new data model inside that product that could artificially cause it to become a dependency when otherwise there might be other better tools to use.

There are actually lot of fee values that might be relevant to developers and applications, and so there also needs to be some discernment about what fee values are relevant and when.

Some fees are directly visible on a transaction, in transaction results, and in transaction meta.

For example, below are the fee fields in a TransactionEnvelope:

{
  "tx": {
    "tx": {
      "ext": {
        "v1": {
          "resource_fee": 420990
        }
      },
      "fee": 421090
    }
  }
}      

And below are the fee fields in a TransactionResult:

{
  "fee_charged": 331991
}

And below are the fee fields in TransactionMeta:

{
  "v3": {
    "soroban_meta": {
      "ext": {
        "v1": {
          "rent_fee_charged": 294604,
          "total_non_refundable_resource_fee_charged": 37208,
          "total_refundable_resource_fee_charged": 294683
        }
      }
    }
  }
}

There are two categories of fees, proposed fees in the original tx, and charged fees in the result and meta.

I think the following is a list of all of the fee values a developer might be interested in, and where they can be found in the structures above or derived from other values:

• proposed
  • resource (envelope.tx.tx.ext.v1.resource_fee)
  • inclusion (derived)
  • total (envelope.tx.tx.fee)
• charged
  • resource
    • resource_non_refundable
      • total (meta.v3.soroban_meta.ext.v1.total_non_refundable_resource_fee_charged)
    • resource_refundable
      • rent (meta.v3.soroban_meta.ext.v1.rent_fee_charged)
      • other (derived)
      • total (meta.v3.soroban_meta.ext.v1.total_refundable_resource_fee_charged)
    • total (derived)
  • inclusion (derived)
  • total (result.fee_charged)

Is adding to the RPC the best place for this? Or in clients and tools, like @tomerweller suggests for the Lab and CLI?

What fee values do developers care about? All of them all the time?

[tomerweller]

Is adding to the RPC the best place for this? Or in clients and tools

I don't think these are mutually exclusive. Lab and CLI are great places to surface this information, potentially even SDKs. However, I believe that this information should be accessible via API and the overall developer ergonomics are better when there is a trivial translation between our API layer and our tooling layer

[janewang]

Agreed, transaction fees should be surfaced consistently at the API layer. Please take a look at how other Layer 1s handle this; I believe that captures the core of the conversation.

For Lab, we've already planned to expose fees, and I agree the CLI is also an appropriate place to do so. For the purposes of this discussion, let’s take those as given and focus on the data layer. We should find a path forward for the API.

it positions RPC as a transformer of data which is something that Horizon was used for in the past, and in general has been a non-goal of RPC

May I suggest that the RPC owners consider evaluating other RPCs for a product comparison, as it may provide useful insights.

[leighmcculloch]

at the API layer...how other Layer 1s handle this

There's the RPC layer, and then here are other APIs too. Looking at just other RPCs:

If we look at Ethereum, this is what it exposes about the first category of fee, proposed fee values:

eth_getTransactionByHash

• gas: QUANTITY - gas provided by the sender.
• gasPrice: QUANTITY - gas price provided by the sender in Wei.

Ref: https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionbyhash

Additional fields listed here for non-legacy txs:

• maxPriorityFeePerGas
• maxFeePerGas

Ref: https://ethereum.github.io/execution-apis/api-documentation/

And this is what it exposes about the second category of fee, charged fee values:

eth_getTransactionReceipt

• cumulativeGasUsed : QUANTITY - The total amount of gas used when this transaction was executed in the block.
• effectiveGasPrice : QUANTITY - The sum of the base fee and tip paid per unit of gas.
• gasUsed : QUANTITY - The amount of gas used by this specific transaction alone.

Ref: https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionreceipt

@janewang Are those the APIs you're referring to, or other non-rpc APIs?