RevX: A Rust Smart Contract IDE for Polkadot (Beta Testing Open Now)

Tech Talk
1

Help shape RevX, our Rust smart contract IDE for Polkadot, and earn prizes for beta feedback.

The Parity team has developed a new Integrated Development Environment (IDE) called RevX for simple RUST contract development. We’re opening the tool for beta testing, with the first 20 testers who meet the requirements receiving a small prize in DOT.

Building Smart Contracts in RUST on Polkadot Hub

With recent changes to the ink! ecosystem, including the discontinuation of the ink! Alliance, many Rust-based smart contract developers have been asking what comes next. Rust has always been an extremely powerful foundation for building in Web3, and that hasn’t changed. What changed is the need for a clearer, better-supported way forward.

Rust remains a first-class language for blockchain development, so to meet developers where they are today, we’re introducing RevX, a new Rust-based IDE, sandbox, and deployment environment designed for smart contract developers building with PolkaVM. It provides a streamlined space to write, test, and deploy Rust contracts with certainty and ease, backed by a maturing Revive environment on Polkadot Hub.

What is RevX? A Rust Smart Contract IDE for Polkadot

RevX aims to address gaps in smart contract deployment, particularly for Rust-based deployments.

Screenshot of the RevX IDE
Screenshot of the RevX IDE1920×962 63.4 KB

Smart Contract Deployment Pathways on Polkadot

Contract deployment can be confusing, especially if you’re new to the ecosystem and unsure of where to start. We strongly encourage everyone to first review the official Polkadot Documentation on Smart Contracts.

RevX BETA Testing is live!

We like feedback! With the RevX IDE now available to the public, we’re seeking 20 Beta testers to give it a test drive and provide feedback, with the first 20 rewarded with a small reward in DOT.

How do I get involved?

Step 1
Check out the IDE here! - https://revx.dev/

Step 2

The first 20 to meet the requirements laid out will be rewarded with 20 USD sent in DOT

  • Applicants MUST deploy x4 contracts on Polkadot. No testnets, only the mainnet is eligible for this beta testing.

  • Applicants must complete the beta testing feedback form available here.

  • Applicants must enter the Contract Address for each deployed contract in the designated box to receive 20 USD in DOT.

  • Feedback must be thorough. Any users attempting to game this will be excluded.

Step 3
Rewards are limited to the first 20 qualifying submissions, but all actionable feedback will directly shape RevX’s evolution. We encourage every Rust developer to test, experiment, and contribute.

Beta Testing Feedback Form

RevX Beta Testing - Feedback Form

Requirements

  • Deploy 4x Contracts on Polkadot
    • Deploying on testnets will not count
    • Must deploy using the RevX IDE
    • All deployments must be successful
  • Must provide clear and thorough feedback
    • Filling out the 2-minute form is critical for us
    • You must input your DOT address to receive your reward
    • You must input your 4x Contract Addresses into the provided slots

A quick celebration

Smart contracts are now live on Polkadot Hub, allowing builders to deploy Solidity-based contracts via pallet-revive, with all contracts compatible with both EVM and PVM execution backends.

If you’d like to get started on deploying your Solidity-based contracts on Polkadot, check out our refreshed docs to get started.

23 Likes
Polkadot Digest 20 February 2026
3

Not entirely sure I understand this. My understanding was:

  • Revive’s main goal is to bring Solidity/EVM compatibility to Polkadot Hub.

  • ink! was discontinued (at least in part) because the focus shifted toward that Solidity-first path.

So I’m confused why now promote writing smart contracts in Rust again, and on top of that without ink!.

What’s the intended benefit? Specially for newcomers. Did Ink! have bad performance or a bad direction?

Genuinely asking, I’m a bit lost and trying to understand the reasons for this. As an outsider (not parity, not super rust technical) it’s a bit confusing.

5 Likes
5

I think it’s more correct to say the focus shifted “to the PolkadVM-first path”, than “to the solidity-first path”.

PolkaVM is built on RISC-V, which is language-agnostic by design. Revive is the Solidity compilation pathway into PolkaVM, but it was always the plan for PolkaVM to support multiple languages, Rust included.

What RevX does is give Rust developers a way to build contracts for PolkaVM without ink!; writing Rust that compiles to RISC-V directly rather than going through ink!'s framework and the old WebAssembly stack.

