How tet.energy handles data
This page describes the data paths implemented in tet.energy as of 29 July 2026. Wallet addresses and blockchain activity are public by design; other product records support authentication, orders, accounting, security and operations.
Wallet connection and TIP-191 sign-in
Connecting a wallet exposes its public TRON address to the product. To sign in, the server issues a time-limited, single-use nonce and asks the wallet to sign a canonical TIP-191 message for tet.energy. The signature proves control of the address; the product creates an internal user record and links the verified address. The authenticated session uses a signed, expiring, host-only HttpOnly cookie and a separate CSRF token. tet.energy does not need your wallet's private key or seed phrase; never send either to us or anyone claiming to be support.
Orders, ledger entries and audit events
When you place or fill an order, the product records its terms, receiver address, timestamps, status and related user, seller, fill, delegation and transaction identifiers. Double-entry ledger entries record amounts, buckets, references and links to orders, fills or chain transaction hashes. Append-only audit events record security and money actions, actors or subjects, time and redacted context. These records keep orders, balances, reconciliation and incident investigation consistent.
Requests, IP addresses and operational logs
Requests may produce request IDs, route, error and status details, and operational logs containing internal user or order IDs or public wallet addresses. IP addresses are read to place traffic into public-request, sign-in and failed-authentication rate-limit or lockout buckets; security events can also log the IP address. The product uses this information to serve requests, control abuse, troubleshoot failures and support users. Do not put secret values in support requests: audit payloads redact common secret fields, but ordinary operational logs are not a safe place for secrets.
Browser storage and cookies
For the current browser session, sessionStorage can hold the CSRF token and wallet metadata: the public address, selected provider, internal user ID, displayed TRX balance and whether that balance is known. A transient localStorage signal is written and immediately removed to coordinate sign-in and sign-out across tabs; BroadcastChannel may also be used. Cookies carry the authenticated session and interface preferences such as theme and accent. Clearing browser data or disconnecting removes local state, but it does not erase server or blockchain records already created.
Conditional analytics
A Google tag loads on every page of the site for advertising measurement and remarketing. It sets first-party cookies, including _ga and _gcl_au, in your browser. Consent is region scoped: analytics storage, advertising storage, advertising user data and advertising personalization default to denied in the EEA, the United Kingdom and Switzerland, and to granted elsewhere. The app does not load an external Google Tag Manager container. Analytics is no longer confined to marketing pages and now also covers the market and the dashboard; administrative pages send nothing. Advertising click identifiers, gclid, gbraid and wbraid, and utm parameters are retained in URLs rather than stripped, and the click identifier is held in your browser session so that an order can later be matched to the advertisement that brought you here. Every event carries only an allowlisted set of parameters. Your wallet address, receiver address, user id, order id and transaction hashes are never sent to Google, and neither are amounts: order and trade identifiers are publicly linkable to on-chain addresses, so they are replaced by a random value generated in your browser that identifies nothing.
What becomes public
The order book is public. Listings can show a receiver address, order terms and timestamps, while public seller and fill views can associate a seller address with activity and measured reliability. Confirmed TRON transactions can expose addresses, contract parameters, amounts, transaction hashes and times on the public network. Explorers and other parties can copy this information, and tet.energy cannot make those copies private or erase the blockchain. A wallet address is pseudonymous, not anonymous; combining it with other information may identify a person.
Security boundaries
Current controls include canonical signature verification, single-use nonces, expiring signed sessions, host-only HttpOnly cookies, SameSite=Lax, CSRF checks for browser mutations, credential scopes, rate limits, redaction of common secret fields in audit payloads and a hash-chained audit trail. Access controls separate public market data from account records. No online system can guarantee absolute security, and this page does not claim an independent certification or audit.
Retention boundaries
The current product does not publish one fixed retention period. Nonces, sessions, rate-limit counters, lockouts and session-revocation records expire or are cleared by the systems that use them, without a duration promised here. Browser session metadata follows the browser's session-storage lifecycle. Orders, ledger entries and audit events are designed as durable operational records; retention for ordinary request and operations logs is not specified here. Public blockchain records are outside tet.energy's control and may remain available indefinitely.
Your choices and contact
You can read public pages and market data without connecting a wallet. If you connect, you can sign out or disconnect and use browser controls to clear local cookies and storage; that does not remove server records or public chain activity already created. For questions about this page or information associated with a wallet address, email [email protected]. Include only the public address and enough context to understand the request. Never send a private key, seed phrase or signature. Public blockchain data, third-party copies and records needed to preserve ledger or audit integrity may not be removable.