Polkadot-API updates thread

[carlosala]

Hi there

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
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!

[carlosala]

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!

[carlosala]

Hello there

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!

[carlosala]

Hello community!

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!

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!

[carlosala]

Hi there

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:

• Smoldot: #2148 #2158 #2169 #2171 #2175

• Polkadot-SDK: #9300 #9773

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

[carlosala]

Hi there

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

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.

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.

@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!

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!

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!