# Polkadot Builder Party - Hackathon Idea List

**URL:** <https://forum.polkadot.network/t/polkadot-builder-party-hackathon-idea-list/14653>\
**Category:** Miscellaneous\
**Created:** [August 28, 2025, 8:15am UTC](https://forum.polkadot.network/t/polkadot-builder-party-hackathon-idea-list/14653 "2025-08-28T08:15:09Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![josep](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/josep/32/2619_2.png) [@josep](https://forum.polkadot.network/u/josep)\
**Post date:** [September 27, 2025, 9:14am UTC](https://forum.polkadot.network/t/polkadot-builder-party-hackathon-idea-list/14653/16 "2025-09-27T09:14:23Z")

</div>

> [@joepetrowski](#):
>
> - A plugin / library so that every wallet / UI supports fee payment in any asset.

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](https://papi.how/signers#polkadotsigner), similar to the one we used for [remote proxies](https://forum.polkadot.network/t/remote-proxies-for-everyone/13529#p-30752-why-this-is-even-possible-5). 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`)](https://forum.polkadot.network/t/toward-an-interoperable-transaction-interface-introducing-createtransaction/15060), 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.

> [@Alex\_Houdz](#):
>
> We like all the ideas listed above, with a special love for @joepetrowski ‘s idea:  
> _”A plugin/library so every wallet/UI supports fee payment in any asset”  
> =\>_ **This idea could turn into a $30K grant after the hackathon, as part of our goal to improve UX & DevEx.**

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.

---

_[View the full topic](https://forum.polkadot.network/t/polkadot-builder-party-hackathon-idea-list/14653)._