Polkadot-API updates thread

Tech Talk
1

Hello there!

I’m Carlo, the most recent member of Polkadot-API team.

Polkadot-API (GitHub) is a project conceived to build upon and surpass the foundational achievements of the PolkadotJs project. At its essence, Polkadot-API is a meticulously crafted suite of libraries, each designed to be composable, modular, and fundamentally aligned with a “light-client first” philosophy. Our overarching mission is to empower dApp developers by equipping them with a comprehensive array of tools, pivotal for the creation of truly decentralized applications.

We’re currently on beta phase, and we plan to release our stable v1 by the end of Q2 2024. Following the example of smoldot, we’d like to open this thread and inform the community on a weekly basis (we’ll try our best to maintain the pace :wink:) a highlight of the progress made during the week.

We’re really active and responsive on our main repo and we, of course, maintain a CHANGELOG with all the relevant changes, but we seek a higher level of transparency with the community with this initiative.

Polkadot-API team (@voliva, @josep and @carlosala)

14 Likes
2

Lots of stuff (and some breaking changes) have been going on these week! We released v0.6.0 today (2024-05-03) wrapping all the changes to deliver them to our beloved early adopters. A big shootout to @kheops, @tim_b, and @mcornholio. They’ve been amazing reporting many bugs and unexpected behaviours. Thanks!

We want to do highlight some of them:

  • Transactions are now mortal by default. As Valentin from Nova pointed out, transactions should be mortal by default. That’s the new default! PR
  • Fee estimation is now more precise. Transaction fee depends, besides other stuff, on the length of the extrinsic. We’re now estimating better this measure, and therefore, fees are now closer to reality. Big shootout to @kheops for this report, besides many others! PR

Bilateral work with smoldot

These week we reported several issues to smoldot (#1787, #1788, #1789, #1804) and we want to thank @tomaka for the responsiveness and quickness solving all of them. As soon as it’ll be released, #1804 will have a big impact on loading times under certain conditions with PAPI and its sm-provider.

Tech deep-dive (PR #448)

PR #448 has been merged, and it’s an incredible change that makes our checksum-based method to construct types way more stable and resilient. Several things changed:

Tuple == Array?

A Tuple type that has the same inner type in all of its components (for example (u128, u128, u128)) now has the same checksum as a fixed-size array of that type (in our example [u128; 3]). These two types are encoded and decoded the same exact way, and therefore, they should hold the same checksum.

Mirrored types:

We also found another case where some circular types that were identical with each other would give different result. As an example, we had in our known-types repo XcmV2Instruction and XcmV2Instruction1, which were types that when you use them they are absolutely identical, but they had different checksums. And these types were in the polkadot relay chain. The problem is a bit hard to explain, but it’s when there were equivalent types with circular references where at some point you can switch from one to the other. This has been solved in the function that calculates the checksum.

Represented in a graph of types, we have something like this in the metadata:

image

Have a nice weekend!

6 Likes
3

:wave: from Soda,

We are excited about adopting the Polkadot API in our Ocelloids SDK. We have a few questions:

  • Could you please explain how compatibility is maintained between different versions of the runtime types? Do we need to generate them upon runtime upgrades, and how does this impact existing logic related to previously generated types?
  • Are there currently hashing-configuration-aware helpers available, or are there plans to develop them, to build storage keys for querying?
  • Do you have any plans to introduce high-level features such as recursive decoding and correlation of batch calls, or is this kind of functionality not within your current scope?

Thank you!

2 Likes
4

Hi @sodazone and thanks for reaching out!

I’m going to briefly answer your questions in here, but I would like to ask you to please move this conversation into GH, as I really think that it’s a much better suited forum for these kinds of discussions. Feel free to open as many discussions as you want.

Please have a look at this section of the docs, as I think that it already answers some of your questions.

Yes, there are. Also, some of them are already being used by other teams in the ecosystem. Although, they are not yet very well documented and/or stable, emphasis on "yet ". Eg: the getChecksumBuilder on @polkadot-api/metadata-builders and the (currently undocumented) view-builder.

EDIT: sorry, I think that you were referring to another kinds of hashing helpers. Yes, of course, please have a look at the tests of the @polkadot-api/substrate-bindings and this very straightforward storage helper. However, if what you want is to get the storage encoders/decoders for a given storage-entry, I recommend using the metadata-builders.

We already have recursive decoding, of course.

I don’t know what you mean by that. I mean, we support batch calls, of course… But I don’t know what you mean by correlation of batch calls.

I’m not sure because I don’t quite understand what you are asking, TBH.

Please, let’s move the discussion to GH :slightly_smiling_face:

1 Like
5

Tis’ been a pleasure!
Love the velocity and i’m excited about where the project is going.

Out of interest what would you say are the big ticket items the team wants to deliver next?

6

We always put at the very top of our priority list are the issues opened by the devs/teams that are using polkadot-api. Even if there is a lot of context-switching, we think that’s the right thing to do, because it helps at creating faster feedback loops, which we think is going to be very important for polishing the library for the delivery of the first stable version. Similarly, we try to spend as much time as possible in calls with different early adopters to better understand how they are using the library, what their thoughts are, the things that the docs didn’t explain properly, etc.

Then, leaving aside bug-fixing and other requested improvements, our main 3 focuses at this moment are:

1) Tx improvements:

As I explained in the last quarterly update there are a number of improvements related with the handling of transactions that are quite urgent. Yours truly is the one leading this front. I have already started tackling this, but the main things that need to be improved are: revalidate transactions after they have been broadcasted (this is one of the most important items), allow advanced users to pass custom nonce when creating a transaction, inform earlier about the events related to the transaction (as of right now you have to wait until its finalized or query those on your own), and a few more items that I will eventually put in a long issue.

2) Improve docs, jsdocs and tests:

