The agreement, in the same register as the rest of this site.

An account is a username and a password. There is no email field, no phone number field, and no column in the database behind either — users.email was dropped from the schema outright. You are responsible for the credentials and for what is done with them.

You must be old enough to enter a contract where you live. One person may hold more than one account; we do not attempt to detect that and hold nothing that would let us.

It buys the operational half of this product: a hosted instance somebody keeps patched, running and backed up, the storage and seat limits published on the pricing page, push delivery, a call relay, and — on the paid tiers — a named commitment about who answers you and how fast. What that commitment actually is, and is not, has its own page.

It does not buy a different security model. The cryptography is the same code at every tier including the free one, no plan lets anybody here read or unlock anything, and no plan reduces the metadata the server keeps. It has not been through a professional security audit; we say so on every page of this site and we will keep saying so until one has happened.

Every limit in the catalogue is the limit the server enforces, with one exception that is marked as such in the comparison table: support is a promise about people rather than a check in the code.

• Prices are in US dollars and exclusive of any tax we are obliged to collect. The catalogue on this site and the price the server charges are the same object; there is no second price list.
• A monthly plan is billed monthly in advance. A yearly plan is one payment covering twelve months, in advance.
• Team and Business bill from a minimum of 3 seats and Enterprise from 50. A two-person team on Team pays for three. That is what a seat minimum is.
• There are two ways to pay: a card, through Stripe's own hosted checkout; or a prepaid voucher code. Enterprise is quoted and can be invoiced.
• Card details never reach this server. You type them into a page Stripe serves from Stripe's origin, and no card number, expiry or security code reaches us at any point. What does reach us is Stripe's notification about the payment, stored verbatim so its signature stays checkable — and for a card payment that carries the email address you gave Stripe, and depending on what it asked for your name, postal address and the card's last four digits. We cannot send anything to that address. A voucher-paid plan leaves none of it.
• An instance with no payment processor configured cannot take a card at all. The site asks the server which it is and does not offer a button that would fail.

• A failed payment puts the subscription past due. Free limits apply to new activity — uploads over the free quota are refused — and nothing is deleted.
• Cancelling takes effect at the end of the period you have already paid for. You keep the plan until then, and afterwards free limits apply. Nothing is deleted. You cancel from the account page in the app, and on a card subscription that instruction is sent to the payment provider and confirmed by it before anything is written on your account — so the cancellation is real at the processor and not merely displayed here. If the provider cannot be reached, nothing is changed at all: your plan, your bill and your renewal date stay exactly as they were, and the app says the provider did not answer rather than showing a cancellation that did not happen. Stripe's own billing portal is the other route, with the caveat that the link into it is created by our server over the same connection, so an outage which reaches us can take that link with it; what happens inside the portal is Stripe's and nothing on our side touches it.
• Moving a card subscription to the free plan is a cancellation, and is handled as one. There is no free price for a card subscription to switch onto, so that request is refused in the app with a sentence pointing at the control that ends the plan at the close of the period you have paid for. The same is true of any other change to what you are billed: a plan, interval or seat change on a card subscription either reaches the payment provider or it does not happen, and it is never applied here alone.
• Deleting your account ends the subscription too, and ends it today rather than at the close of the period. The cancellation is made at the payment provider and confirmed before a single row is deleted, because deleting the account destroys the only handles we hold for that subscription — a card that was not stopped first could never be stopped by us afterwards. If the provider cannot be reached, the deletion is refused and nothing is changed: the account, the plan and the card stay exactly as they were. The unused remainder of a paid period is not returned automatically; it is a refund question and the refunds page says how one is made.
• And the state in between, stated rather than left out. The cancellation at the payment provider is immediate and cannot be undone, while the deletion that follows it runs against a database which can, rarely, refuse — a lock held by another process, a full disk. Every reason the deletion could be refused for is settled before anything is cancelled, so an ordinary refusal changes nothing. But if the cancellation succeeds and the deletion then fails, your subscription is cancelled and your account is still here, and that state is recorded rather than left quiet: the subscription row is marked cancelled, your security log gets an entry saying so, and the billing ledger gets one that carries no link to your account and therefore outlives it. The cancellation is not undone, and the remainder of the period you had already paid for is not returned. Deleting again is safe and cancels nothing twice.
• The retention sweep deliberately skips past-due and cancelled subscriptions. A paid plan's history is not swept because a card bounced or a customer left. The sweep resolves its window from the stored plan and refuses to treat a lapsed paid plan as a free one — that mapping was removed from the code on purpose, because it had been deleting paid customers' history.
• Choosing the free plan yourself is different, and how it takes effect depends on how the plan is paid. On a card subscription, choosing Free is the cancellation described above: it is refused in the app with a pointer to the control that ends the plan, the plan runs to the end of the period you have paid for, and a cancelled paid plan is not treated as Free by the retention sweep. On a plan that is not paid by card — a voucher or a grant — choosing Free applies from the moment you choose it and accepts Free's 90-day window: after that the server deletes its copy of a message. Either way that window is a cost limit, and it cannot reach a device that already synced the plaintext.
• Being moved onto Free by somebody else — removed from a shared plan by its owner, or re-homed because that owner deleted their account — stamps a floor into your subscription that permanently exempts everything written before that moment from any plan-level deletion window. You are not made to pay for somebody else's decision with your history.
• Being over quota means no new uploads until you delete something or resubscribe. It never means we reclaim the difference.
• Subscription fees are not refundable for part of a billing period, except within the 14-day cooling-off window after a payment, which the refunds page describes and the app offers as one action. When you move to a smaller plan, the change applies either at the end of the billing cycle or at once with any prorated unused balance applied as a credit toward future invoices. Haven does the second, and on a card subscription that change either reaches the payment provider or it does not happen — it is never applied here alone. You are billed at the lower price from that moment, and the difference for the rest of the period is settled on your next invoice.
• Moving to a larger plan, more seats or a different billing interval on a card subscription is done from the account page in the app, which shows the new price and asks you to confirm before anything is sent. The difference is then charged to the card already on the subscription at once, less the unused part of the period you have paid for, and the new plan starts only when that payment has gone through. If your bank asks you to confirm the payment, you finish it on the payment provider's own page; until it is paid you keep your current plan, and if it is never paid you simply stay on it. It is never applied to a card without that confirmation.

