Skip to content

Instantly share code, notes, and snippets.

Last active February 2, 2024 12:31
Show Gist options
  • Save xlc/ebc2476afb7ecacdaa5ce95ae3b991c8 to your computer and use it in GitHub Desktop.
Save xlc/ebc2476afb7ecacdaa5ce95ae3b991c8 to your computer and use it in GitHub Desktop.
Polkadot Project Ideas

Polkadot Project Ideas

If you are looking to build something on Polkadot ecosystem but don't know where to start, here is a list of the ideas that I would love to see them implemented.

If you actually start building one of those, or are already building something similar, please reach out to me and I can help you with mentoring & technical support (either from myself, someone from Acala team, or connect you to Parity or other ecosystem teams) and funding support (Polkadot Treasury, Kusama Treasury, W3F grant, Acala grant, other ecosystem grant).

If you have other ideas, please comment below and I can add it to the list.

Note that many teams are already working on various important common good library and tools such as generic multichain transaction history service so I will refrain to list those to avoid potential duplicated works.

Tools & SDKs

  • Generic Multichain Indexer

    • Index blockchain data from multiple chains into a single database to make cross-chain query possible
      • Polkadot, Polkadot parachains, Kusama, Kusama parachains
    • Index all the raw blockchain data, in raw format and parsed format
      • Blocks
      • Metadata
      • Extrinsics
      • Events
      • Storage changes
        • This is what current indexer / scanner missing
        • Store the changed storages for every given block
        • Allow people to query on exactly when a storage value changed (when my balance changed?)
    • Use relational database with JSON support. e.g. PostgreSQL
    • Problem to solve:
      • Make cross-chain query:
        • to analysis account activity across multiple chains
        • to analysis XCM related events across all related chains
      • Identity why / when something changed
        • When and why does my balance changed
        • When and how does a particular invariant breaks
      • Get notified on a particular storage changes
        • Event notification are not exhaust so monitor for storage change can be a better alternative depends on use case
      • Less needs to write custom indexer as this one already have EVERYTHING in the database. So all we need is write some SQL to create new views and make sure they are indexed properly.
      • This will be the foundation for many ideas such as XCM analyzer, blockchain notification tools, blockchain BI tools, etc
    • How to build it:
      • Use SubSquid or SubQuery or some custom solution (e.g. something like this) to index every blocks, and save all the related information to a database
      • Use state_traceBlock to query changed storages for a given block
      • Parse the storage change and store them as a JSON object
  • Generalized multichain monitoring solution

  • MobX integration for polkadot.js

    • Expose MobX API to access onchain data structure
    • Allow writing reactive program without writing reactive program
    • It is magical
    • Problem to solve:
      • Write sync code and it actually works under async environment
      • Super efficient because only one storage subscriptions is enough
      • I like MobX
    • How to build it:
  • Advanced Account management extension

    • Implements Proxy & MultiSig support on top of existing extension wallet (polkadot.js extension, Talisman, SubWallet, etc)
    • Browser extension allow people to configure Proxy & MultiSig
    • Problem to solve:
      • Make Proxy & MultiSig useable in dApps without waiting for extension support, which is never going to happen for some
      • Allow people to still use the existing extension without switching over
    • How to build it:
      • Implement a browser extension with some UI to allow management of proxy and multisig accounts
      • Hijack the injected injectedWeb3 object and override the signing functionality and replace the signing payload to proxy.proxy or multisig.asMulti and let the actual wallet to handle the modified signing request
      • Needs some PoC to confirm this won't cause some unexpected behavior (which is very likely to happen)
  • XCM builder

    • Library to build XCM calls
    • Need to be able to encode calls from multiple chains
    • Problem to solve:
      • XCM is super powerful but it is super hard to construct some XCM calls involoved with multiple chains. e.g. The one used by Kusama governance to make Transact on Statemine to make Transact on Kusama to accept HRMP channel.
      • Should be able to somehow figure out the correct weight limit
    • How to build it:
      • Just some js function to handle the tx encode, weight query, abstract common pattern (withdraw asset, buy weight, transact, refund) etc.
  • Fork the world

    • Implemented at:
    • Similar to this
    • Tools that takes storage snapshots from relaychain and parachains, tweak it, generate new genesis, launch a testnet with latest block state.
    • So we can easily replicate live networks locally and run some crosschain tests
    • Problem to solve:
      • Be able to test crosschain code with live network data
    • How to build it:
      • Allow user to specify the chains to fork
      • Get the latest storage from each chain
      • Tweak authorship related storages
      • Tweak block number consensus realted storages
      • Tweak account balances so you have test tokens to run the test
      • Allow user to specify what other storages to tweak
      • Generate new genesis for each chain
      • Generate script to launch each chain. Maybe able to use
      • Alterntely, you may fork Cumulus & Polkadot to create a custom client that ignores signature validation (always valid), ignores parachain block validation (always valid) and ignore some other security restrictions to allow this custom relaychain / parachain networks run with fake data and signatures.

