Legal.
This page says exactly where BurnLedger's legal documents stand — including the ones that are not finished. We would rather publish an honest status than a polished document nobody has reviewed.
Last reviewed . The status lines on this page are re-checked against the running system whenever a subprocessor, a document's review state, or the operating company's details change.
Terms of Service, Privacy Policy, Data Processing Agreement
Status: version 1.3, in force from . All three documents were written by engineering from the running system, so their factual claims match what the Service actually does. They were reviewed by outside counsel on ; v1.1 and v1.2 carry that review, and v1.3 (2026-09-04) corrects the description of three behaviours without changing a term. A revised version is published here with a new version number and effective date, on the notice each document provides. Every version published stays available at this address — the superseded ones are linked below.
- Terms of Service — v1.3, effective 2026-09-04 · superseded: v1.2, v1.1, v1.0
- Privacy Policy — v1.3, effective 2026-09-04 · superseded: v1.2, v1.1, v1.0
- Data Processing Agreement — v1.3, effective 2026-09-04 · superseded: v1.2, v1.1, v1.0
Each version also has a permanent address of its own — /legal/terms/v1.3/ and so on — so a citation to the text in force today still resolves to that text after a later version supersedes it. Records issued while a version was in force are governed by that version.
Schedule A — Certificate Scope
Status: in force, incorporated into the Terms. Schedule A states what a deletion record asserts and what it does not, and Section 3 of the Terms makes your reliance on any record subject to it. It is written by engineering from the running system; outside counsel review of it is pending, and it says so on its face.
- Certificate Scope (Schedule A) — including section 1.1, the record-unit table: what one record means for each connector type, and why counts from different connector types do not add up.
The limitations block printed on every record cites section 1.1 by name, and from record format 7.0 that citation is inside the text the record commits to by SHA-256. This page is where it resolves.
What binds independently of these documents
Two things bind regardless of any version of the documents above, because they are printed on the product itself:
- The certificate scope statement. Every certificate PDF carries a Scope and Limitations block stating what was measured and what was not — including that BurnLedger does not perform deletions, does not audit whether a query captures every copy of a subject's data, and does not cover unregistered systems, backups, or replicas. The full statement, with the reasoning behind it, is in Certificate anatomy — what a certificate proves, and what it doesn't.
- The verification contract. Certificates verify offline against published keys and an append-only transparency log. That property does not depend on these pages, on this company's continued operation, or on anything you have to take on trust.
Subprocessors
Providers that touch service data today, disclosed in full:
| Provider | Purpose | Location | What they can see |
|---|---|---|---|
| Amazon Web Services, Inc. | 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 systems. |
| Google LLC | Sign-in with Google; email hosting for our @burnledger.io addresses (Google Workspace) | United States | Account email and Google account identifier — and, since we host our mail there, the contents of any email you send to or receive from us, including your own address. |
| Amazon Web Services, Inc. (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 — card details never reach BurnLedger systems. |
| 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. |
Status of these rows, stated precisely because the difference matters. Hosting, sign-in, email, and operator notifications are live. Email moved to Google Workspace on 2026-08-20; the forwarding provider previously listed here (ImprovMX) no longer receives any of our mail and has been removed rather than left on the list. Outbound email is configured but not yet sending — the provider account is still sandboxed and the service holds no SMTP credentials, so no verification mail is sent today. Payment processing is integrated but runs 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.
One correction worth stating rather than quietly fixing: until 2026-08-20 the operator notification carried the account name, email address, and full application text to a topic whose name was the only thing restricting access. That payload now carries no personal data at all — only that an event occurred, plus a link into our own authenticated console. The row stays listed because the service still receives event metadata.
The Verifiable Deletion Addendum
Separately from our own terms, we publish free contract language a controller can drop into a Data Processing Agreement to require deletion evidence they can verify themselves rather than a letter asserting deletion happened. It names no supplier, requires no attribution, and is dedicated to the public domain under CC0 — including for use against us. Read it at burnledger.io/addendum.
Security reports
The coordinated-disclosure policy, with response timelines, scope, and safe harbour, is published at burnledger.io/security, and in machine-readable form at /.well-known/security.txt. Report privately to security@burnledger.io — acknowledged within two business days.
Reaching us about anything else
Contracts, DPAs, and anything for counsel: legal@burnledger.io. Data protection requests about your own personal data: privacy@burnledger.io. Commercial questions, or a written channel that isn't a mailbox: burnledger.io/contact. Account holders can also reach us through the dashboard.
The operating company
BurnLedger is a product of ProChatFlow LLC, a Minnesota limited liability company formed on 25 April 2025 under Minn. Stat. ch. 322C, active and in good standing. Its Minnesota Secretary of State file number is 1558059000024. Every fact in this paragraph, including the registered office we have not reprinted here, is a matter of public record and can be checked against the Minnesota business register rather than taken from us. Write to us at legal@burnledger.io; a postal address for formal notice is in the Terms of Service.
The contracting party is the company, not the product. ProChatFlow LLC is named as the party in the Terms of Service and the Data Processing Agreement, it is the seller of record, and it is the name on invoices and bank records. “BurnLedger” is what the service is called; it is not a separate legal person, and nothing is signed or billed under it. If you are checking us against a register or reconciling a payment, ProChatFlow LLC is the name to look for.
None of the above is load-bearing for a certificate. Records issued before, during, or after any change to the company remain verifiable independently of it — verification is arithmetic against published keys, not trust in a company.