Polkadot-API updates thread

Tech Talk
21

Hi there :waving_hand:

It’s been a while since our last update in this thread! A few months ago, we
summarized our activities from the end of Q4 2024 to the start of Q1 2025 with
Polkadot-API. You can catch up on it here.

New PBA dApps Track

During last month, we prepared and taught an exciting new track in PBA focused
on offchain/dApps development! It was incredibly rewarding to visit Switzerland :switzerland:
and guide a cohort of nearly 30 students through an immersive blockchain
experience, emphasizing key knowledge essential for building next-generation
decentralized applications. We want to thank all the PBA team for the confidence
and we are open to collaborations in the future!

This intense 10-day module condensed all the essential and valuable insights we
identified. We’re extremely proud of the results and warmly welcome all our
students into the vibrant Polkadot community!

polkadot-api@1.10.0 news

New Features

Offline API

We’ve introduced an Offline API, a feature highly requested by advanced users.
This allows creating and signing extrinsics without maintaining an active
connection to a provider. This feature has been available since version 1.9.0
of the library.

Comprehensive documentation for the Offline API is provided at
papi.how. Check it out to learn more!

Typed Codecs

Another highly requested feature was direct access to codecs used in chain
interactions (such as transactions, queries, and more). Users can now access any
codec, even those deeply nested within interactions. We’ve also prepared
comprehensive documentation to help you get started quickly.
Check it out!

ink! improvements

Thanks to @tien feedback, we were able to improve our ink! client, exposing
useful information to the developer that previously was not taken into account.

Other Improvements

Over the past few months, we heavily focused on supporting other ecosystem teams
integrating our libraries. This led to numerous bug fixes and enhancements that
significantly improved the developer experience with PAPI. Here are some key
highlights:

  • Added a blocks$ observable to track any new blocks seen by the client.
  • Updated transaction creation to utilize the highest seen nonce rather than
    the nonce from the finalized block.
  • Included XCM v5 types as “known-types”.
  • Enhanced the finalizedBlock$ observable to reliably emit every block.
  • Improved overall stability, especially concerning provider errors and
    reconnections.
  • CLI and Codegen enhancements to reduce errors and warnings.

Additionally, we’ve continuously maintained and updated our documentation to
reflect all newly added features and ensure clarity.

Thanks for reading! Stay tuned for more updates and insights on our decisions,
improvements, and news.

See you soon! :waving_hand:

22

Hello there!

Continuing our monthly (at least!) updates, here’s our latest news! We have
several exciting announcements, starting with some side projects and other
developments.

RFP Launcher

Throughout May, we built the RFP Launcher, an initiative
funded by the Kusama treasury. This project aims to propose new ideas and
connect them with teams ready to execute. We collaborated with @erin on this
project, and it was a fantastic experience!

Revive

This month, we also dedicated significant effort to pallet-revive. We updated
our contracts SDK to ensure seamless integration with pallet-revive,
identifying and reporting various issues and unexpected behaviors along the way.
Additionally, we shared our concerns and hopes regarding this pallet in this
forum post.

Network Breaking Changes

An unexpected runtime upgrade (1.5.1) caused compatibility issues across many
of our SDKs, including Bounties, Identity, and others. These changes were
critical for numerous dApps, yet unfortunately, the Fellowship did not
communicate them beforehand.

In response, we’ve built diff.papi.how, a tool to
compare two runtimes and identify exactly what entries changed and how they may
impact compatibility. Check it out!

We also shared more details about this tool in a forum post.

polkadot-api@1.13.0 News

Metadata V16 and View Functions

From version 1.11 onwards, polkadot-api supports metadata v16, introducing
View Functions. These allow developers to interact with the blockchain more
easily, querying specific information directly from the runtime—functions
similar in nature to runtime APIs. Discover more in
our docs.

Metadata Caching

Responding to user requests, we’ve implemented metadata caching. This feature
significantly reduces the bandwidth needed when starting a polkadot-api client
(metadata sizes can reach about 500 KiB on chains like Polkadot or Kusama).
Several teams have already started using it with excellent results. Check out
our detailed recipe for guidance!

Storage.getKey

Another frequent request was the ability to generate storage keys directly from
entries without querying the network. This was straightforward to implement, as
the logic already existed internally. Now, we’ve exposed this functionality to
developers!

Quality-of-Life Fixes

We continued addressing bugs and unexpected behaviors throughout this period.
Special thanks to all our users for your valuable reports!

