The dextoro system, explained.

First steps, in order

A do-this-in-order checklist for a new owner. It pulls together actions that also appear in Operations and Known issues, so you have one path to follow. Plain action per line; turn on Technical for the exact settings and files.

1. Transfer the App Store app to your own Apple account.

   The app, its store listing and its id move to your Apple team. The app keeps the same name and id.

   Technical

   • Transfer in App Store Connect. Bundle com.dextoro.app and App Store id 6739891028 stay the same.
   • Apple Team id changes from 65F2J667K9 to yours. Your new Team id then has to go into the domain link-verification file (AASA) and the next build.
2. Take over (or replace) the iosdextoro@gmail.com Google account.

   This one email is the hub for three things, so secure it before anything else: the admin dashboard seed login, the BirdEye account, and the Google Cloud project that holds the Google Play credential.

   Technical

   • Seed super_admin in admin_users = iosdextoro@gmail.com.
   • Same email owns the BirdEye account and Google Cloud project dextoro-635a3 (the Play service account).
   • Either take ownership of the mailbox, or migrate each service to your own account one by one.
3. Issue your own key at every outside service, swap it in, then revoke the old keys.

   For each service in the Services section, create your own account/key, paste it into the backend or the build settings, confirm things still work, then revoke the previous key last.

   Technical

   • Services: Turnkey, Alchemy, Helius, BirdEye, Jupiter, OneSignal, Upstash, Sentry, MoonPay.
   • Backend keys go in Supabase secrets; baked-in ones go in EAS (see Appendix). Redeploy functions after Supabase changes; rebuild the app after EAS changes.
   • Revoke old keys only after the new ones are confirmed live.
4. Rotate the leaked Google Play key and purge it from git history.

   The Play upload credential is committed in the app repo's history, so anyone with the repo has it. Rotate it and scrub it out.

   Technical

   • service-account-file.json is tracked and appears in 2 historical commits (project dextoro-635a3).
   • Rotate the key in Google Cloud (required regardless), purge the file from history with git-filter-repo or BFG, and store the new key as an EAS secret, not in the repo.
5. Upgrade BirdEye to a paid plan and rotate its key.

   This restores the price charts, which are degraded today because the free quota is maxed out.

   Technical

   • Upgrade the BirdEye plan, then rotate BIRDEYE_API_KEY (it is baked into the binary in dead code), updating both the Supabase secret and the EAS value.
6. Set a paid Jupiter key.

   Trades work on the free public router today; a paid key raises the limits so trading stays smooth under load.

   Technical

   • Set JUPITER_SWAP_API_URL=api.jup.ag/swap/v1 + JUPITER_SWAP_API_KEY (EAS) for the app swap path, and JUPITER_API_KEY (Supabase) for the token list/prices.
7. Change the seed super-admin password and keep super_admin to yourself.

   Reset the dashboard login password and make sure you are the only super admin. Invite staff at lower roles.

   Technical

   • Reset the password for the seed login (iosdextoro@gmail.com) or create your own super admin and demote/remove the seed.
   • Invite staff as manager or viewer from User Management (super_admin only).
8. Fund the fee payer wallet with SOL.

   This is the wallet that pays network fees for users. If it runs empty, trades start failing, so keep some SOL in it.

   Technical

   • Send SOL to the fee payer wallet (pubkey is in EXPO_FEE_PAYER_PUBKEY / the dashboard; private key is the Supabase secret FEE_PAYER_PRIVATE_KEY).
9. Stand up your own domain and ship a new build to repoint to it.

   Because dextoro.com is not included, set up your own domain with the link-verification files and the legal and landing pages, then build and submit a new app version that points at it.

   Technical

   • Serve /.well-known/apple-app-site-association (with your Apple Team id), /.well-known/assetlinks.json, the /applinks landing page, the /moonpay return, and real /terms and /privacy pages.
   • Repoint mainly 3 files: constants/urlConstant.ts, app.json, hooks/hooksWithContext/useReviewFlow.tsx; set up your own Branch app and MoonPay return URL. Full steps: DOMAIN_MIGRATION_RUNBOOK.md.
10. Confirm on-chain that trading fees land in your treasury wallet.

    After your build is live, make a small test trade and check that the fee actually arrives at your treasury wallet. Remember the dashboard treasury field is display-only, so do not trust it alone.

    Technical

    • The destination is the baked-in TREASURY_WALLET EAS value (project scope wins; watch the account-scope duplicate, see Operations). Verify the fee transfer on a block explorer, not just in the dashboard.