Substrate & FRAME

  • safe-scheduler

    • Implements the scheduler traits
    • Instead of dispatch call in on_initalize, do it with an unsigned transaction that triggered by offchain worker
    • Allow governance method to purge bad scheduled tasks
    • Problem to solve:
      • Currently, if scheduled task panic, overweight, doing anything crazy, the chain dies. There is no way to avoid execute the bad task because it is part of on_initializehook that cannot be bypassed.
      • If it is triggered by offchain worker sending unsigned tx, that means the block producer can ignore it if it panic or overweight.
      • It is also possible to have all the council members submit a proposal & approve & close within a single block and with enough tip, front run the bad unsigned tx, to prevent it or fix whatever onchain data.
      • And on_initialize is executed before inherents so it have old block timestamp, no access to current relaychain parent number, etc.
    • How to build it:
      • Use the current pallet-scheduler as a reference implementation but add offchain worker & unsigned tx trigger part
      • Need to carefully handle the weights and priority and permission
  • Origin annotation macro


    • New macro to annotate origin requirement for extrinsic

    • Expose such requirement via metadata so frontend will know exactly which method are supposed to be called by users (the one annotated with EnsureSigned)

    • Problem to solve:

      • The only way to check what origin can call an extrinsic is reading the code, there are number of failed council proposal that are failed due to bad origin requirement. If those requirement are exposed to SDK then it will be possible to prevent such bad proposals in UI
    • How to build it:

      • Something similar to the pallet::call macro

      • Support such syntax:

        • #[pallet::weight(0)]
          pub fn root_only(origin:  #[require(EnsureRoot) _, parameter: u32) {}
          pub fn signed_only(origin: #[require(EnsureSigned)] T::AccountId, parameter: u32) {}
          pub fn council_only(origin: #[require(T::UpdateOrigin)] _, parameter: u32) {}
        • should compile to code with pallet::call and

        • #[pallet::weight(0)]
          pub fn root_only(origin: OriginFor<T>, parameter: u32) {
             let origin = EnsureRoot::try_origin(origin).or_else(|_|BadOrigin)?;
             // body
          pub fn signed_only(origin: #[require(EnsureSigned)] T::AccountId, parameter: u32) {
            let origin: T::AccountId = EnsureSigned::try_origin(origin).or_else(|_|BadOrigin)?;
            // body
          pub fn council_only(origin: #[require(T::UpdateOrigin)] T::AccountId, parameter: u32) {
              let origin: T::AccountId = T::UpdateOrigin::try_origin(origin).or_else(|_|BadOrigin)?;
              // body
      • If Metadata v15 is possible, update metadata format to include the origin information

      • Otherwise just abuse extrinsic doc and have the origin information appended there

      • Do the macro magic

  • Invariant macro

    • New macro to assert invariants
    • Should be compiled to nop with feature on-chain-release-build so that prod wasm is not included those assertions
    • But we can use wasm override to run node with those assertions to ensure everything are still fine
    • Problem to solve:
      • Catch bugs on production (or during tests)
      • Invariant are also part of the documentation
      • Helps with sleeping
    • How to build it:
      • There are many invariant / assertion library, just use them as reference or apply them to Substrate directly if possible
      • Use feature flag to gate it
      • Could be integrated with paritytech/substrate#10174
  • Generic Meta transaction pallet

    • Inspired by Jam
    • Allow dispatch calls on behalf of an account, authorized by the origin account signature
    • Make some interesting use case possible.
      • execute(batch_all([as_user(Alice, transfer(10 DOT, Bob)), as_user(Bob, transfer(100 aUSD, Alice))]), [alice_signature, bob_signature]) to perform atomic swap between Alice and Bob
    • Problem so solve:
      • Multi account atomic transaction
      • Dispatch tx on other chain via XCM
      • Allow other account to pay for tx fee
    • How to build it:
      • Few points to keep in mine:
        • The whole body must be part of the signature payload
        • The signature payload need to include chain genesis hash to prevent relay attack on other chains
        • Must have signataure replay protection
        • Usually nonce is used to implement replay protection, but in order to prevent state bloat, the account must have ED to keep nonce data, so it won't work for accounts that does not have balances. Therefore some alternative solution maybe needed.
        • Signer must have a way to invalid the signature. Or the signature cannot be valid forever.
  • Wasm View Functions

  • Parachain governane pallet

  • Redesign Event System

  • Interchain Proof Oracle Network

  • Wasm runtime fuzzer


Copy link

xlc commented Oct 9, 2022

@Vasilije1990 & others willing to take some of those ideas: I would also suggest to make a post at to describe your plan and share progress there. This helps others to discovery your work and we can also provide more in-depth feedbacks there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment