Privacy Policy

Effective Date: July 9, 2026  |  Last Updated: July 9, 2026

1. Introduction

Verified Credentials ("we," "us," or "our") operates a trust-verification platform for W3C Verifiable Credentials. This Privacy Policy explains what information we collect, how we use it, how we protect it, and your rights with respect to it.

This Policy applies to all users of the Platform: Issuers, Verifiers, and Credential Subjects. By using the Service, you acknowledge you have read and understood this Policy.

This Platform is designed primarily as a business-to-business (B2B) API service. Credential claims about individual Credential Subjects are submitted by Issuers and processed on behalf of Issuers — we act as a data processor for that data, not the original data controller.

2. Information We Collect

2.1 Information You Provide Directly

During Onboarding (Issuer or Verifier)

When you register an Issuer or Verifier account, we collect:

• Organization name — the only field explicitly provided at registration.

Everything else is generated automatically:

• Decentralized Identifier (DID) — derived from your cryptographic public key (DID:key method).
• ED25519 keypair — generated on your behalf; the private key is stored encrypted at rest.
• API key — a 128-bit random token, displayed once and never stored in plaintext; only a SHA-256 hash is retained.

We do not collect your email address, physical address, phone number, or any government-issued identification during standard onboarding. Enterprise-tier onboarding may require additional verification details; those are addressed by separate agreement.

During Credential Issuance (Submitted by Issuers)

When an Issuer issues a credential, the credential claims are submitted to us for signing and storage. Depending on the credential type, claims may include:

We are a processor of this data, not its originator. Issuers are responsible for ensuring they have a lawful basis for processing and transmitting this information to us.

During Dispute Filing

When a dispute is filed, we collect:

• The credential identifier in dispute.
• The reporter's DID.
• The stated reason for the dispute.
• Up to 20 evidence items submitted by the parties.

During Billing

When you subscribe to a paid plan, we collect payment information through Stripe, Inc. We receive only billing metadata (subscription status, plan type, usage counts). We do not receive, process, or store payment card numbers, bank account details, or other payment instrument data.

We collect a Stripe Customer ID linked to your Issuer DID for billing association.

2.2 Information Generated Automatically

API Request Logs and Audit Trail

Every authenticated API request generates an audit log entry containing:

• Timestamp (UTC)
• Event type (e.g., auth.success, credential.issued, dispute.opened)
• Actor identifier (API key ID, DID, or IP address)
• Resource identifier (credential ID, DID, etc.)
• Source IP address
• Request correlation ID (X-Request-Id)

Audit log entries are chained using HMAC-SHA256 to detect tampering and support security investigations. Audit logs may be forwarded to a SIEM system (via syslog/CEF) for security monitoring.

Reputation Events

The following events are recorded against an Issuer's DID for reputation scoring purposes:

• Credential issuance
• Credential revocation
• Dispute outcomes (won or lost)
• Verifier feedback signals (positive or negative)

Individual reputation event records are retained for 90 days. The computed aggregate score is retained for the lifetime of the account.

Rate Limit State

To enforce rate limits, we store transient counts of requests per API key and per IP address in Redis. These records expire automatically within the applicable rate-limit window (typically 60 seconds to 1 hour) and are not used for any purpose other than rate limiting.

Authentication Failure Records

Failed authentication attempts are tracked per IP address to detect brute-force attacks. These records expire after 60 seconds.

Webhooks

When webhook delivery fails, a dead-letter log entry is written containing:

• The target URL.
• The event payload (which may include credential identifiers and event types).
• The failure timestamp.

2.3 Information on the Blockchain

When on-chain anchoring is enabled for a credential, the following is written to the Base public blockchain via our smart contract:

• SHA-256 hash of the credential (a 32-byte value with no personally identifiable information).
• Issuer's Ethereum wallet address.
• Anchor timestamp.
• Expiration timestamp (if set).
• Revocation status and revocation timestamp (if applicable).

