HIP-0000: Delegated Transaction Fee Payment Mechanism

[brendonv]

Abstract:
This proposal extends the existing Approval and Allowance API. It creates a new Allowance that enables Hedera accounts to delegate the payment of transaction fees 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.

Motivation:
The current Hedera ecosystem lacks a native capability for an Owner account to cover transaction fees of a Spender without co-signing for every transaction. This limitation hinders the development of user-friendly applications and services that could benefit from a more flexible transaction fee structure.

User Stories:
As an enterprise user of Hedera, I want the ability to have transaction fees covered by an external account provider so that I don’t have to buy, hold and maintain HBAR balances.

E.g a high volume use case could outsource the management of their account to a separate provider. The separate provider could regularly bill the use case say $1k USD and the provider is then responsible for monitoring, acquiring and delivery HBAR that they need. The the use case can then run their application as per normal, but have the fees debited from the provider.

Specification:
Allowance Mechanism would simply be an extension of the existing API whereby Owner accounts can grant an allowance for Spender accounts. When the Spender incurs network transaction fees, it is debited from the HBAR balance of the Owner.

message PayerAllowance {
AccountID owner = 1;
AccountID spender = 2;
int64 amount = 3;
}

Operation ID & Keys: As part of the basic environment setup, alongside Operator ID & Private keys, introduce an additional configuration for PayMasterID, representing the public account number of the Owner. This would simplify the development environment setup for dApps who plans on using another account to pay for the transaction fees.

If the Spender sets the PayMasterID, and that Owner account has not granted an Allowance to the Spender, the transaction will fail.

If the Spender sets the PayMasterID, and that Owner account has granted an Allowance to the Spender but does not hold sufficient HBAR to pay for the transaction, the transaction will fail.

TODO/assistance needed pseudocode example using Hedera SDK which demonstrates flows described in “Operation ID & Keys”

Permission and Revocation: The Owner account can grant and revoke access to the Spender account at any time, ensuring control over who can debit fees from their account.

Allowance setting: If permission is granted, the Owner’s account will be debited for each transaction initiated by the Spender, facilitating seamless transactions. The allowance limit is also debited as the Spender uses it. Once the Spender has fully depleted the allowance, transactions will fail.

Rationale: Implementing this feature would significantly lower the barrier for new users and developers by simplifying the fee management process. It opens new avenues for dApp developers to abstract transaction fees for their users, fostering a more accessible and user-friendly ecosystem.

Backwards Compatibility: This proposal is designed to be an extension of the existing Hedera services and protocols, ensuring compatibility with current infrastructure while expanding functionality.

Conclusion: By allowing accounts to delegate the payment of transaction fees, Hedera can unlock new potential in dApp development and user engagement, making the network more accessible and efficient for all stakeholders.

This is a draft and needs further technical support and community feedback

[bguiz]

Thanks for submitting this - reviewing!

[brendonv]

thanks @bguiz

[Nana-EC]

Thanks @brendonv
Pretty cool idea.
Is it fair to say this proposal suggests supporting 0 HBAR (& potentially 0 gas) transactions in a manner that no longer requires multi sig flows i.e 2 signers where submitter serves as the payer and nothing more?

Providing some raw thoughts and suggestions below to assist.

[brendonv]

Thanks @Nana-EC much appreciated. Yes that's correct!

[app-matt]

Agreed here - this could be extended to include fees_only as a mechanism to restrict the allowance to fee sponsorship only

[Nana-EC]

I think PayerAllowance above is the same as CryptoAllowance so you could just suggest that for reuse.

[Nana-EC]

You may want a boolean flag on transaction similar to is_approval on HBAR transfers except it needs to be applicable to all transactions to ensure applicability.
Thinking on this 🤔

[app-matt]

Had a little think on this one too and am unsure if this is needed or not 🤔 Will definitely need your input on this one @Nana-EC I reckon when we get onto implementation details.

[Nana-EC]

Either this or maybe the inference on the presence of a sponsoring account ID may be sufficient.
I like the latter better

[app-matt]

Agreed, I prefer the simplicity of that too!

[Nana-EC]

