| Report Date | 2026/06/23 |
| Submitted by | Robert van Eerdewijk |
I am applying for promotion to Rank 1, I Dan: Humble Member. I believe the scope and consistency of my merged contributions to polkadot-sdk justify it.
I am Robert van Eerdewijk (0xRVE), a Fellowship Candidate inducted on 2026-04-21. My work has been focused on polkadot-sdk, specifically on pallet-revive: Polkadot's EVM-compatible smart-contract execution layer.
My contributions are concentrated in a coherent, high-value area: bringing EVM-contract compatibility to pallet-revive, building the precompile bridge that exposes core Substrate pallets to Solidity contracts, and fixing correctness and security issues in the surrounding execution code. Since December 2025 I have landed over 30 PRs into paritytech/polkadot-sdk.
The requirements for Rank 1 in §6.2.1 of the Manifesto ask for three clear examples of a modest but substantial contribution to protocol development, alongside independence of work, involvement in the design of a component, and a working awareness of the protocol. The contributions below speak to each of these, and I have ordered them by significance.
New precompiles exposing core pallets to Solidity. A major focus of mine has been EVM/Solidity compatibility for pallet-revive: making native Substrate functionality callable from Solidity contracts through precompiles. The most substantial of these is the asset-conversion precompile (#11590), which exposes the Asset Hub DEX to contracts and let the Web3 Summit ticket sale accept payment in any currency. I made foreign assets addressable from Solidity by adding a StorageMap to the assets precompile (#10869), and I brought vesting into reach of contracts with the vesting precompile (#11398), which lets a Solidity contract unlock vested DOT. I also extended the ERC-20 asset precompiles with EIP-2612 permit support (#11044), enabling gasless token approvals through signed messages, which required implementing EIP-712 signing as a prerequisite. While working on this I also fixed a bug in the existing ERC-20 assets precompile that returned an incorrect encoding to Solidity. For the vesting and asset-conversion precompiles I designed the Solidity interfaces and the mapping from each contract call to its underlying pallet dispatch.
Identifying and correcting non-trivial issues. The pallet-assets precompile had been deviating from the ERC-20 specification by adding to an account's existing allowance instead of replacing it, which I corrected in #11279. In #10920 I fixed storage refunds being calculated incorrectly when a contract allocated storage, a bug that caused some refunds to be ignored and others to be double-refunded. And in #12069 I fixed the pallet-revive tracer underreporting gas for some transactions, which had been causing indexers and explorers to report the wrong gas usage.
Security hardening of pallet-revive.
In #11676 and #11715 I fixed a bug where a malicious intermediary contract could act on the caller's assets. In #12387 I fixed a bug where tload and sload were always charged a fixed storage cost regardless of the actual storage size, which would have let a malicious actor spam storage loads without paying proportionally.
Alongside my own contributions I regularly review pull requests from other contributors, which is where most of my knowledge-sharing happens. I have reviewed over 50 PRs authored by others, mostly on the precompile and pallet-revive surface. This has both spread what I have learned about the EVM compatibility layer and deepened my understanding of parts of the pallet I did not write, and I would like to take on more review responsibility at Rank 1.
This work was carried out independently: investigating, designing, implementing, and seeing each change through expert code-review to merge by the pallet-revive maintainers. Together it represents sustained responsibility for the EVM precompile layer, a component reasonably important to pallet-revive's role as Polkadot's smart-contract execution environment.
Beyond the precompile work I have contributed to surrounding maintenance and tooling, including host-function cleanup, Solidity fixture migration, toolchain bumps, and benchmark consolidation, giving me working familiarity with pallet-revive as a whole and its place in Polkadot.
That broader view is also why the project's direction matters to me. I genuinely value Polkadot's commitment to minimised trust and unstoppability, because they offer a technically feasible alternative to problems currently handled by slow and inefficient bureaucracy: rules anyone can verify and no one can quietly override. It is also why correctness and abuse-resistance in the execution layer matter to me, since the platform can only fill that role if its guarantees actually hold.
I believe this meets the expectations for Rank 1: three clear modest-but-substantial contributions, active involvement in the design of a deployed protocol component, and substantial implementation work in a functional implementation of the protocol, carried out independently and to the standard expected by the maintainers who reviewed it.