TL;DR Building DApps on Polkadot can result in suboptimal UX due to the lack of atomic multi-call flows where later actions depend on the state changes from earlier ones. Could pallet-revive (or more generally, smart contracts with access to runtime pallets) help solve this? The Problem: Chained Transactions Kill UX One of the biggest pain points when developing DApps on Polkadot is the inability to perform certain actions atomically. Often, we have to: Submit a transaction. Wait for its block-inclusion (and sometimes finalization). Extract some state from it (or read some events). Submit a second transaction. This flow introduces friction and complexity that significantly harms user experience. A Real Example: KSM RFP #2 RFP-launcher Dapp While building the RFP-launcher, we needed to do the following in one go: Create a bounty. Submit a referendum for that bounty. Plus a few other related calls. Ideally, all of this would happen in one transaction. But here’s what we ran into: Option 1: Guessing the Bounty ID Since bounty IDs are incrementally assigned, we could try to guess the next ID and use it in the same batch. Most of the time this works — but if someone else creates a bounty just before our transaction is included, everything breaks: we end up referencing the wrong bounty in the referendum. Technically, we could detect this in the DApp and guide the user through a recovery flow. But that’s still a terrible experience. Option 2: Sequential Transactions Instead, we create the bounty in one transaction, wait for it to be included, extract the ID from the emitted event, and then send a second transaction with the rest of the operations. Safer, but introduces delay, complexity, and additional signing — not great UX either. This Isn’t Just About Bounties… This pattern pops up all over Polkadot: you want to conditionally chain actions where subsequent calls depend on freshly-updated state. Current options are either unsafe or clunky. Can pallet-revive solve this? If smart contracts deployed through pallet-revive could tap into other pallets functionalities, we could deploy a contract that: Creates the bounty. Grabs the real ID immediately. Submits the referendum referencing the correct bounty — all in one atomic call. This would open up far more powerful transaction flows than what’s currently feasible today. Is This Possible Today? I might be wrong here, but my assumption is this isn’t currently viable due to how contracts and pallets differ: FRAME pallets: Use weight-based fees estimation (run on WASM). Contracts (e.g., Ink! via revive): Use gas-based metering (run on PVM). This separation likely prevents contracts from invoking pallet logic directly. I could be wrong, though… I really wish to be wrong! But — if Ink! (on pallet-revive) offered a safe interface to tap into other pallets, it could be a game-changer. Is Anyone Exploring This? Is there ongoing work in this direction? Could a smart contract system bridge this gap to allow conditional flows without race conditions or multi-transaction UX hurdles? :folded_hands: Would love to hear if someone is exploring this or if there are design discussions happening around it. cc: @Alex @alejandro @peterw PS: Yes, I’m aware that in the bounty case we could theoretically refactor things — e.g., by making the bounty ID deterministic (like, being a hash of the bounty info). But that’s a major refactor and doesn’t generalize well. The core issue remains: we need a clean way to express “do X, then Y based on X’s result” without breaking the UX.

I think Josep’s sentence about the “two unappealing options” wasn’t a wish-list of both things; he meant that each option, on its own, is unattractive: Expose only a tiny, minimal interface: Great for safety, but not so great for builders. If the precompile shows very little, contracts still need kludgy off-chain workarounds or multi-tx flows—exactly the UX pain he was highlighting. Expose richer functionality via precompiles: Great for short-term Solidity onboarding, dangerous for Polkadot’s long-term evolution. Because precompile ABIs must stay frozen, every future runtime breakthrough would have to preserve yesterday’s interface—or fragment state across new addresses. Cyrill summed this up well in his post (“we do not break contract-space”). Polkadot’s edge has always been its freedom to evolve rapidly at the protocol layer; locking system pallets behind immutable ABIs risks dulling that edge. The problem To me, the technical debate points to a deeper problem: communication A while back the community agreed on the Plaza strategy— Polkadot pallets + EVM hub. Back then nobody could map every downstream consequence. Inside Parity they most probably have been wrestling with real-world constraints, trade-offs, and deadlines. From the outside, most of us only glimpse the finished decision: “Polkadot Hub will launch with NFTs, tokens, XCM and governance precompiles.” By the time external teams understand the fallout—UX trade-offs, ABI lock-in, economic impacts—those decisions already feel baked. In short: the rest of the ecosystem can’t help course-correct if we don’t see the course map until the ship has sailed. A way forward Polkadot is a decentralised network of teams—from one-person dev shops to VC-backed companies—who all care deeply about its success. If we treat Hub design as an open RFC process instead of an internal deliverable, we can: Crowd-source edge-case feedback before ABIs freeze. Share the rationale behind tough calls (security, resourcing, timelines). Align the Hub’s feature set with real DApp builders’ needs, not just our guesses. Polkadot Hub can be a huge win—if we keep the conversation two-way. Together we should hammer out which precompiles truly belong in Hub v1, which can stay experimental (lets use Paseo and Kusama!!!), and how we’ll revisit the set without kneecapping innovation down the road.

