Introduction
One of the most exciting aspects of pallet-revive is that it changes the relationship between smart contracts and the runtime.
Historically, smart contracts have operated inside relatively isolated virtual machines. While contracts could interact with other contracts, access to native chain functionality often required custom integrations, dedicated runtime modules, SCALE-encoded ChainExtensions or entirely separate solutions.
Revive introduces a fundamentally different model.
Because Revive executes within the Polkadot runtime ecosystem, smart contracts can leverage functionality implemented natively within runtime pallets through precompiles and host functions. This allows Solidity contracts to interact directly with capabilities that would traditionally be inaccessible or prohibitively expensive to implement inside a virtual machine.
Asset Hub already demonstrates this direction through precompiles that expose functionality from Assets, XCM, Storage, and other runtime components.
This is a powerful advantage that differentiates Revive from most Solidity ecosystems.
Rather than being limited to the capabilities of the EVM itself, Solidity developers on Polkadot can build applications that directly leverage runtime-native functionality.
The Problem
While precompiles are extremely powerful, they are not always easy to consume.
From a runtime perspective, precompiles are intentionally low-level:
- Calls are routed to fixed addresses.
- Inputs are typically provided as byte payloads.
- Outputs are returned as encoded bytes.
- Developers must understand encoding requirements and data layouts.
This design is efficient and flexible, but it creates friction for application developers.
For example, an XCM precompile may ultimately expect a SCALE-encoded byte payload, but many Solidity developers think in terms of:
- destinations
- beneficiaries
- assets
- instructions
rather than raw byte arrays.
Similarly, advanced cryptographic precompiles may require carefully structured payloads representing elliptic curve points, field elements, signatures, or verification parameters.
The runtime should absolutely remain optimized around bytes.
The developer experience should not.
Motivation
The long-term success of Revive will not be determined solely by the capabilities exposed through precompiles.
It will also depend on how easily developers can use those capabilities.
A developer evaluating different Solidity ecosystems should be able to discover a runtime capability and immediately use it through a clean, strongly typed interface.
Ideally, interacting with a runtime-backed XCM implementation should feel no more difficult than importing a Solidity library and calling a function.
Reducing integration complexity has several benefits:
- Lower onboarding friction.
- Faster application development.
- Reduced encoding mistakes.
- More reliable testing.
- Better documentation and discoverability.
- Increased developer retention.
Most importantly, it allows developers to focus on application logic rather than byte manipulation.
Proposal
I would like to propose the idea of a standardized SDK layer for Revive precompiles.
The objective is not to replace precompiles.
The objective is to make them easier to consume.
The SDK layer would provide:
Address Registries
Developers should not need to memorize or repeatedly reference precompile addresses.
Instead:
XCM.send(...);
Assets.transfer(...);
Storage.read(...);
should internally resolve to the correct runtime endpoint.
Strongly Typed Interfaces
Instead of manually constructing byte payloads:
bytes memory payload = ...;
developers should interact with structured types:
XCM.Message memory message = XCM.Message({
destination: ...,
beneficiary: ...,
assets: ...
});
The SDK would perform deterministic encoding and decoding automatically.
Validation Layers
Precompile wrappers can perform early validation before data reaches the runtime.
This improves safety while producing clearer error messages.
Local Tooling
A complementary Rust-based CLI can provide:
- payload generation
- validation
- deterministic test vectors
- smoke tests
- CI integration
This creates a reliable path for verifying runtime behavior against local expectations.
Proof of Concept
Over the past few weeks, I have been building a proof of concept around this idea.
The implementation currently focuses on cryptographic precompiles exposed through Revive (on a fork).
Specifically:
- BLS12-381 operations
- Schnorr verification
The goal was not to build a BLS SDK.
The goal was to validate the broader developer experience model.
The proof of concept includes:
Solidity Integration Layer
- Address registries
- Strongly typed structures
- Encoding helpers
- Decoding helpers
- Wrapper modules
- Example contracts
Rust Tooling
- Deterministic vector generation
- Payload validation
- Local execution helpers
- End-to-end smoke testing
Example Workflow
Developer
↓
Typed Solidity Struct
↓
SDK Encoding Layer
↓
Precompile Call
↓
Runtime Execution
↓
SDK Decoding Layer
↓
Developer-Friendly Output
The same approach can be applied to any runtime-backed capability.
Beyond Cryptography
While the current proof of concept focuses on BLS and Schnorr operations, those are simply demonstrations of the approach.
The same pattern could be extended to any other Precompile such as XCM, Assets e.t.c. Saying the opportunity is much larger than any individual precompile. The goal is to establish a common developer experience layer for runtime-backed functionality.
Why This Matters
One of Revive’s greatest strengths is that Solidity contracts are not isolated from the runtime.
Instead, they can become consumers of runtime-native functionality.
If we can provide a clean and predictable interface for accessing those capabilities, Polkadot can offer something that very few Solidity ecosystems can match:
- Runtime-native integrations at faster pace
- Advanced cryptography
- Native XCM capabilities
- Shared security
- Strong developer ergonomics especially ease of upgrading
This combination could become a significant differentiator for the ecosystem.
Discussion
I would love feedback from ecosystem participants, particularly around:
- Whether a standardized SDK layer would be valuable.
- How such tooling should be organized.
- Whether it should remain community-driven or eventually become ecosystem infrastructure.
- Which precompiles would benefit most from improved developer ergonomics
The current implementation is only a proof of concept, but I believe it demonstrates a direction that could significantly improve the experience of building Solidity applications on Revive.
Regards,
Bolaji Ahmad