For newcomers right now? The Solidity path is honestly more mature and practical — familiar tooling, bigger community, more resources. But Rust on PolkaVM has a potential long-term performance edge.

11 Likes
6

Amazing, thanks!

3 Likes
7

Thanks for asking about ink!. A few things we wanted to address from the ink! alliance. We spent two years making ink! compatible with RiscV and PolkaVM – no longer using WASM. ink!'s maturity (7+ years of development) has already solved many of the DevEx issues that raw Rust is going to face.

Including:

  • ABI and metadata
  • Manual serialization
  • Storage Abstractions
  • Dispatch, entry points, events, etc.
  • Cross contract calls, with type safety
  • Testing frameworks
  • Years of tooling and examples

The ink! docs lay this out in detail. Bare rust contracts introduce a lot of foot-guns that ink! has solved already. Bare rust = more dangerous and more bugs.

Solana developers faced the same problem and built Anchor and Pinocchio, frameworks to make Rust smart contracts easier to build and safer. Every ecosystem that ships Rust smart contracts ends up building these abstraction layers because raw Rust alone doesn’t scale.

ink! can still be compatible with Polkadot Hub, but we need approval from W3F and Parity to get funding from the treasury.

14 Likes
8

Was the plan to defund ink! development so that Parity could create their own Rust IDE and dev tools?

I am fine with that, but why was there no transparency in these decisions?

Why didn’t parity disclose their plans during the voting process?

I feel in the dark as a member of the community.

3 Likes
9

Thank you for chiming in here @ink_alliance . You are 100% correct, bare Rust introduces complexities and footguns, and frameworks like ink! (similar to Anchor on Solana) are useful for safe, scalable smart contract development.

To clarify, RevX is an IDE (a tool), not a framework intended to replace ink!. In fact, our internal team originally built RevX specifically with ink! in mind because we felt the UI/UX tooling just wasn’t where it needed to be for browser based, quick product prototyping. When the ink! Alliance’s future became unclear, we had to pivot RevX to bare Rust on PolkaVM simply so that Rust developers still had a working environment on Polkadot Hub in the interim.

We have massive respect for the 7+ years of DevEx the ink! team has built. If ink! is able to secure funding through the Web3 Foundation or the Treasury to ensure its ongoing maintenance, the team would be absolutely thrilled to integrate ink! support back into the IDE.

We are on the same team: we all want Rust to thrive on Polkadot.

14 Likes
10

@Karim, we really appreciate the transparency, respect and acknowledgment for ink!'s work. It’s great to hear RevX was originally built with ink! in mind, it’s a nice UI for DevX.

It would be great to start discussions again towards securing funding for ink!, but we’ve got a catch-22 we should address.

The last communication we received from W3F’s Governance Team was:
“Parity’s feedback remains that they are not in a position to endorse ink! as the strategic default path for Rust smart contracts on Polkadot Hub, and they still have open questions about expected demand for ink! relative to other contract development approaches.”

The situation since January 23rd has been Parity won’t endorse ink!, which blocks strategic support signaling from the W3F. So, the message here about “we’d love to support ink! if it gets funded” makes it confusing to us on how to proceed.

What the Alliance needs to re-engage is clarity:

  • Has Parity’s official position on ink! changed?
  • If Parity now supports ink! as a framework for Rust contracts on Polkadot Hub, will they say so publicly, in a way that unblocks funding?
  • If not, what is the endorsed plan for a secure developer experience layer above bare Rust?

We still care about this ecosystem, and feel deeply for the ink! community that has been impacted by ink!'s discontinuation. If Parity is interested in restarting discussions, we’d happily engage openly and transparently here on the Polkadot Forum. The goal can be towards treasury funding, or engaging directly with Parity/W3F for co-development.

We agree that we are on the same team, and look forward to creating some structure, a plan, and committed efforts moving forward.

9 Likes
12

Ship It: Lessons from Building RevX

Hey everyone, Leonardo here - I’m the lead developer at Parity behind RevX.

To give a bit of context on how RevX came to be: the idea started while experimenting with ui.use.ink and testing ink! v6 contracts. I kept thinking how useful it would be to have a similar interface that could also build and deploy contracts directly, something like Remix. So I built it. When ink! development was later discontinued, I adapted RevX to focus on pure-Rust contracts on PolkaVM instead. The mission stayed the same: make contract development simpler and more accessible.

