Privacy Policy

1. Scope and purpose

This Privacy Policy describes the data Operator collects from Customer in relation to the Service, the retention windows applied to each data class, the third-party processors Operator invokes (and the third-party processors Operator does not invoke), and the Customer-side rights Operator recognises in respect of the data collected. The Policy forms part of the Terms at /legal/tos and applies to the Service as defined in the Terms.

The procured-infrastructure jurisdictions for the Service are the Russian Federation, the Republic of Belarus, and the Republic of Kazakhstan. None of these are within the European Economic Area; the General Data Protection Regulation does not apply by territorial scope to a Customer who selects a procured-infrastructure jurisdiction outside the EEA. Operator’s voluntary GDPR-equivalent posture is described in section 6.

2. Data Operator collects

The data set below is the operator-side inventory of Customer data held at any point during the Service lifecycle. The inventory is exhaustive at the placeholder layer; counsel finalises the field-level enumeration and the legal-basis citation for each field before deploy.

2.1 Account email

The email address Customer provides at /signup. Operator uses the account email for transactional communication: Order confirmation, renewal invoice, suspension notice, termination notice, security advisory. Operator does not use the account email for marketing communication, does not enrol the address in a marketing list, and does not transfer the address to a third-party marketing processor.

2.2 Billing data

The asset selected for the Order, the operator-rotated receiving address generated by BTCPay Self-Host, the on-chain transaction hash recorded by BTCPay Self-Host on confirmation, and the cycle selected at Order time. Operator does not collect a payment-card number, a bank account number, a clearing identifier, or any other fiat-rail credential — fiat is not in the payment loop per the Terms section 5.

2.3 Signup IP

The source IP recorded by the operator-side web server at the moment Customer submits the /signup form. The signup IP is retained for the operator-disclosed retention window in section 4 and is used for the operator-side anti-abuse review surface only.

2.4 Configurable access logs

The operator-side web server emits access logs for the operator’s own infrastructure; the Service environment Customer rents is fully Customer-controlled, and Operator does not collect access logs from inside the Customer environment. The operator-side access log retention is configurable at the operator-disclosed defaults — current default is the minimal-retention configuration, which retains only the operator’s own infrastructure access logs for the operator-disclosed window in section 4.

2.5 Support correspondence

Email correspondence between Customer and the operator-side support, abuse, and legal aliases. Correspondence is retained for the operator-disclosed retention window in section 4. Operator does not analyse correspondence content for marketing-segmentation, lead-scoring, or product-recommendation purposes.

3. Data Operator does not collect

The data set below is enumerated explicitly because the absence of these fields is a brand-defining posture, not a passive consequence of the data-minimisation default. Operator does not collect: a customer-side identity document scan; a customer-side residence-address verification; a customer-side phone number for verification; a customer-side biometric primitive; a customer-side device fingerprint produced by a tracking SDK.

Operator does not embed third-party analytics on the BulletHost site. Specifically: no Google Analytics tag, no Google Tag Manager container, no Facebook Pixel, no Hotjar session-replay, no FullStory session-replay, no Mixpanel event-stream, no Segment customer-data-platform handoff, no Amplitude product-analytics SDK, no third-party A/B-testing tag, no third-party advertising-network conversion pixel.

Operator runs a self-hosted Plausible analytics instance for aggregate page-view counting. The Plausible instance is hosted on Operator-procured infrastructure within the operator’s home jurisdiction; data does not transit a third-party processor. Plausible’s no-cookie posture is the operator-disclosed default; the Plausible domain is operator-distinct from the BulletHost site domain so the analytics flow is auditable from the public-observable surface.

4. Retention windows

The retention window for each data class is operator-disclosed below. The default posture is minimum-feasible retention consistent with operational integrity; counsel finalises every retention window before deploy.

Account email and billing data are retained for the operator-disclosed accounting window — pre-launch placeholder pending counsel’s confirmation of the mandatory accounting-record retention period under the operator’s home jurisdiction. Signup IP is retained for the operator-disclosed anti-abuse window — pre-launch placeholder pending counsel’s confirmation of the operationally appropriate window. Operator-side access logs are retained for the operator-disclosed default window — pre-launch placeholder. Support correspondence is retained for the operator-disclosed support-context window — pre-launch placeholder. All windows are configurable downward by Customer through the /cabinet privacy settings post-launch.