That’s all for now—talk to you soon in our next update! :waving_hand:

23

Hello there :waving_hand:

Q2 has come to a close, and what a whirlwind it’s been! This quarter flew by with a host of exciting new features and important bug fixes.

polkadot-api@1.14.0 Updates

Archive Support

The headline feature of this release is transparent archive support. Whenever the RPC node offers archive_v1 methods and the target block isn’t pinned, we’ll automatically use those calls, allowing you to query any historical block. One caveat: the block’s metadata version must be at least v14.

This feature was highly requested by the community, but we waited until archive functionality was broadly available across nodes. Give it a spin!

Other Fixes

We also tackled several maintenance items:

  • Transaction validation logic
    Previous PAPI versions (prior to 1.14) didn’t consider the mortality block hash during validation. As a result, some transactions were wrongly marked invalid if they originated from a non-parent block. This has been corrected, and most users won’t notice a change, but edge cases are now handled properly.
  • Improved error handling for non-pinned blocks
    While integrating archive support, we discovered and fixed an issue with error messages when querying non-pinned blocks.

SDK Work

Remote Proxy SDK

We’ve been heads-down on the Remote Proxy SDK, which makes integrating with the Remote Proxy pallet (currently on Kusama) a breeze. Now you can authorize Asset Hub transactions using proxies on the relay chain. Check out our detailed forum post on Remote Proxies for Everyone for all the details!

Revive

Since our last update, we’ve completed full compatibility with the Revive pallet and continue to share feedback on its upstream development.

Smoldot

We collaborated with @tomaka this month to build a new Smoldot feature: getting storage proofs directly from the light client! This feature will enable the Remote Proxy SDK with the light client, delivering stronger security and lower trust requirements. Amazing progress, and it is soon to be completed! Thanks for your detailed reviews Pierre!

Protocol BERG

Earlier in June, the team attended Protocol BERG—a fantastic conference on Web3 technical challenges. We learned tons and met several key members of the Polkadot community. Big thanks to the organizers for a great event!

Thank you for your continued feedback, and talk to you next month!

24

Hello community! :waving_hand:

This is our first update for Q3 2025. Time’s flown by, and we’ve almost reached the end of the month! As always, we’ve got plenty of exciting news and updates to share.

polkadot-api@1.15.0 API

We’ve released a new version with several notable improvements. Here’s what’s new:

query.rawQuery API

Previously, certain storage entries weren’t accessible via our top-level client API, as they don’t follow the usual Pallet.Entry structure. Examples include entries such as :code and :grandpa_authorities, which are particularly useful for low-level developers.

To solve this, we’ve introduced the new rawQuery API. It allows you to query custom keys and directly access their underlying storage values.

Improved BitSequence Support

While PAPI has supported the BitSequence type since its initial release, our previous implementation wasn’t optimal. We used to expose BitSequences as regular byte arrays (concatenated bits), limiting usability.

Now, we’ve improved the API to expose BitSequences as Array<0 | 1>, where each bit is independent. This change significantly simplifies data handling, making transformations and interactions much more intuitive for developers.

This improvement was possible thanks to the contribution of @kukabi, who helped bring this into our attention. Big shoutout! :clap: :100:

Fixed Initial Blocks Behavior

While conducting unrelated tests, we discovered a bug preventing certain interactions during the initialization of the PAPI client. We’ve now resolved this issue and added additional tests to ensure this behavior doesn’t occur again in the future.

Additionally, we identified a rare issue that could occur if the client started precisely during a runtime upgrade. We’ve fixed this unlikely (but still possible) misbehavior as well.

Smoldot / Polkadot-SDK Contributions

As always, our efforts go beyond our library, as we consistently aim to contribute upstream. During our usual integration testing, we uncovered an issue in the GRANDPA consensus implementation, affecting to how smoldot determines block finality.

