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, distribution, and monetization system.

4 sectionscontracts-and-deployment

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.
System modules can be reused instead of rebuilt.
Apps can be installed into the account workspace through Store.
Distribution and monetization have on-chain state behind them.

What Store Gives Developers

Your app can be registered, discovered, and installed instead of spreading only through an external link.
App NFT makes “this user installed your app” an on-chain fact.
After install, the app reappears inside the account workspace 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.

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.

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 TokenManage / NFTManage instead of shipping its own asset-control layer?
Does it need system capability, explicit authorization, App NFT installation, or some combination of the three?
After installation, what should the entry and visible state look like inside the account workspace?