TODO/assistance needed pseudocode example using Hedera SDK which demonstrates flows described in “Operation ID & Keys”

No worries about this as it's more an implementation detail for each SDK language. Rather you'd want to specify any protobuf changes and suggest that the SDK would expose the new properties.
To that avail one potential route is to extend TransactionBody proto something like

message TransactionBody {
  ...

  /**
   * The account a spender is noting has provided prior willingness through an HBAR allowance to sponsor transaction fees
   */
  AccountID fee_sponsor_account_id = 53;
}

This would allow nodes to quickly verify the validity of an allowance claim and if sufficient balance exists.

[brendonv]

ok perfect thank you

[app-matt]

@Nana-EC Agree that this would serve purpose for the implementation of this HIP and would serve as an appropriate place for the network to query if the transaction has fees sponsored 🙏

[Nana-EC]

@brendonv one way to increase the understanding of the proposal is to add a few user flow examples with specific transactions and uses cases to drive the point home.

[brendonv]

Thanks @Nana-EC. At a high level, the flow in this diagram is what I'm looking to achieve. I'm hoping that the Payer can be used for as many transaction types as possible. The existing Hedera API (from HIP336) has the same concepts Owner, Spender, amount, ApproveAllowance, DeleteAllowance, etc. I just want to add a payer/fee sponsor... does that make sense?

[Nana-EC]

Yep, it's clear in my head.
Just you'll need to convince multiple readers to concrete examples help.
Below here' some rough details to add to your diagram

User story
As a DApp hoster I want to cover the transaction fees of another account to allow them to interact with my DApp even with 0 HBARs.

Scenario
To achieve the above Alice would submit a transaction to the network to give Bob an approval of some amount of HBARs that may be used to pay for fees.
From this point on Bob can submit transaction with a flag noting that fees should be deducted from their allowance from Alice.
In this way Bob can submit transactions to the network and Alice will pay the fees so far as Bob has sufficient allowance.
This increase usability and onboarding of users. For example new account could be approved prior to their 1st transaction and their experience on the network will be void of having to go acquire HBARs so far as the have a fee sponsor.

Some thing like the above but maybe better. You can speak to a DEX use case or a specific use case you have that really calls out the user personas, and transaction steps.

[app-matt]

I've pulled together a couple of User stories that I'll share here for feedback 🙏

#1 - Enterprise DApp Operator

User Story:

• As an enterprise DApp operator I want to provide a Web3 service / product but do not want to handle crypto assets as part of the operational costs.

Scenario

1. The enterprise DApp operator signs a commercial off-chain agreement with a crypto intermediary to service their crypto purchases for the operation of their DApp.
   1.1 The crypto intermediary whitelists the enterprise DApp operators primary Hedera account Id on their management platform (for ongoing management platforms needs).
   1.2 The crypto intermediaries signs and submits an AccountAllowanceApproveTransaction (using a new method of approveHbarFeeAllowance) to provide an on-chain reference to the agreement which designates the enterprise DApp operator as the spender.
   1.2.1 The fee for this transaction is covered by the crypto intermediary.
   1.2.2 The new approveHbarFeeAllowance method could allow for both fixed and unlimited values.
2. The enterprise DApp operator configures the Crypto intermediary as their Fee Sponsor for all HBAR transaction / query costs.
   2.1. E.g. Client.setFeeSponsor()
3. The enterprise DApp operator submits a signed transaction to the network, the transaction body is interrogated (by the network) for the fee_sponsor_account_id and the Fee Sponsors account identified (where present).
4. The Fee Sponsor’s Account is interrogated (by the network) for a Fee Allowance using the enterprise DApp operators account Id.
   4.1 The transaction succeeds if the allowance is present and has either:
   4.1.1 unlimited remaining allowance; or
   4.1.2 A remaining balance greater than the current transaction fee
   4.2. Otherwise the transaction fails.
5. Where the transaction succeeds, the HBAR fees for the transaction are deducted from the Fee Sponsors account.
   5.1 The enterprise DApp operators HBAR account balance (used to sign the transaction) is left untouched
   5.2 The enterprise DApp operator’s HBAR balance can be zero.
