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 and token custom 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	335fc2b
🔍 Latest deploy log	https://app.netlify.com/sites/hedera-hips/deploys/67608c468595d80008ad1f89
😎 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]

Typo - new repetition

[Nana-EC]

Fixed

[IvanKavaldzhiev]

Typo: NftAllowance -> TokenAllowance

[Nana-EC]

Fixed

[IvanKavaldzhiev]

Typo: an -> a

I think the field description is a bit too complex and can be simplified. Part of the description can be moved in the description for the TransactionSponsorClaim operation

[Nana-EC]

Fixed

[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

[hendrikebbers]

Definition of AllowanceScope enum in solidity is missing

[Nana-EC]

Added

[hendrikebbers]

While I know HTS I do not know what HAS or EOA stand for. Can we add a link or the full name at first usage?

[IvanKavaldzhiev]

HAS -> Hedera Account Service
EAO -> Externally owned account

I agree with your comment for adding more info about the full names.

[Nana-EC]

Added

[hendrikebbers]

Do I call this endpoint when want to get information about an allowance for calling smart contracts for example? If that is correct I dislike the "/crypto" at the end. Since we have the scope I would assume "/api/v1/accounts/{idOrAliasOrEvmAddress}/allowances" as endpoint.

[Nana-EC]

This is an existing endpoint that lists all the allowances with relation to hbar crypto.
This is distinguished from the /api/v1/accounts/{idOrAliasOrEvmAddress}/allowances/nfts and /api/v1/accounts/{idOrAliasOrEvmAddress}/allowances/tokens endpoints.
See https://testnet.mirrornode.hedera.com/api/v1/docs/