Flap Apps (Draft Spec)

From a token launchpad to an app launchpad.

Flap will not only be a launchpad for tokens — with Flap Apps, it becomes a launchpad for apps. Ship your contract; Flap hosts your UI and backend and keeps your app running. Your app, unstoppable.

Table of Contents

• Vision
• Roadmap
• From token launchpad to app launchpad
• Why Flap hosts mechanisms
• What is a Flap App?
• Vault vs Flap App
• Architecture
• The three layers
  • 1. Contract — any audited contract
  • 2. Backend — hosted by Flap
  • 3. UI — hosted by Flap
• Flap Shared Indexer (FSI)
• Building a Flap App, step by step
• Open questions

Vision

Today, everything built on Flap starts with a token. Flap Apps remove that requirement. Any project with a smart contract — a game, a tool, a launchpad, or a Vault — can launch on Flap and get the same guarantees mechanism tokens get today:

• Audited contracts, reviewed by Flap and its partner security firms.
• Flap-hosted UI, so the app doesn't disappear when its creator walks away.
• Flap-hosted backend, through shared infrastructure instead of servers the developer has to keep alive.

Roadmap

From token launchpad to app launchpad

Flap started as a launchpad for tokens. With Vaults, a token's tax flows into a smart contract where the developer implements custom logic, and with a Vault UI that logic gets its own interface — hosted by Flap.

But the Vault model has a structural limitation: you need a token first. A token is launched, then it has a Vault, then the Vault gets a UI. Many applications don't fit that shape:

• a tool (a dashboard, a calculator, a batch utility) that has no token of its own;
• a launchpad built on top of Flap that launches other people's tokens but has no token itself;
• a game whose contract people play with directly;
• any other app that simply has a smart contract users want to interact with.

These apps still have a contract, still need a backend, and still need a UI that users can trust to keep working. Flap Apps widen the Vault + Vault UI model to cover them. Our goal is for Flap to be a launchpad of apps, not just a launchpad of tokens — and for Flap's infrastructure to make your app unstoppable.

Why Flap hosts mechanisms

Almost every token that uses a Vault has some mechanism built into that Vault — dividends, buybacks, games, social-proof routing. We call these mechanism tokens. Their biggest pain point is durability:

• If the UI is hosted on the creator's own server, the mechanism dies when the creator rugs, loses interest, or stops paying for hosting.
• If the mechanism needs a custom backend (an indexer, a database, a keeper), it dies when that backend goes down.
• Users can't tell whether the contract behind a third-party UI is safe.

Flap removes these failure points:

Developers only have to care about the contract itself, and integrate Flap's infrastructure into it so the app is as decentralized as possible. Users don't have to worry that the mechanism will break because of a dead server or an unmaintained contract: the contract has been checked by Flap and its audit partners, and the UI and backend are run by Flap.

What is a Flap App?

In this draft, a Flap App is:

