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.

[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

[EmmanuelEklipse]

@PieWol, bringing this to your attention. Please let me know if you need any further clarification.

[EmmanuelEklipse]

Hi @semuelle @laboon @takahser , KYB is done. We’ve got 2 approvals + 1 support, just one more to go. This tool lets developers simulate and validate (EVM + ink!) transactions before deployment, and end users will also benefit by seeing accurate fee estimates and risk checks before signing. It helps protect users from scams by catching issues early. Other networks have or are building similar tools, but Polkadot doesn't. Ours adds unique wallet integration that gives the project an edge; we’d love to bring this to life. Thanks for your support.

wrong account

[keeganquigley]

Thanks @EmmanuelEklipse can confirm KYB is approved, I just pinged the team again.

[EmmanuelEklipse]

Thank you.

[semuelle]

Just some minor remarks

[semuelle]

Since you've already gone through KYB now, can you please clarify this part? At least the name or type of entity.

[semuelle]

What does "Integrates" mean here? That it would be possible for the wallet devs to integrate it, or is there a different way to use it?

[EmmanuelEklipse]

Thanks for the question @semuelle. By integrate, we mean that wallet developers (e.g. Talisman, SubWallet) will be able to connect to TxSim via the Polkadot.js API, without requiring any new accounts or extra setup. The SDK is being designed to make integration straightforward for wallet teams, while end users will experience it seamlessly within their existing wallet interface. I’ve also updated the proposal to clarify this point.

[semuelle]

Thanks for the updates, @EmmanuelEklipse. LGTM.