@carlosala is the one leading this front. We think that this is a win/win, because on the one hand it helps him at getting more familiar with the top-level API, and the other hand it gives him an opportunity to check how things behave vs how things should behave, etc. There is quite a lot of work to be done in this end, but I think that we are making really good progress.

3) Improve bundle-sizes, loading times and types/DX:

@voliva is leading this end. He has already made quite a bit of progress, but there is quite a bit more work that needs to be done.

There are many other things that we would like to tackle, but we try to “pick our battles”, as they say. I mean, we also try to find some time to improve some of our inner libraries which can empower other dev-tool builders, but we think that our top priority at the moment should be to empower DApp builders.

6 Likes
7

Hello there! :wave:

We’re excited to announce that this week, on Friday (2024-05-10), we released polkadot-api@v0.7.0! A big thank you to our early adopters for their invaluable feedback and bug reports!

This update brings several enhancements, particularly on the transaction side, which we’ll explore in more detail in the following section. First, let’s briefly review some other changes this week:

  • Introduced a _request method in the client, providing an “escape hatch” for JSON-RPC provider consumers to access debugging endpoints. #482
  • Separated descriptor types from their values, reducing unnecessary display of empty pallets in operations. #502
  • Implemented “lazy-loading” for descriptors, significantly reducing the bundle sizes for dApps utilizing PAPI. #504
  • Enhanced the consistency and stability of the stop event recovery process. #493 #495
  • Ensured pjs-signer now returns the same payload as @polkadot/extension. #501
  • Updated smoldot to version 2.0.26, addressing issue smoldot#1804.

Transaction Improvements

This release features numerous enhancements regarding transactions!

Additions

  • We’ve introduced support for optimistic transactions. The .submit family of methods now includes an optional at parameter, allowing developers to specify the block for submission. #486
  • Added a custom nonce option, enabling advanced users to queue multiple transactions smoothly. #498

Changes

  • Refined the structure of transaction events:
    • signed: Now returns the txHash for user convenience. This resolves issue #346.
    • broadcasted: This event also now includes the txHash.
    • txBestBlocksState: This event has been significantly revised to provide more detailed information, ensuring consistency with the finalized event.
    • finalized: Continues to provide the same detailed event information.

We believe these changes will greatly enhance the functionality of our transaction API, which we expect to remain stable leading up to the official release.

Have a wonderful weekend ahead!

2 Likes
8

Hi community! :wave:

We’ve made several improvements to PAPI this week! Let’s directly dive into the details!

Bundle Size

PAPI descriptors have seen a significant reduction in size for multi-chain dapps. Our tests show the size has decreased by just over 50% in both parsed and gzipped formats. However, for single chain dapps, there is a slight increase of about 10%.

Controlling bundle size is a core aspect of PAPI development. Over the past few weeks, we’ve been systematically researching ways to reduce it even further.

CLI Improvements

