Mini Apps on Polkadot

Ecosystem
1

What problems do we face with Polkadot from a user perspective?

  • There isn’t enough “to do” within the Polkadot ecosystem
  • We have a negative perception of “no users” or “no apps” (even if untrue)

What problems do we have from a technical perspective?

  • Many of the products being built have long cycle times - all previous products were infrastructure (chains) which then had typically a single dapp built on them. New products built on existing chains also have a long cycle time.
  • Long cycle times mean a long wait for failure, hard to achieve product market fit
  • High complexity to build. The current stack has a high complexity to understand and this deceases the incentive to build on Polkadot vs Solana.

What tailwinds do we have?

  • PVM launching soon on Assethub allows for a new generation of dapps to be built, fun things to be tried and tested
  • PVM brings solidity compatibility, opening up to a wider range of builders in Web3. However web3 builders are still a niche subset of the total developer community.
  • We have wallet products with good adoption (Talisman/Nova/Subwallet) that have good fanbases

What headwinds do we have?

  • Simply launching smart contract functionality and paying existing products to deploy on Polkadot doesn’t necessarily mean we will achieve product market fit or bring any more users.
  • (I speculate) not many of these “to be deployed” products will bring virality, culture, fun or a real drive to bring users to Polkadot. So Uniswap gets deployed on Polkadot, so what?

What are other options beyond solidity compatibility

Something others are doing to drive adoption is building, facilitating and pushing Mini Apps.
Mini apps are popular in Web3 with Farcaster with mini apps being built on Base and pushed hard in Coinbase wallet.
Mini apps are very popular in Asian super apps specifically, e.g. Wechat, Line and popular in more western products like Telegram.

Building mini apps on Polkadot could help solve the negative user perceptions of “nothing to do” and help with the long cycle time of building products. You could easily vibe code a mini app by having cursor understand a basic SDK.

It could also help with people experimenting with Polkadot without needing to build a smart contract, bringing Polkadot development opportunities to even more people.
If these mini apps / products are good enough, they could be built into smart contracts or have their functionality expanded.

How to proceed with MiniApps on Polkadot

  • Create a standard / SDK for mini apps that can be rendered on the web like Farcaster
  • The SDK should be the first step and could emulate basic SDKs like Base’s MiniKit.

Once the SDK is being built.

  • Create a small team to design, develop and deliver mini apps
  • Like a dapp browser, in the Polkadot App we could feature popular mini apps that let you perform certain actions / tasks / games in the app to retain users and increase engagement.
  • These mini apps could also let users spend or play with their DOT / USDC for mini experiences.
  • This will allow us to iterate fast, deliver fun experiences and potentially bring a creative culture back to Polkadot.
  • These mini apps could be visible in any wallet, browser page, the Polkadot website etc.

Why not just wait for PVM and smart contracts?

Assuming the SDK is good enough, this opens up building on Polkadot to anyone with front experience, without needing to learn another language or skill. It allows people to easily deploy something fun and try things out.

What do we need for success?

We need to ensure that the mini apps have a place to be discovered / interacted with and promoted. This would likely be Nova Wallet, given it has an established user base.
The Polkadot app (and other wallets) can also display a curated list of Miniapps, built by reputable developers.

To have the best success, many teams should build at least one mini app to galvanise the idea, protocol and SDK.

Mini Apps SDK

  • The SDK needs to be free to use and not required a sign up, cost, or tokens to interact with.
  • The SDK must be opensource and ideally contributed to by many parties.
  • The SDK should be API agnostic, meaning that the design is not tightly coupled to a specific API e.g. Papi, Polkadot JS
  • The SDK should feature simple to use APIs that require no blockchain knowledge of how to interact
  • The SDK should allow other teams to contribute to it, building APIs for their specific functionality. E.g. if Hydration wanted to extend an API for a service they provide, they could make a simple API exposing this for developers to use.

How would we move forward?

  • If interested, we should perform deeper market research on mini apps as a whole across web2 and web3, specifically the SDKs provided, how easy it is to get setup and build with these products.
  • Allocate a budget / team towards the building of the SDK proof of concept via an RFP

