Telegram Mini App
User wallet view, separate TRX and USDT balances, KYC status, deposit address display, and controlled test workflows.
Operating platform, not just a wallet screen
The current build proves the core loop needed before cards: user identity, KYC evidence, wallet addresses, on-chain detection, admin review, ledger posting, audit history, backup evidence, and controlled operations.
Admin cockpit
Users, KYC review, deposit review, ledger entries, audit logs, TRON operations, commission wallet, and backup operations.
Ledger evidence
Double-entry-style wallet accounts, holds, idempotency keys, detected deposits, admin approval, withdrawal records, and commission accounting.
KYC archive
Controlled internal KYC form and document storage outside the public web root, with admin-only access and manual approval.
TRON pilot
Mainnet tiny-value TRX and USDT TRC-20 detection with review before balance credit, plus direct transaction-hash recovery for rate-limit cases.
Provider-ready path
The next product block is a mock provider and card state machine, kept behind ZEN APIs so future providers can be replaced.
Current stage status
The product is in a controlled internal pilot. Public onboarding, real card issuing, and broad withdrawals are not part of the public stage.
Done
Foundation
VPS deployment, Caddy HTTPS, API, PostgreSQL, Redis, Telegram Mini App, admin panel, backup scripts.
Done
Identity and KYC
Telegram users, admin users, KYC form, document archive, OCR/name-check support, admin approval.
In pilot
Wallet and ledger
TRX/USDT balances, deposit detection, admin deposit review, ledger entries, commission wallet, audit separation.
Next
Security and reconciliation
Admin MFA/RBAC, withdrawal limits, reconciliation report, risk tiers, country policy, incident and wind-down runbooks.
Later
Cards and provider integration
Mock provider, card models, card funding states, webhooks, reversal tests, then provider sandbox when ready.
Security and custody posture
The first build is intentionally conservative. ZEN user surfaces call ZEN APIs only; secrets, private keys, database access, and provider logic stay server-side.
No keys in clients
Private keys are never placed in Telegram, the admin frontend, screenshots, Git, or chats.
Admin approval gates
Detected deposits remain pending until administrative review and ledger posting. KYC is required before wallet use.
Caddy HTTPS
Caddy remains the TLS owner for public domains. No conflicting SSL layer should be enabled on the VPS.
Audit trail
KYC, deposits, ledger entries, scans, withdrawals, backup operations, and admin actions are recorded for review.
Backup evidence
Database backups and restore-test procedures are part of the operating platform, not an afterthought.
AI principle
AI may summarize and explain operations later. It must not approve deposits, block users, move money, or access raw KYC files.
Next build sequence
The next stage strengthens the wallet pilot before cards: pilot safety, reconciliation, RBAC/MFA, risk rules, then mock card provider foundations.
1. Pilot safety
Withdrawal controls, limits, restricted mode, and clearer admin review for external money movement.
2. Reconciliation
Daily report for deposits, withdrawals, commissions, ledger balances, detected events, and exceptions.
3. Admin security
MFA path, RBAC roles, session timeout, action attribution, and support view-only permissions.
4. Risk policy
Residence/country rules, risk tiers, manual review reasons, and sanctions/KYT provider readiness.
5. Support workflow
Support tickets, notes, escalation, user timeline, and evidence without direct balance editing.
6. Mock cards
Cardholder model, card object, virtual/physical type, provider reference, limits, simulated transactions, holds, and reversals.
Investor and partner access
ZEN Space Plus is available for controlled demonstration. Public user onboarding is not open yet.