This week, we enhanced the developer experience with the papi CLI. Here are the changes:

  • Added support for fetching metadata and generating descriptors from a WASM runtime without needing a running node, chainspec, etc. This should simplify the workflow for preparing a dapp for future runtime upgrades.
  • Accelerated the papi update and papi add commands while also reducing their memory usage.

Documentation

We’ve made significant improvements to our documentation! You can find more sections now on our docs page.

Quiet work

Besides all the visible work, we’ve focused on researching several things that we think that could be improved in PAPI.
One of them is how to improve our isCompatible (see docs) check. We aim to make it easier and more straightforward for developers to ensure it behaves as expected. We’re making really amazing progress here, and you’ll hear about it sooner rather than later!

Have a great weekend ahead!

3 Likes
9

Hi everyone! :wave:

It’s been a quiet week in the repo! @voliva and @josep flew to Singapore last weekend to attend PBA, as mentioned in our proposal. Due to this, we expect slightly slower progress over the next three weeks.

We’re steadily working towards our stable version, aiming for the end of Q2. Our documentation website is also being improved to cover more aspects of our library, and we’re very pleased with the progress!

A big thank you to PBA for accepting two of our team members into their course. We’re confident it will enhance our abilities to contribute to the Polkadot ecosystem.

Have a great weekend!

2 Likes
10

Hello community :wave:

We’re excited to share that polkadot-api@0.8.0 was released on May 30, 2024 :tada:. This update is fully compatible with previous versions, so we encourage all PAPI users to upgrade soon!

Updates

This week brought several enhancements:

  • We’ve further refined our documentation, particularly the events and tx sections.
  • We’ve added support for the CheckMetadataHash signed extension in PAPI, and the pjs-signer has been updated as well to accommodate this feature. Chains implementing this extension are now automatically supported in PAPI. For more insights, see this detailed post by @bkchr. This feature enhances security and safety, particularly for users of air-gapped signing solutions like Polkadot Vault or Ledger. A big thank you to everyone involved in this!
  • The blockNumber has been added to the tx payload, a direct response to feedback from our valued early adopters!

Decoded 2024 @ Brussels

We are pleased to announce our participation in this year’s Polkadot Decoded, where we will be presenting as well! It’s a fantastic opportunity to meet with fellow members of the ecosystem and some of our early adopters. We look forward to seeing you there! :rocket:

Enjoy your weekend!

7 Likes
11

Hi there :wave:

It’s been a while since our last post, and we’ve been quite busy over the past month and a half. Here’s a wrap-up of what we’ve been up to!

TL;DR:

  • We released polkadot-api@0.11 :tada: Let’s dive into the new features added from version 0.8 to 0.11.
  • We’re welcoming a new team member: a big :wave: to Hannah. We’ll introduce her further in future posts!
  • We published @polkadot-api/merkleize-metadata, which implements RFC#0078 natively in TypeScript.
  • We gave a fantastic talk (with a live demo!) at Decoded in Brussels. If you missed it, you can watch it on YouTube!

polkadot-api@0.11

Our last update was after publishing version 0.8. The biggest highlight is the introduction of a new compatibility check system.

Compatibility Check API

Previously, every interaction with the chain through the typed API had an isCompatible method that returned a boolean: compatible or not. This method allowed the dApp to know if the interaction had the same types as those generated at compile time. It was good but not enough. We replaced isCompatible with getCompatibilityLevel, which has four levels:

  • Incompatible: The types are completely incompatible, such as when a mandatory argument is added to a transaction.
  • Partial: The types are sometimes compatible and sometimes not, like when an optional transaction argument becomes mandatory. If you were passing the argument, it works; if not, it fails.
  • BackwardsCompatible: The types are different but always compatible, such as when a new enum variant is added to a transaction argument. All previous variants still work.
  • Identical: The types are exactly the same.

This change makes the previous “not compatible” situation more granular. In earlier releases, Incompatible, Partial, and BackwardsCompatible were all considered “not compatible.”

Other changes

We also made several small fixes and additions. Notably, we added support for the community-run testnet Paseo and made some changes to the PJS wallets support:

  • We now allow PJS wallets to send a modified payload for broadcasting, in line with PJS changes that enable wallets to modify certain signed extensions.
  • We added support for the signBytes functionality of wallets.

@polkadot-api/merkleize-metadata

We published @polkadot-api/merkleize-metadata, a library implementing RFC#0078 purely in TypeScript! We leveraged our scale-ts and @polkadot-api/substrate-bindings libraries to handle most of the SCALE encoding work, focusing solely on the implementation. It is feature-complete, and significant ecosystem players like Talisman have already implemented it seamlessly!

Have a nice weekend! :wink:

8 Likes
12

Hey everyone! :wave:

It’s been 10 days since our last update, and we’re thrilled to announce the release of polkadot-api@0.12.0! In this post, we’ll dive into the exciting new features and improvements in this version. Plus, we have some great news – our talk at Decoded 2024 is now available on YouTube. Check it out here!

Highlights of polkadot-api@0.12.0

CLI and Codegen Rework

Our beloved CLI tool, papi, and the codegen part have undergone significant rework. One of the major changes is that you no longer need to install @polkadot-api/descriptors before starting to work with PAPI. Now, the only dependency you need is polkadot-api.
We’ve optimized the system by creating the package locally in a .papi directory. This change addresses several flaws in the previous setup, making the experience smoother and more efficient.

Other Changes

In addition to the rework, we’ve implemented several other updates:

  • Named Error for Invalid Transactions: We now expose a named error when a transaction becomes invalid. You can read more about this in our documentation.
  • isCompatible Helper: To enhance the developer experience with the compatibility system, we’ve added an isCompatible helper. Details are available in our updated documentation.
  • New Chainspecs: We’ve added the Polkadot People and Paseo AssetHub chainspecs.

We’ve also fixed several issues reported by our early adopters. Thanks for your feedback and support!

We’re rapidly approaching the release of polkadot-api@1.0.0, so stay tuned for more exciting updates! :rocket:

4 Likes
13

Wow, time sure flies! It’s already been three weeks since our last update!

We’re thrilled to announce that Polkadot-API has officially reached its first stable release with version 1.0!

polkadot-api@1.0.0

The major highlight of this release, apart from a few bug fixes, is the addition of a smoldot worker specifically designed for NodeJS environments. While we’ve had a WebWorker for some time, the demand for a NodeJS-compatible worker was overwhelming, and we’re excited to finally deliver!

Other Updates

Wrap-Up Post

Our very own @josep has published a comprehensive forum post summarizing all the key changes and developments from the past 3-4 months. It’s a must-read to stay up to date with everything happening in the project!

Treasury Proposal

We’ve also submitted our third treasury proposal, outlining our development plans for the next six months (Aug 2024 - Jan 2025). We encourage you to check it out, share your thoughts, and participate in OpenGov by giving your feedback and votes. We greatly appreciate your continued support! Read about it at Polkassembly or Subsquare!

WebZero Hackathon

We kicked off our journey with PAPI Actions at the recent WebZero hackathon, which ran alongside the Web3 Summit in Berlin. We’re proud to share that we were one of the four winning teams! A huge thank you to everyone at the hackathon who supported us and to the WebZero team for making it all possible!

Wishing you all a great weekend! Stay tuned for our upcoming posts! :wave:

1 Like
14

Hello Carlo, I have a question, but I don’t find a answer in the topics. Sorry if it is redundant. I wrote a code in JS to retrieve rewards from my staked stashes. It normally returns my address, account identity and rewards in a time frame. Since some months ago it is not working. The functions related to identity is not working. i thing it could be related to the People chain, but not sure. Do you have any idea? I 'm beginner in java scrip but that worked. By the way, it is not working more less in the same time that polkadot.js ui stoped to show what validator is nominated and keep showing “waiting nominations”, although the stash nominated normally as I can check at subscan. Thanks. I think you will need more info, so I’ll be glad to share it with you.

15

Hi everyone :wave:

We hope you’re all doing well!

We’re excited to share another update, this time focusing on the key changes from 1.0 to our newly released 1.3, along with some other important news.

Chopsticks Integration

Our team member @voliva submitted a series of PRs (1, 2, 3, and 4) to the Chopsticks repo, adding support for the JSON-RPC API spec, specifically applying to the chainHead, chainSpec, and transaction groups of functions. We’re thrilled about these updates, as they now allow PAPI dApps and scripts to connect effortlessly with Chopsticks environments. This changes are available since chopsticks@0.15. A big thank you to the Chopsticks team for their guidance and support throughout the process! :tada:

Treasury Proposal Approved

We’re delighted to announce that our third treasury proposal has been approved and executed, with an incredible 99.99% of votes in favor! We’re deeply grateful to the community and our adopters for the overwhelming support. Rest assured, we remain committed to giving back to the community in return for all the encouragement we’ve received.

