| Report Date | 2026/07/14 |
| Submitted by | Maheswaran Velmurugan |
Filed for discussion and review in polkadot-fellows/Evaluations#324.
pallet-revive / PolkaVM — the Ethereum-compatibility (smart-contract) layer of the Polkadot HubHi, I'm Maheswaran. I got into Polkadot properly in June 2024, when I graduated from Wave 5 of the Polkadot Blockchain Academy, where I learned Substrate, FRAME and how the protocol works under the hood. Day to day I work as a smart-contract security auditor, with 15+ confirmed findings on Sherlock, Code4rena, Cantina and Immunefi, and I build across several chains.
Since my induction I've put that EVM and security background into one part of Polkadot: pallet-revive and its Ethereum JSON-RPC server (pallet-revive-eth-rpc) in polkadot-sdk. This is the layer that lets normal Ethereum tools like wallets, libraries, indexers and block explorers talk to the Polkadot Hub without any changes.
This matters a lot for Polkadot. Those tools only work if the RPC behaves like Ethereum's does, which in practice means behaving like go-ethereum, the client everyone builds against. When it doesn't, tools break. Often they break quietly: instead of an error, they get an answer that looks fine but is wrong.
I found several of these silent bugs: wrong fee data, dropped log results, bad input accepted without complaint, and one standard method missing entirely. My work has been to fix them one by one, and to write down the compatibility rules so they don't quietly break again.
Here's how this maps to each Rank I requirement in Section 6.2.1 of the Manifesto.
"Three clear examples of a modest but substantial contribution to protocol development." I've made seven of these contributions to paritytech/polkadot-sdk. I found each one myself, and Parity maintainers reviewed them all.
The first to merge fixed eth_feeHistory. It caches fee data in half-percent steps, but the lookup rounded to whole percents, so any tool asking for a fee estimate got the wrong number (#12470, merged).
A second, now approved by a maintainer, made eth_getLogs accept the finalized, safe and pending block tags that the rest of the server already handled. The maintainer asked me to go further, so I merged three separate copies of that block-tag logic into one shared function (#12474).
Four more fix log filtering and fee history. Empty and null topic slots now act as wildcards, like go-ethereum, while still requiring a log to have at least as many topics as the filter (#12479, #12483). eth_feeHistory now rejects bad percentile input instead of guessing (#12547). And the eth_subscribe log filter now follows the same rules as eth_getLogs (#12626).
In each case I turned a quietly-wrong answer into the right one. That's the worst kind of bug for the tools relying on it, and it's exactly the Manifesto's own example of this requirement: "identifying and correcting a non-trivial issue in protocol code."
"Actively been involved in the design of a component ... reasonably intended for future deployment ... at the standard expected of a PRP," and "substantially assisted in the analysis, or authoring of formalisation or implementation of a protocol component." Rather than just fixing symptoms, I wrote RFC-0172 to deal with the root cause. It's a proposed compatibility standard for pallet-revive's RPC. It says the server should match Ethereum's execution-apis spec and go-ethereum, spells out the few places where Substrate and Ethereum really differ (how block tags map to GRANDPA finality, EIP-1474 error codes, log-filter edge cases, and how Polkadot's two-part Weight plus storage deposit turn into a single gas number), and asks for a CI test suite so this is checked automatically.
The RFC is currently under Fellowship review and is meant to become the standard for this component. It's also a small collaboration story: another contributor, @Nathy-bajo, had the same idea, and instead of opening a competing RFC he joined mine as co-author.
On the implementation side, I added a standard method that was simply missing: eth_getBlockReceipts (#12636). It returns all of a block's receipts in one call. Indexers and explorers need it, and not having it was a real blocker for running that tooling against Polkadot.
I also caught a problem during review. A reviewer suggested a quick one-line fix for the subscription length rule, but I noticed it would have broken things, because the filter stored an explicit null the same way as an unset slot. So I did the proper fix instead.
"Should be able to list all key goals, principles and tenets of Polkadot's overall philosophy." Polkadot's main goal is decentralisation: no single point of control or failure, and as little trust in middlemen as possible, using cryptography and staking instead. Security is shared, so parachains get their security from the Relay Chain's validators, and the network keeps working even if some of them act maliciously.
It scales by running many specialised chains side by side (heterogeneous sharding) and connects them with XCM. Anyone can take part, staking secures it, and on-chain governance decides how it changes. Behind all of this is the Web3 idea of giving users control and not having to trust powerful third parties.
I also commit to the Fellowship's four tenets: to genuinely act in Polkadot's interest, to respect its philosophy and principles, to respect the Fellowship's rules and voting conventions, and to respect the other members and the wider community.
The rank also asks for some broader qualities, and I think this work shows them. It covers one component in real depth: nearly all of pallet-revive's Ethereum RPC layer, from how receipts are built and logs are queried to the fee-history cache, block-tag mapping, subscriptions and gas. That sits on top of the wider Substrate knowledge I picked up at the Academy.
I found, scoped and finished every one of these on my own, with nobody assigning them to me. That's the independence the rank looks for.
My audit background fits the requirement that a candidate understands a system has to keep working even with some malicious users. Several of these fixes close cases where a bad or malicious request used to get a silently-wrong answer.
I've also tried to stay available and share what I learn: writing the RFC, going back and forth with maintainers over many review rounds, and turning a would-be competitor into a co-author.
Why it matters going forward: this is part of making the Polkadot Hub a real home for Ethereum developers and their existing tools. Each fix lets unmodified tooling work correctly, the new method unblocks indexers and explorers, and once the RFC's test suite is in place it will keep the RPC correct as both Polkadot and Ethereum change.
As a Rank I member I want to keep going: ship the conformance suite, cover more methods, and start reviewing other people's pallet-revive work. You can follow what I'm doing through my open pull requests on polkadot-sdk.
N/A, I am a candidate.