Each item is expanded in Operations and Known issues. The treasury "ghost control" trap and the duplicate TREASURY_WALLET landmine are explained in full under Operations.

How the pieces fit together

Two apps talk to one backend. The backend talks out to a handful of specialist services. Click any box for what it is and how to manage it.

What users touch, and what you run it from

Supabase: the brain of the system

One Supabase project (ref ehauakpcvvuoocxjytwb) holds the database, runs the server functions that build and submit trades, handles login, stores avatars, and pushes live updates to the app. You manage it from the Supabase dashboard.

Server functions (the things the apps call)

These are small server programs ("edge functions"). Plain purpose on the left. Turn on Technical for which are login-protected and what they call.

The main database tables

Live updates (Realtime)

When something changes a user's balance (a deposit, a trade), the backend pushes it to that user's app instantly, so balances and the activity list update without a manual refresh. Implemented with Supabase Realtime listening to INSERTs on the activities table filtered by wallet (hooks/useRealtimeBalance.ts), kept warm by a 60s pg_cron job. Live price ticking on the home and token screens is a separate, older mechanism, see Known issues.

The specialist services dextoro relies on

Each of these is a separate company with its own account and dashboard. On takeover you generally create your own account, issue your own keys, and point the system at them. Each card says what it does, where its dashboard is, and how you manage it.

How the system actually works, step by step

Four common journeys, click through each step. The plain story is the default. Turn on Technical to see the exact function and file behind every step.

Running dextoro day to day

Where the money goes: the treasury wallet

Every buy or sell charges a small platform fee. That fee is sent to your treasury wallet, a Solana wallet you control. Fees pile up there automatically as people trade. The admin Infrastructure page shows the treasury balance and total fees collected.

The fee payer (gasless trading)

Solana charges a tiny network fee for every action, and setting up a new token in a wallet costs a small refundable deposit. The fee payer is a wallet that quietly covers those costs and co-signs every trade, so your users can trade without first buying SOL for "gas". It needs to stay funded with SOL.

• Keep it funded: send SOL to the fee payer wallet when it runs low. If it empties, trades start failing.
• Where its key lives: the private key is a Supabase secret (FEE_PAYER_PRIVATE_KEY), never in the app.
• To rotate: generate a new keypair, fund it, set FEE_PAYER_PRIVATE_KEY (Supabase) and the matching pubkey in admin_settings.fee_payer_pubkey and FEE_PAYER_PUBKEY (EAS), then ship a build. The transaction function refuses to co-sign if the pubkey does not match admin_settings.

Who can do what (admin roles)

Enforced both in the UI and in the database via the admin_role() function and row-level security on the admin_* tables. Staff are invited from the User Management page (super_admin only), which calls the admin-users function. The seed super admin is iosdextoro@gmail.com.

Shipping an update

Monitoring: what healthy looks like

• Admin Infrastructure page: the dashboard has a health page that should show green across the chain connection, the deposit watcher, the cache, the database, the scheduled jobs, live updates, and crash reporting. It refreshes about every 20 seconds and also shows user counts, trade volume, and the treasury balance. Backed by the admin-health function, which holds the keys server-side and only returns status to the browser.
• Sentry: shows crashes and errors from the live apps. Healthy is a high crash-free rate and no sudden spike in new issues. Org ios-dextoro, project dextoro-app. Email alerts are not fully configured yet, that is a quick setup task.
• Fee payer + treasury: the fee payer wallet should always have some SOL; the treasury balance should climb over time as people trade.

Where the secrets live

No secret values are in this document. Here is where each kind lives and how to rotate it. Full list in the Appendix.

• Backend secrets (API keys for the outside services, the fee payer key, login signing): in the Supabase Dashboard under the project's secrets. Rotate by issuing a new key at the service, pasting it in Supabase, then redeploying the functions.
• App build settings (what gets baked into the phone app, like the treasury wallet, the public RPC key, the Supabase URL): in EAS as environment variables. Changing them requires a new app build.
• Admin site settings (just the Supabase URL and public key): in Cloudflare Pages build settings.

Cross-reference: a fuller owner guide for the dashboard already exists in the admin repo at dextoro-app-admin/docs/OWNER_GUIDE.md.

As-is items, in the open

This is an as-is sale, so here is the honest list. Your engineer will find these anyway. None of them stop the core flows (login, trade, deposit) from working today.

Plain definitions

Reference

Public identifiers (safe to share)

Secrets inventory (names only, never values)

Rotation rule of thumb: on takeover, issue your own key at each service, replace the value in Supabase (or EAS for the baked-in ones), redeploy or rebuild, then revoke the old key.