oapps-fun

openapps.xyz（oApps）向けのビルド

oApp とは、作成者がいなくなった後も存続するアプリです。openapps.xyz で起動し（旧アドレスの oapps.fun と oapps.org からはリダイレクトされます）、トークン、ビルド資金、そしてアプリを統治するコミュニティを得ます。Bounded は、その運営を担うスチュワードです。

このスキルのすべては、次の設計目標に基づいています。

作成者がアプリをラグプルできてはなりません。 「しないと約束する」のではなく、 構造的にできないようにします。

そのため、oApps では次のようにします。

• すべてを Bounded の管理下に置く必要があります。 ホスティング、データ、認証、決済、 ウォレット、オンチェーンアクセス、AI はすべてランタイムが提供し、アプリ自身のクレジットプールに 課金され、実証済みのポリシーによって統治されます。
• シークレットは一切ありません。 API キー、ベンダーアカウント、誰かの引き出しにしまわれた認証情報は 使いません。作成者名義のキーは、ルールで取り除くレバーそのものなので、oApp の関数では secrets を拒否します。
• Bounded にできないことは、あなたにもできません。 誰にも停止できない小さなアプリのほうが、 停止スイッチのある大きなアプリより優れています。Bounded がまだできないことは、 一度だけプラットフォーム全体にリクエストし、個人キーで回避してはいけません。

参照ルーター

現在のステップに該当するページだけを読んでください。

タスクまたは用語	読むページ
Local -> Bounded -> Open -> Commence、sitePrivate、作成者アプリごとに 1 回のローンチ、oapp_creator_already_launched、/a/<slug>、Open で公開される内容、sourcePush	ライフサイクル
publish-oapp による拒否、必須の boundaries 行、boundaries.egress、service:cap と service:x402 の許可、gov-frozen、再現可能な dist（static / built）、フロントエンドのないアプリ、bounded propose	ローンチゲート
リクエストされた機能：ネイティブ対応またはライブ対応、x402 経由で呼び出し可能か、あるいはリクエストが必要か、対応状況、禁止された依存関係、X402_FETCH、bounded services request	機能の段階
bounded oapp preflight（機能の段階に基づき、Open が拒否する内容を確認）、bounded oapp rehearse、データがゼロの状態からのブートストラップ	リハーサル
Open の前と Commence の前に確認するすべての項目	チェックリスト

仕組み（ポリシー、関数、ウォレット、決済）については、bounded-backend、 bounded-frontend、bounded-onchain を参照してください。

画面 1 枚でわかるライフサイクル

1. Local。 通常のリポジトリです。デプロイはされていません。
2. Bounded（開発）。 bounded init、bounded verify、bounded deploy、 bounded site deploy dist --with-source を実行します。アプリには myapp-x7k2.bounded.page などの開発用アドレスが割り当てられます。非公開 （sitePrivate）のままにし、自分で公開に切り替えないでください。作成者アプリは、作成時の プロトコルのままにしてください。realtime_mainnet として再作成したり、--protocol を渡したり してはいけません。メインネット部分は Open が処理します。
3. Open（公開済み、Commence 待ち）。 Open が完了すると、Solana メインネット上に会場所有の ルートとワークロードが作成されます（これはプラットフォームが設定します。オンチェーンの所有者は Bounded が管理するキーであり、あなたのウォレットではありません）。ワークロードのサイトとソースは https://<workloadAppId>.bounded.page で公開され、会場のページは /a/<slug> になります （旧 /l/ リンクからはリダイレクトされます）。作成者アプリは接続されていないサンドボックスのままです。 開かれたルートやワークロードでは、絶対に bounded deploy を実行しないでください。Open には、 作成者ポリシーの egress で service:cap と service:x402 が許可されている必要があります。 Open が拒否する内容をすべて確認するため、まず bounded oapp preflight を実行してください。
4. Commence。 openapps.xyz でアプリの slug を確保し、掲載情報を書き込み、トークン販売を作成して、 Gauntlet を開始する明示的な操作です。作成者アプリは 1 回だけローンチできます。Commence の後は slug が恒久的に固定され、以降のローンチは oapp_creator_already_launched（409）で拒否されます。 Commence の前に slug を選んでください。2 つ目の oApp を作る場合は、別のアプリを開始してください。