No names, dates of birth, claims, or any other credential content are ever written to the blockchain. Blockchain data is public, permanent, and irrevocable.

3. How We Use Information

We do not sell, rent, or trade your personal information or credential data to third parties for marketing purposes.

4. On-Chain Data and Immutability

4.1 What Goes On-Chain

Only cryptographic hashes (SHA-256) of credentials and associated metadata (issuer address, timestamps, revocation status) are written to the blockchain. These hashes are one-way and cannot be reversed to recover credential content.

4.2 Permanence

Public blockchain records cannot be deleted, altered, or erased — by us or anyone else. This is a fundamental property of distributed ledger technology. Before requesting on-chain anchoring of any credential, Issuers and Credential Subjects should understand that the associated hash record will remain permanently visible on the Base network.

4.3 Revocation On-Chain

When a credential is revoked, the revocation is recorded on-chain. This records only that a particular hash was revoked at a particular timestamp; no personal data is included.

5. Data Sharing and Disclosure

5.1 Verifiers

When a credential is verified through the Platform, the Verifier receives:

• The verification result (APPROVE, DENY, NEEDS_REVIEW).
• A confidence score.
• Issuer Trust Tier and Reputation Score.
• Metadata about the credential (type, issuance date, expiration date, revocation status).

Whether the Verifier receives full credential claim contents depends on the implementation of the calling application; the Platform API can return the full credential JSON to authenticated Verifiers.

5.2 Webhooks (Issuer-Configured)

When an Issuer registers a webhook, event notifications are sent to that endpoint. Webhook payloads include event type, timestamp, and relevant identifiers (credential ID, dispute ID, verification result). Issuers are responsible for securing their webhook endpoints and for the downstream processing of any data delivered to them.

5.3 Stripe (Payment Processor)