With that out of the way, we want to share a few lessons from building RevX. Of course, many of these ideas are familiar, but it is useful to restate them and inform the community of what’s happening behind the scenes at Parity.

The Backstory

When building products, there are generally two approaches. One is to build extensively before release, polishing features, refining architecture, and expanding scope until the product feels 100% complete. Whatever ‘complete’ means these days.

The other is to build the smallest version that works, put it in front of real people, observe how they interact with it, and iterate based on what you learn. RevX followed the second approach as the goal was not to build a feature-complete IDE. The goal was to ship the minimum viable product, listen, test, and iterate. Fast.

The Problem

A classic trap teams fall into in product development is over-polishing before any kind of real-world exposure. This is hardly surprising in a world shaped by a fierce attention economy, where human attention spans are shortening by the day. However, that might mean teams can spend months refining a product internally, only to discover that:

  • Users didn’t need half of what was built.
  • They need/want something different.
  • Crucial friction points were overlooked.

Without real users, assumptions will simply remain untested. Much to our dismay, users tend not to evaluate internal architecture from the get-go. Who knew? However, they interact with what they can see and feel in front of them: buttons, workflows, and edge cases. They click the one path that wasn’t fully considered, and ultimately, surface pain points and friction really quickly.

But the big lesson is that feedback can only be received if the product is shipped early enough to allow it.

The Fix

RevX began as a basic IDE capable of compiling and deploying a contract. It was by no means feature-complete, but it was sufficient to learn a few things about our audience.
From there, iteration followed direct feedback, and solutions to real problems were shipped quickly:

  • GitHub integration was added when users needed to move projects into proper environments (and temporarily removed pending review).

  • AI-assisted coding was introduced to help users working with Rust on PolkaVM.

  • API calls were kept client-side to avoid touching users’ keys.

  • Wallet auto-detection and mapping were added to reduce onboarding friction.

  • Compilation time was reduced from approximately 220 seconds to 20–30 seconds by pre-warming default crates.

  • Project sharing via Bulletin was improved by compressing CAR files.

None of these were part of a long, winding, or predetermined roadmap; they just emerged from hands-on usage.

The Result (So Far)

Users were very direct in their feedback and quick to report any and all bugs. They pointed out confusing interactions and requested features that challenged our initial assumptions.

And we lapped it up like a kid with an ice cream on a hot day.

Every bug report, every confused click, every “why can’t this work differently?” is solid gold information. But it only becomes useful information if the team is moving fast enough to respond. Overall, we think that the broader lesson is simple:

If something is being built, the key question is not how complete it is. The key question is whether it is in front of real users with unbiased opinions and feedback.

Ship it.
Learn from it.
Iterate.

Thanks for your support.

9 Likes
13

That’s the exact lesson the best seller The Lean Startup talks about, and I 100% agreed.

But there’s a phase shift, Ship It is the best strategy for starting a new product or project, user-centric approach guide towards what the user really wants, not what you think he wants.
But once you achieved success and have a considerable amount of users relying in your product then stability starts to matter, is unavoidable to make bad design decisions and realize that later, but you are stuck with it because now thousands of people rely on that “bad feature”, changing it will disrupt their work, that’s when the “boring” part starts, which is less about rapid iteration and adding features and more about maintainability, engineers hate that part, but boring is good, boring means predictable and reliable, means people can do long-term plans in advance using that technology, it requires years of boring slow incremental iteration for any piece of software be successful.
The other side of the coin is change everything even if that disrupt the user workflow, for the sake of improve the technology, then you will be in beta all the time, and users will treat it as a beta product and not build anything serious.

Seems in the battle between Stable Slow Boring EVM and Better Fast Rust/PVM, seems the boring winned. That’s why I’m seeking for more boring Rust smart-contract tools.

14

Thanks for the thoughtful comment, @Lohann.

I completely agree that stability matters enormously once a product has real users depending on it. No argument there.

I just want to gently note that this post was specifically about RevX’s journey so far - a project I started as a side project exactly 40 days ago. At this stage, the “ship early, learn fast” approach is genuinely the right fit for where RevX is in its lifecycle. It’s not a general prescription for the whole ecosystem.

The broader conversation around “Boring EVM” vs “Fast Rust” and platform stability is an important one, but it’s probably a bit beyond the scope of what RevX can speak to as a tool that’s still finding its feet.

