I think that being able to offer miners fees in PUSD and MUSD could be a positive thing for the BCH ecosystem (this may be true for other CashTokens as well, and I don’t think being able to do that would harm BCH as a native currency in any way). At nodes level, I suppose a tool/option could be added so that miners can enable accepting tokens and the nodes can relay transactions that pay fees with tokens (specifying which ones they accept, what amounts per byte, etc). In other words, rather than requiring a major protocol upgrade, we can technically see a token output in a transaction which anyone-can-claim as a reward for a miner (or whoever pays the tx fee with BCH).
This reminds me that, when similar ideas were proposed for SLP tokens, the community discussed a solution called “Postage Protocol”. The basic idea was that a server (integrated as a service in one or more wallets) could accept those tokens/stablecoins and pay the fee in BCH, earning a small difference (like a post office making money by selling small postage stamps). I think it’s a valid solution to remember/consider. I think the idea of the “Postage Protocol” is a valid idea to consider and remember…
If I remember correctly, it was related to Badger Wallet (an SLP wallet from Bitcoin./com).
On the other hand, Selene Wallet recently launched its "stablecoin mode," which allows, at the application level, a behavior in which, if you receive BCH with stablecoin mode activated, that balance is converted to the stablecoin you have selected (PUSD or MUSD), and when you pay to a no-token-aware BCH address, the wallet converts the amount you send to BCH (and that is what the person receives).
Based on my observation of Selene Wallet, the wallet retains a small portion of BCH during the swap to cover the tx fee costs (please correct me if I’m mistaken on this specific detail @kzKallisti @BitcoinCashPodcast ), which means the user doesn’t need to worry about holding BCH themselves.
Furthermore, if I understand correctly, all CashTokens transactions could, in theory, include outputs with enough BCH to cover the fees for a future standard transaction (in the event that the user lacks a sufficient balance). This, once again, leaves room for solutions to be implemented at the wallet level.
Regarding “EIP-7702, a new standard that enhances EOAs (Externally Owned Accounts) with smart account features without giving up self-custody”, it’s my understanding that this specific functionality was exploited in the recent hack of Binance. In that sense, I believe we cannot simply copy every EVM innovation—whether from Ethereum or Binance Smart Chain—because not all of them are necessarily secure enough for the powerful yet conservative scripting system of BCH.
But the general idea of not having to worry about having BCH to pay the transaction fee sounds valid to me for improving the UX of people without much technical knowledge.
Considering that, I think we can consider that many of the possible solutions, or the solutions we need, may come at the wallet and service level, rather than by changing the BCH consensus. And I think this conversation can give us a starting point to be able to track down solutions that can be applied, or even to mention which solutions have already been implemented or are underway…
