@www.hyperlinks.space/program-kit 1.2.91881 → 81.81.81

package/docs/storage-availability-console-script.js

@@ -0,0 +1,152 @@
+/**
+ * Telegram Mini App storage availability probe (paste into DevTools console).
+ *
+ * What this script does:
+ * 1) Checks whether Telegram WebApp bridge exists.
+ * 2) Probes SecureStorage by real write+read+remove roundtrip.
+ * 3) Probes DeviceStorage by real write+read+remove roundtrip.
+ * 4) Probes CloudStorage by real write+read+remove roundtrip.
+ * 5) Prints a single QA verdict:
+ *    - "secure" => SecureStorage works.
+ *    - "device" => SecureStorage fails, but DeviceStorage works.
+ *    - "none"   => neither SecureStorage nor DeviceStorage works.
+ *
+ * Notes:
+ * - "API object exists" does NOT mean storage is supported. Telegram Desktop may expose methods
+ *   but return UNSUPPORTED at runtime. This script verifies runtime behavior.
+ * - Probe keys are deleted at the end.
+ */
+(async () => {
+  const wa = window.Telegram?.WebApp;
+  if (!wa) {
+    const result = {
+      verdict: "none",
+      webApp: null,
+      error: "Telegram.WebApp not found (not running in TMA context).",
+    };
+    console.log("[storage-probe]", result);
+    return result;
+  }
+
+  const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms));
+
+  const probeSecureOrDevice = async (storage, eventPrefix, includeCanRestore) => {
+    const key = `probe_${eventPrefix}_${Date.now()}`;
+    const value = "ok";
+    let eventFailed = null;
+
+    const failedEventName = `${eventPrefix}_failed`;
+    const savedEventName = `${eventPrefix}_key_saved`;
+
+    const onFailed = (payload) => { eventFailed = payload; };
+    const onSaved = () => {};
+
+    try {
+      wa.onEvent?.(failedEventName, onFailed);
+      wa.onEvent?.(savedEventName, onSaved);
+    } catch {}
+
+    const cleanup = () => {
+      try { wa.offEvent?.(failedEventName, onFailed); } catch {}
+      try { wa.offEvent?.(savedEventName, onSaved); } catch {}
+    };
+
+    if (!storage || typeof storage.setItem !== "function" || typeof storage.getItem !== "function") {
+      cleanup();
+      return {
+        present: false,
+        supported: false,
+        set: null,
+        get: null,
+        remove: null,
+        eventFailed: null,
+      };
+    }
+
+    return new Promise((resolve) => {
+      storage.setItem(key, value, (setErr, stored) => {
+        storage.getItem(key, async (getErr, gotValue, canRestore) => {
+          await wait(50);
+
+          const base = {
+            present: true,
+            supported: setErr == null && getErr == null && gotValue === value,
+            set: { err: setErr ?? null, stored: stored ?? null },
+            get: includeCanRestore
+              ? { err: getErr ?? null, value: gotValue ?? null, canRestore: canRestore ?? null }
+              : { err: getErr ?? null, value: gotValue ?? null },
+            remove: null,
+            eventFailed,
+          };
+
+          if (typeof storage.removeItem === "function") {
+            storage.removeItem(key, (rmErr, removed) => {
+              base.remove = { err: rmErr ?? null, removed: removed ?? null };
+              cleanup();
+              resolve(base);
+            });
+          } else {
+            cleanup();
+            resolve(base);
+          }
+        });
+      });
+    });
+  };
+
+  const probeCloudStorage = async () => {
+    const cs = wa.CloudStorage;
+    const key = `probe_cloud_${Date.now()}`;
+    const value = "ok";
+
+    if (!cs || typeof cs.setItem !== "function" || typeof cs.getItem !== "function") {
+      return {
+        present: false,
+        supported: false,
+        set: null,
+        get: null,
+        remove: null,
+      };
+    }
+
+    return new Promise((resolve) => {
+      cs.setItem(key, value, (setErr, stored) => {
+        cs.getItem(key, (getErr, gotValue) => {
+          const out = {
+            present: true,
+            supported: setErr == null && getErr == null && gotValue === value,
+            set: { err: setErr ?? null, stored: stored ?? null },
+            get: { err: getErr ?? null, value: gotValue ?? null },
+            remove: null,
+          };
+
+          if (typeof cs.removeItem === "function") {
+            cs.removeItem(key, (rmErr, removed) => {
+              out.remove = { err: rmErr ?? null, removed: removed ?? null };
+              resolve(out);
+            });
+          } else {
+            resolve(out);
+          }
+        });
+      });
+    });
+  };
+
+  const secureStorage = await probeSecureOrDevice(wa.SecureStorage, "secure_storage", true);
+  const deviceStorage = await probeSecureOrDevice(wa.DeviceStorage, "device_storage", false);
+  const cloudStorage = await probeCloudStorage();
+
+  const verdict = secureStorage.supported ? "secure" : deviceStorage.supported ? "device" : "none";
+
+  const result = {
+    verdict,
+    webApp: { platform: wa.platform ?? null, version: wa.version ?? null },
+    secureStorage,
+    deviceStorage,
+    cloudStorage,
+  };
+
+  console.log(`[storage-probe] verdict=${verdict}`, result);
+  return result;
+})();

