Polkadot-API updates thread

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:

6 Likes