[image] Alex: You are just asking for two conflicting things: Expose a very rich detailed API surface which is absolutely stable. It is just not possible. Not exactly. I wasn’t asking for that — I was pointing out that both of the currently available options are unappealing, as I wrote explicitly: [image] josep: In practice, there seem to be two unappealing options Let me clarify my point further: What I’m trying to highlight is something that, quite frankly, should be obvious: there’s too much of an impedance mismatch between Solidity-based contracts and the current FRAME based runtime. That mismatch makes it extremely unlikely that Solidity contracts will ever interact meaningfully with complex pallet logic (e.g., staking, governance, etc.). Sure, precompiles can be very helpful for exposing basic asset-level functionality, and that’s nice and all… but let’s not fool ourselves pretending that these precompiles can also fully support complex, stateful flows like staking or governance. I remain especially skeptical about how XCM-related precompiles will pan out… but I’ll withhold judgment until I see something concrete. [image] Alex: And just because it doesn’t expose every little detail it doesn’t mean it is useless. That’s a bit of a straw man. I never said “every little detail.” I actually mentioned basic, essential staking operations… like rebagging, reward prediction, validator analytics (so that nominators can make informed decisions when nominating), era information, etc. These aren’t edge cases. They’re fundamental building blocks of any real staking UX. If you believe the current precompiles are sufficient to build a meaningful EVM-based staking DApp on Polkadot, then please have someone build one and show it to me. I would love to be proven wrong and stand corrected. [image] Alex: You can always cautiously expand the functionality Can you, though? The more functionality you expose, the more brittle the interface becomes… and the harder it is to evolve the underlying pallets without introducing breaking changes. This is particularly risky for areas like governance and staking, which are still actively evolving. I’m not trying to be contrarian here, I’m just trying to be realistic. My concern isn’t about technical feasibility alone, but about maintainability and practical developer experience. Right now, I don’t see a clear path for Solidity contracts to deeply integrate with Polkadot’s ever-evolving runtimes. Time will tell, of course, and I genuinely hope I’m proven wrong.

[image] josep: I’m not trying to be contrarian here Sure as hell sounds like you are. I don’t see any constructive criticism here. Just a rant how everything is unappealing and how it will never work out because of some “impedance mismatch”. Would really appreciate to have a discussion with you and not ChatGPT. The pre-compiles are not meant to be a replacement for off chain code. They are meant to facilitate things like a DAO and such. And if you see them lacking important APIs please comment in the PR with some constructive feedback.

[image] Alex: The pre-compiles are not meant to be a replacement for off chain code. :thinking: Ok, so perhaps there have been a misunderstanding here… I was under the impression that the goal was to empower Ethereum DApp devs to use their usual tooling (Viem, or Etherjs, or Web3js, etc.) to interact directly with Polkadot AssetHub. E.g. build a staking DApp entirely with Ethereum tools. What I’m hearing now is more like: since Solidity contracts can’t expose every bit of functionality you’d need for a full-featured DApp on AssetHub, Ethereum DApp devs will have to either: Mix their Ethereum tooling with non-Ethereum tools to bridge the gaps, Lean heavily on indexers/aggregators, Or most likely, do both. Is that a fair summary of what you’re saying? If that is not what you are saying, then could you please put yourself in the shoes of an Ethereum DApp developer who wants to build on Polkadot AssetHub, and explain how they will manage to build a DApp which interacts with Polkadot’s core functionalities? :folded_hands:

[image] Daanvdplas: … The problem To me, the technical debate points to a deeper problem: communication A while back the community agreed on the Plaza strategy— Polkadot pallets + EVM hub. Back then nobody could map every downstream consequence. Inside Parity they most probably have been wrestling with real-world constraints, trade-offs, and deadlines. From the outside, most of us only glimpse the finished decision: “Polkadot Hub will launch with NFTs, tokens, XCM and governance precompiles.” By the time external teams understand the fallout—UX trade-offs, ABI lock-in, economic impacts—those decisions already feel baked. In short: the rest of the ecosystem can’t help course-correct if we don’t see the course map until the ship has sailed. You are very welcome to suggest new features and to contribute to the code. We are very busy up to September but if you have concrete asks please state them and ideally add a PR. Polkadot is late to the EVM game. After we push the fist version to Polkadot, we will open up the process more. There is a long wishlist of things which are not in the V1 and collaboration is the way to decide what goes in the V2: from performance improvements, which precompiles, enhanced compatibility etc Pierre Nit: APIs are rarely perfect and even less when they need to keep compatibility with the past. @Alex did explain well what it is the case.