package/docs/storage-lifetime.md

@@ -0,0 +1,33 @@
+# Storage Lifetime for Wallet Keys
+
+This document summarizes practical storage lifetime expectations for wallet-related secrets.
+
+Important: "lifetime" is never absolute. Every layer can be lost due to account loss, uninstall, reset, policy changes, corruption, or compromise.
+
+## Quick Matrix
+
+| Storage type | Typical lifetime | Main limiting factor | Cross-device | Notes for wallet keys |
+|---|---|---|---|---|
+| Telegram CloudStorage | Potentially long-lived | Telegram account/app availability and platform behavior | Yes (inside Telegram ecosystem) | Use for ciphertext/public metadata, not raw mnemonic |
+| Telegram SecureStorage | Device-scoped durable | Device/app reinstall/reset and client support | No | Best TMA local tier when supported |
+| Telegram DeviceStorage | Device-scoped durable | Device/app reinstall/reset | No | Weaker than SecureStorage; fallback tier |
+| Session Storage (`sessionStorage`) | Current tab/session only | Tab/window/browser session end | No | Not suitable for persistent keys |
+| Browser Local Storage (`localStorage`) | Potentially long-lived on same browser profile | User clearing data, browser profile loss | No | Use only encrypted blobs if needed |
+| IndexedDB (web) | Potentially long-lived on same browser profile | User/browser data clearing, profile loss | No | Better than localStorage for larger encrypted blobs |
+| Expo Secure Store (iOS/Android) | Durable on device | Uninstall/reset/device change | No | Good native local secret store; still not "forever" |
+| Electron OS secure storage (Windows/macOS) | Durable on device profile | OS profile/device lifetime, reinstall/migration | No | Suitable desktop local secret store |
+| In-memory runtime only | Process/session only | App restart/crash/background termination | No | Best for temporary decrypted material |
+
+## Lifetime Statements (practical wording)
+
+- **Telegram CloudStorage:** theoretically long-lived, practically bounded by **Telegram account lifetime and platform behavior**.
+- **Device-local storage (SecureStorage/DeviceStorage/Secure Store/OS keychain):** bounded by **device/app/profile lifetime**.
+- **Session storage:** bounded by **session lifetime** (tab/window/app session).
+
+## Recommended usage pattern
+
+1. Keep **mnemonic as offline backup** (user-controlled, not in backend/cloud plaintext).
+2. Store day-to-day local unlock material in the strongest available **device-local secure store**.
+3. Store only **ciphertext** in cloud/sync layers.
+4. Treat all lifetimes as "best effort durability", not guaranteed permanence.
+

package/docs/telegram-raw-keys-cloud-storage-risks.md

