Superseded — version 1.1 is not the text currently in force. It is published here because Section 14 of the Terms undertakes that every version we have published remains available. Records issued while this version was in force are governed by it.
The current text is at /legal/privacy/.
Privacy Policy
Status: v1.1, in force from 2026-09-03. Written by engineering from the running system and reviewed by outside counsel on 2026-09-03. Version 1.0 was published on 2026-08-28 without that review and remains available at burnledger.io/legal/, as Section 11 requires.
Version: 1.1 · Prepared: 2026-08-18 · Reviewed: 2026-09-03 · Effective: 2026-09-03
This describes personal data BurnLedger processes as a controller — account data, and data about how the service is used. Personal data we process on a customer's behalf, including data-subject identifiers, is governed by the Data Processing Agreement; the two overlap and Section 4 explains where.
Controller: ProChatFlow LLC, a Minnesota limited liability company formed on 25 April 2025 under Minn. Stat. ch. 322C, Minnesota Secretary of State file number 1558059000024, whose registered office is on file with the Minnesota Secretary of State. BurnLedger is a product of ProChatFlow LLC and is not a separate legal person; where this policy says "BurnLedger" it means the service. Contact: privacy@burnledger.io EU/UK representative: None appointed. Business decision, 2026-08-27: the Service is not offered to customers established in the EEA or the UK (Terms §2), so Art. 27 is not engaged. Whether marketing the Service on GDPR Article 17 compliance nonetheless amounts to offering services to data subjects in the Union is a question we have put to counsel; if the answer is yes we will appoint a representative and say so here. Data Protection Officer: None appointed. Our processing is not of the kind that requires one under Art. 37; privacy@burnledger.io reaches the person responsible.
1. What we collect, and why
| Data | Why | Basis |
|---|---|---|
| Account name and email | To create and administer your account, and to sign you in | Contract |
| Google account identifier, if you sign in with Google | Authentication | Contract |
| A per-customer random salt | To hash data-subject identifiers so we need not store them | Contract / legitimate interests |
| Connection configurations for your datastores, encrypted | To connect and run your queries | Contract |
| Certificates and attestations we issue for you | To provide the service, and because the records are the product | Contract / legal obligation |
| Audit and security logs, IP addresses, request metadata | Security, abuse prevention, debugging | Legitimate interests |
| Billing details, when payment is enabled | To take payment | Contract |
We do not use your data to train models, we do not sell it, and we run no advertising.
2. Data-subject identifiers — the part that needs stating precisely
To do its job, BurnLedger is given identifiers of your data subjects — an email address, a customer number. What happens to them:
- The raw identifier exists only in memory inside the enclave, for the duration of a query. It is not written to our database or our logs.
- What is stored is a SHA-256 hash of the identifier salted with your per-customer salt, inside the certificate.
- We store that salt, in our database, alongside the hash. Anyone with both can test a guessed identifier against the hash. We therefore treat the salted hash as personal data (pseudonymised, in the sense of GDPR Recital 26) and not as anonymous data, and we apply the protections in this policy to it.
We say this plainly because the alternative claim — "we never store identifiers" — is the kind of statement that reads well and does not survive a DPIA.
3. What is public, and what is not
BurnLedger publishes an append-only transparency log so that certificates cannot be issued or withdrawn silently. Each entry contains a certificate identifier, a hash, an entry type and a timestamp.
The log contains no data-subject identifiers, no salted hashes, no customer names and no data. A log entry reveals that a certificate with a given identifier exists and when. Certificate contents are served only to the customer who owns them, and to anyone that customer chooses to give the certificate to.
Because the log is append-only, entries cannot be removed. Section 7 explains what that means for erasure.
4. Controller and processor — where the line falls
- For your account data (Section 1), BurnLedger is a controller.
- For data-subject identifiers you send us and the records built from them, BurnLedger is a processor acting on your instructions. Your DPA governs that processing, and you are the controller.
If one of your data subjects contacts us directly, we will tell them to contact you, and tell you, unless you have instructed otherwise.
5. Who we share it with
Sub-processors, and everything they touch:
| Provider | Purpose | Location | What they can see |
|---|---|---|---|
| Amazon Web Services | Hosting, key management, enclave attestation | us-east-1 (United States) | Encrypted storage and compute. Datastore credentials are encrypted under a key released only to the measured enclave, so they are not readable by AWS support or by our own host |
| Google LLC | Sign-in with Google, where used; email hosting for our @burnledger.io addresses (Google Workspace) | United States | Account email and Google account identifier — and, because our mail is hosted there, the contents of any email you send to or receive from us, including your own address |
| Amazon Web Services (SES) | Outbound verification and notification email | us-east-1 (United States) | Account email and the contents of messages we send |
| Stripe, Inc. | Payment processing and subscription billing | United States | Billing contact, subscription state, and card data entered on Stripe's own hosted checkout page |
| ntfy.sh | Operator push notification that a signup, application, or contact message has arrived | Germany | That an event of a given kind occurred, and when. No names, no email addresses, no message contents — the notification carries a link to our own authenticated console, where the details are read |
Status of these rows as of 2026-08-28, stated precisely because the difference matters: email and operator notifications are live (email moved from a forwarding provider, ImprovMX, to Google Workspace on 2026-08-20; ImprovMX no longer receives any of our mail and has been removed from the list rather than left on it); outbound email is configured but not yet sending (the provider account is still sandboxed and the service has no SMTP credentials, so no verification mail is sent today); payment processing is integrated but running in test mode only, restricted to an allowlisted operator address, so no customer payment data has been processed. BurnLedger is the seller of record — Stripe's managed-payments mode is explicitly disabled — and card details are entered on Stripe's hosted page and never reach BurnLedger systems.
On the notification service, an issue this document previously flagged for counsel and which engineering has since closed: notifications used to carry the signup name, email address, and the full text of a trial application to a topic whose name was the only thing restricting access. That was an unauthenticated disclosure of personal data, and the retained history meant it could not be withdrawn. As of 2026-08-20 the payload carries no personal data at all — only the fact that an event occurred and a link into our own authenticated console. The service is retained in the list above because it still receives event metadata; counsel may take the view that a row carrying no personal data does not require customer-facing disclosure, in which case it can be dropped, but we would rather over-disclose than have a reader discover it elsewhere.
6. Where the data is, and transfers
All processing takes place in AWS us-east-1, in the United States. We do not contract with customers established in the EEA or the UK (Terms §2), so we do not make controller-to-processor transfers out of those territories.
This does not mean GDPR never applies to data we process. A customer established outside the EEA may still have data subjects inside it, and where it does, that customer is the controller subject to the GDPR and we are its processor handling EU personal data. The Standard Contractual Clauses in the DPA remain available and are the mechanism for that case; they are dormant rather than removed.
Business decision, 2026-08-27. Engineering note, unchanged and relevant to any transfer impact assessment: relocating processing to an EU region is possible but not trivial — Nitro Enclave availability and the KMS key policy are region-bound.
7. How long we keep it, and the erasure question we should answer honestly
| Data | Retention |
|---|---|
| Account data | For the life of the account, then deleted within 30 days of closure — except the audit rows described below and any certificates you have asked us to keep |
| Attestations that were never certified | Expire after 72 hours by default (you may set up to 7 days), then deleted 30 days after expiry by a daily job. The 30-day window exists so a failed run can be investigated; it is a support window, not a legal judgement, and we will shorten it if asked to |
| Attestations behind an issued certificate | Retained as long as the certificate, because they are the evidence it is verified against |
| Certificates, including their salted subject hash | For as long as your account exists, and after closure until you ask us to delete them — because they are evidence you or a third party may rely on. Deleting a certificate removes the salted hash and the record contents; the transparency-log entry remains but links to nothing once our backups have expired (60 days). See the paragraphs below |
| Transparency log entries | Permanently, by design |
| Audit and security logs | 24 months from the event, then deleted by a daily retention job; synthetic/internal test accounts 90 days. Enforced at the database layer: audit rows are append-only (no UPDATE, no DELETE outside the retention job) and cannot be deleted before a 90-day floor even by the job itself. On account erasure the audit trail is retained for its full term as a security and legal-obligation record (GDPR art. 17(3)(b)); it contains action names, timestamps, resource identifiers and request IP addresses, and we disclose that retention here rather than scrubbing the rows — deliberately, because a mutable audit log is not an audit log. |
| Backups | Nightly database backups replicated off-site since 2026-08-21, retained for 60 days, then expired automatically. A deletion becomes complete in our backups 60 days after it is made in the live system |
The tension, stated rather than hidden: a certificate is designed to be evidence that outlives us, and it contains a salted hash of a data subject's identifier. Deleting it on request destroys the evidence a customer may be relying on; keeping it retains pseudonymised personal data indefinitely.
Engineering's view of the mechanics, for counsel to build on: deleting the certificate record removes the salted hash and the certificate contents. The transparency log entry survives, but it holds only an opaque hash and an identifier, with no subject data in it — so erasure of the personal data is achievable without rewriting the log. That is a deliberate property of the design and not an accident.
8. Your rights
Where the law of your country gives you rights over your personal data — to access it, correct it, have it deleted, restrict or object to its processing, or receive a copy in a portable form — you exercise them by writing to privacy@burnledger.io from the email address on your account. We answer within 30 days, and we will tell you if a request cannot be met in full (for example because audit rows are retained, Section 7) and why. You may also complain to a supervisory authority or attorney general with jurisdiction over you. For requests about your customers' data subjects, see Section 4: we refer the data subject to you and assist you.
9. Security
Summary of what is actually true, for counsel to render in the appropriate register: datastore credentials are encrypted under a key released only to a measured AWS Nitro Enclave, so neither our host system nor our staff can read them; signing keys exist only inside that enclave; access to production is restricted and logged; the service enforces a verified-TLS floor on every datastore connection. We have not completed an independent penetration test or a SOC 2 examination, and we do not claim either.
10. Children
The Service is not directed to children and we do not knowingly collect their data.
11. Changes
We may change this policy. A material change is announced at least 30 days before it takes effect, by email to the account address and by publishing the new version, with its version number and effective date, at burnledger.io/legal/. Every version we have published remains available there.