Fast promote Victor Oliva to rank 2

121d...GFvz
1d 12hrs ago
0
Deciding
No context provided.
Who can edit?
121d...GFvz
Reply
Up
Share
Evidence for Promotion

Argument-0001: Promotion to Rank II
Report Date 2026/06/09
Submitted by Victor Oliva

Member details

  • Matrix username: @voliva:matrix.org

  • Polkadot address: 16JGzEsi8gcySKjpmxHVrkLTHdFHodRepEz8n244gNZpr9J

  • Current rank: Rank 0 (Candidate)

  • Date of initial induction: 2026/06/09

  • Date of last report: N/A

  • Area(s) of Expertise/Interest:

    • Developer tooling
    • Runtime and node API ergonomics
    • FRAME pallet UX

Reporting period

  • Start date: 2024/02/01
  • End date: 2026/06/09

Argument

I am applying for fast promotion to Rank II: Proficient Member. I believe this is justified by my sustained work on Polkadot as a core developer of Polkadot-API since February 2024, spanning more than two years of contribution, together with direct contributions to Polkadot SDK and related ecosystem projects.

My strongest evidence for Rank II is my ongoing ownership and development work in Polkadot-API, where I have contributed to the developer-facing infrastructure used to interact with Polkadot SDK-based chains. This work is directly relevant to runtime interaction, standard RPC usage, transaction construction, metadata/codegen, runtime compatibility, storage/event subscriptions, signer abstractions, and upgrade-safe client behaviour.

In May 2024, I attended the in-person Polkadot Blockchain Academy in Singapore, where I graduated with distinction from the protocol track: PBA graduation certificate on Asset Hub Polkadot.

Polkadot-API

Since February 2024, I have worked as a core developer of Polkadot-API.

During this time, I have opened over 250 PRs in the repository, mainly covering development work, API design, maintenance, releases, issue triage, and ecosystem support. My biggest contributions have been in API design, runtime safety through the compatibility API, bundle-size improvements, CLI and codegen architecture and ink!/Revive contracts support.

Most important contributions:

  • Compatibility API

    I worked on Polkadot-API’s runtime compatibility layer, including static compatibility checks, generated-descriptor compatibility checks, reporting of compatibility changes and granular detection of changes across runtime updates. This helps applications handle runtime upgrades and metadata changes more safely.

  • Typed Signed Extensions

    I implemented typed signed extensions support, improving type safety around transaction construction and making custom signed-extension handling more explicit for advanced users.

  • Performance and size improvements: #502, #504, #516

    I improved descriptor generation and loading by decoupling descriptor types from values, lazy-loading descriptor values, compacting generated descriptors, and reducing memory usage when updating multiple chains.

  • CLI refactor into new architecture

    I improved the CLI/codegen workflow substantially, including whitelisting, automatic codegen after chain changes, generating from the metadata of a specific block, and more robust CLI error handling.

  • Revive contract support

    I worked on typed contract support in Polkadot-API, including the ink-contracts package, TypeScript support for ink! and later Revive contract interactions, event decoding, nested storage queries, as well as Solidity support.

  • Event API redesign

    I contributed to the event API and subscription layer, including a TypedAPI event interface redesign and watchBest event support.

  • Meta-signers: multisig signer and proxy signer

    I contributed to signer infrastructure, including the multisig signer and proxy signer, which are higher-order signers that abstract away signing with a multisig or proxy account.

This is complemented by substantial maintenance work, including fixes, releases, issue triage, ecosystem support, and documentation, as well as initiating the development of the PAPI Console.

This work represents sustained ownership of a major developer-facing component, including API design, implementation, release work, compatibility maintenance, and support for downstream users.

Polkadot SDK

I have also contributed directly to Polkadot SDK in areas related to contracts, RPC behaviour, and governance/runtime functionality.

Additionally, I have participated in issues and discussions, specifically in pallet-revive and foreign assets: Polkadot SDK issues authored by me.

Smoldot

My main Smoldot contribution was implementing state_getReadProof support.

This PR implemented the state_getReadProof RPC method in Smoldot. The motivation was to support storage-proof retrieval in Polkadot-API while preserving Smoldot/light-client compatibility. The implementation required working through proof retrieval, proof verification, multi-key proof handling, proof merging, and integration with Smoldot’s JSON-RPC and sync-service internals.

I have also opened issues that helped identify light-client correctness, performance, and developer-experience issues:

Acala Chopsticks

