ACCOUNT · EXECUTION · DATA
Security with a defined scope.
Protection is layered and tested. No system can promise immunity to every known or unknown attack.
Implemented controls
- Confirmed accounts, TOTP MFA for trading and management, server-validated roles, HttpOnly cookies, immediate app-session revocation and same-origin mutation checks.
- AES-256-GCM credential encryption bound to the account owner and exchange. API secrets stay server-side. No withdrawal, deposit or borrowed-position automation.
- Database ownership checks, row access restrictions, atomic allocations, worker fencing, order-intent persistence, kill switches and uncertain-order reconciliation.
- Nonce-based Content Security Policy, frame blocking, strict browser permissions, no third-party page scripts, bounded request/response sizes, timeouts and persistent rate limits.
- Native USDC payment verification with payer signatures, exact transfer logs, canonical finalized blocks and transaction uniqueness.
- ML-DSA-65 signatures for exported account reports, with a separately published verification-key fingerprint. The report states its record window; a signature does not prove profit or complete lifetime history.
EnteleKRON security alignment
Compatible controls include a server-enforced three-minute inactivity boundary, refresh-token session binding, approved email callback origins, least-privilege scanner workflows, pinned action revisions and dependency-update proposals. Review tooling has no production keys or deployment authority. Read-only ecosystem checks use fixed HTTPS endpoints without redirects or customer credentials. Exchange REST clients keep rate limiting enabled while queues and concurrency remain bounded.
EnteleKRON reference architecture is reviewed as design evidence, not represented as a deployed trading consensus or independent certification. Cross-project signing, shared login and wallet authority are not enabled. A scanner result cannot authorise a financial operation.
Post-quantum scope
ML-DSA-65 protects signed report integrity against the intended post-quantum signature threat model. AES-256 protects stored credentials. Exchange API authentication, Ethereum wallet signatures, public-chain security, browser TLS and third-party providers retain their own cryptography. This is not an end-to-end quantum-resistant trading system.
Operational work
Restrict exchange keys to isolated portfolios, approved markets and server egress IPs; disable withdrawal permissions. Use MFA at exchanges and hosting providers. Operators must configure WAF/DDoS controls, incident monitoring, backup recovery, key rotation, authenticated email and access reviews. Independent penetration testing and a broader audit remain necessary before a public production launch.
Report security issues privately to team@tvklabs.com. Do not send credentials or customer data.