@@ -0,0 +1,31 @@
+# Telegram CloudStorage Raw Keys Risks
+
+This note clarifies a common misunderstanding:
+
+- It is true that Telegram Mini App `CloudStorage` is scoped per bot/per user.
+- It is true that each Telegram user session is strongly protected by Telegram account security controls (session management, device authorization, transport security, etc.).
+- It is also true that endpoint compromise exists in both models (Bitcoin Core local storage and TMA/web clients).
+
+The key security difference is not "cross-user direct reads". The key difference is how compromise can scale through the app runtime.
+
+In other words: Telegram session protection is a strong baseline and should be acknowledged. The residual risk discussed here is about compromised Mini App code/runtime on an already authenticated user session, not about bypassing Telegram account/session controls.
+
+## Corrected comparison
+
+Exactly: a PC can be hacked in both cases.
+
+- **Bitcoin Core local storage:** an attacker usually needs to compromise that specific machine (or steal wallet backups) to get that user's keys.
+- **Raw mnemonic in Telegram CloudStorage:** per-user storage still applies, but if the Mini App runtime/supply chain is compromised, malicious code can read each currently logged-in user's own CloudStorage during their session and exfiltrate it. This can impact many users over time without a "read all users" API.
+
+So both models are vulnerable to endpoint compromise, but web/TMA delivery can add centralized distribution/supply-chain risk that increases aggregate exposure.
+
+## Practical differences vs local desktop wallet model
+
+- **Runtime surface:**
+  - Local desktop wallet (Bitcoin Core style): narrower app distribution/runtime model.
+  - Web/TMA app: JavaScript/runtime/supply-chain surface is broader.
+
+- **Secret impact on read:**
+  - **Raw mnemonic in cloud:** one successful read is immediate takeover.
+  - **Encrypted cloud blob:** attacker still needs decrypt capability (password/device key), which adds a barrier.
+

package/docs/wallets_hosting_architecture.md

@@ -1,7 +1,7 @@
 # HyperlinksSpace — Wallet Architecture Doc
 
 > High-level system design, UI flow principles, and implementation thoughts.  
-> Target: non-custodial TON wallet built into the HyperlinksSpace app (Flutter/TMA/Web).
+> Target: TON wallet architecture options for HyperlinksSpace app (Flutter/TMA/Web), including non-custodial and custodial modes.
 
 ---
 