[image] josep: If that is not what you are saying, then could you please put yourself in the shoes of an Ethereum DApp developer who wants to build on Polkadot AssetHub, and explain how they will manage to build a DApp which interacts with Polkadot’s core functionalities? :folded_hands: Maybe you could help and give us a list of things that should happen in order of priority to be a “good platform” for an Eth Dapp dev?

[image] josep: I was under the impression that the goal was to empower Ethereum DApp devs to use their usual tooling (Viem, or Etherjs, or Web3js, etc.) to interact directly with Polkadot AssetHub. E.g. build a staking DApp entirely with Ethereum tools. The most important goal is to allow Ethereum native Apps to run with minimal changes on the PolkadotHub. And yes, those can use their existing javascript tooling. I don’t think people already in the Polkadot ecosystem should migrate away from Papi or Polkadot.js in order to build a staking Dapp. That said, my hope is that the staking pre-compile exposes enough functionality to build a staking Dapp using Viem if people want to. Not sure if that can be done from the got go or we need to iterate. If you have insight into which functions are missing please speak up now. [image] josep: What I’m hearing now is more like: since Solidity contracts can’t expose every bit of functionality you’d need for a full-featured DApp on AssetHub, Ethereum DApp devs will have to either: Mix their Ethereum tooling with non-Ethereum tools to bridge the gaps, Lean heavily on indexers/aggregators, Or most likely, do both. Is that a fair summary of what you’re saying? No. I mean that we need to think hard of how level level the pre-compile API can be so we can guarantee its stability. And this is probably not possible in the first deliverable. The earlier we get feedback the better (from you for example). We should expose as much as we have to and as little as we can to still allow writing a useful frontend. This includes simple things like error codes: In the pre-compile we should just map them to success/failure since it will be hard to keep them stable. Error handling should not happen on-chain. I can’t predict all the possible use cases. And I don’t have time to put myself in a builders shoes, sorry. I rely on feedback. Therefore what I can do is start with the minimal API I can guarantee to be stable. And add more stuff on demand. The last thing we want is top break existing Apps. As a matter of fact this will be considered a bug.

