Sponsored Fees

[Nana-EC]

Description:
This HIP proposes an expansion to the approval and allowance network logic (i.e. CryptoApproveAllowance, NftAllowance
and TokenAllowance) by allowing any account on the network to provide allowances that will sponsor the payment of the
fees for another account’s submitted transactions.
In this way account Alice may assign an HBAR / token transaction fee allowance for EOA account Bob or Contract account
Carol and pay the fees due to nodes, the network and accounts for any transactions they submit, thus allowing Bob or
Carol to have zero balance and still transact on chain.

This proposal extends the existing Approval and Allowance API by adding the concept of a scope that designates the type
of value transafer an allowance applies to.
The scopes will include CryptoTranafer, HAPI transsaction fee, token custom fees and gas fees.
This enables value transfer and fee payments to another account without requiring one-off
approval for each transaction. This feature enhances flexibility and efficiency in managing transaction costs,
particularly for high volume applications.

Related issue(s):

Fixes #912

Notes for reviewer:
Expect more changes soon.
There's an outstanding item to condense the Allowances types to instead be scopes on the existing allowances as a cleaner API form

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[netlify]

✅ Deploy Preview for hedera-hips ready!

Name	Link
🔨 Latest commit	265855a
🔍 Latest deploy log	https://app.netlify.com/sites/hedera-hips/deploys/6789603df6acee00085f0c1f
😎 Deploy Preview	https://deploy-preview-1068--hedera-hips.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[Nana-EC]

Updated HIP with scope concept and fixed PR description with updated Abstract

[tud0r6]

Would it be possible for sponsored fees to be optionally set towards spending by a smart contract, thus limiting the scope of the approval to executing only 1 particular smart contract.

[gregscullard]

Would it be possible for sponsored fees to be optionally set towards spending by a smart contract, thus limiting the scope of the approval to executing only 1 particular smart contract.

@tud0r6 I like this idea, to be clear, you mean that if I grant some hbar to Alice, I would be able to specify that Alice can only spend the hBar on executing transactions related to a specific contract, nothing else. She would not be able to execute another contract, or create an NFT, etc...

Note, hbar in this case is gas for contracts, does the allowance extend to paying for gas (through the SDK and/or relay), or just native fees ? If only native fees, we may need to consider supporting gas payments.

[Nana-EC]

Would it be possible for sponsored fees to be optionally set towards spending by a smart contract, thus limiting the scope of the approval to executing only 1 particular smart contract.

@tud0r6 I like this idea, to be clear, you mean that if I grant some hbar to Alice, I would be able to specify that Alice can only spend the hBar on executing transactions related to a specific contract, nothing else. She would not be able to execute another contract, or create an NFT, etc...

Note, hbar in this case is gas for contracts, does the allowance extend to paying for gas (through the SDK and/or relay), or just native fees ? If only native fees, we may need to consider supporting gas payments.

Great considerations @gregscullard and @tud0r6 .
So the intention of this HIP was to cover value transfers that cover fees.
Initially it was not intended for gas, however, gas is eventually settled used to define the work but it's paid in the form of hbar.
So there's a possibility to extend it to cover gas payments with a specific scope or as GAS_PAYMENT 🤔.
I like it, though we need to think on any unintended emergent features here 😅.
For example the Ethereum JSON RPC API doesn't support the ability for an EOA to specify the transaction is sponsored. Which would mean it might only be available via ContractCall/ContractCreate HAPI and not via EthereumTransaction

[tud0r6]

tention of this HIP was to cover value transfers that cover fees.
Initially it was not intended for gas, however, gas is eventually settled used to define the work but it's paid in the form of hbar.

Indeed, I won't want to sponsor general-use gas(HBAR), rather application(SC)-specific gas(HBAR).

[Nana-EC]

@gregscullard and @tud0r6 I've added the gas scope but also added thoughts in the open questions section around some challenges here.
Any ideas on how to address this?

[gregscullard]

@Nana-EC on the gas scope and the EVM tooling question, could we not consider that if an EOA account has 0 balance, then gas fees should be paid out of the allowance, or if the account has balance, it consumes that balance first, then dips into allowances if they exist ?
Given the inference is that accounts would have 0 balance, this seems to be in line with the ethos of the hip and this would make the solution compatible with existing tooling.