Technical Changes (1.0 :arrow_right: 1.3)

Stability

In recent months, our primary focus has been on improving the library’s stability. We’ve made significant strides in reducing runtime errors and fixed a few minor memory leaks. Special thanks to @tien and @mcornholio for reporting many of these issues! Additionally, we identified and resolved several bugs in the Polkadot-SDK’s implementation of the JSON-RPC spec, once again with invaluable input from @mcornholio. We opened a few issues to the SDK (1, 2, and 3) and developed enhancements to work around the flaws while waiting for fixes.

txFromCallData

We’ve introduced a new API within our top-level typedApi called txFromCallData. This allows users to create a Transaction object from binary call data, enabling signing, broadcasting, and even using it as a parameter in another transaction. This was a highly requested feature, and we’re thrilled to make it available!

TxCallData Type

Thanks to feedback from our adopters (especially @tbaut, thanks!) we learned that creating transactions with other transactions as parameters (e.g., Utility.batch in multi-chain dApps) was cumbersome due to some TypeScript limitations. We’ve greatly simplified the types, making them more flexible by default while still allowing developers to narrow them down as needed.

Thank you for your time!

8 Likes
16

Hello :wave:

For this first update of October 2024, we’re excited to announce a significant release of polkadot-api, which went live at the end of last week! In this post, we’ll walk you through the updates.

polkadot-api@1.4

Unsafe API

Since the launch of PAPI, one of the most requested features has been the ability to create a top-level client without relying on pre-compiled descriptors generated by our CLI, allowing for dynamic connections to arbitrary chains. We’re thrilled to introduce the new getUnsafeApi method in our top-level client, which offers a similar API to the previously available TypedApi.

However, this new API comes with its own limitations. It lacks runtime type safety and does not validate compatibility between the coded interactions and what is found at runtime; therefore it is an API meant for advanced users. We strongly recommend checking out our documentation to explore this topic further.

WebSocket Provider

The WebSocket provider has been completely reworked to introduce new features and address highly requested fixes from our users. Here’s an overview of the improvements:

  • Multiple Endpoint Support: The getWsProvider function now accepts multiple endpoints for the same chain. The provider will automatically switch between them in case of connection issues, both during initial connection and ongoing usage.
  • Connection Status: Consumers can now query the provider for the current connection status or supply a callback that gets called whenever the connection status changes, providing updated information.

We have significantly revamped the providers section to expand and clarify the content. Additionally, we recommend checking out the WebSocket section for more details on the new features.

UMD Export

We have also released this version with a UMD bundle, which enables PAPI to be embedded directly into an HTML <script> tag, as demonstrated in this example. This approach lowers the barrier to entry for PAPI and facilitates quick and easy prototyping, whether directly in a browser console or within a simple HTML file.

@polkadot-api/ledger-signer

Continuing our series of signers, we have just released a new signer for Ledger devices. This library serves as a bridge between polkadot-api and Ledger devices without the need of a PJS-based wallet extension, implementing the library-agnostic PolkadotSigner interface used by our signers. Special thanks to @tien for being the first to test it and for adding support in his fantastic library ReactiveDOT. See this tweet for more information. Big shoutout to him!

Check the library’s documentation and an example for more information about the library.

ink! support

Since the beginning of September, we have been working diligently to add first-class support for ink! contracts, and we’re pleased with the progress so far. We anticipate releasing an initial version in the coming weeks, allowing our adopters to start testing it and providing their invaluable feedback!

Thanks for reading us, and see you next time! :rocket:

7 Likes
17

Hello community :wave:

Again, one post summarizing our last two weeks of work! And, indeed, we released a new update, polkadot-api@1.6 is out there!

polkadot-api@1.6

This release comes with some bug fixing raised by our adopters, and some features as well!

Custom Signed Extensions

A request we had for some time was that our library did not support “custom” signed extensions, understood as extensions that are not widely used in the ecosystem and just affect one or a couple of chains. This is the case, for instance, of Avail’s appId. We now leave the consumer decide what to do with the extensions that are unknown to polkadot-api library.

Increased support to metadata v14

In this version we fixed some critical aspects regarding metadata retrieval and transaction validation that should increase the stability for those chains that only support this metadata version. Nevertheless, we encourage all teams to migrate in a timely manner to metadata v15, since it comes with several improvements; e.g. typed runtime-apis.