6. The transaction is successful.

#2 - Enterprise Software Provider

User Story:

• As a software provider I want to cover the transaction fees of a customer’s account to allow them to interact with my Software even with 0 HBARs in their account.

Scenario:

1. The software provider signs an AccountAllowanceApproveTransaction (using a new method of approveHbarFeeAllowance) which designates the customer as the spender.
   1.1 The fee for this transaction is covered by the software provider.
   1.2 The new approveHbarFeeAllowance method could allow for both fixed and unlimited values.
2. The software provider sets the customer’s fee sponsor as the software provider’s dedicated fee account (and synchronizes this with customer’s software for use during transaction submission).
3. The customer submits a signed transaction to the network, the transaction body is interrogated (by the network) for the fee_sponsor_account_id and the Fee Sponsors account identified (where present).
4. The Fee Sponsor’s Account is interrogated (by the network) for a Fee Allowance using the customer’s account Id.
   4.1 The transaction succeeds if the allowance is present and has either:
   4.1.1 unlimited remaining allowance; or
   4.1.2 A remaining balance greater than the current transaction fee
   4.2 Otherwise the transaction fails.
5. Where the transaction succeeds, the HBAR fees for the transaction are deducted from the Fee Sponsors account (i.e. the software provider).
   5.1 The customer’s HBAR account balance (used to sign the transaction) is left untouched
   5.2 The customer’s HBAR balance can be zero.
6. The transaction is successful.

[app-matt]

For Use Case #2 I can see a potential loop hole for abuse if the sponsored account isn't custodial, where the fee allowance is granted and then the account holder could use this privilege for other transactions outside of the software. Might be worth capturing this as a caveat.

[brendonv]

@nodlRob as discussed tagging @gregscullard

[Reccetech]

I recently posted this code snippet that shows a potential flow using our existing capabilities. As mentioned in this proposal this flow suffers from the issue that the Payer needs to sign every transaction and there needs to be infrastructure for the owner to pass the frozen transaction to the payer, and then after the payer or the owner will need to submit the transaction in <3min.
https://github.com/hedera-dev/hedera-code-snippets/tree/main/crypto-intermediary

[Reccetech]

I like this proposal - but I would like to talk through the deltas between the current approveHbarAllowance functionality and the above proposal.
Just to align with the current allowance terminology I am going to use "owner" which is the account submitting the transactions, and "payer" which if the account paying for the transactions in hbar.

The above proposal designates a payer account. Under this arrangement potentially all the HBAR in the payer account could be consumed by the owner. This is why the proposal also needs the ability to revoke that permission. Alternatively the current Allowance functionality permits a certain # of HBAR to be spent by the owner - with no ability to revoke that permission. It would be good to understand the pros and cons of both approaches to see what is preferred.

I think the above question should be brought into the use case of a "crypto intermediary". You have a company Acme which is providing crypto intermediary services to their customers A, B, C. So owners A,B,C perform a range of Hedera transactions which Acme pays for though the payer accounts. So to me the question is how Acme "recharges" those payer accounts and manages the lifecycle.

Proposal 1:
If the Account Allowance is account based - then Acme would need to:

1. Setup Payee accounts for A, B, & C.
2. Submit a transaction authorizing payment for transactions of accounts of owners A,B,C.
3. Acme would need to monitor the HBAR balance of the payer accounts and if the balance got to XX level - recharge the accounts with more HBAR funds.
4. If companies A,B,or C end their relationship with Acme - Acme would need to create a transaction revoking the payee authorization or just let the accounts run out of funds.

Proposal 2:
If however the Account Allowance is for a set amount of HBAR - then Acme would need to:

1. Setup Payee accounts for A, B, & C to make consumption monitoring easier.
2. Submit a transaction authorizing accounts A,B,C to spend XX HBAR from the respective Payee account
3. Acme would need to monitor that balance of HBAR balance of the payer account and if the amount removed got to a threshold of the HBAR amount authorized in #2 then ensure there are enough funds in the payee account and then create a new transaction further authorizing XX HBAR. We would have to take into consideration a situation where there are overlapping authorizations. I suppose a new transaction would supersede any previous allowance transactions.
4. If companies A,B,C end their relationship with Acme - Acme would allow the current authorizing transaction to be used - and then create no further authorizing transactions.

