Privacy Policy
This policy explains how we handle personal data when you use nrg.market (the "Service"). It is written against the GDPR and against Cyprus data protection law (Law 125(I)/2018). Our supervisory authority is the Office of the Commissioner for Personal Data Protection of the Republic of Cyprus.
1. Who is responsible
The controller is NEOLOGIC LTD, a company incorporated in the Republic of Cyprus with registration number ΗΕ 414468 and registered office at Arch. Makariou III, 233, Kanika Phaethon Building, Flat/Office 127, 3105 Limassol, Cyprus, operating the Service as nrg.market.
- Contact for privacy questions: privacy [at] nrg.market.
- Data protection officer: we have not appointed one, and Article 37 GDPR does not require one here — we are not a public authority, and our core activities involve neither regular and systematic monitoring of data subjects on a large scale nor large-scale processing of special categories of data. If that changes, this section will name a DPO and a contact.
- EU/EEA representative: not applicable — the controller is established in Cyprus, in the Union.
2. What we process
We keep this list literal. It is derived from the database schema, not from an idea of what a service like this usually stores.
2.1 Account and sign-in
| Data | Notes |
|---|---|
| E-mail address | Stored encrypted (AES-256-GCM). A separate keyed hash of the address is stored so that sign-in can find your record; the plain address appears in no column. |
| Password | Stored only as an argon2id hash. We never see or store your password. |
| Two-factor secret and recovery codes | The TOTP secret is stored encrypted; recovery codes are stored only as keyed hashes. |
| Google account identifier | Only where you sign in with Google: the stable subject identifier issued by Google, not your Google password. Google sign-in is currently disabled in configuration; this row applies once it is switched on. |
| Preferences | Time zone, interface language, which optional e-mails you have switched off. |
| Account status and timestamps | Registration, e-mail verification, last update. |
2.2 Sessions and security records
| Data | Notes |
|---|---|
| Session records | A hash of the session token, creation time, last-seen time, expiry, revocation, IP address and browser user-agent. These are what the "devices" screen shows you. |
| Sign-in and abuse counters | Short-lived counters and temporary bans in our cache, keyed by IP address and by account-plus-IP, used to stop password and code guessing. |
| Audit log | An append-only record of security- and money-relevant actions (registration, sign-in, failed sign-in, sign-out, session revocation, password reset, second-factor changes, API key issue and revocation, webhook changes, operator actions), with the actor, the action, before/after values and the IP address. |
| Access logs | Request logs record the path without the query string; request and response bodies are not logged, and fields marked sensitive (including email) are redacted. |
2.3 One-time links and e-mail
| Data | Notes |
|---|---|
| One-time link tokens | Hashes of links sent for e-mail verification, password reset and e-mail change, with expiry and single use enforced by the database. For an e-mail change, the new address is stored encrypted until confirmation. |
| Outgoing e-mail queue | The whole letter — recipient, subject, both body parts — is stored encrypted. Left in the clear are only the template name and delivery state, which is what metrics and incident review need. |
| Device notification | A new sign-in from a browser user-agent we have not seen before triggers a notification e-mail; the user-agent string is included, sanitised and truncated. |
2.4 Service use
| Data | Notes |
|---|---|
| TRON addresses | The Deposit Address we assign to you; sending and receiving addresses in your orders; addresses you nominate in auto-refill rules. |
| Ledger | Append-only accounting entries: purchases of Service Credits, reservations, charges, releases and manual adjustments, with amounts, the on-chain transaction id of a deposit, and the sending address of that deposit. |
| Orders and positions | Amounts, energy quantities, prices, statuses, error causes, on-chain transaction ids. |
| Signed transactions (Mode B) | The transaction you signed, stored encrypted and deleted seven days after the position reaches a final state. |
| Auto-refill rules | The address, the daily budget, spending and recognition history, and the position of our reading cursor over that address's on-chain activity. |
| API keys | A label, a hash of the key, an optional IP allowlist, last-used time. The key itself is shown once and never stored. |
| Webhook endpoints | The URL you register and the signing secret, stored encrypted. |
2.5 What we do not have
- Private keys and seed phrases. We never request, receive, derive or store them. In Mode B we handle a transaction you already signed; we cannot sign anything on your behalf.
- Identity documents. We do not run identity verification and hold no identity documents. The one exception is a discretionary return of an unused balance at account closure (Terms of Service §13.3.3), which we perform only after verifying identity for that case; documents provided for it are used for that decision alone. If systematic identity verification is ever introduced, this policy will be amended first — a new data category, a new legal basis, and a retention rule.
- Payment card or bank data. There is none: the Service is paid for in TRX.
- Marketing profiles, advertising identifiers, analytics. The dashboard runs no analytics or advertising scripts, and this policy will be amended before any are ever added.
3. Why we process it, and on what basis
| Purpose | Data | Basis |
|---|---|---|
| Providing the Service: creating your account, delivering energy, keeping your balance and order history, sending events to your webhook | §2.1, §2.4 | Performance of a contract |
| Sign-in, sessions, second factor | §2.1, §2.2 | Performance of a contract |
| Security: preventing password and API key guessing, detecting account takeover, notifying you of new devices and of changes to your account | §2.2, §2.3 | Legitimate interests (protecting accounts and the Service); some notifications are also contract performance |
| Checking a proposed password against a public list of breached passwords | Derived value only — see §5 | Legitimate interests (account security) |
| Investigating incidents, reconciling money, and defending claims | §2.2, §2.4 | Legitimate interests; also legal obligation where accounting is concerned |
| Accounting and tax records | §2.4 (ledger, orders) | Legal obligation |
| Sanctions screening and freezing an account on a match | Deposit sending addresses, account data, IP | Legal obligation for the EU and UN restrictive measures, which bind us directly; legitimate interests for the additional lists we screen as a risk control (see the Acceptable Use Policy §2.1) |
| Service e-mails you can switch off (order completed, deposit credited, weekly summary) | E-mail address | Legitimate interests, with an opt-out in the dashboard |
| Service e-mails you cannot switch off (password changed, e-mail changed, second factor enabled or disabled, new device) | E-mail address | Legitimate interests — a security notice that the attacker could switch off would not be a security notice |
| Marketing | — | Not done. If it ever starts, it will be based on consent, and this policy will be amended first |
For each processing based on legitimate interests we keep a written balancing assessment internally; you may object to any of them (§8).
4. Who else sees it
We use the following processors and service providers, each under a data processing agreement where it processes personal data on our behalf. They are listed by category, which is how the GDPR permits recipients to be described: we do not advertise our infrastructure by name. The register of the specific companies is kept internally, is disclosed where the law requires, and if you ask us (§8) which provider holds your data, we will tell you.
| Provider | What they do | What they see |
|---|---|---|
| Cloud hosting provider | Hosting of the application, database and workers (United Kingdom, London) | Everything in §2, at rest on their infrastructure |
| Edge and CDN provider | Reverse proxy, TLS and abuse protection in front of the API; static hosting for the dashboard and documentation | Request metadata including IP addresses; TLS terminates on their edge |
| Transactional e-mail provider | Delivery of the e-mails we send you | Recipient address and message content of e-mails we send you |
| Off-site backup storage provider | Encrypted off-site backups (European Union — Germany or Finland) | Encrypted backup archives; the encryption key is not held by them |
| Sign-in with Google, where you choose it (currently disabled in configuration) | That you signed in, and your Google account identifier | |
| Anti-bot challenge provider | Anti-bot check on the registration form. Not yet connected; listed here so that the policy is ready before it is | Registration-form request metadata |
| TRON RPC node providers (a primary and fallbacks) | Reading the TRON network and submitting transactions | The TRON addresses and transactions we query or submit — including yours. This is public blockchain data, but the queries themselves reveal which addresses we are interested in |
| Status-page host | Hosting of the public status page at status.nrg.market, outside our own infrastructure so that it stays up when the service does not | Request metadata of status page visitors, including IP addresses. No account data reaches them: the page is fed by four public words (ok/down) from GET /v1/health, and subscriptions to status updates are switched off, so no e-mail addresses are shared |
| Operator alerting service | Delivery of internal alerts to the operator | Alert text: transaction ids, TRON addresses and internal account identifiers. Alerts do not contain e-mail addresses or other direct identifiers |
We also disclose personal data where we are legally required to, and to advisers (accountants, lawyers) under confidentiality.
We do not sell personal data and do not share it for advertising.
5. The breached-password check
When you set a password we check it against the Have I Been Pwned breached password service using its k-anonymity model: we send only the first five characters of a hash of the password, never the password, never your e-mail address, and never an identifier. If that service is unavailable, the check is skipped and registration continues; the skip is recorded in our metrics.
6. Where your data is
The application, its database and its background workers run in the United Kingdom (London). Off-site backups are stored in the European Union (Germany or Finland) on an encrypted repository; the encryption key never leaves us. Our edge/CDN provider, our e-mail delivery provider and Google have infrastructure outside the EEA, including in the United States.
Transfers outside the EEA therefore happen, on the following bases:
- United Kingdom — covered by the European Commission's adequacy decision for the UK, renewed in 2025. If that decision ever lapses, we will put Standard Contractual Clauses in place with the affected providers or move the processing.
- United States — our edge/CDN provider and Google are certified under the EU-U.S. Data Privacy Framework; our e-mail delivery provider is engaged under a data processing agreement incorporating the EU Standard Contractual Clauses.
7. How long we keep it
| Data | Retention |
|---|---|
| Account and sign-in data (§2.1) | Until the account is closed, then deleted |
| Sessions | Until revoked or expired: 7 days of inactivity, 30 days absolute |
| Sign-in and abuse counters | Minutes to hours, by cache expiry |
| One-time link tokens | Until used or expired (verification 24 hours, password reset 1 hour), and in any case deleted with the account |
| Outgoing e-mail queue | Kept, encrypted, for the life of the account and deleted with it. There is currently no earlier ageing-out of sent letters; if one is introduced, the period will be stated here |
| Signed transactions (Mode B) | 7 days after the position reaches a final state, then deleted |
| Ledger and audit log | Retained as accounting and security records, including after an account is closed, for at least six years after the end of the year in which the account closes — the period Cyprus tax and company law requires accounting records to be kept — and thereafter until disposal. They are append-only by design: rows cannot be edited or deleted, and the database role the application uses has no rights to do so. Disposal therefore happens by archiving and destroying whole record sets in a documented operation, never by editing rows; we review annually what has become due |
| Orders, positions, provider records | Retained with the account record for the same reason as the ledger |
| Backups | Local base backups: last 7. Off-site: 7 daily, 4 weekly, 6 monthly — so up to roughly six months. Deletion of an account does not reach into existing backups: deleted data persists in them until they expire on that schedule. If a backup is ever restored, deletions made since it was taken are re-applied as part of the restore procedure |
8. Your rights
Subject to the conditions in the GDPR you may ask us to:
- give you access to your personal data, and a copy of it;
- correct data that is wrong;
- erase data (see the limits below);
- restrict or object to processing based on legitimate interests;
- port data you gave us, in a machine-readable form;
- withdraw consent where processing is based on consent (currently nothing is).
You may also complain to a supervisory authority — in Cyprus, the Office of the Commissioner for Personal Data Protection, or the authority where you live.
How to exercise them. Write to us from the e-mail address on your account, at privacy [at] nrg.market. We answer by hand. There is no self-service delete button, deliberately: closing an account cancels any Service Credits left on it (Terms of Service §13.3), and doing that behind a one-click button would be taking money silently. A person tells you the amount and closes the account only once you have confirmed it.
In practice, most of an access request is already served by the product: your ledger, orders and sessions are readable at any time through the API and the dashboard. We will still answer a formal request properly.
Limits on erasure. Closing an account deletes your sign-in identity: e-mail address, password hash, second-factor secret and recovery codes, Google link, and all sessions. API keys are revoked. What stays is the ledger and the audit log — these are financial and security records that we keep for accounting and for defending claims, and they are append-only by design. The account record itself is retained in a suspended state so that its history remains coherent. We also cannot remove anything from the TRON blockchain: on-chain transactions are public, permanent and outside anyone's control, including ours.
For the ledger we rely on Article 17(3)(b) GDPR — retention is required for compliance with our legal obligation to keep accounting and tax records. For the audit log we rely on Article 17(3)(e) — the establishment, exercise or defence of legal claims — together with Article 17(3)(b) where the record documents a legally required action (for example, a sanctions freeze).
9. Cookies and local storage
The dashboard uses no advertising or analytics cookies.
| What | Purpose | Type |
|---|---|---|
__Host-nrg_session | Keeps you signed in. HttpOnly, Secure, SameSite=Lax. | Strictly necessary |
| CSRF token | Sent as a header with every state-changing request, to stop other sites acting as you. | Strictly necessary |
| Short-lived sign-in exchange cookie | Only during a Google sign-in, to tie the redirect back to the request that started it. | Strictly necessary |
localStorage: theme and language | Remembers your interface choices on that browser. Never sent to us. | Not a cookie; local to your device |
Because all of these are strictly necessary for a service you asked for, or never leave your device, no consent is required for them under the ePrivacy rules as applied in Cyprus (Law 112(I)/2004), and we do not show a consent banner. If the anti-bot check (§4) is ever connected, we will re-assess this section before it goes live.
10. Security
The measures below are the ones the system actually implements; they are described more fully in our internal security documentation.
- E-mail addresses, second-factor secrets, webhook secrets, queued e-mails and stored signed transactions are encrypted at rest with AES-256-GCM. Encryption keys carry an identifier and can be rotated without downtime.
- Passwords are hashed with argon2id. API keys, session tokens and one-time link tokens are stored only as hashes.
- The ledger and audit log are append-only, enforced twice over: the application's database role has no rights to update or delete rows, and a database trigger raises on any attempt, including by a superuser.
- Traffic is TLS-only with HSTS; the origin accepts connections only from our reverse proxy.
- Rate limiting and expanding temporary bans protect sign-in, second-factor entry and API keys against guessing.
- Backups are encrypted, verified after they are taken, and restore drills are run rather than assumed.
- Private keys used by the business live on a separate signing service on isolated infrastructure, which will only sign transfers to a fixed whitelist of addresses within fixed limits.
No system is perfectly secure. If you believe your account has been compromised, change your password (which ends every session) and contact us.
Breach notification. The operator assesses any suspected personal data breach on discovery and records the assessment and its outcome. Where the breach is likely to result in a risk to individuals, we notify the Office of the Commissioner for Personal Data Protection within 72 hours of becoming aware of it; where the risk is high, we also notify the affected account holders directly by e-mail.
11. Children
The Service is not directed at children and we do not knowingly process their data.
12. Changes
We may update this policy. The current version, with its date, is always published at https://nrg.market/legal/privacy. For material changes we will notify account holders by e-mail.