I’ve spent a fair bit of time exploring how to make this real. Short version: the ideal place for this logic is inside wallets/extensions (and, for offline flows, in the tools that talk to them). Today, though, native wallet support isn’t feasible because of how dApps communicate with wallets. Solving it “from the outside” is technically possible, but only in a library-specific way and with a rather suboptimal UX.
If someone wants to pursue a library-specific path right now, it’s absolutely doable with PAPI by writing a PolkadotSigner enhancer/middleware, similar to the one we used for remote proxies. You can even enhance the whole client so the middleware is always applied whenever a transaction is created.
The more durable route is to standardize the interface for creating transactions. With an interoperable transaction interface (see: createTransaction), this becomes solvable in a generic, library-agnostic way. Also, wallets could then integrate this functionality natively. That’s not possible with the current signPayload pattern that dApps use to talk to wallets.
One scope note: to my knowledge, paying fees via the ChargeAssetTxPayment extension is supported on AssetHub today. It may be prudent to limit the scope to transactions created for chains that have the ChargeAssetTxPayment extension available.
As I’ve told you in the past: throwing money at patches can unintentionally cement the underlying architectural issues that are the root-cause of many of our UX challenges.
It would be wiser to invest these resources into standardizing the infrastructure and interfaces that the ecosystem needs to unlock truly seamless UX and DevEx, rather than funding stopgap solutions that might ossify today’s limitations.