# Platform

> How the Sollar mini app platform is built and why — runtime, security model, identity, review policy and distribution.

Source: https://miniapp.sollar.com/platform/

---

This section explains **why** the platform is shaped the way it is. It is background, not
instructions; nothing here is needed to ship a mini app, and all of it is needed to argue with the
design.

| Page | |
|---|---|
| [Architecture](/platform/architecture/) | The runtime, and why it is a hardened WebView |
| [Security model](/platform/security-model/) | The threat model, and the six failures it is built against |
| [Identity](/platform/identity/) | Four layers of identifier, and why correlation is prevented |
| [Review policy](/platform/review-policy/) | What Sollar checks, and what it refuses |
| [Distribution](/platform/distribution/) | Two gates, version states, rollout and revocation |

## The shape of the decision

Sollar's core is deliberately narrow: messaging, calls, translation, groups, AI agents. Everything
that involves communication is in; everything else is out. There are no connectors, no MCP servers,
no plugins, and no skills in the core.

That is not a limitation to be worked around later. It is the premise. A messenger that accepts
arbitrary third-party extensions into its core has, in practice, accepted arbitrary third-party code
into the process that holds every conversation its users have.

**Mini apps are what make Sollar a superapp** — and they are the *only* extension surface. A mini
app is a signed, reviewed, sandboxed web package whose capabilities are enumerated in a manifest
that a human approved and a key attested. That is a very different security proposition from a
plugin.

It also resolves what would otherwise be a contradiction. AI agents are a core pillar, and an agent
that cannot act is a chatbot. So agents need capabilities — but opening the core to give them
capabilities would undo the premise. The resolution is that the mini app's `actions[]` **is** the
agent tool registry. One installation, one permission model, one review, two consumers.

## What this costs

Being honest about it, since the rest of this section argues for the design:

- **No payment API.** A mini app cannot take money in-app. See [Store compliance](/compliance/).
- **No embedded browser component.** External content opens in the system browser.
- **No native API surface beyond Sollar's own domain.** Camera, location and files are Web APIs, and
  what they cannot do, a mini app cannot do.
- **Every new native capability is an Apple approval, not a sprint.** Guideline 4.7.2 makes exposing
  a platform API to third-party software a matter requiring Apple's prior permission.
- **Nothing here has been through an independent security audit.** The platform is specified, not
  built. Treat the claims in this section as a design intent with evidence, not as a result.