On termination of the Service per the Terms section 9, Customer data is retained for the operator-disclosed post-termination window — pre-launch placeholder — then destroyed. Destruction is operator-side; Operator does not transfer terminated-Customer data to a third-party archive.

5. Third-party processors Operator invokes

The third-party processor inventory below is exhaustive at the placeholder layer. Each processor is named, the data class transmitted is identified, and the processor’s role is described. Counsel finalises the processor list and the data-processing-agreement reference for each processor before deploy.

BTCPay Self-Host: invoked for invoice generation and on-chain confirmation tracking. Data class transmitted: the operator-rotated receiving address, the asset selected, the on-chain transaction hash. BTCPay Self-Host is hosted on Operator-procured infrastructure; the processor is operator-side from the Customer’s perspective. Counsel finalises the BTCPay Self-Host processor designation before deploy.

SMTP relay: invoked for transactional email delivery. Data class transmitted: the account email, the email subject and body of the transactional message. The relay is operator-disclosed in the operator footer and the relay’s PTR / SPF / DKIM / DMARC are operator-controlled. Counsel finalises the relay’s data-processing-agreement reference before deploy.

Operator does not invoke a third-party processor outside the inventory above. Specifically, Operator does not invoke: a third-party customer-relationship-management platform, a third-party email-marketing platform, a third-party customer-data-platform, a third-party fraud-scoring service, a third-party identity-verification service.

6. Customer-side rights

Customer has the rights set out in this section in respect of the Customer data Operator holds. The rights are recognised regardless of whether GDPR applies by territorial scope to the Service Customer rents, on the basis of operator-side voluntary policy.

Article 15 GDPR — right of access. Customer requests a copy of the Customer data Operator holds by emailing the legal@ alias listed in the operator footer. Operator responds within the operator-disclosed response window — pre-launch placeholder pending counsel’s confirmation of the appropriate window.

Article 16 GDPR — right to rectification. Customer corrects inaccurate Customer data through the /cabinet profile or by emailing the legal@ alias.

Article 17 GDPR — right to erasure. Customer requests destruction of Customer data Operator holds by emailing the legal@ alias. Erasure is constrained by the mandatory retention windows in section 4; data subject to a mandatory accounting-record retention is not destroyed before the retention window closes.

Article 18 GDPR — right to restriction of processing. Customer restricts the operator-side processing of specified Customer data by emailing the legal@ alias. Restriction is implemented as the suspension of any processing not strictly necessary to fulfil the Service Order.

Article 20 GDPR — right to data portability. Customer requests an export of the Customer data Operator holds in a structured, commonly-used, machine-readable format by emailing the legal@ alias. The export format is operator-disclosed in the response.

Article 21 GDPR — right to object. Customer objects to the operator-side processing of specified Customer data by emailing the legal@ alias. Operator reviews the objection and either restricts the processing per Article 18, destroys the data per Article 17 (subject to the retention constraints in section 4), or responds with the operator-side reasoning for continuing the processing.

Article 22 GDPR — right to non-subject to automated decision-making. Operator does not invoke automated decision-making in the Customer-Operator relationship. Suspension and termination decisions under the AUP are made by an operator-side human reviewer; the Article 22 right is therefore exercised by default.

7. Children and minors

The Service is not directed at minors. Customer warrants on Order placement that Customer is of the age of legal capacity in Customer’s residence jurisdiction. Operator does not knowingly collect data from a Customer below the age of legal capacity; on confirmation that a /signup originated from a minor, the corresponding account is destroyed under section 4.

8. Security posture

Operator applies the operator-disclosed security posture to the data classes inventoried in section 2 — encryption at rest for the operator-side database, encryption in transit for transactional email and the operator-side web surface, role-based access control on the operator-side administrative surface, and the operator-disclosed audit logging on the administrative surface. Counsel finalises the security-posture disclosure before deploy.