Thoughts and feedback appreciated.

[brendonv]

@Reccetech thanks very much for your input here - much appreciated!

The main difference between the current approveHbarAllowance functionality and the above proposal is effectively a narrowing of the allowance to cover ONLY the payment of fees of a 'spender' account, and not transfers.

Perhaps the option that would give the most flexibility would give the ability to revoke the permission AND set a spend allowance. This would make the setup in both proposal 1 and proposal 2 feasible. Even if you only intended to use the account method in proposal one, you could set a VERY high limit making it operate in a similar way. Yes any updates to the permission should supersede the old one.

Having an allowance would also give the added benefit of granting multiple allowances from a single account (rather that creating new accounts for each individual user for ACME). Some users might have a preference for the transaction payments to be pooled with other users and not be separately identifiable from a single account.

I think not being being able to revoke the permission would be commercially unviable for ACME. Practically there could be a range of reason why that could be necessary.

[Reccetech]

Regarding above.
"Having an allowance would also give the added benefit of granting multiple allowances from a single account (rather that creating new accounts for each individual user for ACME). Some users might have a preference for the transaction payments to be pooled with other users and not be separately identifiable from a single account."

The question in my mind is how would you monitor that the balance of the allowance for a given customer in the above scenario?
I think a worst case scenario is that a customer runs of of their allowance and can no longer make transactions while they wait for Alice to generate a new allowance.

[brendonv]

@Reccetech Yes good point, it assumes that the amount remaining in the allowance can be queried in the same way we currently do with CryptoAllowance. ACME would be responsible for updating the allowances to reflect the commitments to the user. This would be complicated further by the fact a commercial arrangement is presumably is USD, but the HBAR required to complete transactions fluctuates on an hourly basis. It would be a complex implementation, but technically possible.

[app-matt]

Couple of thoughts here:

1. Unlimited allowances could sidestep any issues here and prevent service loss.
2. Where allowances are not unlimited, as long as the allowance can be queried (as would be needed for the network to validate an appropriate allowance is available to use) then the fee sponsor can be held responsible for monitoring this and prompting the sponsored account to update their allowance to avoid losing access to their specific services.
   2.1 This can be handled off-chain using existing messaging solutions.
   2.2 The sponsored account would need to provide a fee budget through an agreed approach with the sponsor.
   2.3 The sponsor, having verified funds have been received, can then sign and submit a new AccountAllowanceApproveTransaction to update the allowance and ensure the sponsored account's services remain in operation.

[ty-swirldslabs]

This is a very cool idea @brendonv! It could help reduce onboarding friction for big use cases. That diagram is a great breakdown of how this could be used.

My biggest question for feasibility is:

• How will the user with 0 hbar sign the transaction without spending any fees?

Do we have a mechanism where it's free for a account to sign the transaction allowing this fee transfer?

I know in @Reccetech example the transaction was frozen then returned. Is this a new method or already supported method of transaction passing that we would automate on the network level for this feature?

[brendonv]

Thanks @ty-swirldslabs! Appreciate you jumping in here. I don't think their is current functionality for this (could be wrong) and open to ideas as to how this could best work. The Spender will need to sign with their private key, but the transaction body (or elsewhere in the environment setup?) will direct the network to debit the Owner account rather than the Spender, as long as their is a valid allowance granted. Perhaps extending the TransactionBody proto as suggested by @Nana-EC above

[app-matt]

Couple of thoughts here:

• If the mechanism to setup this configuration is that: a new fee allowance transaction is signed and submitted by the sponsor which designates the sponsored account. Then the sponsored account does not need to sign / submit any transactions prior to the fee approval being in place (then can simply configure the fee sponsor as part of their client configuration).
• However, if the mechanism to setup this configuration requires a signature from the sponsored account, this could be done using the sponsor’s platform capabilities where the sponsor pays for the transaction and the sponsored account is simply connecting their wallet and signing the AccountAllowanceApproveTransaction. Much like an AppNet architecture.