Context matters a lot when applying these principles, and I’d hate for the takeaway to be that we’re advocating for “move fast and break things” as a universal philosophy - that was never the intent.

That said, I hear what you’re saying about wanting reliable, long-term Rust tooling. That’s something we care about too, and as RevX matures, stability will naturally become a bigger priority.

2 Likes
15

To give context I tested REVX and is awesome, the issue wasn’t REVX but interacting with low-level PVM API is challenging for people who doesn’t know the black art of unsafe rust..

My feedback:
Once it is not open-source yet I dig into the code to understand the internal workings, (don’t worry I do this all the time), I was curious if it works similar to how solc works, where we can download the page and run it locally.

I notice the shell command line and filesystem are running locally, probably using emscripten, files are stored locally in the browser’s IndexedDB using IDBFS filesystem, but what I was truly interested is how it compiles Rust code to PVM, which is the hardest part (I tried before).

For context there’s a open question wether is possible to compile Rust to PVM efficiently in the browser, I even mentioned that in another post. Web IDE’s like Remix scales very well to thousands of simultaneos users because everything happens locally, solcjs can compile Solidity code in less than a second even running in the browser.

While testing REVX I noticed the compilation process happens in the backend and with the example code for me took about 41 seconds, I don’t know what are specs of the machine where it’s running, but I was wondering if the compilation step would take even longer if running locally in WASM, because in my understand this is a possible barrier for mass adoption.

Btw this is not a criticism, just a honest initial feedback. I know it’s in beta and compile code in the backend is the fastest path forward, but I have three concerns:

  1. Wondering if I could recommend it to students and not worry about the service stop working because 50 people attempt to compile the code at the same time (which is what would happen in a class).
  2. No one knows yet (because no one tried) if is even feasible to compile Rust code in the browser efficiently, rust playground also compiles code server-side, if the code takes more than 4min to build in the browser this already tells is not possible to provide a good developer experience in the browser. And being server-side means people must rely on service availability and internet connection.
  3. Putting more servers when more people are using the tools doesn’t scale IMO, because who will absorve the cost? Then it will need to become a paid tool while still be inferior to remix, because remix still works if the connections drops.
1 Like
16

I think at some point would be interesting build rustc and polkavm’s rustc-rv32e-toolchain to wasm just to check the performance. I tried that one weekend but I got stuck trying to compile rust’s fork of LLVM’s to WASI emscripten…
I realized that cargo and rustc compiles fine on qemu rv64gc userspace mode, my next plan was use some existing RISC-V interpreter to run rustc in the browser, I stopped here because I could find any existing riscv interpreter easy to compile to WASM which also have the necessary userspace extensions… will give it another try eventually.

17

This is, indeed, a huge red flag.

What’s the actual reason compilation is happening on Parity’s backend? If it’s not strictly necessary, it’s hard to justify: it adds latency, creates a single point of failure, and turns “compile” into an ongoing ops bill that grows with usage.

Is local compilation on the roadmap? Or is the intent that the IDE remains dependent on a Parity-run service long-term?

An IDE that only works while a centralized Parity service is up is… not exactly aligned with the “local-first / decentralized” story. I think this architecture needs a clear explanation.

1 Like
18

Last year we created a fork of Remix with PVM compilation in mind (for Solidity source code, using our resolc compiler). The compiler was running directly in the browser as a wasm build, but the wasm blob was 60 MByte and some browsers couldn’t handle it. Wasm builds of rustc are tens to hundreds of MB and currently impractical for most browser use cases (rustc binary is 50-80 MByte, LLVM libraries are 80–150 MB).

19

Interesting… I didn’t know there was a limit on WASM size that browsers can handle, maybe is possible to reduce this size by stripping down unused targets and LLVM modules.

My idea about using RISC-V instead pure WASM came after playing with this:

I got quite impressed by the performance as it is able to run a full operating system, including rustc in this example, it runs x86 binaries by JIT compilying it to WASM, so instead a single big WASM blob it creates WASM blobs in realtime when a memory page PROT_EXEC flag is enabled, the limitation of this tools specific is that it only works with 32bit system. I realized that RISC-V 64bit instructions are quite easy to translate to an equivalent WASM so my idea was using the same technique, being RISCV-V means it can use pre-compiled binaries (no more time wasted trying to compile everything to WASM), but yes is a lot of work and could fail miserably.