My Chopsticks contributions focused mainly on implementing and hardening support for the JSON-RPC interface spec, including chainHead_v1, transaction_v1, chainSpec_v1, and storage-query APIs used by modern Polkadot clients and tooling. The most important contributions are:

Overall, these Chopsticks contributions improved compatibility between Chopsticks and modern Polkadot client tooling, particularly Polkadot-API. They are relevant to testing, simulation, and development workflows for Substrate/Polkadot-based chains.

PolkaHub

I also led the development of PolkaHub, a library designed to unify signers and wallets behind a single interface so they can be integrated more easily into applications.

PolkaHub supports predefined components as well as external components through plugins and composition. This work is relevant to wallet interoperability, signer UX, and application-level integration with Polkadot accounts and transactions.

Forklift

As introduced in the Polkadot Forum, I also led the development of Forklift: a Chopsticks-like tool designed to create local testing scenarios with multiple forks and chain heads.

Forklift allows tooling developers to test reorg-sensitive scenarios that were not possible with previous solutions such as Zombienet or Chopsticks. This is relevant to client correctness, chainHead behavior, fork handling, and testing tooling for applications that need to behave correctly under chain reorganization conditions.

Published technical articles

I have published technical posts concerning Polkadot developer tooling, Revive contracts, signer UX, and light-client-based applications:

  • [Revive] Solidity contracts using a Polkadot signer

    This post explains how to interact with Solidity contracts on Revive using Polkadot tooling. It covers the boundary between ABI-encoded contract data and SCALE-encoded runtime calls, Revive.instantiate_with_code, runtime API calls for gas and storage deposit estimation, and PAPI-based querying/submission flows.

  • [PAPI] Stateless Multisig Tool

    This post introduces a stateless multisig tool built with PAPI. It explains how the tool avoids indexer dependency by relying on on-chain data and URL parameters, how it coordinates multisig operations, and how PAPI can be used to build light-client-friendly tooling for practical governance and account-management workflows.

Polkadot Blockchain Academy Instructor

I was an instructor at the Polkadot Blockchain Academy editions in Luzern and Bali in 2025, teaching new developers how to build applications and contribute effectively to the Polkadot ecosystem. This has also led to many new developers joining the ecosystem.

Additional ecosystem background

I completed the Polkadot Blockchain Academy protocol track in Singapore 2024 with distinction, where I learned about the development of Polkadot SDK.

Additionally, I have given technical talks at ecosystem events:

  • Parachain Summit 2024: technical talk on the Compatibility API, including the challenge of circular references in metadata types.
  • sub0 reset 2024: Next Gen Devtools for Polkadot, introducing the PAPI Console to the ecosystem.

Basis for Rank II promotion

I believe this application meets the expected standard for Rank II promotion. My contributions show sustained ownership of Polkadot developer tooling through Polkadot-API, direct merged contributions to Polkadot SDK, related work across Smoldot and Chopsticks, and published semi-technical material concerning Polkadot.

The basis for this request is not isolated PR activity. It is continued responsibility for tooling that developers use to interact with Polkadot, including API design, runtime compatibility, code generation, contracts support, signer infrastructure, client correctness, releases, and ecosystem support.

For the Rank II requirement of being primarily responsible for the implementation or analytical improvement of a major protocol component, my argument is based on sustained ownership of Polkadot-API’s protocol-facing interaction layer with Polkadot SDK-based chains.

This work is not generic application tooling. It sits at the boundary between applications and the Polkadot protocol, and depends directly on runtime metadata, standard RPC behaviour, transaction validity, storage proofs, signed extensions, runtime upgrades, chainHead behaviour, and client correctness. My related contributions to Polkadot SDK, Smoldot, and Chopsticks further show that I have improved underlying protocol-facing interfaces rather than only consuming them.

I intend to continue expanding my contributions to core Polkadot SDK work, especially around developer tooling and FRAME pallet developer experience.

References

Voting record

Ranks Activity thresholds Agreement thresholds Member's voting activities Comments
I 90% N/A N/A As a Rank 0 Candidate, I was not eligible to vote on any referenda during the reporting period.
II 80% N/A Target rank.
III 70% 100% N/A
IV 60% 90% N/A
V 50% 80% N/A
VI 40% 70% N/A

Misc

  • Question(s):

  • Concern(s):

  • Comment(s):

Status
Decision30d
Confirmation
1hr
Attempts
0
Tally
100%Aye
0%Nay
Aye1
Nay0
  • 50.00%
  • 0.0%

    Threshold

  • 0.0%
Bare Aye1
Max Voters11
All votes
Actions
Check how referenda works here.
Call
Metadata
Timeline3
Curves
Comments