onchain: true のコレクションは、まだ Open できません （oapp_opening_onchain_policy_unsupported）。埋め込みウォレット、決済、プラグイン呼び出しは問題ありません。 その旨を明確に伝え、回避策を講じずに停止してください。

ローンチの経済設計

封印された head が transfer-fee-v1 を選択する Open では、USDC による CCA を使用し、配分は Treasury 65％／初期流動性 30％／クリエイター 2.5％／OpenApps 2.5％です。 最低額は 5,000 ドルで、セットアップ費用の支払い後、将来の取引収益を見込まずに、運営の基準コストを 6 か月分維持する必要があります。 アプリトークンの固定 1％送金手数料は、すべてアプリトークンで Treasury に帰属します。 標準の DAMM v2 プールには、OnlyB を有効にし、動的手数料を無効にした、別途固定の 0.5％ USDC 手数料があります。 Meteora の 20％のプロトコル取り分を差し引いた後、指定されたローンチポジションの実際の純収入は、クリエイター 50％／OpenApps 50％に分配されます。 追加のアプリポジションの収益はアプリに帰属し、プロダクト収益もすべてアプリに帰属します。 既存のローンチは、封印時のモデルを維持します。 発生した送金手数料は、保留中のトークンクレームとして表示されます。利用可能な USDC でも、前払い済みの Bounded クレジットでもありません。 管理対象のブレインは、ホルダーの提案なしで、クレジット上限を指定して手数料の回収を要求できます。 Treasury ポリシーで出金権限と送金先を固定し、Bounded は回収のインフラ、トランザクション署名、クレジット課金を提供します。 ホルダーがガバナンスを行う準備金の交換では、USDC による運営の基準費用 6 か月分を目標とし、デフォルトでは 3 か月分を下回った時点で開始します。

回収と保留中残高については、トークン送金手数料をご覧ください。

ケイパビリティの段階

ユーザーが求めるすべてのケイパビリティについて、必ず次の順に判定し、回避策に飛びつかないでください。bounded services search "<need>" で該当する段階を確認できます。各項目は live、callable、または requestable のいずれかです。

1. まずネイティブ機能またはライブ機能：ctx.ai、ctx.email、ファイル、認証、コレクション、決済レール、埋め込みウォレット、DEX／トークンプラグイン、またはアプリの service:cap グラントのもとで関数から ctx.services.invoke("<slug>", ...) を呼び出すライブカタログアクション。
2. 次に x402 経由で呼び出し可能か確認：相手側が x402 で料金を設定している場合、Bounded がアプリに代わってスチュワードリレーウォレットから呼び出しごとに支払うため、承認は不要です（service:x402 のもとで ctx.services.invoke("X402_FETCH", ...) を使用）。
3. リクエストしてから、できないことを伝える：bounded services request "<what you need>" で Capability Hub に一度だけ申請します。利用可能になると Hub からメールで通知されます。現時点でできないこと、必要となる個人が保有する依存関係、そのルールがある理由、最も近い準拠した代替手段を説明してください。そのうえで、準拠した方法を構築します。ユーザーが保有するシークレットを「一時的に」追加することは絶対にしないでください。

詳細、利用準備状況、禁止されている依存関係、リレーの動作については、docs/capability-ladder.mdをご覧ください。

手放す前に

• 境界を早期に記述します：posture: "closed"、binding: "all"、egress の許可リストに 2 つのグラント service:cap と service:x402（および認証情報不要のホスト）を含め、openApps のみを "mode": "locked" で凍結します。クリエイターアプリで boundaries を凍結したり、amend を設定したりしないでください。プラットフォームがローンチ後のクローンに対してそれらを設定します。
• bounded oapp preflight が READY であること：これは Open ゲートのドライランであり、拒否する依存関係ごとに、該当する段階を示します。
• policy.json にユーザーが保有する認証情報に依存するルール、関数、または egress がないことを確認します。bounded verify がパスし、すべての外部 egress が宣言済みであることを確認します。
• ソースはデプロイに含めます（sourcePush: true または --with-source）。同期済みのツリーが実際の完全なプロジェクトであり、デプロイ済みの dist をそのツリーから再現できるようにします。
• Open によってサイト、ソース、境界が公開されること、また、フロントエンドのないアプリではホームページが公開リポジトリの表示になることをユーザーに伝えます。

全項目については、docs/checklist.mdをご覧ください。