I think we're still missing something with regards to the applicability of allowances for gas. Specifically the ability to be explicit about which contracts can be executed with a given allowance. User-stories-ish for example:

• Alice allows Bob to spend up to 100 hbar on gas costs (implies any contract)
• Carol allows Dave to spend up to 1000 hbar on gas costs only for contract 0.0.1234
• Carol allows Grace to spend up to 1000 hbar on gas costs for either contract 0.0.1235 and 0.0.1243 (how many can be specified here could be subject to a limit of 10 for example).
• Alternatively, Carol allows grace to spend up to 500 hbar on gas costs for contract 0.0.1235 and separately allows Grace to spend up to 500 hbar on gas costs for contract 0.0.1243

[Nana-EC]

@Nana-EC on the gas scope and the EVM tooling question, could we not consider that if an EOA account has 0 balance, then gas fees should be paid out of the allowance, or if the account has balance, it consumes that balance first, then dips into allowances if they exist ? Given the inference is that accounts would have 0 balance, this seems to be in line with the ethos of the hip and this would make the solution compatible with existing tooling.

Hey @gregscullard ,
I see what you're going for. To date though the network requires explicit intent from an account to utilize an allowance vs its own balance. This is the case for CryptoTransfer so it'd be inconsistent to do so with gas expenses.
It might not be right for the network to infer as different users may have different intents or be held to different policies offchain.
As such even with 0 balance but non zero allowance a node should still reject a transaction where there's a requirement to transfer value from a spender.
For example with ERCs a user must call transferFrom and with HAPI a user must set is_approval to true to tap into an allowance.
Additionally, a user may have multiple allowances, a node would not be able to infer the correct allowance to pull from even if it did want to.
I'm still pondering though to see if there's a pathway for this HIP, but I think it should be a proposal for another HIP.
@rbair23 thoughts here?

[Nana-EC]

I think we're still missing something with regards to the applicability of allowances for gas. Specifically the ability to be explicit about which contracts can be executed with a given allowance. User-stories-ish for example:

• Alice allows Bob to spend up to 100 hbar on gas costs (implies any contract)
• Carol allows Dave to spend up to 1000 hbar on gas costs only for contract 0.0.1234
• Carol allows Grace to spend up to 1000 hbar on gas costs for either contract 0.0.1235 and 0.0.1243 (how many can be specified here could be subject to a limit of 10 for example).
• Alternatively, Carol allows grace to spend up to 500 hbar on gas costs for contract 0.0.1235 and separately allows Grace to spend up to 500 hbar on gas costs for contract 0.0.1243

Hey @gregscullard ,
I get the user scenarios and the value. I just don't believe that it connects with this HIP which utilizes allowances logic as is but applies them for nameable criteria regardless of the other entities involved in the transaction.
The requested changes to the network for an account to be able to specify allowance to another account only for expenses on other entities is an extra dimension for the nodes to manage with state and complexity implications.
I think it'd be a great feature.
I just think it should be in a separate HIP as the logic differs from this and it needs to be considered separately and deeply.
@rbair23 thoughts?

[IvanKavaldzhiev]

This behaviour seems similar to the behaviour we have for NFT allowances, more specifically approvedForAll=true, where each new serial number of a given NFT will have been granted as an allowance to the spender.

Is the concept here the same? Since hbars are fungible there might be some applications like:

1. If a sponsor gives allowance to multiple accounts with unlimited HBAR amounts - the granted accounts might use a competative greedy approach to try to use a part or the whole balance for their personal use before another account and thus having unfair share of the sponsored balance
2. Defend the sponsor against a malicious account which performs operations in a loop, exhausting all of the balance

There might be safe use cases for this unlimited amount sponsorship, but I wanted to raise some security implications and corner cases, which can be thought of.

[Nana-EC]

Interesting points.
If by similar you mean will new hbars or FTs made available by a treasury be applicable to an existing allowance then yes, this would continue to be the case.

The cases noted are the same today I believe if an account was to provide one or multiple allowances with large enough values in comparison to their balance, so I don't believe this is a new edge case.
Solid consideration but I think it's already covered within the service capabilities.

It's the responsibility of the account to consider its awarded allowances.