Specifically, we found that Polkadot-SDK peers weren’t sending finality proofs right after authority changes. This caused smoldot to emit stop errors and forced it to re-sync with the chain. We opened relevant issues (smoldot#2148, polkadot-sdk#9300) and provided a reproducible example to help identify the bug. We expect a fix in the coming days!

Web3Summit Hackathon

Last week we traveled to Berlin to attend the Web3Summit. The event was excellent, very well organized and executed! We had the pleasure of meeting many ecosystem colleagues and engaging in productive conversations, which will undoubtedly benefit our ecosystem in the future.

Additionally, we participated in the WebZero hackathon, where we built an ink! v6 contract, deployed it using pallet-revive, and even created a precompile to call pallet-balances directly from our contract. Everything worked as expected, even though building the precompile and integrating it with the contract through revive internals was admittedly quite complex.

You can sneek into the code of the contract and the precompile!

Our efforts paid off, and we won a prize in the ink! track! Overall, it was an amazing experience, and we look forward to participating again next year.

That’s it for now! Next week we’ll publish another post, where we’ll explore the upcoming minor versions of PAPI. There are important features coming up that deserve their own dedicated update.

Until next time!

25

Hi there :waving_hand:

Q3 is wrapping up, and it’s time to share what we’ve shipped to the community!

SDK Work

Over the past few months, our SDKs have continued to evolve, keeping pace with upstream pallet changes and incorporating quality-of-life improvements.

ink! / Revive

We’ve put extra effort into the ink! / Revive SDK. An important update is landing soon that will add out-of-the-box support for Solidity contracts. If you’re curious about how we’re approaching Solidity interactions, check out this forum post by @voliva.

Statement Store

This past week we began exploring the new Statement Store primitive, an off-chain statement storage component that nodes can run, unlocking a wide range of potential functionality. As always, our goal is to provide a clean, easy-to-use SDK that abstracts away the shenanigans so you can focus on building. Follow our development!

Legacy Provider

In this time, we released @polkadot-api/legacy-provider, a middleware that converts old JSON-RPC calls into valid JSON-RPC API spec compliant calls and responses. Check this post by @josep to dig into it.

polkadot-api@1.18

The latest releases pack some sizable upgrades. Heres what’s new.

hodlBlock

We added this API so you can override PAPI’s automatic block-unpinning strategy. It’s especially useful for advanced dApps and infrastructure like indexers that need fine-grained control over block retention.

hasNewRuntime / getMetadata

A highly requested capability: fetch chain metadata directly from the client—no more calling Metadata_metadata_at_version. There’s a new client API for that, and all blocks emitted by blocks$, finalizedBlock$, bestBlock$, etc. now include a boolean hasNewRuntime to flag runtime upgrades. That way, consumers can confidently switch to the correct metadata at the right time.

WS Provider revamp

We introduced a new export for the WebSocket provider that’s slated to become the sole option in the next PAPI major. It trims overloads, simplifies configuration, and adds a websocketClass option so you can pick the WebSocket implementation you prefer. By default, it uses the global WebSocket available in browsers, Node.js >=22, and Bun.

For most users the migration is a simple swap. We’ll update the docs to reflect the new defaults and examples.

Other changes

A grab bag of QoL improvements and fixes:

  • We now export descriptor types, not just descriptors, enabling TypedApi<typeof dot> => TypedApi<Dot>.
  • Fixed issues around stop-event recovery.
  • Improved validation logic: previously some valid transactions misclassified as invalid should now pass.
  • Infer the chain’s hasher from the first header we receive.

PBA @ Bali

During last month, we prepared and taught an exciting new cohort in PBA focused on offchain/dApps development! It was incredibly rewarding to guide a cohort of over 30 students through the course. We want to thank all the PBA team for the confidence and, as always, we are open to collaborations in the future!

Upstream contributions

As always, we kept opening issues and PRs to smoldot, Polkadot-SDK, and any other relevant repo in the ecosystem, to ensure the constant improve of every part of the Polkadot supply chain where we can help. Some examples:

As always, thanks for your attention, and see you next time!

26

Hi there :waving_hand:

After two busy months, here’s a fresh update from the PAPI team!

:chart_increasing: Staking Optimizer (& SDK!)

One of the most significant dApps we’ve released so far is the Staking Optimizer!
@voliva recently shared it on the Polkadot forum, and it’s already getting strong traction from many users. We received very positive feedback from early users!

As with all our dApps, it’s built light-client first. This time, however, we also offer an optional centralized indexer so users can access trusted data in a snappier way.

The dApp is primarily made available through IPFS (as of 2025-11-24, CID: bafybeidhg7g3doyrwu6udfpqmlhw5lc3s4oimdta5ivveuutvg2nb5foga), and secondarily available through a centralized server.

:artist_palette: PolkaHub

We’ve released PolkaHub, an account and wallet toolkit designed for dApps. It follows a concept similar to RainbowKit in the Ethereum ecosystem, and we’re really proud of how it turned out.
PolkaHub is highly configurable, fully frontend-agnostic, and built to make wallet integration effortless for developers.
@voliva also highlighted it in a recent forum post.

:toolbox: @polkadot-api/check-runtime

We had yet another release over the past two months: the check-runtime CLI. This plug-and-play tool performs sanity checks and flags common pitfalls in Substrate runtimes, helping ensure that production runtimes remain as safe and reliable as possible.

It has already been integrated by Westend runtimes by Parity and by Paseo, with more integrations expected in other chains’ pipelines. The tool has already helped uncover runtime issues in both Paseo and Westend!

:books: polkadot-api@1.21

Typed Signed Extensions

Starting from polkadot-api@1.21.0, custom signed extensions are now strongly typed, delivering a major improvement to the developer experience.

We’ve seen growing demand for this feature, likely driven by the upcoming Extrinsic V5 format and the introduction of new authentication mechanisms across various chains. We’re proud to say that PAPI has full Extrinsic V5 support.

The PAPI Console has also adopted this upgrade, making it easier than ever to work with custom signed extensions.

Solidity Codegen

Developers using ink! are already familiar with the papi ink command, and now we’re excited to share that papi sol is officially here!
Solidity contracts are now first-class citizens in PAPI (and in @polkadot-api/sdk-ink), making it incredibly easy to interact with them from a dApp in a fully typed manner.

Providers Work

Over the past few months, we’ve done extensive fine-tuning on our providers, especially the WebSocket provider. This includes improvements to the heartbeat logic (the WS ping-pong mechanism), ensuring stale connections are detected and closed promptly, as well as tightening up reconnection and teardown edge cases.

Thanks to this work, our providers are now in an exceptionally stable state.

Upcoming polkadot-api@2.0

polkadot-api is preparing itself to receive its first major update since the stable release. We’re working actively on it, and expect to release the first release candidate before EOY. It will come with a bunch of changes improving the developer experience, reducing the API surface where necessary, and adding new useful APIs.
The migration will be straightforward, and a migration guide will be released prior to the final release.

Make sure to follow this thread to be informed!

:airplane_departure: sub0 Symbiosis @ Buenos Aires

Two weeks ago we visited Buenos Aires to attend the sub0 conference, where we gave a talk on the PAPI SDKs and PolkaHub. We also mentored at the WebZero hackathon and hosted a barcamp session, all of them with very positive outcomes.
We’re deeply grateful for the invitation and for the hard work of the entire organizing team!

27

Hi everyone! Victor here :waving_hand:

Here’s a quick update on the latest news around PAPI. Most of our current work is focused on stabilizing v2, which I covered in detail in the Introducing Polkadot-API v2 post. This update focuses on other PAPI-related work.

polkadot-api@1.23

We’ve released what will be the last v1 version, adding a few last features before fully focusing on v2.

tx-helper

We introduced a low-level utility in @polkadot-api/tx-utils that allows you to analyze transactions, such as mortality parameters, genesis hash, tip, asset, etc. There is also a helper to extract these values from a PolkadotJS JSON payload.

getBareTx

Based on popular demand, the Polkadot-API Transaction type now includes a .getBareTx() method to obtain an unsigned extrinsic ready to be submitted on-chain.

No more need to build unsigned extrinsics manually.

Whitelist rework

Now the whitelist can also be applied differently per-chain. Check out the docs to see how that’s done. It’s fully typed as well!

Additionally, a whitelist setting can now be added to the PAPI config, so it is automatically applied to every build.

PAPI Rescue

We’ve also been helping recover funds from compromised accounts. We now have an advanced solution that can prevent attackers from submitting transactions, recovering control of the compromised account and moving the funds to a safe one.

We’ll be sharing more details soon, with an official announcement coming next week. In the meantime, you can check out the original post where this all started: If you got hacked

If you know someone in a similar situation, please reach out ASAP, we may be able to help.

Upstream contributions

Since the last update, we’ve also contributed upstream to polkadot-sdk:

polkadot-api@2.0.0

We’re very close to the final 2.0.0 stable release. As mentioned earlier, check the Polkadot-API v2 post for a full overview of the changes.

Please give us your feedback, as it helps ensure the new API fits a wide range of use cases.

28

Hi everyone!

Quick follow-up to my previous update.

polkadot-api v2 is stable

We released the stable version, polkadot-api@2.0.0, on April 9th 2026.

This was the main milestone we had been working toward, and it marks the point where our focus shifted from stabilizing release candidates to improving the new stable line based on real-world usage and feedback.

If you’re migrating from v1, the migration guide is now available here: Migrate to V2 · PAPI

PAPI Rescue

During this time, we also launched PAPI Rescue. It successfully recovered all funds from the accounts we initially created it for, for a total of more than USD 250,000 saved.

Check out the forum post and the website for more information.

event.watchBest

On April 21st 2026, we released polkadot-api@2.1.0.

The main addition in that release is a new typedApi.event.<Pallet>.<Event>.watchBest() API.

This was requested by the community and lets consumers follow events on the best chain, while still providing the information needed to properly handle reorgs.

Check out the docs for a quick example.

Forklift

To test scenarios for both watchBest and PAPI Rescue, we needed a toolkit to consistently simulate forks and reorgs.

That’s why we released Forklift, a Chopsticks-inspired tool with support for multiple branches, fully built with PAPI v2.

Check out the forum post for more information and usage details.

What’s next

Our proposal for additional PAPI features was recently approved: Polkadot-API: Additional Feature Development through Polkadot Community Foundation

From that feature set, we have already delivered the Extrinsic Analyzer for the PAPI console. It lets you inspect the call, signed extensions, a small mortality chart, and priority estimation. Check out this extrinsic for a quick demo.

We’re currently working hard on first-class support for extrinsic v5 and generalized transactions, as well as improvements to the JSON-RPC spec around statement store support and chainHead. We’ll share more details as we go.

Thanks

Thanks again to everyone testing PAPI and sending feedback. That feedback was important both in getting v2 stable out and in the follow-up improvements we shipped afterward.

As always, if you run into issues or have thoughts on the API shape, please let us know.

29

Hey again!

Here’s another update on what’s been happening in polkadot-api.

Polkadot-API

For v2, we’ve released four more patch versions, up to 2.1.6. These include performance improvements, bug fixes, and updates to smoldot, which now fully supports chains with elastic scaling.

In parallel, we’ve been working on general transaction support. As Polkadot evolves, polkadot-api also needs to adapt to the new specifications, which means this work will be released in v3.

General transactions let chains create transactions that can be verified through mechanisms other than signatures. So the action of “signing” is generalized to “creating a transaction”, since depending on the chain, you might not need to sign with your private key in order to submit a transaction.

With this new specification, transaction extensions (the new “signed extensions”) play a greater role. We’re also generalizing this so that PAPI will no longer assume that certain extensions are always present, such as CheckNonce, ChargeTxPayment, CheckMortality, CheckGenesis, and so on. Instead, it provides the TxCreator interface with everything needed to fill in the data for each extension. This means all of that logic now moves out to the transaction creators.

For developers using PAPI, most of this will be transparent. As of now, the only surface-level API change is renaming .sign(signer, options) to .create(txCreator, options). For advanced use cases, however, the TxCreator interface is more generic, fully composable, and createTransaction-first, which lets developers build their own transaction extension handlers. We will also provide a set of utilities to help with that.

If anyone would like to give this a try, we’re publishing it to npm under the canary tag. Please note that this is not even a beta yet: it is in active development, and you may encounter major issues and frequent breaking changes.

PAPI Console

The PAPI Console has had a major overhaul. It now has a complete redesign of the shell, makes better use of horizontal space while also improving support for smaller screens and windows, and includes new features that make it even more useful than before.

Workspace

On the right-hand side of the console, there is now a “workspace”. This is a panel where every operation performed during the session is kept for future reference. You can pin and delete items, or add new ones from each section in the console.

This lets you keep a log of all the information you’re looking for without having to constantly change pages.

Cross-chain transfers

The PAPI Console has a new “Transfer” page that lets you perform cross-chain transfers, powered by the Paraspell SDK.

That SDK helps us build XCM transactions, show route information, and dry-run transactions. You can choose to either submit the transaction straight away, or open it in the extrinsics page to modify it or wrap it with other transactions.

Submit Extrinsic

Submitting an extrinsic has also been redesigned. Previously, it was difficult and unclear how to change signed extension options like nonce, mortality, and tip. Custom signed extensions were also hidden behind a button that was easy to miss.

Now everything is in the same form, which makes it easier to customize while also requiring fewer clicks to submit extrinsics.

Extrinsic Analyzer

The extrinsics page now has a tab where you can paste an extrinsic and have it decoded, showing the call data, signature, signed extensions, and more.

Additionally, some signed extensions have a detailed view. For example, mortality visually shows the mortality window, including which blocks it starts and ends on, while ChargeAssetTxPayment is presented in a more human-readable way.

Account Locks

The Account page now also features a section for managing your account locks.

It scans the different pallets that might cause locks, shows where the different locks were found, and offers quick actions to remove them.

Query at block

Previously, we already supported querying storage at a specific block for RPCs that support archive queries.

Now we also support this for runtime calls, view functions, and constants.

Digest

The block detail page now also includes a decoded view of the digest, showing the engines used and their decoded payloads.

Proxy and Multisig signers

You can now also set up signers that wrap other signers. For instance, if you are one of the delegates of a proxy, you can create a “Proxy signer” that wraps your actual signer and adds the appropriate proxy call when you sign a transaction with it.

Similarly, using our PAPI Multisig Tool, a fully decentralized multisig signing tool, you can create a Multisig Signer that generates a PAPI Multisig Tool link. You can then share that link with your multisig peers so everyone can sign it.

Closing

That’s all the updates we have for now. We’ll keep sharing progress over the next few weeks.

The three of us are going to the Web3 Summit this week. Hope to meet you there!

30

hello papi

31

Hey everyone!

Here’s a quick new update about Polkadot-API.

Polkadot-API v3 RC.1

We’ve released the first release candidate for PAPI v3, which fully supports Extrinsic V5 and general transactions :tada:

While it was already possible to create V5 extrinsics with PAPI v2, it wasn’t well optimized and relied heavily on the signer, which meant that some cases required workarounds. Now, with the stabilization of createTransaction, the signer is generalized, fully supporting Extrinsic V5 with multiple extension versions.

The biggest breaking change is for signer implementations, as PolkadotSigner has been replaced by TxCreator. For developers using PAPI, the breaking changes are minimal:

  • The sign, signAndSubmit, and signSubmitAndWatch methods have been replaced by create, createAndSubmit, and createSubmitAndWatch.

    This was needed to better represent the new action, as creating a transaction doesn’t always require a signature.

  • getPaymentInfo and getEstimatedFees now take a TxCreator instead of an account address.

    This was needed because, in order to get payment info on-chain, you need an extrinsic because it depends on the extensions, like nonce. PAPI v2 worked around this by creating a “fake” signer before querying the information.

    With general transactions, this is no longer practical, as PAPI doesn’t know the expected extrinsic type or authorization method. So now it takes a TxCreator.

    The TxCreator interface supports fake signing, so estimating fees won’t require the user’s signature, while still being generalized for any authorization method.

This is, of course, compatible with V4 extrinsics as well, as it is a generalization. We encourage developers to give it a try and let us know about any issues or possible improvements before we stabilize it into the final PAPI v3 release.

In PAPI v2, we’ve released two additional patches, 2.1.7 and 2.1.8, updating to the latest Smoldot version. Also, thanks to @kheops for a fix in the pjs-to-tx helper.

PAPI Console

The PAPI Console is finally out of beta :confetti_ball:. Since the last update, we’ve added the following:

Metrics

A new Metrics page, showing various stats about the chain: block time, weights, finalization time, transactions, and more.

Network Picker

We redesigned the network picker, making better use of space and requiring fewer clicks to select a chain.

Additionally, it now includes a way to select “Any WS RPC”, and PAPI will use the first one that works.

Forklift

We’ve integrated Forklift into the console as an alternative way to fork a chain.

It currently supports the same features as Chopsticks, but it will allow us to build more features on top of it.

Validate and Dry Run Extrinsics

When creating an extrinsic, the console will validate it in the background and let you know in advance whether it will be valid.

Additionally, it lets you dry run the extrinsic on a local fork, returning the actual events that would be produced by submitting that extrinsic, without requiring a signature.

Other Fixes

We’ve also polished small things, such as rounding issues, nonce display, some jitter on the explorer page, and more.

Thanks also to the external contributors who help keep networks and RPCs up to date: @pandres95, @gatotech and @stakeworld.

Closing

With this, we’ve delivered everything that was left in our last proposal.

We’ll continue with basic PAPI maintenance, stabilizing v3, and working with teams to ease the migration.

We’ll also be in conversations again with relevant stakeholders regarding a new proposal for future work.

Thank you all for your support!