@@ -254,4 +254,150 @@ Swap between implementations via a flag (`kUseMockWalletState` for dev, env-driv
 
 ---
 
+## 13. Custodial Model Extension
+
+This section adds a custodial architecture option alongside the existing non-custodial design.
+
+### 13.1 What "custodial" means in this doc
+
+- Wallet secrets are stored centrally as encrypted data in backend storage.
+- Backend trust boundary can participate in decrypt/sign authorization.
+- User identity (Google/Telegram/GitHub/email OTP) becomes a stronger operational gate.
+
+This is a product/trust choice, not just an implementation detail.
+
+---
+
+### 13.2 Custodial key architecture (envelope encryption)
+
+Store per-wallet:
+
+- `ciphertext` (wallet secret encrypted by a DEK)
+- `wrapped_dek` (DEK encrypted by KEK)
+- metadata (`key_version`, `algo`, `created_at`, `status`)
+
+Keep KEK in KMS/HSM, not in DB/app code.
+
+Result:
+- DB theft alone is insufficient.
+- Attacker also needs KMS/HSM access path and permissions.
+
+---
+
+### 13.3 Identity and auth in custodial mode
+
+Identity providers:
+- Google OAuth
+- GitHub OAuth
+- Telegram login bridge
+- Email + OTP (protection code)
+
+Account linking maps all providers to one internal `user_id`.
+
+Auth session is used to authorize protected operations:
+- key unwrap requests
+- signing requests
+- provider linking/unlinking
+
+---
+
+### 13.4 Custodial state machine
+
+```
+[ No Wallet Record ]
+     │
+     ├── Create wallet ─► [ Custodial Encrypted ]
+     │                         │
+     │                         ├── Unlock request (auth + policy) ─► [ Session Unlocked ]
+     │                         │                                         │
+     │                         │                                         └── Sign tx ─► [ Ready ]
+     │                         │
+     └── Restore/import ─────► [ Custodial Encrypted ]
+```
+
+`Session Unlocked` should be short-lived and policy-limited (risk checks, cooldowns, limits).
+
+---
+
+### 13.5 Signing variants
+
+## Variant A: Backend signing (fully custodial)
+- Backend unwraps DEK and signs transactions server-side.
+- Client receives signed transaction/hash.
+- Simplest UX, highest custodial responsibility.
+
+## Variant B: Backend-assisted client resolve (hybrid custodial)
+- Backend authorizes access and returns short-lived decrypt context.
+- Client resolves and signs locally.
+- Better client-side control, still centralized key lifecycle.
+
+Choose one variant explicitly in product docs and legal language.
+
+---
+
+### 13.6 API extension for custodial mode
+
+```
+POST /wallet/custodial/create
+  Body: { user_id, wallet_label, encrypted_payload, wrapped_dek, key_version }
+  Response: { ok: true, wallet_id }
+
+POST /wallet/custodial/unlock
+  Body: { wallet_id, auth_context }
+  Response: { unlock_token, expires_at }   // or server-side unlock only
+
+POST /wallet/custodial/sign
+  Body: { wallet_id, unlock_token, tx_payload }
+  Response: { signed_tx | tx_hash }
+
+POST /wallet/custodial/rotate-kek
+  Body: { wallet_id? | batch_selector, new_key_version }
+  Response: { rewrapped_count }
+```
+
+All endpoints must be audited and rate-limited.
+
+---
+
+### 13.7 Security controls required in custodial mode
+
+- KMS/HSM-backed KEK, non-exportable where possible
+- Strict IAM separation (runtime vs admin)
+- Row-level access control by `user_id`
+- Risk checks before unlock/sign (IP/device anomaly, velocity limits)
+- Immutable security event log
+- Emergency freeze and key-rotation runbook
+- Signed release pipeline + dependency controls
+
+---
+
+### 13.8 UX implications vs non-custodial
+
+Benefits:
+- Easier cross-device recovery
+- Less mnemonic friction for mainstream users
+
+Tradeoffs:
+- Backend/service compromise has larger blast radius
+- Stronger legal/compliance burden
+- Must clearly disclose custodial trust model
+
+Recommended product stance:
+- Keep non-custodial as default for advanced users.
+- Offer custodial mode as explicit opt-in with clear warnings and recovery terms.
+
+---
+
+### 13.9 Updated roadmap including custodial track
+
+| Phase | Non-custodial track | Custodial track |
+|---|---|---|
+| **Phase 1** | Create/restore local wallet, deploy flow | Auth foundation (Google/GitHub/Telegram/email OTP), user linking |
+| **Phase 2** | Device/local storage hardening | Envelope storage (`ciphertext` + `wrapped_dek`) + KMS/HSM integration |
+| **Phase 3** | TMA/Desktop fallback tiers | Unlock/sign endpoints + policy/rate limits |
+| **Phase 4** | Send/receive/history | Custodial signing UX + anomaly protections |
+| **Phase 5** | Backup/export UX hardening | Key rotation, incident runbooks, compliance hardening |
+
+---
+
 *Last updated: April 2026. Maintained in repo at `docs/wallets_hosting_architecture.md`.*

package/fullREADME.md

@@ -4,23 +4,30 @@
 
 <u>**In progress, contribute!**</u>
 
-This program is built upon [React Native](https://reactnative.dev/) by Meta and [Expo](https://expo.dev) multiplatform technologies, Windows build and executable creation achieved with [Electron Builder](https://www.electron.build/) and [Electron Forge](https://www.electronforge.io/), working in Telegram with help of [Telegram Mini Apps React SDK](http://telegram-mini-apps.com/) and [Bot API](https://core.telegram.org/bots). AI is backed by [OpenAI API](https://openai.com/ru-RU/api/), blockchain data is processed from [Swap.Coffee API](https://docs.swap.coffee/eng/user-guides/welcome).
-
-## Program Kit
-
-To give value for other developers we decided to launch an npm package that provides a ready starter for creating a multiplatform program in one command.
-
-```bash
-npx @www.hyperlinks.space/program-kit ./your-project
-```
-
-Link to the package: https://www.npmjs.com/package/@www.hyperlinks.space/program-kit
+This program is built upon [React Native](https://reactnative.dev/) by Meta and [Expo](https://expo.dev) multiplatform technologies, Windows build and executable creation achieved with [Electron Builder](https://www.electron.build/) and [Electron Forge](https://www.electronforge.io/), working in Telegram with help of [Telegram Mini Apps React SDK](http://telegram-mini-apps.com/), [Bot API](https://core.telegram.org/bots) and [Grammy](https://grammy.dev/). AI is backed by [OpenAI API](https://openai.com/ru-RU/api/), blockchain info is processed from [Swap.Coffee API](https://docs.swap.coffee/eng/user-guides/welcome). DB for the best user's experience we host on [Neon](https://neon.tech/).
 
 ## Program design
 
 Access [Figma](https://www.figma.com/design/53lDKAD6pRv3e0uef1DP18/TECHSYMBAL-Inc.?node-id=754-71&t=v3tmAlywNgXkTWMd-1) in real time for contributing. Contact [Seva](t.me/sevaaignatyev) in Telegram to discuss and implement.
 
-Copying fully or partially, usage as an inspiration for other developments are unpleasant, participation in our projects is appreciated. All core materials are available publicly for instant access worldwide and our project availability for newcomers.
+All core materials are available publicly for сгккуте hyperlinks.space team members' instant and easy access worldwide and our project's availability for newcomers' research only.
+
+## Structure
+
+- [`app`](./app) - Expo/React Telegram Mini App client (web/mobile screens, navigation, UI logic).
+- [`ui`](./ui) - shared UI layer (components, theme tokens, and font configuration used by the app).
+- [`bot`](./bot) - TypeScript Telegram bot service and runtime entrypoints.
+- [`database`](./database) - database startup/migration/service scripts.
+- [`ai`](./ai) - AI assistant service logic and model integration points.
+- [`api`](./api) - backend API handlers and server-side endpoints.
+- [`blockchain`](./blockchain) - TON/blockchain interaction logic and related helpers.
+- [`telegram`](./telegram) - Telegram-specific integration utilities and adapters.
+- [`windows`](./windows) - Electron desktop shell, NSIS installer config, and auto-update flow.
+- [`scripts`](./scripts) - developer/ops scripts (local run, migration, release helpers).
+- [`docs`](./docs) - project and operational documentation.
+- [`backlogs`](./backlogs) - short-term planning notes and prioritized work items.
+- [`assets`](./assets) - static assets used by app, installer, and branding.
+- [`dist`](./dist) - generated web build output (export artifacts).
 
 ## How to fork and contribute?
 
@@ -74,6 +81,35 @@ git switch -c new-branch-for-next-update # Create and switch to a new feature br
 
 ## Local deploy
 
+`npm` package note: `.env.example` is included in the published package so you can use it as a reference for establishing your testing environment with `.env` file.
+
+Before local deploy / cloud deploy, prepare these env-backed services:
+
+1. **Neon PostgreSQL (`DATABASE_URL`)**
+   - Create an account/project at [Neon](https://neon.tech/).
+   - Create a database and copy the connection string.
+   - Put it into `.env` as `DATABASE_URL=...`.
+2. **OpenAI API (`OPENAI_API_KEY`)**
+   - Create an account at [OpenAI Platform](https://platform.openai.com/).
+   - Create an API key in the API Keys page.
+   - Put it into `.env` as `OPENAI_API_KEY=...`.
+3. **Telegram bot token (`BOT_TOKEN`)**
+   - In Telegram, open [@BotFather](https://t.me/BotFather), create a test bot with `/newbot`.
+   - Copy the bot token and put it into `.env` as `BOT_TOKEN=...`.
+4. **Vercel project envs (for comfortable deploy/testing)**
+   - Create a [Vercel](https://vercel.com/) account and import this repository as a project.
+   - In Project Settings -> Environment Variables, set at least:
+     - `DATABASE_URL`
+     - `OPENAI_API_KEY`
+     - `BOT_TOKEN` (or `TELEGRAM_BOT_TOKEN`)
+   - Pull envs locally when needed with `vercel env pull .env.local`.
+
+Copy env template locally:
+
+```bash
+cp .env.example .env
+```
+
 To start the full local stack, run:
 
 ```bash
@@ -82,6 +118,13 @@ npm run start
 
 This runs Expo dev server, the Telegram bot (polling mode), and local Vercel API (`vercel dev`).
 
+After `npm run start`, you can test the app on real phones with Expo Go:
+
+- Install **Expo Go** from Google Play (Android) or App Store (iOS).
+- Make sure your phone and development machine are on the same network.
+- Open Expo Go and scan the QR code shown in the terminal/Expo UI.
+- The app will launch on the device and hot-reload on code changes.
+
 Isolated/local run options:
 
 - Expo only (no bot, no Vercel): `npm run start:expo`
@@ -113,11 +156,11 @@ The `.env` file is gitignored; do not commit it.
 
 Current Actions workflows include:
 
-- `Vercel Deploy Test` (`.github/workflows/vercel-deploy-test-envs.yml`) - manual web deploy to Vercel.
-- `NPM Package Release` (`.github/workflows/npm-package-release.yml`) - npm/GitHub Packages release workflow.
-- `Electron EXE Release` and `Electron Forge EXE Release` - manual Windows release pipelines.
-- `EXPO Publish` (`.github/workflows/expo-publish.yml`) - manual OTA publish with EAS CLI.
-- `Lint errors check` (`.github/workflows/lint-errors-check.yml`) - manual lint check.
+- [`Vercel Deploy Test`](./.github/workflows/vercel-deploy-test-envs.yml) - manual web deploy to Vercel.
+- [`NPM Package Release`](./.github/workflows/npm-package-release.yml) - npm/GitHub Packages release workflow.
+- [`Electron EXE Release`](./.github/workflows/electron-exe-release.yml) and [`Electron Forge EXE Release`](./.github/workflows/electron-forge-exe-release.yml) - manual Windows release pipelines.
+- [`EXPO Publish`](./.github/workflows/expo-publish.yml) - manual OTA publish with EAS CLI.
+- [`Lint errors check`](./.github/workflows/lint-errors-check.yml) - manual lint check.
 
 ## Expo Workflows
 
@@ -134,14 +177,6 @@ Run `npm run draft` to [publish a preview update](https://docs.expo.dev/eas/work
 
 Run `npm run development-builds` to [create a development build](https://docs.expo.dev/eas/workflows/examples/create-development-builds/). Note - you'll need to follow the [Prerequisites](https://docs.expo.dev/eas/workflows/examples/create-development-builds/#prerequisites) to ensure you have the correct emulator setup on your machine.
 
-### Production Deployments
-
-Run `npm run deploy` to [deploy to production](https://docs.expo.dev/eas/workflows/examples/deploy-to-production/). Note - you'll need to follow the [Prerequisites](https://docs.expo.dev/eas/workflows/examples/deploy-to-production/#prerequisites) to ensure you're set up to submit to the Apple and Google stores.
-
-## Hosting
-
-Expo offers hosting for websites and API functions via EAS Hosting. See the [Getting Started](https://docs.expo.dev/eas/hosting/get-started/) guide to learn more.
-
 ### Deploy web build to Vercel
 
 From the repository root, deploy the static web build to Vercel production:
@@ -152,7 +187,7 @@ vercel --prod
 
 Deploying from repository root makes this folder the project root, so `api/bot` is deployed and no Root Directory setting is needed. The project is configured so Vercel runs `npx expo export -p web` and serves the `dist/` output. Link the project first with `vercel` if needed.
 
-## Telegram bot (Grammy)
+## Telegram bot
 
 The bot is extended beyond a basic "Hello" and "Start program" responder and now supports AI streaming and threads.
 
@@ -174,6 +209,16 @@ The bot is extended beyond a basic "Hello" and "Start program" responder and now
 - Run full local stack (Expo + bot + Vercel): `npm run start`
 - Keep production and local bot tokens separate when possible to avoid webhook/polling conflicts.
 
+## Program Kit
+
+To make it easier for developers to create multiplatform programs with us, we decided to launch an npm package that provides a ready starter for creating such a program basis in one command.
+
+```bash
+npx @www.hyperlinks.space/program-kit ./new-program
+```
+
+Link to the package: https://www.npmjs.com/package/@www.hyperlinks.space/program-kit
+
 ## Where to discuss the project?
 
 This repository has [GitHub Discussions](https://github.com/HyperlinksSpace/HyperlinksSpaceProgram/discussions) opened, as well you can join our [Telegram Chat](https://t.me/HyperlinksSpaceChat) and [Channel](https://t.me/HyperlinksSpace).

package/index.js

@@ -0,0 +1,3 @@
+// Earliest bundle entry: polyfill Node `Buffer` before expo-router loads route modules (@ton/* uses it at load time).
+import "./polyfills/buffer";
+import "expo-router/entry";

package/npmReadMe.md

@@ -19,13 +19,13 @@ and deployed across popular platforms.
 ### npmjs (public)
 
 ```bash
-npx @www.hyperlinks.space/program-kit ./my-new-program
+npx @www.hyperlinks.space/program-kit ./new-program
 ```
 
 ### GitHub Packages
 
 ```bash
-npx @hyperlinksspace/program-kit ./my-new-program
+npx @hyperlinksspace/program-kit ./new-program
 ```
 
 If you install from GitHub Packages, configure `.npmrc` with the `@hyperlinksspace`
@@ -34,7 +34,7 @@ registry and token.
 ## After Scaffold
 
 ```bash
-cd my-new-program
+cd new-program
 npm install
 npm run start
 ```

package/package.json

@@ -9,6 +9,7 @@
     "program-kit": "scripts/program-kit-init.cjs"
   },
   "files": [
+    ".env.example",
     "README.md",
     "fullREADME.md",
     "npmReadMe.md",
@@ -39,8 +40,8 @@
     "type": "git",
     "url": "https://github.com/HyperlinksSpace/HyperlinksSpaceBot.git"
   },
-  "main": "expo-router/entry",
-  "version": "1.2.91881",
+  "main": "index.js",
+  "version": "81.81.81",
   "type": "module",
   "engines": {
     "node": ">=18 <=22"
@@ -161,6 +162,10 @@
     "@react-navigation/native": "^7.1.6",
     "@swap-coffee/sdk": "^1.5.4",
     "@tma.js/sdk-react": "^3.0.16",
+    "@ton/core": "^0.63.1",
+    "@ton/crypto": "^3.3.0",
+    "@ton/ton": "^16.2.3",
+    "buffer": "^6.0.3",
     "electron-updater": "^6.8.3",
     "expo": "~54.0.0",
     "expo-blur": "~15.0.8",

package/scripts/test-api-base.ts

@@ -1,8 +1,8 @@
 /**
- * Quick check that api/base.ts works. Run: npx tsx scripts/test-api-base.ts
+ * Quick check that api/_base.ts works. Run: npx tsx scripts/test-api-base.ts
  * In Node (no window), getApiBaseUrl() uses Vercel env or falls back to http://localhost:3000.
  */
-import { getApiBaseUrl, buildApiUrl } from "../api/base.js";
+import { getApiBaseUrl, buildApiUrl } from "../api/_base.js";
 
 const base = getApiBaseUrl();
 const full = buildApiUrl("/api/telegram");

package/telegram/post.ts

@@ -7,6 +7,7 @@ import {
   normalizeUsername,
   upsertUserFromTma,
 } from '../database/users.js';
+import { getDefaultWalletByUsername } from '../database/wallets.js';
 
 const LOG_TAG = '[api/telegram]';
 
@@ -302,10 +303,53 @@ export async function handlePost(
   const dbStart = Date.now();
   try {
     await upsertUserFromTma({ telegramUsername, locale });
+    const wallet = await getDefaultWalletByUsername(telegramUsername);
     log('db_upsert_done', {
       dbMs: Date.now() - dbStart,
       elapsedMs: Date.now() - startMs,
+      hasWallet: !!wallet,
     });
+
+    if (wallet) {
+      log('success', {
+        telegramUsername,
+        hasWallet: true,
+        totalMs: Date.now() - startMs,
+      });
+      return new Response(
+        JSON.stringify({
+          ok: true,
+          telegram_username: telegramUsername,
+          has_wallet: true,
+          wallet: {
+            id: wallet.id,
+            wallet_address: wallet.wallet_address,
+            wallet_blockchain: wallet.wallet_blockchain,
+            wallet_net: wallet.wallet_net,
+            type: wallet.type,
+            label: wallet.label,
+            is_default: wallet.is_default,
+            source: wallet.source,
+          },
+        }),
+        { status: 200, headers: { 'content-type': 'application/json' } },
+      );
+    }
+
+    log('success', {
+      telegramUsername,
+      hasWallet: false,
+      totalMs: Date.now() - startMs,
+    });
+    return new Response(
+      JSON.stringify({
+        ok: true,
+        telegram_username: telegramUsername,
+        has_wallet: false,
+        wallet_required: true,
+      }),
+      { status: 200, headers: { 'content-type': 'application/json' } },
+    );
   } catch (e) {
     logErr('db_upsert_failed', e);
     return new Response(
@@ -317,12 +361,4 @@ export async function handlePost(
     );
   }
 
-  log('success', {
-    telegramUsername,
-    totalMs: Date.now() - startMs,
-  });
-  return new Response(
-    JSON.stringify({ ok: true, telegram_username: telegramUsername }),
-    { status: 200, headers: { 'content-type': 'application/json' } },
-  );
 }