Other stuff

  • Once again, we have improved the library’s stability and reliability, particularly when handling "stop" events, connection errors, etc. Special thanks to @mcornholio for their invaluable help on this regard!
  • The polkadot-api now supports chains that use u64-based block numbers, including Kilt. We’re thrilled to have the Kilt team onboard!

JSON-RPC API SPEC

Since the release of polkadot-api@1.0, we’ve had to develop several “enhancers” for our WebSocket provider to ensure smooth integration with nodes based on polkadot-sdk, since they are not fully spec-compliant. We’re quite pleased with the results, as it highlights the flexibility and composability of our provider interface.

Besides that, we’ve just published a post on this forum sharing the insights we’ve gathered over the past few months. Check it out! :rocket:

Chain-specific docs

@mcornholio played a crucial role in this development! He wired everything up and wrote a detailed post a few days ago explaining the entire process. Make sure to give it a read to the post, and check the docs at https://chains.papi.how!

That’s all for this week. We hope to see many of you in a few weeks at sub0 @ Bangkok :wave:

7 Likes
18

Hello there! :wave:

It’s been a while since our last forum update, and we’ve been hard at work! Between maintaining and improving our libraries, we’ve also dedicated some spare time to developing a brand-new developer console. Today, we’re excited to give you a closer look!

polkadot-api@1.7 :rocket:

The latest release is packed with quality-of-life improvements and exciting new features. Here’s a quick summary:

Stable Release of ink!

We’re thrilled to announce the first stable release of the ink! module, now available for import via polkadot-api/ink. It includes as well an update to the CLI, which is now capable of generating types for a contract’s metadata, making it easier than ever to work with ink contracts.

Check out the documentation for all the details, and don’t hesitate to share your feedback—we truly value your input! :raised_hands:

Enhancements to Signers

After identifying and addressing some complex issues, the polkadot-api signers—and the top-level client itself—now fully support what we’ve termed exotic extrinsics. These are extrinsics whose origin isn’t a Multiaddress and whose signature isn’t a Multisignature.

Here are some examples:

  • Hydration: Uses an AccountId32 address directly, without a Multiaddress enum wrapping it.
  • EVM-Based Chains (e.g., Moonbeam): Utilize an AccountId20 (Ethereum-style address) and a standard ECDSA signature (secp256k1, as in Ethereum).

We’ve ensured that all possible permutations—at least those identified in our research—are now supported. :rocket:

Provider Reliability Upgrades

Beyond adding new features, we’ve significantly improved the WebSocket (WS) and Smoldot providers. These enhancements boost reliability and resilience, especially in handling unexpected behaviors from RPC providers (specifically for WebSocket connections).

PAPI Console: The Next-Gen Developer Tool :hammer_and_wrench:

At the recent sub0 conference in Bangkok, we proudly unveiled the PAPI Console, the very first end-user tool developed by the polkadot-api team. This project was a labor of love, created during our spare time alongside our ongoing work on the polkadot-api libraries. Despite being a side project, we’re thrilled with how it turned out and are excited to share it with the developer community.

The project’s goal is to make your development experience smoother and more intuitive. We’d love for you to give it a try and share your thoughts! Feedback is incredibly valuable as we continue to refine and improve the tool. You can submit your feedback or suggestions directly on the GitHub repository.

The PAPI Console is now live and available at dev.papi.how. Dive in and explore its features!

PS: If you missed the sub0 presentation, you can catch the recording on YouTube. It provides a deeper insight into the motivation and development journey behind the PAPI Console and a nice live demo.

Team Restructuring

At the end of October 2024, we made the decision to part ways with Hannah Redler, a developer introduced in our previous proposal. This hard decision was not made lightly, but we believe it was necessary to align the team with our current goals and priorities. We are grateful for Hannah’s contributions to the project and wish her the best in her future endeavors.

We acknowledge that this decision means we requested (and were awarded) some funds that no longer match our current team structure. We are committed to working with the treasury to find the best solution to address this. Despite this, we remain fully dedicated to minimizing disruptions, maintaining the quality and pace of our work, and continuing to exceed expectations as we always aim to do.

For the time being, the PAPI team will consist of Víctor, Carlo, and Josep, all working full-time to drive the project forward. This structure allows us to remain focused and continue delivering on our commitments.

5 Likes