:warning: DISCLAIMER I’ve been accused of using ChatGPT to generate my replies in this post. Just to be crystal clear: every idea, argument, and point made in my responses is mine. I do use ChatGPT to help me rephrase my thoughts, not to generate them. English isn’t my first language, and I tend to write in a very direct, to-the-point, and sometimes confrontational way that some people perceive as aggressive. Frankly, I use ChatGPT to soften the tone so that oversensitive people (aka “snowflakes”) can focus on the what instead of getting distracted by the how. If tone matters to you more than substance, then feel free to copy-paste what’s coming below into ChatGPT and ask: “Can you rephrase this so that it doesn’t come across as aggressive?” That’s literally what I’ve been doing. You’ve been warned. If you choose not to do that, please don’t come back whining about tone. Let’s keep the focus where it belongs: on the actual arguments. [image] Alex: I can’t predict all the possible use cases. And I don’t have time to put myself in a builders shoes, sorry. This right here is the heart of the problem. If you’re not willing to think like the people who actually use what you are building, then you’re building in a vacuum. From your ivory tower it might feel like you’re crafting a masterpiece, but without walking a mile in a DApp developer’s shoes, you’re almost guaranteed to miss the mark. Put simply: stop designing for hypotheticals and start designing for your users. If you can’t (or won’t) empathize with the builders, then don’t be surprised when your “solutions” end up gathering dust. [image] pierreaubert: Maybe you could help and give us a list of things that should happen in order of priority to be a “good platform” for an Eth Dapp dev? I surely can! Gosh, I’m glad you asked… Step one (and this really shouldn’t be controversial) is to define the scope of what should realistically be achievable using only Ethereum tooling and Solidity smart contracts. Because let’s be honest: an Ethereum DApp built with Ethereum tools alone (and using their wallets) is never going be able to leverage the full potential of Polkadot. And there’s one especially glaring limitation that comes to mind: multi-chain DApps. You see, Ethereum tooling was never designed with multi-chain DApps in mind. I’m sure you’ve tried your fair share of Ethereum DApps (like me) and you’ve probably noticed the moment your wallet isn’t connected to the “right” network, the DApp immediately nags you to switch. That’s not a coincidence. Most Ethereum DApps rely on wallets as their primary JSON-RPC provider, and those wallets follow the EIP-1193 spec, which includes things like the chainChanged event. In practice, this means your provider is tied to a single chain at any given moment. Now, sure technically you could build a multi-chain DApp with Ethereum tooling. You’d spin up multiple providers, use custom infrastructure, and juggle a few headaches. But when it’s time to actually sign a transaction… ups! you’re back to using the wallet provider… and that’s where things become a massive PITA. Anyhow, all of that is actually a moot point. Because realistically, not every Polkadot parachain is going to implement pallet-revive, spin up the extra infrastructure needed to support the Ethereum JSON-RPC endpoints, and expose a full set of Solidity precompiles tailored to their own custom runtime logic. So let’s be real: this isn’t happening in the foreseeable future. Also worth noting: no one in Ethereum land is working on multi-chain DApp tooling either. So yeah, I think it’s fair to draw the line and say: multi-chain DApps are out of scope for anything that sticks to Ethereum tooling. If you’re targeting cross-chain functionality: Coretime, Hydration, People Chain, AssetHub… you name it, then you’re gonna need Polkadot-specific tools. Period. Let that sink in for a second. If you’re building a DApp that touches multiple parachains, you’re already forced to reach for Polkadot-specific tools. At that point, why bother dragging Ethereum tooling into the mix? It becomes pure overhead. And yes, eventually PAPI will offer a Solidity SDK, the same way we have Ink! SDK. But let’s be honest -if I were building a serious multi-chain DApp, I’d much rather use Ink! contracts. So, I think that it’s a bit sad that Ink! is being treated as a second class citizen, but I digress, sorry. So, I think it’s safe to say we’ve ruled out multi-chain DApps. Which brings us to the next obvious question: What else should be out of scope? Excellent question, @pierreaubert. So glad you asked! It’s pretty obvious to me that anything outside of asset management should be completely out of scope. At least for now. For real: keep the API surface of these precompiles as small as humanly possible. I strongly recommend excluding everything that isn’t directly tied to asset handling. Focus only on making Polkadot assets compliant with established Ethereum standards like ERC-20, ERC-721, etc. Nothing else. Pick the standards you want to support, and then very carefully implement the minimal interface required to meet those standards, and only those standards. Once that’s done, the next step isn’t “what else can we cram in?”—it’s proving that this minimal approach actually works. And please, for the love of all that is modular, don’t try to expand anything until you’ve validated that core hypothesis. But how do we prove it worked? I’m so glad you asked, @pierreaubert. You’re really on a roll today. Here’s one idea: deploy a well-known Ethereum DApp as-is, without any rewrites, on Westend AssetHub. Pick something that’s asset-heavy and leans fully into the standards you’ve chosen to support. A perfect example would be deploying the open-source contracts and frontend of Uniswap into Westend AH. Have someone at Parity do it (or better yet, outsource it to a real-world Ethereum team to get a more honest take on DX and compatibility). If that DApp can be deployed and used without major compromises, then… CONGRATS! you’ve got a win. Only then should expanding the precompiles even be on the table. But of course, that leads to the real question: How should precompiles that touch the rest of Polkadot’s core functionality be designed? Yet another great question, @pierreaubert! You’re on fire today. Let’s be honest: these precompiles are going to have far-reaching consequences. Once introduced, they will severely constrain how things can evolve, because backwards compatibility becomes a hard requirement. Given that, I’m afraid that there’s only one sane path forward: Start by carefully and methodically defining a set of standardized interfaces, based on real, long-term use cases… interfaces that are thoughtfully discussed, scrutinized, and agreed upon by the community of experts (and just to be super clear: I’m not referring to protocol developers at Parity living in their comfy ivory towers). And look, I’ll just say it: this is something that Polkadot has historically struggled with. We’ve never had a strong culture of defining durable, community-driven standards. I genuinely wish we had a Foundation that excelled at promoting standards, but sadly: we don’t. That said, this is an incredible opportunity to start changing that. A moment to build some real muscle around open standards. So, please: don’t waste time and resources rushing out precompiles that no one’s sure how to use, when to use, or whether they’ll even survive runtime upgrades. First, define the flows and interfaces that are built to last. Once we have that clarity, then and only then should we start thinking about how those standards could map onto minimal Solidity-facing precompiles. The last step would be to deliver an Ethereum DApp on Polkadot that showcases the success of these new standards and contracts (eg a fully fledged Staking DApp) So, to summarize, here’s what I believe should happen in order of priority (as you asked :saluting_face:): Define a clear scope and set of realistic expectations. Understand both the limitations and possibilities of Ethereum-based DApps on Polkadot. Don’t overpromise what can’t be delivered. Build only the essential precompiles, those strictly needed to comply with established, widely adopted Ethereum standards (e.g., ERC-20, ERC-721) that AssetHub should support out of the gate. Prove it works. Deploy a real, standard Ethereum DApp on Westend AssetHub using those precompiles (Uniswap, Aave, SushiSwap, whatever). No shortcuts. No “hello world” demos. Show the thing actually running. If -and only if- that works, begin designing standards for other parts of the Polkadot ecosystem like staking and governance. But do so with a deep awareness that these areas are evolving, and any standards must leave room for growth. Craft minimal, durable precompiles based on those standards. Showcase success again: this time with a full-fledged DApp that exercises those new interfaces. A proper staking dashboard, for example, that actually works using just the Ethereum tooling and the new precompiles. Honestly, I’d be shocked if we even make it to step 3 before the year is over. And frankly, even if we do, I’d be extremely cautious about pushing beyond that. Like it or not, the Ethereum tooling stack will never unlock the full potential of Polkadot, not without major compromises. That said, I genuinely love what’s happening on AssetHub -especially the idea of having contracts available out of the box. I just wish those contracts could also power the real-world use cases we actually need… like the concrete example that kicked off this forum post. I think that Ink! supports upgradable/versioned contracts, and from what @Daanvdplas has shared, Pop-API has been working on another approach. But if everything is coupled to minimalist Solidity precompiles, we’re screwed. Maybe I’m missing something-but until there’s a path for more sophisticated flows, we’ll keep bumping against the same limitations. Bottom line: I love AssetHub’s momentum, but please let’s deliver contracts that aren’t just a comfort blanket for Ethereum devs, let’s build something that solves our real problems, too.

