The KRD bot's "Create Wallet" button generated a 12-word seed inside the
edge function and sent it to the user as a chat message. Every new
wallet's seed therefore passed through this server, and stayed in
Telegram's cloud history on every device the account is signed in on:
whoever gets into the server, a log, or the Telegram account gets the
wallet.
The button now opens the mini app at ?page=wallet, which lands on the
wallet section; that section already creates the seed on the device
(src/lib/wallet-service.ts) and never sends it anywhere. The
create_wallet callback stays for buttons on old welcome messages, and
answers with the same mini app link instead of a seed.
With nothing left to derive, the bot no longer imports the keyring,
util-crypto or bip39.
Every Telegram call logged its full request body and the echoed reply. Those
bodies hold what users write, the assistant's answers and, from the KRD bot's
create-wallet button, the generated seed phrase, so the seed reached the
container log in clear. Calls now log the method and chat id, replies only
whether they failed and why, and incoming updates only their id and kind.
The bot imported @pezkuwi/api to build a Keyring. That package brings in every
type definition and rxjs; each worker spent ~40 s and ~300 MB loading it, and a
worker that expired and was replaced kept adding to the container's memory
until the 1 GB limit killed it after about eight hours. @pezkuwi/keyring is the
same Keyring without the API.
* ops: run the Telegram bots and the assistant on vps3
telegram-bot and ask ran on the free cloud project, which paused itself
after a quiet week; every bot went silent and the deploy job failed against
the paused project. They now run in their own edge-runtime container on vps3
(bots/), from /opt/pezkuwi-bots.
Separate from the shared functions runtime because that one verifies a JWT
on every request, which Telegram cannot send, and holds the platform's wallet
keys, which a public bot feeding user text to a language model should not
sit next to. The new runtime holds only the keys the two functions read.
- telegram-bot refuses updates without Telegram's secret-token header
(TELEGRAM_WEBHOOK_SECRET); the main slot reads TELEGRAM_BOT_TOKEN_MAIN,
since TELEGRAM_BOT_TOKEN on vps3 is the miniapp's sign-in check.
- nginx keeps the public URL shape:
supabase.pezkuwichain.io/functions/v1/{telegram-bot,ask}.
- deploy.yml ships them with a new bots-deploy verb on the existing deploy
key; the host script accepts exactly main, telegram-bot and ask, restarts
the container and fails unless the bot comes back refusing unsigned updates.
- Registry: _cloud_hosted becomes _hosted_elsewhere; the gate refuses those
names in the shared volume and reports any copy there as stale.
* ask: send the legacy service key as a bearer token on vps3
The vps3 gateway has no opaque sb_secret keys and honours the service_role JWT
only as a bearer token; sent on apikey alone it reads as anon, the limiter's
count fails, and every question is refused as rate-limited.
The Gemini-first chain and the Groq model swap from 2026-09-05 never reached
main, so the next deploy from main put back models that no longer exist:
both llama models 404, gpt-oss-120b sits at its daily token cap, and
claude-sonnet-4-20250514 is retired. Every DKS bot question ended in
"could not process your question".
- Gemini first, Groq second, Claude last, in telegram-bot and ask.
- Model lists re-measured against the live accounts today; a hung Gemini
model is cut off after 20 s so it cannot eat the function's wall-clock.
- Strip <think> blocks from replies.
- The app bots now answer "Start" typed by hand and any other plain text
with the welcome and its app buttons, instead of staying silent.
TronGrid's free plan allows 10,000 requests a day. Checking every user's
TRC20 address on every five-minute run needs ~29,000 a day at 101 users,
so the key ran out at 03:00 UTC and every later run was refused.
get-deposit-info now records when a user opened the deposit screen.
check-deposits checks users seen in the last 24 hours on every run and
everyone in one run every six hours (00, 06, 12, 18 UTC): about 3,300
requests a day at 10 active users. A deposit made without opening the
screen within the past day waits for the next full scan.
The user-list query now reports its error instead of ending the TRC20
check as if there were no users.
A run walks every user's TRC20 address at ~4 TronGrid requests a second,
so a one-minute schedule stops fitting at roughly 150 users. Five minutes
leaves room to grow; deposits are detected up to five minutes later.
Subscan's free plan answers 403 row_limit_exceeded to a page of 50, so
every Polkadot check failed once a key was configured. 25 is the largest
page it accepts (measured: 25 succeeds, 30 is rejected).
The TON check walked every jetton transfer in the deposit address's event
feed, including the ones it sends. An outgoing transfer whose comment
matched a user's deposit code would have been credited to that user; the
2026-02-13 sweep of 41.9 USDT was reported as an unknown-memo deposit on
every run.
Resolve the configured address to its raw form and skip any transfer
whose recipient is not the deposit address.
tonapi rejects `Authorization: Bearer ` with 401 but serves keyless
requests, so every TON check failed whenever TONAPI_KEY was unset. Send
the header only when a key is configured.
TON and Polkadot API errors now carry the first 200 bytes of the
response body and are logged, so the cause of a failure is visible
instead of a bare status code.
pg_net's default 5 s timeout is shorter than the check, so every call since at
least this morning was stored as a timeout and the function's result was
lost. The function kept running; only the record was missing.
The 429 body logged by the previous change reads: 'The key exceeds the
frequency limit(15), and the query server is suspended for 27 s'. The run sent
batches of 8 at once, which tripped it although it averaged about 7 a second,
and the suspension outlasted the 1 s and 2 s retries, which never recovered a
request.
Requests now go one at a time, at most 4 a second. The retries are removed.
Each run starts at a different user, so a run that does hit the limit stops
at a different place each time instead of always skipping the same users.
After the pacing fix, 429 still came back in about a third of the runs: from
around the 17th user on, every request was refused, retries included
(measured 2026-10-18 over 404 runs). The body of that answer says which limit
was hit and for how long, and it was never logged. The first 429 of a run now
logs it, and the users after it are skipped with one line saying how many,
instead of each being sent into the same limit.
check-deposits polls every user's TRC20 address each minute in unpaced
batches of 8. Since the previous change logged TronGrid failures, two
consecutive runs showed HTTP 429 from about the 24th request on: deposit
indexes 24-53, 30 of 53 users, were skipped on every run, so their TRC20
deposits were never seen. The old code returned silently on a non-2xx reply.
- batches start at least 1.1 s apart
- a 429 is retried twice, after 1 s and 2 s
- per-user failures, including thrown errors, are logged and returned in
result.errors instead of being dropped
Deposits are found from the last 20 transfers per address and deduplicated
by tx_hash, so once users are checked again a skipped deposit is picked up
on the next run.
Both TRC20 deposit functions sent `TRON-PRO-API-KEY: ''` when the key was
unset, and check-deposits returned silently on any non-2xx TronGrid
response, so a 401 or 429 skipped a user's deposits with nothing in the
logs.
- send the key header only when TRONGRID_API_KEY is set; warn once if not
- check-deposits logs the status and deposit index on a failed call
- process-deposits records the TronGrid status in results.trc20.errors
- type the batch item in check-deposits (deno check TS7006, pre-existing)
* chore(deps): move vulnerable dependencies to patched versions
Direct dev dependencies: vite ^5.4.1 -> ^6.4.3 (5.x has no patched
release for the fs.deny bypass and launch-editor advisories; also lifts
esbuild from 0.21.5 to 0.25.12), vitest and @vitest/coverage-v8 ->
^4.1.11, postcss -> ^8.5.23.
Transitive packages refreshed within their existing ranges:
brace-expansion, js-yaml, baseline-browser-mapping, qs, @humanfs/node,
browserslist, postcss-selector-parser, nanoid, form-data, @babel/core,
picomatch.
Overrides with a floor at the patched version where a parent pins an
old release: axios ^1.20.0 (tronweb pins 1.15.0) and ws ^8.21.0
(ethers pins 8.17.1).
* fix(security): address open code scanning findings
- auto-merge: pass workflow_run.head_branch through env instead of
interpolating it into the shell script (code injection).
- ci, deploy, code-quality: restrict GITHUB_TOKEN to contents: read.
- telegram-bot: return a generic error body on failure; the error stays
in the function log instead of being echoed to the caller.
- p2p-e2e-test.py: stop printing a prefix of the service-role key.
The DKSapp project's legacy anon/service_role keys were disabled on
2026-10-02, after the service_role key leaked through a public commit.
ask read SUPABASE_SERVICE_ROLE_KEY, so its rate limiter stopped working.
- Read the secret key from SUPABASE_SECRET_KEYS ('default'), the variable
Supabase provides alongside the legacy one, and send it on the apikey
header only: as a Bearer token the gateway rejects it as a malformed JWT.
- The limiter read a missing content-range as a count of zero, so a
rejected key let every request through to the paid model. A failed
count, a failed log write or a missing key now refuses the request.
check-deposits hits the isolate's CPU ceiling on almost every run — 17 limit
events across 20 invocations in the last 20 minutes — and when it does, the
supervisor cancels the worker and the scan stops partway. Deposits after the
cut-off simply are not seen until some later run happens to reach them.
The cause is in deriveTronAddress: it calls mnemonicToSeedSync per user, which
is PBKDF2 with 2048 iterations. The seed depends only on the mnemonic, so with
51 accounts that cost was paid 51 times a minute to produce the identical seed.
Only the derivation path varies per user.
Derive the master key once and reuse it. Measured over the 51 accounts we
actually scan: 418ms -> 58ms, a 7.2x drop in the part that was blowing the
budget.
Verified the addresses are unchanged: old and new paths produce identical
private keys for every index tested, including repeated indexes in one run,
which is what would expose derive() mutating the parent key. It does not.
The main slot was described as a retired testnet bot. It is not retired — a
fresh bot was created for it on 2026-07-30 under separate ownership, username
@BizinikiwiBot, display name Pezkuwichain_Bot. It is not a recovery of the
compromised @pezkuwichain_bot; that account is gone and its token stays invalid.
Its webhook carries no ?bot parameter, so getBotId falls back to main and this
slot is now a live path rather than a fallback. The cloud secret
TELEGRAM_BOT_TOKEN holds the new token.
Also puts the PEX.network link on the main welcome, so all three bots offer it.
MINI_APP_URLS.main still pointed at telegram.pezkuwichain.io, the testnet domain
whose DNS record was removed on 2026-07-12. Live webhooks arrive as ?bot=krd and
?bot=dks so that default is never reached today, but a webhook call without the
parameter would have answered /start with a link that cannot resolve.
Also puts the PEX.network link on the krd menu — @pezkuwichainBot, the bot that
actually opens the mini app. It only existed on the dks welcome, so no user
reaching the mini app through the main bot has ever been shown it.
Leaves the three-slot routing alone: both slots are live and healthy on the
cloud project, and collapsing them would have removed the AI assistant.
The button is live but has never existed in this repo — `git log -S "Buy/Sell
Crypto"` returns nothing, so it was added by hand on the server and missed when
9bb9d2c synced git with the deployed source. Deploying telegram-bot from CI
would therefore have silently dropped it.
Restoring it here keeps what is actually running. Removing it should be a
deliberate decision, not a side effect of the first automated deploy.
`ask` has never been deployed, and the CI step in this branch will publish it.
Its limiter counts rows in ai_chat_log to cap requests at 8/min and 120/day per
IP, but no migration ever created that table, and the limiter fails open when
the count cannot be read.
Shipping `ask` without this would put an unauthenticated endpoint with
Access-Control-Allow-Origin: * in front of paid model APIs with no limit at all.
Applied to the live database as well.
#1 brought the live P2P identity resolution into main, which this branch's CI
deploy step needs to be present before it can safely publish these functions.
Version stamp was the only conflict; took main's.
The Supabase edge-function volume on the host is shared with pwap-web, which
deploys into it by rsyncing its whole tree. Both projects defined a function
called telegram-auth, so on 2026-06-28 pwap-web's login-widget handler replaced
this project's initData handler. Sign-in and every wallet screen behind it have
returned 401 ever since; nothing failed loudly because the name still resolved.
Rename this project's two colliding functions to a tgm- namespace so the two
deploys can no longer reach the same directory, and point the client at the new
name. process-withdraw is renamed too: it is currently unreferenced here, but it
moves platform funds, so leaving it shadowed by another project's version is not
something to keep.
Also deploy functions from CI. They were last pushed by hand in April, so seven
of them had drifted behind the repo and one had never shipped at all. The new
step writes through the host's ownership gate, which refuses any name this
project does not own — the drift and the collision both stop here.
Ownership is recorded in /opt/supabase-self-hosted/functions-registry.json.
User decision after the Groq reliability fix (previous PR): prioritize
Groq's smallest/fastest model, llama-3.1-8b-instant, over gpt-oss-120b —
it's long out of preview and has historically the best free-tier
availability, at the cost of gpt-oss-120b's better Turkish/Kurdish
fluency (which is why it was chosen originally). Model order is now
llama-3.1-8b-instant -> gpt-oss-120b -> llama-3.3-70b-versatile before
the (currently uncredited) Anthropic fallback.
Also fixed a real UX complaint: asking about the Mining Simulation made
the model repeat "this isn't real mining / it's just an estimate" in
nearly every paragraph. Added an explicit instruction to state that once,
briefly, near the start of the answer, and not repeat it — verified live,
the disclaimer now appears once per response instead of several times.
User decision after the Groq reliability fix (previous PR): prioritize
Groq's smallest/fastest model, llama-3.1-8b-instant, over gpt-oss-120b —
it's long out of preview and has historically the best free-tier
availability, at the cost of gpt-oss-120b's better Turkish/Kurdish
fluency (which is why it was chosen originally). Model order is now
llama-3.1-8b-instant -> gpt-oss-120b -> llama-3.3-70b-versatile before
the (currently uncredited) Anthropic fallback.
Also fixed a real UX complaint: asking about the Mining Simulation made
the model repeat "this isn't real mining / it's just an estimate" in
nearly every paragraph. Added an explicit instruction to state that once,
briefly, near the start of the answer, and not repeat it — verified live,
the disclaimer now appears once per response instead of several times.
The AI assistant (both @DKSKurdistanBot on Telegram and the news.pex.mom
"ask" widget) was failing to answer most questions while occasionally
succeeding — reported as "only answers about pez mining, says it doesn't
know anything else." Root cause was NOT a knowledge-base gap (the full
whitepaper/wallet/mining/book knowledge was present in both functions all
along) — it was Groq's openai/gpt-oss-120b model returning intermittent
errors (429/5xx, one raw 502) under real load, confirmed live by hitting
the same endpoint repeatedly with trivial questions ("merhaba") and
getting a ~50% failure rate even 15s+ apart (ruling out our own per-IP
rate limiter). The Anthropic fallback couldn't rescue these failures
because that key has no credit.
Fix: retry each Groq call up to 2x with backoff, and fall back to
llama-3.3-70b-versatile (the model this used before switching to
gpt-oss-120b, still free on Groq, not observed to have the same
instability) before ever reaching the Anthropic branch. Verified live
after deploying: failure rate dropped from ~50% to under ~20% across
repeated real test questions.
Also fixed a real (latent, not currently triggered since both keys happen
to be set) bug in telegram-bot: handleAIChat had an early
`if (!ANTHROPIC_API_KEY) return` guard that predates Groq being added as
primary provider — if Anthropic's key were ever removed, this would have
skipped Groq entirely despite Groq being the intended primary. Changed to
only bail if BOTH keys are missing.
Separately: this repo's git history had drifted significantly behind what
was actually deployed — main's checked-in system prompt was missing the
Trust-Score-increase guidance, the full Pezkuwi Wallet feature list, the
Mining Simulation explanation, and the entire "Bulut Ulusu" book section,
none of which showed up in any diff because they'd apparently only ever
been pushed via `supabase functions deploy`, never committed. Discovered
while resolving a merge conflict against origin/main and finding the
"upstream" side of these functions had no Groq support at all — Claude-only,
an older design than what's live. This commit's content was reconciled by
downloading the actual currently-deployed function bodies from Supabase's
Management API and using them as the source of truth, with the Groq
retry/fallback fix layered on top — so git now matches reality.
Root cause chain found while investigating why TRC20/TON/Polkadot deposits
were never being credited after the self-hosted Supabase migration:
- DEPOSIT_TRON_HD_MNEMONIC, TRONGRID_API_KEY, DEPOSIT_TON_ADDRESS,
DEPOSIT_POLKADOT_ADDRESS and the pg_cron job itself were never carried
over during the 2026-04-09 migration, so check-deposits never ran.
- Once reconnected, the TRC20 loop was fully sequential (one address at a
time) and hit the edge function's CPU/time budget with 50+ users -
parallelized with a bounded concurrency of 8.
- The dedup check (select-by-tx_hash + .single()) breaks permanently once
2+ rows ever share a tx_hash - .single() then errors on every future
lookup, so the guard silently stops working and every cron tick
reinserts. This is what produced 50k+ and 30k+ duplicate rows for two
historical deposits back in April. Replaced with upsert +
onConflict/ignoreDuplicates against a new unique constraint on tx_hash,
so duplicates are impossible at the DB level regardless of app-level
races.
- deposit_index 0 is the platform admin account and also used as the
treasury sweep destination - excluded from the TRC20 scan so internal
sweep transfers landing on it are never mistaken for a customer deposit.
- Correct Instagram/TikTok/Telegram/X/Facebook URLs to official accounts
- Apply same Telegram channel fix to bot welcome messages
- Add ask edge function powering the AI assistant on news.pex.mom
The Telegram assistant now answers via Groq (free) first and falls back to
Claude when ANTHROPIC has credit. Keys come from env (GROQ_API_KEY /
ANTHROPIC_API_KEY) — no secrets in source. Wallet/p2p logic untouched.
Add p2p_user_id column to tg_users to bridge citizen/visa UUID (v5)
used by pwap/web with the Supabase Auth UUID (v4) used by the mini app.
- Migration: tg_users.p2p_user_id UUID (nullable, indexed)
- 6 P2P edge functions: replace listUsers+find with direct tg_users
lookup — resolves userId as p2p_user_id ?? id (backwards compatible)
- Eliminates O(N) auth.admin.listUsers scan in every P2P call
When p2p_user_id is populated (via TelegramConnect wallet link),
mini app users share the same P2P balance and offers as pwap/web.
- Add DKS bot support to telegram-bot and telegram-auth functions
- Claude-powered Q&A using PezkuwiChain whitepaper knowledge base
- Update Telegram social link to dijitalkurdistan channel
request-withdraw-telegram now sends tokens from hot wallet to user wallet
using @pezkuwi/api, instead of leaving requests in pending state.
Falls back to pending if PLATFORM_PRIVATE_KEY is not configured.
- Rewrite DepositWithdrawModal to send TX automatically via assetHubApi
instead of manual copy-paste-hash flow
- Fix listUsers pagination bug (default 50) in 4 edge functions by
adding perPage: 1000 - fixes P2P offers not showing for users
- Add new i18n keys for automated deposit states in all 6 languages
- Fix process-withdraw and verify-deposit-telegram to use RPC_ENDPOINT
env var defaulting to Asset Hub (wss://asset-hub-rpc.pezkuwichain.io)
- Add P2P E2E test script (scripts/p2p-e2e-test.py) covering full flow:
offer creation, trade accept, payment, escrow release, cancel, visa
user trade, and withdrawal request
- Update p2p_balance_transactions transaction_type check constraint
to include withdraw_lock, withdraw_complete, dispute_refund
- Remove wallet setup/create/import/connect steps from CitizenPage
- Add privacy notice banner with Shield icon to form
- Add seed phrase textarea with mnemonic validation
- CitizenProcessing creates keypair directly from seed phrase
- CitizenSuccess shows 3-step next process info
- Add /citizens path support alongside ?page=citizen
- Update bot URL to /citizens
- Add 10 new i18n keys in all 6 languages
- Add telegram.pezkiwi.app to CORS allowed origins in all edge functions
- Support multiple bot tokens (TELEGRAM_BOT_TOKEN, TELEGRAM_BOT_TOKEN_KRD) in auth
- Dynamic origin matching for proper CORS headers
