[DISCUSSION] RFP-002: Avail Wallets

Research & Explorations RFP Discussion
1

RFP-002: Avail Wallet Support

Note

Use this space to discuss and ask questions about the RFP. We want this thread to facilitate a 2-way communication between the community and the team regarding this RFP.

Context/Background

As a Substrate-based chain, Avail inherits some of the infrastructure and tooling created for the Polkadot/Kusama ecosystem. However, Avail implements certain changes to the chain that make some of the tooling not work out of the box. This is the case with wallets, which need some tweaks to support Avail.

Since Avail is building a rollup infrastructure designed to provide scalable blockspace and data availability, the primary use cases for wallet integrations are:

  • Validators and nominators managing their accounts and staking/nominating
  • Blockchain Infrastructure providers (e.g., rollups) and applications (e.g., sovereign appchains) managing accounts used to pay transaction fees to post data to Avail
  • End users using applications that post transactions onto Avail

Project Description

A wallet tailored to work with Avail would ideally have the following features:

Essential Features

The following are key features for the user types above, with some Avail-specific notes.

Account Management

  • Create account
  • Import account (e.g., created via the explorer or subxt)
  • Export account

Transfers

  • Receive AVL transfers
  • Transfer AVL to another account

Staking

  • Bonding to validate, nominate, or join a nomination pool
  • Bonding more funds
  • Unbonding and withdrawing unbonded funds

Advanced Features

Verification

  • Embedded light client for verifying availability and other functions

Avail has a light client implemented in Rust that can verify the chain’s published blocks are indeed available, without downloading the entire blocks. It does this by using DAS (Data Availability Sampling), coupled with KZG commitments and erasure coding to verify that sampled data is accurate. Only a few KBs need to be downloaded to provide high guarantees of availability.

Not Supported

For clarity—there are some features sometimes found in wallets that are not supported in Avail directly but on execution layers built on top of Avail:

:x:Receive or transfer other tokens or NFTs

AVL transfers are important for Avail users, but other types of tokens are not directly supported, because Avail does not have an execution layer. Other tokens could be implemented by an execution layer higher in the modular stack, but those are out of the scope of this document.

:x:Dapp support

For the same reason, Avail does not directly support dapps—in the modular stack these are higher, implemented as either appchains or contracts on a chain on Avail.

:warning:Token bridging

Avail does not yet have a token bridging solution in place, only a lower-level attestation bridge with Ethereum. We do hope to have a smooth way to exchange AVL in the future.

Known Complexities & References

Avail blocks have some header changes that require some configuration to the Polkadot tooling to make RPC calls. See the rpc, types, and signedExtensions options passed to the polkadot.js API in this example.

Beyond that, much of the tooling should work.

In particular:

  • Avail supports ed25519 keys as accounts, and all of the standard Polkadot tooling will work with them.
  • Transfers work via the standard balances pallet extrinsics without any changes.

An exception is the Polkadot browser extension, which currently does not work.

Visit the Avail Docs site to learn about Avail and how to build with it.

Read the entire RFP, Funding Milestones, and Application Instructions here.

5 Likes