• Do not use the service to commit a crime against another person — the fact that we cannot read a message is not permission and is not a defence.
• Do not attack the instance: no attempt to exceed a limit by evading it, no automated account creation, no flooding, no attempt to reach another account's data.
• Do not resell seats as your own service. Enterprise exists for arrangements of that shape and is quoted.
• Do report a vulnerability rather than exploiting it. security.txt is the route, and a report made in good faith will not be answered with a lawyer.

We comply with valid legal process. Saying otherwise would be a promise nobody can keep. What matters is what compliance can actually produce, so here is the list rather than the posture: message ciphertext; every conversation key we hold, wrapped to a participant and useless without a password we do not have; the participants table, which is the complete social graph; message timestamps to the second; attachment sizes in bytes; sign-in times; last-seen times except on accounts that hide presence, where the column is empty; usernames, including those of deleted accounts wherever an administrator acted on one; the TOTP secret of any account with two-factor turned on — encrypted at rest under a key held outside the database, and still producible by us because we hold that key; a coarse device label per session unless the account asked for it to be withheld; and per message, two signatures — one over its contents and one over its position in the conversation.

Not message content or filenames, because we have no way to get at them. Group names: only for groups created since group names were sealed. A group made before that still holds a readable name in the database, and we could be compelled to produce it.

An email address, if you have ever paid by card. There is no email column on your account — that column was dropped and nothing rebuilt it. But the payment processor's notifications are stored here exactly as they arrive, so that each one can still be checked against the signature it came with, and for a card payment those notifications contain what you gave the processor on its own page: in practice your email address, and depending on what it asked for, your name and postal address and the last four digits of the card. We have no way to send anything to that address and we hold it anyway. A free account and a voucher-paid account leave no such record.

A preservation order — a legal hold — can make us stop deleting. If a court or other lawful authority orders us to preserve an account or a conversation, we place a hold on it, and while the hold is in force nothing it covers is destroyed: not by retention windows, disappearing messages, your own deletions or edits (the overwritten version is kept), the retirement of old conversation keys, or deleting your account. If a held account is deleted or leaves a group, the hold carries onto its conversations. What is kept is what we always held — ciphertext and wrapped keys we cannot open — so a hold can make us keep your messages but not produce what they say. A hold is placed only by a named person, from the server's own command line, against a case reference, and is recorded in a register that is never edited; when it is lifted, deletion carries on as if it had not been there. The app does not tell you a hold exists, because telling you would disclose the order. The canary page says more.

Where we are permitted to tell you about a demand, we will. Where we are not, we will not be able to, and the warrant canary is the only instrument we have for that — read what its absence would and would not mean before relying on it, because it is less than people assume.

The demand this design does not defeat is not "hand over the messages". It is "hand over who this account talks to, and when", which we can satisfy completely. The threat model states it in both columns.

Our aggregate liability to you is limited to the amount you paid us in the twelve months before the claim. We are not liable for indirect or consequential loss, for lost data where the loss follows from a property of the design that this site documents, or for anything arising from a device you control being compromised.

A solicitor has to write this clause properly. Consumer law in most jurisdictions limits how far a liability cap can go, and nothing here is intended to exclude liability that cannot lawfully be excluded — including for death, personal injury or fraud. The wording above states the intent; it is not yet the wording that would be relied on.

Governing law and jurisdiction are deliberately blank. They depend on where the operator of this instance is established and where its customers are, and inventing a jurisdiction here would be worse than leaving the gap visible. This is the first clause a solicitor must complete, together with the consumer-law carve-outs in clause 8 and the international-transfer terms in the data processing addendum. Until then, treat this document as a statement of how we intend to behave, which is the part we can actually vouch for.