I have discussed this idea with many parties and they have all given positive feedback, so I’ve decided to bring this to the forum for others to give their feedback and ideas before raising an RFP.

Discuss :high_voltage:

10 Likes
2

A focus on simplicity, inclusivity, and low-barrier experimentation will make this initiative stand out. Mini Apps should be something anyone with basic web skills can vibe-code on a weekend, with clear docs, open standards, and no gatekeeping.

It’s a fantastic idea, and with that focus, it could become a unique adoption vector not just for developers, but for culture within Polkadot.

Looking forward to seeing this take shape.

1 Like
3

The current idea is great, and I appreciate you sharing it with the community. The following is additional feedback, not meant as a replacement of your idea :slight_smile:

What I think the proposition is missing is the “who builds what and when” and “why would they bother” piece. It reads to me like trying to fix things by just adding more code (an SDK), and not by getting people excited to build. The same point you make in the “headwinds” section apply for this idea: it’s currently possible to create self contained, single file HTML dapps (i made a few I shared on X and with colleagues, they would qualify as mini apps), so if an SDK like this would exist, why would someone build a mini-app?

Building stuff for users on Polkadot is currently too hard and I acknowledge that. You gotta fight with wallets, fight nodes and complicated tech stuff, APIs also change very often, and it takes ages. In short, developping a dApp has a clear cost (maintenance & keeping up with upgrades), and the only reward mechanisms are either through treasury/grants or by manually building in a fee to a utility.batch call (cumbersome and confusing thing to present to a user).

So not many people do it, or they give up after releasing a V0-beta. Plus, even if you build something cool (like what we saw with the ordinals, to date it remains a visible bump in the charts), there’s no real way to keep earning from it easily. You just hope it helps your main, bigger project, or you ask the treasuries for money.

I believe we need to make it super easy for anyone (especially normal web devs) to build small, useful, and most importantly PROFITABLE things on Polkadot that people actually want to use. The key is that those builders should get paid automatically when people use their stuff. No asking the treasury or complicated grant applications for every little thing.

So maybe instead of mini-apps we can take the idea of a nice toolkit, like what the UX bounty is currently doing here: a thing that hides all the complicated Polkadot stuff, and add to it the incentivisation part (on-chain logic?).

Want to send DOT? One line of code. Want to use a smart contract? One line of code. An AI could even write this code for you, like what we showcased at the Parity retreat in December during the hackathon with the invited ecosystem teams, or the Façade project we have internally aiming to abstract away the set of decentralized APIs that the different Polkadot units provide. (if you like the sound of this, please reach out!!)

The crucial part is that if your little tool gets used and it involves a fee (even a tiny one), you automatically get a cut. By design, and not shoe horned on top. The hypothesis hinges on:

  • If it’s easy and you can make money, more people will build. Not just hardcore crypto devs or hobby tinkerers. The builders have a vested interest in making their dapp/mini-app succeed, and thus Polkadot APIs used.
  • Lots of small, useful tools mean users actually have things to click on and interact with. Solves the “nothing to do” feeling and the “same dapp but just with different colors”, so more diversity.

When builders try to make successful little tools despite the hurdles (CUDA isn’t fun to work with, but people use it to build cool stuff), we have designed a way to sustain continuous development: because success == they earn. In some sense, making those who use Polkadot win, will make Polkadot win. And I’m sure they’ll talk about it too, so free marketing & excellent inbound.

Giving people a reason to build here will help in the long run, because FWIW, Farcaster built a community around its social protocol first and then added the frames stuff, to add utility within the community vs a gimmick to bootstrap it.

A tangential (but crucial) point will of course be: who gets to select or curate the mini-apps that make the cut to the place we send people to (Nova/Polkadot App)? Without a distribution channel, success is difficult and we remain at the mercy of others.

So your idea would be in essence building a sort of “mall” and fill it with lots of cool little “shops” (the mini apps) that people want to visit. So far so good. What I suggest is to make sure the shopkeepers (developers) actually want to run them, and if they run them well (read: they are profitable), they are happy and have a chance to stick around as the sole stewards of their success.

I hope my answer helps to add some perspective! Happy to chat about it in a burger place soon, leaving the picture out for now :grin:

4 Likes