[Nana-EC]

My intention was that the account being sponsored does not take part in the allowance assignment. Just as an hbar allowance can be assigned to anybody so would a transaction fee allowance.
My thought is the structure would maintain the allowances standard and this is just another type of allowance.

[app-matt]

Agreed @Nana-EC - I think this would be more consistent with the current approach

[gregscullard]

This should also support queries, not just transactions ?

[app-matt]

Agree that this change should cover costs for both transactions and queries. Could the approach to queries be implemented in a similar way to Nana’s suggestion for transactions (including a fee_sponsor_account_id in the transaction body protobuf)?

For example including a fee_sponsor_account_id in the query protobuf that can be used to validate a fee allowance and where fees should be debited from?

What do you think? 🤔

[Nana-EC]

Seems reasonable and consistent to also add fee_sponsor_account_id to the query body. In this way devs have a consistent experience across transactions and queries

[gregscullard]

Placeholder for discussion, what does the TransactionId become, historically, the accountId in the TransactionId is the payer for the transaction. If a transaction's fee is sponsored by another account, does the TransactionId need to specify that accountId, or remain the same (the account that submitted the transaction)

• I feel it should remain the same, but wonder if anyone is assuming that this account is always the payer, which may not be true when this HIP is implemented.

[bugbytesinc]

This can break a lot of analytics that already exists. Backwards/Fowrwards compatibility might be a nightmare, especially for mirror nodes and systems that consume mirror node information.

[iron4548]

Just a thought - If there were multiple high-volume use cases submitting transactions to random nodes and the transaction ID all belong to the same delegated payer account, wouldn't that increase the possibility of DUPLICATE_TRANSACTION compared to the transaction ID belonging to the signer account?

[app-matt]

IMO, this should remain the same, logically the submitting account is still paying for the transaction (just by proxy).

[Nana-EC]

Remaining the same seems appropriate.
Today the accountId refers to the submitter and payer by inference.
In this case the transactionId would still clearly label the submitter but the payer would be designated in the transaction/query body for clarity.
Additionally, the transferList in the record would also highlight who was charged the fee.

[gregscullard]

I also like the ability to have an unlimited allowance, I can manage the actual allowance by managing the balance of the account being allowed, I don't need to both keep a balance in the account and repeatedly update allowances

[app-matt]

I think both options have their merit, and will find their place in different implementations. Providing both fixed and unlimited allowances will allow for a greater variety of implementations. 🙏

[bugbytesinc]

You could just allow piggy-back transfer of funds (payments) for any transaction and utilize the existing allowances mechanism already in place. I believe the protocol already supports this for Queries due to the way query payments are structured presently.

[gregscullard]

Existing allowances don't restrict use of allowances for transaction fee payments only, if you allow me some hbar now, I can send it to an exchange. The idea of this HIP as I understand it is to specifically allow spending on transaction fees and nothing else (although there is a question over royalties and fixed fees on token transfers... should that be covered by the allowance or not).

[brendonv]

Yes thats correct, thanks Greg

[app-matt]

I think both options have their merit, and will find their place in different implementations. Providing both fixed and unlimited allowances will allow for a greater variety of implementations. (Apologies this comment was meant to be in response to Greg's in the thread above, apology for any confusion.)

[Nana-EC]

@ty-swirldslabs suggested a similar item around the covering of custom fees (royalty fees are a type of custom fee). I beleive we could extend the idea and in the HIP that would give this discussion structure we would propose 2 new types of allowances - TransactionFeeAllowance and CustomFeeAllowance.
Both open up a world of possibilities for smoother user experience.

[app-matt]

Agreed, I think missing this out would undoubtedly cause confusion, great suggestion! Thank you @ty-swirldslabs

[app-matt]

Hi All, I'll be jumping into a few of the threads here to support this HIP from an AP+ perspective, so apologies in advance for multiple notifications! 😄

[brendonv]

Thanks @app-matt & everyone. This has shaped up really nicely. The input and assistance is much appreciated.