Based Apps

What it is

Start here when one app needs shared-state concurrency by default.

You build one app in Rust. It runs inside a managed environment that provides built-in accounts, balances, shared-state execution. If your product is mostly about native asset rules without default shared-state concurrency, first check whether Covenants fits more naturally.

Mental model

Picture users sending app actions through Kaspa L1 to your app. The managed environment runs your Rust logic, updates shared app state, and later settles back on L1.

flowchart TD
    U1[User A]
    U2[User B]
    L1[Kaspa L1]
    R[Managed environment]
    A[Your Rust app logic]
    S[Shared app state<br/>Balances and app data]

    U1 --> L1
    U2 --> L1
    L1 --> R
    R --> A
    A --> S
    S --> R
    R -.-> L1

Pick this when

• Many users need to touch the same app state without waiting for previous actions to finish.
• You want built-in accounts and shared-state execution.

Good fits

• Consumer apps with many concurrent active users
• Trading venues or product suites

When not to use it

• Your product is mostly about native asset rules and flows.
• You do not need concurrency by default and your state fits naturally in Covenants.
• Each action should be verified and settled independently.
• You need a custom account model or a privacy-first execution model.

Current expectations

This option is in construction.

If you are thinking about broader app-to-app composition, treat Full vProgs as the future direction rather than a separate current option.