[IvanKavaldzhiev]

The GAS scope seems to be missing.

[hendrikebbers]

Isn't GAS part of the TRANSACTION_FEE for a Smart contract call?

[IvanKavaldzhiev]

There is an interesting case that we should make sure is covered properly by this scope concept.

If we perform a precompile smart contract call that creates a token - this precompile requires gas amount in tinybars + separate value sent in tinybars, since the gas amount will be above some of the limits. This implies that calling createFungibleToken precompile call might make use of both GAS and TRANSACTION_FEE scopes.

We can elaborate more of what TRANSACTION_FEE covers in this HIP as a scope? I understand it as hbar amount needed to cover transaction expenses different than the gas itself. Or is it actually the gas amount itself?

[hendrikebbers]

But at some other points GAS is used as a scope (Mirror Node endpoint, for example). Here it must be clear what is the difference and if GAS must be included.

[IvanKavaldzhiev]

I agree, I'm a bit confused regarding the difference between GAS and TRANSACTION_FEE scope.

[Nana-EC]

To clarify, gas is a concept of resource utilization.
Gas fee is how much each unit of gas costs a user in HBAR.
Here the allowance is capturing the cost in hbar when settlement occurs

[Nana-EC]

Gas is an EVM concept which is a proxy for the amount of work the EVM needs to do to porcesss your transaction, which is not the same as the Hedera transaction fee (cost assigned to each HAPI transaction based on the feeSchedule)
Gas is indeed settled in HBAR and charged to an EOA so this might be where things are getting mixed up.
They are separate concepts and scopes so we have a TRANSACTION_FEE and a GAS_FEE to cover each separately.
Both cases are existing concepts on Hedera and are noted in summary in the HIP in the protobuf summary.
Maybe additional illustrations of the Scopes would be helpful.

It is possible as @IvanKavaldzhiev noted that a single transaction could utilize a combination of scopes. If that user has the appropriate allowances then the network will support it.

[rbair23]

For the EVM this is very interesting. We have two scopes: GAS_FEES and TRANSACTION_FEES. So we should consider (and document) the behavior of three variations:

1. A ContractCall transaction has only a single allowance for GAS_FEES
2. A ContractCall transaction has only a single allowance for TRANSACTION_FEES
3. A ContractCall transaction has two scopes: GAS_FEES and TRANSACTION_FEES with the same sponsor
4. A ContractCall transaction has two scopes: GAS_FEES and GAS_FEES by two sponsors
5. A ContractCall transaction has two scopes: GAS_FEES and TOKEN_CUSTOM_FEES by one or more sponsors

The first case is the base expected case: the sponsor will pay for a certain amount of gas. Gas is denominated in USD, and so the amount of hbars per gas is variable. So the sponsor is saying "I will pay whatever the USD equivalent of HBAR is up to this limit of gas". So this works.

For the second case, gas fees are a subset of possible transaction fees, so it seems very reasonable that a sponsor willing to pay for transaction fees would expect it to also cover gas. For example, as a sponsor, I could say I am willing to pay a certain amount of HBAR and I don't care whether it is for crypto transfer fees for gas fees. We could instead say that gas fees are special and must be specified separately.

The third case is dependent on our answer to the second case. If we say that TRANSACTION_FEES is illegal, then the third case is also illegal. If however we say that TRANSACTION_FEES is legal, then we have a situation here where the sponsor has provided two different allowances and we have a decision to make. Is this combination saying "you can spend X gas AND Y transaction fees", or is it saying "you can spend X gas but not more than Y hbars when converted to fees".

The fourth case we should just define the behavior. I think we will go to the first sponsor and use their funds first, and only if there is insufficient, then we go to the second sponsor. This seems simple enough.

The fifth case should be a failure because TOKEN_CUSTOM_FEES is not applicable to ContractCall. We should fail transactions that have inapplicable scopes. This is a little frustrating for dapps because they have to analyze what the transaction type is and then select the right sponsor and claim type, they cannot just put all claims in there and let the network figure it out. But this has been our policy to this point for all our transactions, to be strict on what we accept, to have the greatest forward compatibility. If this becomes a problem we can always loosen our position, but if we start off loose, we cannot tighten it.

So I think the pivotal cases are the second and third.