What happens if you can't trust us
Most vendor-trust pages ask you to believe a company. This one is the opposite: it explains why the proof you get from Oreoasis keeps working when we're not in the picture — if we go down, if we go away, or if you simply stop believing us. Everything below is checkable, and where something isn't built yet, it says so.
Continuity — the answer to "what if you disappear?"
We're a small operation selling multi-year retention. That deserves a straight answer rather than a confidence trick, and the architecture already contains one:
- Your receipts verify offline, forever, without us. We run this as an acceptance test, not a slogan: an exported bundle, checked by a standalone verifier under plain Node, with no call to any Oreoasis service — DSSE signature, signer, hash chain, and anchor binding all pass, and a single tampered byte makes it fail.
- You can export everything, any time. No exit fee, no export ticket, no format we invented to keep you. The bundle is a DSSE envelope set — open, documented, and boring on purpose.
- The verifier and the format are already public. Verification runs on
@kashscript/attest, a published, permissively-licensed npm package. You don't need our permission — or our continued existence — to check a receipt. We will never close that in response to a competitor; openness is the point, not a concession. - Anchoring writes to logs we don't own. Chain tips are witnessed on Sigstore's Rekor (per-receipt, paid plans) or OpenTimestamps (batched, free) — public logs whose contents outlive us. Every verify page shows a receipt's true anchor state, including "pending"; we never display a witness we don't have. On the free tier, anchors confirm in batches — typically within hours — and a receipt's signature and chain link verify immediately, without waiting on the anchor.
- Bus factor, stated honestly. Oreoasis is run by one person. A dead-man credential arrangement — a named individual able to reach the domain, the keys, and this service if the founder can't — is being put in place before the first paid customer. Until it is, your continuity does not depend on it, because of the four points above.
That is the differentiator we'd rather be judged on: a venture-backed competitor can copy the product, but it cannot honestly promise that its receipts survive its own shutdown unless it gives away the same verifier and anchors to the same public logs.
Erasure, against a log nobody can erase
Public transparency logs cannot be rewritten — that's their whole value, and it's in obvious tension with a right to erasure. The design resolves it rather than dodging it:
- Payloads are deletable. The receipt contents we store and display go on request.
- Hashes are immutable. They stay, so the chain and everyone else's receipts keep verifying.
- Anchored fields are personal-data-free by construction. What reaches a public log is a hash of a hash chain — never a payload, never an email, never a name. The SDK hashes content in your process precisely so this stays true.
The full statement, including who is controller and who is processor, is on the privacy page. We'll sign a DPA on request.
Sub-processors
Everyone who can touch data on our behalf, and what they see. Status is stated as it actually is — "on approval" means the rail isn't live yet, "not yet contracted" means we haven't signed the provider and will name them here the day we do.
| Sub-processor | What for | What they see | Status |
|---|---|---|---|
| Resend | Transactional email (sign-in links, account notices) | Email address, message content | in use |
| Paddle | Merchant of Record — payments, invoicing, sales tax/VAT | Billing details you give Paddle at checkout | on approval |
| Dodo Payments | Merchant of Record (secondary rail) | Billing details you give Dodo at checkout | on approval |
| Sigstore (Rekor) | Public transparency log — anchoring receipt chain tips | Hashes only. No payloads, no personal data — by construction | in use |
| OpenTimestamps | Public timestamping — batched anchoring on the free tier | Hashes only. No payloads, no personal data — by construction | in use |
| Anthropic | Model calls for the Done-for-you tier only — never for self-serve receipts | Work items, after the redaction pass strips personal data before the call | in use |
| Hosting + managed Postgres | Running the service and storing your account, keys, and receipts | Everything under 'What we hold' | not yet contracted |
We'll email account holders before adding a sub-processor that can see customer data.
Standards we build to
Every receipt is a DSSE envelope with a registered payload type. Nothing bespoke.
Signing happens in your process with your key; canonicalization is deterministic so anyone can re-derive the bytes we signed.
Chain tips are witnessed on a public transparency log — per-receipt on paid plans, batched on free.
Agent tokens follow the MCP authorization profile; agent identity binds to a human owner.
Agents and organizations are identified by DIDs that self-certify — the holder keeps the key, we never custody an agent's key.
The Done-for-you tier's Work Certificate is structured to AIUC-1's control domains.
Self-assessed. These are the standards we build to, not certifications we hold — no third party has audited or certified Oreoasis, and we will say so plainly until one has.
What we haven't done yet
The list a buyer would otherwise have to extract from us:
- No SOC 2, no ISO 27001, no third-party audit. We hold nothing, and won't imply we do.
- No uptime SLA on the self-serve tiers. Your exported proof doesn't depend on our uptime, which is the mitigation we actually believe in.
- No cloud KMS yet. Organization signing keys are envelope-encrypted at rest, under a master key held in the platform secret store rather than the database, and every custody operation is written to an append-only log. Moving that master key into a managed KMS happens when the hosting provider is contracted.
- No rehearsed incident drill yet. The key-compromise procedure and the quarterly backup-restore drill are written; neither has been run for real. We'll say so until they have.
- Zero customers. We're pre-launch and the counters start at zero. You would be early, and early has a price.
Reaching a human
Security reports: /security.txt. Abuse and takedown: the takedown policy. Everything else, including vendor questionnaires and DPAs: founders@oreoasis.com.
Last reviewed 26 July 2026. Oreoasis is pre-launch. The free tier and the public verify pages run; paid checkout opens when Merchant-of-Record approval lands, and until then upgrading joins a waitlist.