1. An app whose UI and backend are both hosted by Flap. It is published at its own URL on Flap (https://flap.sh/apps/{slug}) and does not need a token, a Vault, or a factory to exist.
2. Backed by any smart contract. The contract can be a Vault, but it doesn't have to be. A game contract, a tool's helper contract, or a launchpad contract are all valid.
3. Audited. The contract must pass an audit. We work with partner security companies who will audit your code.

That's it. We don't draw a hard boundary around what a Flap App may do — during the draft phase we keep the definition open and review submissions case by case.

Vault vs Flap App

A project can ship both: a Vault UI for its token and a standalone Flap App. They are reviewed and published separately but can reuse the same contracts and most of the same UI code.

Architecture

flowchart LR
    U[User] -->|flap.sh/apps/slug| UI

    subgraph Flap["Hosted by Flap"]
        UI[Flap App UI<br/>reviewed and built by Flap Workbench]
        FSI[Flap Shared Indexer<br/>indexes and serves your contract's events]
        INFRA[Other shared infrastructure<br/>Trigger Service, AI Oracle,<br/>X General Verifier, FlapVaultEx]
    end

    subgraph Chain["On-chain"]
        C[Your audited contract]
    end

    UI -->|reads, simulates, writes<br/>through the Flap SDK| C
    C -->|emits FSI events| FSI
    UI -->|queries leaderboards,<br/>feeds, activity| FSI
    C <-->|callbacks / proofs| INFRA

All business state and every rule that moves funds live in your contract. Flap hosts everything around it.

The three layers

1. Contract — any audited contract

Your contract can implement any logic. The only hard requirement in this draft is that it passes an audit by one of Flap's partner security companies before the Flap App is published. Reach out to the Flap team to schedule one.

Keep in mind when you design the contract:

• Put everything that matters on-chain. Anything involving funds must be enforced and readable on-chain. Off-chain data (including FSI) is a cache for display, never a settlement source.
• Prefer Flap's shared infrastructure over your own servers. If you need a scheduler, an AI decision, or a social-proof check, use the existing services — see Quick start for Vault Developers § 3. They work for any contract, not just Vaults.
• Emit FSI events for anything your UI needs to list, sort, or page through (see below), so you never have to run your own indexer.

2. Backend — hosted by Flap

Most apps need a backend for one reason: to turn on-chain events into data a UI can query (leaderboards, user histories, feeds, activity logs). Instead of running your own indexer, database, and API, your contract emits a small set of standard events and Flap indexes them for you — this is the Flap Shared Indexer (FSI).

Other backend needs are covered by existing Flap services:

If your app needs a backend capability that none of these cover, tell us — that is exactly the kind of infrastructure we want to add.

3. UI — hosted by Flap

Flap App UIs are built with the flap-vault-component-template, the same template used for Vault UIs, in its standalone Flap App v2 mode. The developer preview lives on the template's feat/mini-app-v2 branch — start with its Flap App v2 quickstart and the step-by-step walkthrough.

The essentials:

• A controlled business component, not a free-form website. Like a Vault UI, the App is a React component under src/vaults/{slug}/ (Component.tsx, manifest.json, VaultABI.ts, i18n.json). The same safety boundaries apply: no direct wallet provider access, no undeclared endpoints, no hidden transaction targets.

• Independent identity. The manifest declares the standalone model and an immutable slug, with no token/factory/Vault bindings:

  {
    "schemaVersion": 2,
    "mode": "mini-app",
    "appModel": "standalone",
    "slug": "my-app",
    "artifactId": "vaultui_my-app_01ARZ3NDEKTSV4RRFFQ69G5FAV",
    "name": "My App",
    "displayTitle": { "en": "My App", "zh": "我的应用" },
    "match": { "bindings": [] },
    "i18n": ["en", "zh"]
  }

• Reviewed wallet permissions. Instead of binding to a token, an App declares exactly which chains (walletChains) and which contracts and function signatures (walletContracts) it may call, with bounded native value and ERC20 approval caps. Dynamic per-token targets go through on-chain resolvers. The host refuses any transaction outside the declared policy.

• One SDK, host-owned wallet. The App calls useFlapSdk({ chainId }) for reads, simulations, writes, and receipts, using the user's wallet already connected to Flap. Apps never implement their own wallet connection.

• Check, test, package, review. yarn app:scaffold → yarn app:check → yarn app:e2e → yarn app:package → yarn app:verify-package, then submit the generated ZIP to the Flap App Workbench. Flap reviews, builds, and publishes it at https://flap.sh/apps/{slug}. No on-chain registration is required for the UI.

Flap Shared Indexer (FSI)

A Flap App does not run its own indexer. It emits events in the Flap Shared Indexer (FSI) templates, and Flap indexes them and serves them over HTTP to the app's UI: leaderboards, user histories, feeds, activity logs. See the FSI page for the templates, the base contract, write semantics, the query API and quotas.

Building a Flap App, step by step

1. Talk to us early. Since the draft scope is reviewed case by case, share your idea with the Flap team before building too much.
2. Write the contract. All rules involving funds live on-chain. Integrate Flap's shared infrastructure rather than running your own services.
3. Emit FSI events for every list, ranking, or history your UI needs. Use absolute values for A/B and append-only records for L/G.
4. Test with integration tests, and on BNB Chain Testnet or Robinhood Testnet (https://testnet.flap.sh).
5. Get audited. Your contract must pass an audit by one of Flap's partner security companies.
6. Build the UI with the template's standalone Flap App v2 mode: scaffold, implement against useFlapSdk({ chainId }), declare walletChains / walletContracts, and pass app:check and app:e2e.
7. Package and submit the ZIP produced by yarn app:package to the Flap App Workbench, together with your slug, display titles, feature summary, endpoint declarations, and contract upgrade-authority notes.
8. Go live. After review, Flap publishes the App at https://flap.sh/apps/{slug}.

Open questions

This draft deliberately leaves several things open. We will settle them as the first Flap Apps go through review:

• Scope. There's no hard boundary yet on what a Flap App may be; each submission is reviewed case by case.
• Contract upgradeability. Verified Vaults must use the beacon proxy pattern with upgrade authority held by the Flap Guardian, so audit findings can be fixed. Whether Flap App contracts follow the same rule is still being decided.
• Audit process and cost for non-Vault contracts.
• FSI trusted scope. Today trusted only marks Vaults registered on VaultPortal; whether audited Flap App contracts are also marked is still open.
• FSI details still to be confirmed: whether data stays string or becomes bytes (this would change the A/B/L signatures and must be decided before signatures freeze), whether historical (time-travel) queries for A/B open up, and whether the default quotas are enough.
• Real-time updates. A WebSocket push of not-yet-confirmed values is planned so UIs can show "confirming" state immediately; logic involving funds must still read on-chain state.

Feedback on any of these is welcome — reach out to the Flap team.