TxSim: Transaction Simulator and Risk Detector for Polkadot

[EmmanuelEklipse]

Project Abstract

TxShield is a transaction simulator and risk detection tool designed to prevent failed transactions, gas waste, and honeypot scams by previewing potential risks before execution. Built for Polkadot using Next.js for the frontend, leveraging Node.js and the Polkadot.js API for backend transaction simulation and blockchain interactions. It uses custom WASM bytecode analysis for detecting risky contracts and integrates with wallets like Talisman and SubWallet to provide a seamless user experience. Targeting Polkadot’s rapidly growing ecosystem of 2+ million wallet users and aims to expand support across multiple parachains for broader coverage and safer transactions.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[EmmanuelEklipse]

I have read and hereby sign the Contributor License Agreement.

[keeganquigley]

Hi @EmmanuelEklipse the PR correctly reflects a level 3 grant, but the application notes a level 2 grant. Can you update this on the application itself?

[EmmanuelEklipse]

@keeganquigley Thanks for pointing it out. I have corrected it

[keeganquigley]

Thanks @EmmanuelEklipse we usually only allow one grant application to be open at a time per grantee. Would you prefer to keep this one open and close #2563 since it hasn't garnered enough approvals?

[EmmanuelEklipse]

@keeganquigley Yes, please.

[keeganquigley]

Thanks @EmmanuelEklipse I will mark as ready for review and ping the rest of the committee for comment. In the meantime, one more question:

Would you be willing to support upcoming PVM (Asset Hub) as well as EVM and WASM? Please see this forum post regarding the latest news there.

[EmmanuelEklipse]

@keeganquigley Much appreciated.

Yes, we’re absolutely willing to support the upcoming PVM developments on Asset Hub — including both the WASM-based PolkaVM and the potential EVM-compatible stack. TxSim will be built with a modular architecture, and we’ve already accounted for multi-VM support (EVM via Moonbeam, WASM via Astar, and PVM via Asset Hub). This makes it straightforward for us to extend compatibility to Polkadot Hub's evolving smart contract layers without requiring additional funding, it can be delivered as a natural extension within our current technical framework.

We’re actively tracking the roadmap around PolkaVM, Solidity support, and EVM compatibility on the Hub. TxSim’s simulation and detection logic is designed to adapt to such changes, and we’re committed to ensuring it remains aligned with the most widely used execution environments in the Polkadot ecosystem.

[keeganquigley]

Thanks @EmmanuelEklipse yes I know PVM on Asset Hub is still a ways off, and there are of course the ongoing compatibility issues as well, but we expect many of these to be resolved eventually. To make one correction though, PVM is actually RISC-V based, not WASM based. Maybe you could add some language about potentially supporting PVM in the contract, and note if you foresee any challenges regarding this.

[EmmanuelEklipse]

@keeganquigley Thanks for the clarification. Just updated the proposal to reflect the planned phased support for the RISC-V–based PVM, including the challenges and our modular approach. Please let me know if you have further feedback.

[EmmanuelEklipse]

Hi @keeganquigley any update on this?

[keeganquigley]

Hi @EmmanuelEklipse it seems like so far it hasn't been able to garner enough approvals. in my opinion I think it's a bit expensive for mainly a tx simulator. It might be hard to get 5 approvals for this. Would you perhaps be willing to lower it to a $30k level 2 PoC, even if its just for one milestone? Maybe you could hold off on the risk detection module until a future M2. Then you would only need 3 approvals and would give us a chance to see the simulator in action before spending more money on it.

[EmmanuelEklipse]

@keeganquigley Thanks for the feedback! I've updated the budget to $28K and revised the milestones accordingly. Let me know what you think or if you'd like to see any other adjustments.

[Noc2]

Thanks a lot for the application. It seems like you only focus on EVM as part of this grant. How are you planning to compete with established teams like https://www.hypernative.io/ that at this point also have a brand name and are used by various projects.

[EmmanuelEklipse]

Thanks for the question @N0C2! While Milestone 1 focuses on Moonbeam’s EVM compatibility for speed of delivery, TxSim is designed as a multi-VM simulation framework, meaning from the start it will support WASM-based contracts on Astar and runtime calls on Asset Hub (PVM) as the tooling matures.

This is one of our main differentiators from Hypernative, which is EVM-focused. Our competitive advantages are:

1. Polkadot-native focus: Simulation for Substrate-based WASM contracts and extrinsics, not just EVM.
2. Fee estimation for Polkadot’s weight-based model: This is a unique need for Substrate chains that EVM-first tools typically don’t address.
3. Wallet-first integration: Targeted integration with Talisman and SubWallet so the simulation and fee data are available before signing, directly in the wallet.
4. Public-good, open-source approach: We’re making TxSim fully MIT-licensed, so any wallet, dApp, or parachain can integrate without vendor lock-in.

Our aim is not to replicate Hypernative’s EVM-only solution, but to fill the gap for Polkadot’s diverse execution environments and give users safer transaction previews across Moonbeam, Astar, and Asset Hub.

[Noc2]

Could you make this clearer as part of the milestone/deliverables or integrate something already regarding compatibility with pallets/wasm?

[EmmanuelEklipse]

@N0C2 Thanks for the suggestion. We've updated the milestones to make the WASM and pallet compatibility explicit. TxSim is being built as a multi-VM simulation framework, so Milestone 1 will support Moonbeam (EVM) and Astar (WASM) from the start, with the architecture ready for Substrate pallet/runtime extrinsic simulation (e.g., Asset Hub).

[quigl1kd]

thx @EmmanuelEklipse for the changes, I'm now happy to approve it. While waiting for other reviews feel free to start the KYB verification process for the Build Union entity. Thanks!

[keeganquigley]

whoops sorry wrong account. Here is link to verification process

[EmmanuelEklipse]

Thanks @quigl1kd @keeganquigley for reviewing and approving the updates! 🙏 I’ll get started on the KYB verification process while we wait for the final approval.

[PieWol]

Left some comments. Thanks for the application.

[EmmanuelEklipse]

@PieWol Done. Please check. I’m in the process of verifying the KYB and should have it all sorted by next tomorrow.

[keeganquigley]

re-approving

[PieWol]

Left a few more comments. Looking forward to your feedback.

[PieWol]

It might be more appropriate to not specify Astar in the deliverable, since they just use pallet-contracts which is simply a pallet and well defines what we are talking about. Let me know what you think. This would also be more interesting, since it'll allow simulation of all ink! contracts.

[EmmanuelEklipse]

Thanks @PieWol Astar was just used as an example. This depends on pallet-contracts, so the scope naturally extends to any chain supporting ink! contracts.

[PieWol]

What are these enhancements? Sounds very unspecific.

[EmmanuelEklipse]

Sure, I can clarify the “Performance Tuning” deliverable. It refers to

Reducing average simulation runtime, aiming for ≥30% compared to the M1 baseline
Improving fee estimation accuracy to within ±5% deviation on benchmark test cases
With M2, our main goal is to add advanced functionality and improve usability and integration.

[PieWol]

How can developers test their contracts with your tool, without already having them deployed on-chain somewhere?

[EmmanuelEklipse]

Great question on contract testing. Developers will be able to test their contracts before deploying them on-chain. The simulator will accept the compiled contract artifacts (bytecode + ABI for EVM, Wasm + metadata for ink!) and run them in a local execution environment. This will be verified with sample contracts from both ecosystems to demonstrate that pre-deployment testing works as expected. Deployed contracts will also be supported, but pre-deployment validation is a key use case we will enable.

[EmmanuelEklipse]

KYB completed