Ecosystem Dev
Ecosystem App Development
Building in Moss is not only about deploying a logic contract. It is about plugging an app into the account, installation, and monetization system.
4 sectionscontracts-and-deployment
01
Why Build Inside Moss
Moss gives apps more than a traffic source. It gives them an existing account context. Before users open your app, they already have a wallet, assets, permissions, and an installation model.
That lets developers spend less time rebuilding the account layer and more time on application logic.
- Account, asset, and permission semantics already exist.
- Wallet-native asset capabilities can be reused instead of rebuilt.
- Apps can be installed into the Runtime through Store.
- Distribution and monetization have on-chain state behind them.
02
What Store Gives Developers
- Your app can be registered, discovered, and installed instead of spreading only through an external link.
- Install state makes “this account installed your app” a verifiable fact.
- After install, the app reappears inside the Runtime instead of staying inside the store page.
- Store also handles revenue recording and distribution. It is not only a catalog.
Key point
Store matters because it turns app distribution into part of the account system.
03
Revenue and Builder Benefits
- The current split is 70% for developers and 30% for the Store.
- Revenue is recorded per app rather than mixed across the whole ecosystem.
- Builders get a clearer path from installation to usage to revenue.
- Compared with a standalone site model, Moss can close the loop between install, usage, and monetization much more directly.
04
Questions to Resolve Before Launch
- Should this app really live inside the account surface, or is it better as a standalone site?
- Can it reuse wallet-native asset capabilities instead of shipping its own asset-control layer?
- What install, enablement, and permission path does it need?
- After installation, what should the entry and visible state look like inside the Runtime?