We share your organization name, Issuer DID (as customer metadata), and usage counts with Stripe for billing purposes. Stripe processes payment information under its own Privacy Policy (https://stripe.com/privacy).

5.4 Blockchain Infrastructure

Credential hash data is transmitted to Base network nodes as part of on-chain anchoring. This is a public network; once broadcast, transaction data is visible to anyone.

5.5 SIEM / Security Monitoring

Audit log entries may be forwarded to a configured SIEM system for security incident detection. These entries contain event types, actor identifiers (DIDs, API key IDs, IP addresses), and resource identifiers, but not full credential claim contents.

5.6 Legal Disclosures

We may disclose information if required by law, court order, subpoena, or government authority, or if we reasonably believe disclosure is necessary to:

• Comply with a legal obligation.
• Protect the rights, property, or safety of Verified Credentials, our users, or the public.
• Detect, prevent, or address fraud or security incidents.

6. Data Retention

7. Data Security

We implement technical and organizational measures to protect data including:

• Encryption at rest: Private signing keys are encrypted using Fernet symmetric encryption with HKDF-SHA256 key derivation. API key secrets are stored only as SHA-256 hashes.
• Encryption in transit: All API traffic is served over TLS (enforced by HSTS headers with a 2-year max-age). Redis connections use TLS. Database connections require TLS.
• Access control: API keys are role-scoped (CLIENT, ADMIN, PLATFORM_ADMIN). Key operations are DID-bound and enforce strict authorization checks.
• Tamper-evident audit logging: All security-relevant events are logged with HMAC-SHA256 chaining, enabling detection of log tampering.
• Rate limiting and brute-force protection: Per-IP failed authentication attempts are rate-limited; adaptive rate limiting reduces throughput under high server load.
• Request sanitization: All requests are validated for header injection, oversized headers, body size limits, and malformed encoding before processing.
• Constant-time key comparison: API key validation uses hmac.compare_digest to prevent timing-based attacks.
• Secret management: Production secrets are managed via sops/age encryption; the application refuses to start if placeholder secrets are detected.
• Principle of least privilege: Containers run as non-root users; database and Redis connections use dedicated, limited-permission accounts.

No system is perfectly secure. If you discover a security vulnerability, please disclose it responsibly to pavon@vectorguardlabs.com.

8. Cookies and Tracking

The Platform is an API service. We do not use cookies, web beacons, tracking pixels, or behavioral advertising technologies. The API documentation endpoints serve standard HTML pages without third-party tracking scripts.

9. Children's Privacy

The Service is not directed at individuals under 18 years of age. We do not knowingly collect personal information from minors. If you believe a minor has submitted personal information through the Platform, contact us at pavon@vectorguardlabs.com and we will take appropriate steps.

10. International Transfers

Our servers may be located in the United States or other jurisdictions. If you are accessing the Service from outside the United States, be aware that information may be transferred to, stored in, and processed in the United States, which may not provide the same level of data protection as your home jurisdiction.

For users in the European Economic Area (EEA) or United Kingdom, transfers are conducted under appropriate safeguards including Standard Contractual Clauses where required.

11. Your Rights

11.1 Rights Available to All Users

• Access: You may request a copy of the data we hold about your account (DID, API key metadata, reputation score, dispute records, billing status) via the API endpoints.
• Correction: If your organization name or other account data is inaccurate, you may update it via the API.
• API Key Revocation: You may revoke any of your API keys at any time.
• Key Rotation: You may rotate your signing keys at any time.
• Subscription Cancellation: You may cancel your billing subscription at any time.

11.2 Rights for EEA and UK Residents (GDPR / UK GDPR)

If you are in the EEA or UK, you have additional rights:

• Right to Erasure ("Right to Be Forgotten"): You may request deletion of personal data we hold about you. Note that data written to the blockchain (credential hashes) cannot be erased due to the technical nature of distributed ledger technology. Credential claim data stored off-chain can be deleted upon request, subject to any applicable legal retention obligations.
• Right to Restriction: You may request that we restrict processing of your data in certain circumstances.
• Right to Portability: You may request an export of your data in a machine-readable format.
• Right to Object: You may object to processing based on legitimate interests.
• Right to Lodge a Complaint: You have the right to lodge a complaint with a supervisory authority.

11.3 Rights for California Residents (CCPA / CPRA)

California residents have the right to:

• Know what personal information is collected about you.
• Know whether personal information is sold or disclosed and to whom.
• Opt out of the sale of personal information. (We do not sell personal information.)
• Request deletion of personal information.
• Not be discriminated against for exercising these rights.

To exercise any of these rights, contact pavon@vectorguardlabs.com.

12. Credential Data and Controller / Processor Distinction

12.1 Platform as Processor

For credential claim data submitted by Issuers about Credential Subjects, Verified Credentials acts as a data processor on behalf of the Issuer (the data controller). We process this data only as directed by the Issuer through the API.

12.2 Issuer Responsibilities

Issuers are responsible for:

• Having a lawful basis for collecting and processing Credential Subject data.
• Obtaining appropriate consent or establishing another valid legal basis before issuing KYC, AML, or other personal-data-containing credentials.
• Providing Credential Subjects with privacy notices as required by applicable law.
• Complying with data subject rights requests from Credential Subjects regarding credentials they have issued.

12.3 Data Processing Agreement

Enterprise-tier customers who require a Data Processing Agreement (DPA) for GDPR compliance should contact pavon@vectorguardlabs.com.

13. Third-Party Services

We rely on the following third-party services in delivering the Platform:

14. Changes to This Policy

We may update this Privacy Policy from time to time. Material changes will be communicated through the API at least 30 days before taking effect. The "Last Updated" date at the top of this document reflects the most recent revision. Continued use of the Service after changes take effect constitutes your acceptance of the revised Policy.

15. Contact

For privacy inquiries, data subject requests, or to report a potential privacy issue:

Verified Credentials
Email: pavon@vectorguardlabs.com
Website: https://vercre.vercel.app