[image] josep: I surely can! Gosh, I’m glad you asked… Excellent question, @pierreaubert. So glad you asked! I’m so glad you asked, @pierreaubert. You’re really on a roll today. Yet another great question, @pierreaubert! You’re on fire today. Hey @josep, what’s that for? you want people to engage and listen to you? This is not conductive to proper discussions. This is not the tone we want on this forum. Pierre

[image] pierreaubert: This is not the tone we want on this forum With all due respect, I think you’re directing that criticism at the wrong person. It wasn’t me who introduced a confrontational tone into this thread… it was one of your subordinates: [image] Alex: Sure as hell sounds like you are. I don’t see any constructive criticism here. Just a rant how everything is unappealing and how it will never work out because of some “impedance mismatch”. Would really appreciate to have a discussion with you and not ChatGPT. I’m not sure if you consider that tone acceptable, but I’d argue it’s far more inflammatory than anything I’ve said. My responses have been direct, sure -maybe even a little snarky- but I’ve avoided insults, personal attacks, or dismissing anyone’s arguments out of hand. If you’re going to moderate tone, then please make sure it applies consistently, regardless of whether the person in question reports to you or not. That said, I’d honestly prefer if we moved past the tone policing and got back to what actually matters here: the substance of the discussion. :folded_hands:

Can pallet revive Help Improve Polkadot's UX?

Tech Talk

josep July 24, 2025, 8:22pm 31

As suspected, Ethereum tooling can’t assist Ethereum builders at crafting the XCM interactions via strongly-typed APIs. No worries, though… PAPI to the rescue!

Topic		Replies	Views
Contracts on AssetHub Roadmap Tech Talk	72	5761	July 15, 2025
H160 Precompile Gateway: Standardized EVM Access for Polkadot DApps Ecosystem	41	1143	February 18, 2026
"Revive" Smart Contracts: Status Update Tech Talk smart-contracts	22	2989	February 26, 2026
Major Milestone for Solidity Smart Contracts: First Part of the Preview Release Now Live on Kusama Ecosystem smart-contracts , documentation	27	1993	July 24, 2025
Polkadot Hub: Prioritizing growing ecosystem 3rd party providers, inc. DeFi, ASAP (through EVM) Ecosystem	9	1529	August 6, 2025

Can pallet revive Help Improve Polkadot's UX?

Related topics