VerifiableTrust you can check, not only read.
Trustvice exists to issue signed facts that other people rely on. This page sets out how that works, what we protect and how, where your data lives and what we commit to. Each statement links to the document that binds it.
Operated by Avonao, Inc., DelawareLegal documents last updated November 6, 2026
How a receipt is made.
Every call follows the same path. Credentials are checked at the front door, the work is done and stored in the workspace's own region, and Trustvice signs the receipt with an AWS KMS key held in that region.
- Authenticate
The front door resolves the credential to one workspace before any suite code runs. Secrets are stored and compared as SHA-256 hashes, in constant time.
- Forward
The workspace and permissions travel to the regional service in headers signed by our own services. Without a valid signature, the service refuses the request.
- Observe or record
The regional service does the work the suite was asked for and records the facts the receipt will cover.
- Sign
Trustvice signs the receipt over the artifact's hash with its Ed25519 key in AWS KMS, in the receipt's data region; the private key never leaves KMS. Until the signature exists, the artifact shows Receipt pending, never an unsigned receipt.
- Verify anywhere
The receipt holds its key id inside the signed bytes. Anyone with the receipt and the public key can check it without us, for as long as the key stays published.
What a receipt proves, and what it does not.
A receipt is a precise, narrow statement. Read both columns before you rely on one, and before you ask someone else to.
A valid signature proves
- Origin: a Trustvice signing key signed exactly these bytes.
- Integrity: nothing in the envelope has changed since, down to one digit.
- A signed time: Trustvice's clock read issuedAt when it signed.
It does not prove
- That a fact you reported is true. Some suites sign facts the caller supplies, others what we observed; each suite's page says which.
- Who authored or approved the content. The receipt records a workspace, not a person.
- The real time of an event. There is no third-party timestamp authority.
- That nothing happened where there is no receipt.
- That we are neutral beyond our word. Trustvice signs with its own keys and keeps its own write-once copy; no outside party checks what a receipt says.
What you still trust us for
Verification is independent. Trust is narrowed to a short, named list.
| You trust | Why | If it fails |
|---|---|---|
| The public key you verify against is ours | A signature proves who holds a key, not whose key it is. | A substituted key makes forgeries look valid. Pin the key id out of band. |
| Trustvice's signing keys are used only by its receipt service | The service signs what its code decides to sign. | A misused key could sign events that never happened. |
| We observe honestly for the observed features | Those receipts say Trustvice saw this. | A compromised Trustvice could sign a false observation. |
| Our clock | issuedAt is our server time at signing. | A skewed clock gives a wrong issuedAt. |
Signing keys and where to find them
Each receipt is signed with Ed25519 by an AWS KMS key that Trustvice holds in the receipt's data region, one key per region. Trustvice publishes the public halves as its own key set.
Custody
- Trustvice issues, signs and stores its receipts itself. The private key never leaves KMS, and the Worker holds only a sign-only credential.
- No API route returns private key material. Public routes return public fields only.
- If KMS is unavailable, the receipt waits as Receipt pending and is retried every five minutes. An unsigned receipt is never shown, and there is no local-key fallback.
Stated limits
- Rotation is a manual ceremony, not a schedule. A retired key stays published so old receipts keep verifying.
- Every hour Trustvice writes the signed receipt hashes of the closed hours, with a Merkle root signed by the region's KMS key, as one object in an Amazon S3 Object Lock bucket in COMPLIANCE mode, in the same region. Nobody, the AWS root user included, can alter or delete it before its lock date. It is Trustvice's own bucket and key: it narrows what Trustvice could do quietly, but it is not an independent witness.
- A signing key cannot stop whoever can run the signing service from causing it to sign, which is why observed and reported facts are kept apart.
Published key locations
| Address | Content |
|---|---|
https://trustvice.com/.well-known/receipt-keys.json | Trustvice's JWK set: https://trustvice.com/.well-known/receipt-keys.json |
https://api.trustvice.com/v1/receipts/keys | The same key set from the API: https://api.trustvice.com/v1/receipts/keys |
curl -sSL https://trustvice.com/.well-known/receipt-keys.json
// kid = RFC 7638 thumbprint of the key
const raw = Uint8Array.from(atob(x.replace(/-/g, "+").replace(/_/g, "/")
.padEnd(Math.ceil(x.length / 4) * 4, "=")), (c) => c.charCodeAt(0));
const digest = new Uint8Array(await crypto.subtle.digest("SHA-256", raw)).slice(0, 16);
const kid = btoa(String.fromCharCode(...digest))
.replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");For the strongest position, fetch the key once, store its kid and x value in your own repository, and verify against that copy. /legal/verification
Access control and isolation
Every request carries a credential that the gateway resolves to one workspace before any suite runs. What follows is how credentials and tenancy are handled today.
Hashed credentials
API keys, personal access tokens and session tokens are stored as SHA-256 hashes, shown once and compared in constant time. Keys expire after 30 days, 90 days, a year or never, and rotate with a grace period of 0 to 60 minutes.
Sign-in and sessions
Sign-in only through your Avonao ID; Trustvice holds no passwords, passkeys or authenticator secrets. Sessions are HttpOnly, Secure and SameSite=Lax, with a 12-hour lifetime and a 30-minute idle timeout.
Scopes and roles
Read, write and manage scopes, narrowed to named suites if you choose. Checks fail closed.
Tenancy
The gateway, not the caller, decides the workspace. Every read and write carries the workspace id, and a body naming another workspace is refused. Separation is logical, in a regional database.
Rate limits and abuse
600 requests a minute per IP and 1,200 per account at the gateway.
Stated limit: IP allow-lists fail open if they cannot be read, so a database fault cannot lock customers out.
Data protection
The service is designed to hold as little as it can.
Append-only receipts
Each receipt is stored next to the artifact it belongs to for your plan's window. A hashes-only copy goes into a write-once Object Lock bucket in the same region. Only audited routes can redact or delete, and each writes an audit event.
Readable fields are readable
Readable fields, such as URLs and labels, are in clear text in a receipt. Put nothing there you would not show its reader.
Data regions
Receipts and quota counters are kept in the region chosen when the workspace is created. Each receipt is signed with that region's own AWS KMS key and its hash is locked in that region's Object Lock bucket. The dashboard, website, sign-in, billing and account data are served from the United States (US West) in every case.
| Region | Code | Paired AWS region | Storage |
|---|---|---|---|
| US East | enam | us-east-1 | Location hint |
| US West | wnam | us-west-2 | Location hint |
| Europe Central | weur-1 | eu-central-1 | EU jurisdiction (enforced) |
| Europe West | weur-2 | eu-west-1 | EU jurisdiction (enforced) |
| Europe North | neur | eu-north-1 | EU jurisdiction (enforced) |
| Asia-Pacific | apac | ap-southeast-1 | Location hint |
| Oceania | oc | ap-southeast-2 | Location hint |
A region says where data is stored and processed. A workspace never moves, and a region that cannot be reached fails the call rather than fall back to another.
Encryption
Data is transmitted over TLS between you and the service, and stored with our infrastructure provider, Cloudflare, under its security terms. Receipts are signed, so any change to stored evidence is detectable by anyone who verifies it.
Deletion and erasure
Account deletion takes effect after a 30-day grace period in which you can export and restore. Receipts are not removed by the deletion job; they age out under the plan window, or you delete them, or you ask us. The hash of a deleted receipt stays in the write-once copy until its lock date. A receipt you already handed to someone stays verifiable by them whatever we do.
Retention
- Receipts
- The plan window: Free 7 days, Starter 90, Pro 90, Pro+ 90, Team 180, Scale 365, Enterprise custom. The write-once copy of the hash stays locked 12 hours longer; a plan with no automatic deletion is locked 7 years.
- Account and sign-in data
- Until the account is deleted, then erased after a 30-day grace period.
- Operational logs and rate-limit counters
- 30 days at most.
- Security audit log
- For the life of the workspace and after, with the subject replaced where erasure is required.
- Billing records
- As long as tax law requires, up to 7 years.
- Idempotency replay cache
- 24 hours, with the status and receipt id, never the body.
Privacy PolicyData regionsRetention and erasureSub-processors
Availability
Status is measured, not written by hand. Service levels are a contract term for Enterprise customers, and verification never depends on us being up.
Public status page
- Probed every five minutes: the API gateway in each of the seven data regions, the MCP server, OAuth discovery and receipt verification. Receipt issuance (a test receipt issued by Trustvice and stored) is added once its dedicated probe workspace is configured; until then it is not measured.
- A check that fails or takes more than 8 seconds is down; one slower than 3 seconds is degraded. A stale monitor shows no recent data, never green.
- Incidents are posted with updates, by email subscription, Atom feed and JSON.
- The status page is not signed and is not a service-level agreement.
Enterprise SLA
For Enterprise plans with a signed order form. Covers the REST API, the MCP server and receipt issuance. Support is staffed during business hours and acknowledges every Enterprise request within 1 business hour. Self-serve plans carry no uptime commitment, service credits or support response time.
| Monthly uptime | Service credit |
|---|---|
| Below 99.9%, at least 99.0% | 10% of the monthly fee |
| Below 99.0%, at least 95.0% | 25% of the monthly fee |
| Below 95.0% | 50% of the monthly fee |
| Severity | Meaning | Acknowledgement target |
|---|---|---|
| Severity 1 | Covered service unavailable, or receipts cannot be issued, for production use. | 1 business hour |
| Severity 2 | A major feature impaired or degraded, with a workaround. | 1 business hour |
| Severity 3 | A minor problem, question or request. | 1 business hour |
If uptime is below 99.0% in three consecutive months, or in any four of twelve, the customer may terminate the affected order with a pro-rata refund.
Verifying a receipt needs only the receipt and a public key. It keeps working when our service does not.
Incident response and vulnerability disclosure
What we commit to when something goes wrong, and how to tell us about a weakness before anyone else finds it.
Personal data breaches
We notify the account owner by email without undue delay and in any case within 72 hours of becoming aware of a breach affecting customer personal data, with what is known: its nature, the people and records affected, the likely consequences and the measures taken. The notice is supplemented as we learn more.
Service incidents
Incidents are published on the status page with a timeline from Investigating to Resolved. During a Severity 1 incident, Enterprise customers get an initial notice and updates as the situation changes.
Responsible disclosure
Report through the form, with your contact details or anonymously, or by email. Good-faith research under the policy is authorised, and we will not take action against you for it.
| Step | Target |
|---|---|
| Acknowledge your report | Within 3 business days |
| Initial assessment and severity | Within 10 business days |
| Updates while the issue is open | At least every 14 days |
| Fix for critical and high severity | We aim for 30 days |
| Fix for lower severity | We aim for 90 days |
Targets, not guarantees. We ask for 90 days before public disclosure. There is no monetary bug bounty; we credit researchers by name on request.
Compliance posture
What exists today and what is available on request. If a row matters to your review, the linked document is the binding text.
| Item | State | Detail |
|---|---|---|
| Data Processing Addendum | In place | Part of the Terms. Applies automatically on acceptance; no countersignature is needed. |
| International transfers | In place | EU Standard Contractual Clauses (2021/914, Modules Two and Three), the UK Addendum and the Swiss adaptation, incorporated in the DPA. |
| Article 27 representatives | In place | Named representatives in the European Union and the United Kingdom, listed in the Privacy Policy and the Imprint. |
| Sub-processor changes | In place | At least 30 days' notice by email and on the list, with a right to object and to terminate with a refund. |
| Privacy rights requests | In place | Receipt confirmed within 10 days; answered within one month under GDPR and UK GDPR, or 45 days under US state laws. |
| Security pack | In place | An architecture and security whitepaper and a pre-filled security questionnaire, to read online or download. |
| Security questionnaire | On request | Written answers to a reasonable questionnaire within 30 days, under DPA §9. |
| Customer audit | On request | Where documentation is not enough: once a year, on 30 days' notice, by an independent auditor bound by confidentiality, at the customer's cost. |
| Sub-processor compliance reports | On request | Our providers' public compliance reports, where we are entitled to share them. |
| Bug bounty | Not offered | No monetary rewards. Researchers are credited on request. |
Legal documents
Every document that governs the service, with the date of its current version. Material changes to the Terms, the Privacy Policy, the DPA and the Acceptable Use Policy are announced to account owners at least 30 days ahead.
| Document | What it covers | Updated |
|---|---|---|
| Terms of Service | The agreement for the website, API, MCP server and dashboard: accounts, fees, data, liability and governing law. | |
| Privacy Policy | What personal data we process, why, who receives it, how long it is kept and how to exercise your rights. | |
| Data Processing Addendum | Processor terms: sub-processors, security measures, breach notice, audits and international transfers. | |
| Sub-processors | Each provider that processes personal data, what it does, where, and how changes are announced. | |
| Cookie Policy | Cookies and browser storage on our sites, what each is for, how long it lasts and how to change your choice. | |
| Acceptable Use Policy | What may not be done with the service, how it is enforced and how to report abuse. | |
| Enterprise SLA | Uptime commitment, service credits, incident response targets and chronic-failure rights for Enterprise plans. | |
| Responsible disclosure | How to report a vulnerability, what is in scope, safe harbor and our response targets. | |
| Digital Services Act | Points of contact for EU authorities and users, our EU legal representative, notices of illegal content and statements of reasons. | |
| EU Data Act | Switching to another provider, exporting your data, the formats we use, and where each service runs. | |
| EU AI Act | Which part of Trustvice is an AI system, how Number One meets the transparency rules, and the Article 25(4) agreement for high-risk AI systems. | |
| Right of withdrawal | For consumers in the EU and the UK: withdrawing from a paid plan within 14 days, what you get back, and the model form. | |
| Receipt Practice Statement | What a receipt attests, how it is built, signed and timed, and what it does not prove. | |
| Verifier Terms | What anyone who checks a receipt can rely on, what they cannot, and our responsibility to them. | |
| Key management | One AWS KMS signing key per region, held by Trustvice, and the published key set. | |
| Verifying receipts | How to check a receipt yourself, offline, with our libraries or your own code. | |
| Format versions and long-term verification | How the receipt format is versioned and how old receipts keep verifying. | |
| Post-quantum status | The signature algorithm today, the quantum risk, and how receipts are built to change algorithms. | |
| Continuity | What stays verifiable, and how to keep your receipts, if Trustvice stops operating. | |
| Imprint · Impressum | Who publishes Trustvice, where the company is registered and its representative in the EU. Also in German. |
Request security documentation.
Running a vendor review? Tell us what you need. We answer questionnaires in writing and walk Enterprise buyers through the architecture.
Send a security questionnaire
Written answers within 30 days, as the DPA sets out. Send it to privacy@trustvice.com.
Email privacy@trustvice.com →EnterpriseSecurity review with sales
For an Enterprise evaluation: the SLA, data residency, custom retention and the procurement paperwork.
Contact sales →SecurityTalk to the security team
Questions about the security model, signing keys or a finding. Vulnerabilities go through the report form.
Contact security →PrivacyPrivacy and data questions
Data subject requests, sub-processor objections and questions about the DPA.
Contact privacy →