Privacy Policy

1. Overview

HIPKit is a commercial product built on top of the Human Integrity Protocol (HIP). This privacy policy describes what data HIPKit — the product operated at hipkit.net — collects, processes, and retains. It is separate from the protocol-layer privacy posture documented at hipprotocol.org and from the Tier 1 pathway provider (HIPVerify) which has its own privacy policy.

HIPKit is designed around minimal data collection. The credentials and attestations that drive the product live in your browser; HIPKit-the-server stores only what's necessary to bill, authenticate, and meter usage. We don't track you, we don't sell data, and we don't use cookies for analytics or advertising.

HIPKit is operated by Peter Rieveschl as an individual at the time of this update. See § 13 (Operator and Successor Entity) for how this policy continues to apply if HIPKit's commercial operations are transferred to a successor entity. For the contractual side of your relationship with HIPKit (separate from this privacy policy), see the HIPKit Terms of Service.

2. Data We Collect

Data stored only in YOUR browser (localStorage)

HIPKit does not have access to data stored in your browser's localStorage. The following are local-only:

• Your HIP credential: Your cryptographic key pair (Ed25519 private + public key), credential ID, tier, issuance metadata, and pathway provenance. The private key is generated and held entirely in your browser. HIPKit-the-server never sees, receives, or stores your private key.
• Attestation cache: Recent attestations you've made (content hashes, classifications, timestamps) cached for offline verification fallbacks. Capped at 500 entries with oldest-first eviction.
• Thumbnail cache: Image thumbnails (data URLs) for recent attestations, displayed in your Portfolio. Capped at 100 entries with oldest-first eviction.
• Session state: UI preferences, draft work, and ephemeral state for in-progress flows.

Data we DO store (HIPKit servers)

• Stripe customer reference: Your Stripe customer ID and the email address you provided to Stripe at checkout. Used to associate credit purchases with your credential and to issue receipts.
• Credit balance and usage history: The number of credits you've purchased, when you used them, and against which API endpoint. Stored in Cloudflare KV indexed by credential ID.
• Attestation records: When you attest content via HIPKit (the POST /api/attest endpoint), we store the proof record (content hash, classification, signature, timestamp, optional thumbnail) in Cloudflare KV under your credential ID. This is required for verification, portfolio enumeration, and certificate generation. Records also carry a ledger_proof field that anchors them to the Bitcoin blockchain via OpenTimestamps; see § 14 (Ledger Anchoring).
• API key hashes: When you create an API key, the SHA-256 hash of the key is stored on the server alongside its credential binding, label, and active/deactivated status. The raw key is shown to you exactly once at creation; HIPKit cannot recover it after that moment.
• Series and collection records: When you create or extend a HIPKit-originated series or collection, the signed manifests and member events are stored in Cloudflare KV.

Data we do NOT collect

• Your name, address, phone number, date of birth, or any personally identifiable information.
• Your government ID, biometric data, or identity documents (these are processed by Didit on hipverify.org during Tier 1 issuance, never by HIPKit).
• Your IP address (beyond what Cloudflare's edge infrastructure observes for routing and abuse mitigation).
• Device fingerprints or persistent identifiers other than the cryptographic credential ID you knowingly submit when authenticating.

3. Analytics

HIPKit uses Cloudflare Web Analytics, a privacy-respecting analytics service. Cloudflare Web Analytics:

• Does not use cookies or local storage to identify visitors.
• Does not perform browser fingerprinting.
• Does not track users across websites or sessions.
• Aggregates page views, referrers, anonymized device categories, and country-level geographic data.
• Does not collect IP addresses for analytics purposes (Cloudflare derives country from the IP at the edge and discards the address).

This analytics data is used solely to understand which pages get visited and where traffic comes from, in aggregate, to improve the product. It is not joined with your credential, your purchase history, or any other identifier.

4. Payment Data

Payment is processed entirely by Stripe. HIPKit does not receive, process, or store your credit card number, billing address, or other payment details. HIPKit receives from Stripe only:

• A confirmation that a payment succeeded.
• Your Stripe customer ID (a pseudonymous identifier internal to Stripe).
• The email address you provided at checkout (used to issue receipts and confirmations).

Stripe's privacy policy governs their handling of your payment data. See stripe.com/privacy.

5. Third-Party Data Processing

Cloudflare hosts the HIPKit infrastructure: Pages (the static frontend), Workers (the API runtime), KV (storage of credentials, proofs, indices, balances), and Email Routing (the support@hipkit.net inbox forward). Cloudflare's privacy policy applies to their infrastructure services. See cloudflare.com/privacypolicy.

All HIPKit infrastructure today runs in a single Cloudflare account operated by the HIPKit operator. Decentralized record persistence — where independent Steward Node operators hold their own copies of attestation records to outlast any single operator — is a planned protocol-layer feature described at SN-SPEC-v0.md. As of this update, no Steward Nodes are activated and HIPKit-the-product holds the only operational copy of HIPKit-originated records. See § 15 (Sunset and Continuity) for what happens to records if HIPKit is wound down before the Steward Node tier activates.

Stripe (payment processor) handles all credit card data under their own privacy policy. HIPKit has a data processing relationship with Stripe limited to the customer-reference and receipt fields described above.

HIPKit does not share data with any other third party except as required by law or to operate the service.

6. Data Retention

• Attestation records, series records, collection records: Stored permanently. The protocol's value depends on durable, verifiable proofs that don't disappear when convenient.
• Credit balances and usage history: Stored permanently for billing reconciliation and audit. Credits purchased as one-time packs do not expire; subscription credit allotments are restored at each billing cycle and unused subscription credits do not roll over (see Terms of Service § 5). Refund eligibility for unused credit packs is 14 days from purchase (see Terms of Service § 6).
• API key hashes: Stored permanently when active. When you deactivate a key, the hash is retained but marked inactive (so reactivation would require a new key) plus a deactivation timestamp and reason.
• Stripe customer reference and receipt email: Retained while you have any active record on HIPKit.
• Cloudflare Web Analytics data: Retention is governed by Cloudflare's own retention policy.
• Email Routing logs: Cloudflare's Email Routing Activity Log shows forwarded messages; retention governed by Cloudflare.

7. What We Do NOT Do

• We do not sell, share, or rent your data to any third party for marketing or advertising.
• We do not use your data to train AI models or any other unrelated downstream system.
• We do not track you across websites.
• We do not use cookies for analytics or advertising. The product uses localStorage only for the operational state described above.
• We do not require, request, or accept personally identifiable information beyond what Stripe collects to process payment.

8. Data Security

All data in transit is encrypted via HTTPS/TLS. Your credential's private key is generated and stored entirely in your browser's localStorage and is never transmitted to any server. Authentication to HIPKit endpoints uses either an API key (hashed server-side) or a signed AppAuth canonical (signed by your credential's private key, verified server-side via Ed25519). Server-side data lives in Cloudflare KV with access scoped to the HIPKit Workers.

9. Your Rights

Because HIPKit primarily stores cryptographic identifiers and operational records rather than personally identifiable information, traditional data subject rights apply in a narrow but real way:

• Access: You can enumerate your own attestations, series, collections, and API keys via authenticated endpoints in the HIPKit app. Your credential ID is the access token; without your private key, no one (including HIPKit) can read your records on demand.
• Deletion: Attestation records, series records, and collection records cannot be deleted from the public protocol — that's a fundamental property of a verification protocol. You can deactivate API keys at any time. You can stop using HIPKit at any time, in which case no further records will be created. To request removal of your Stripe customer reference and receipt email, contact us at support@hipkit.net.
• Credential retirement: You can retire your credential via the HIPKit app, which marks it as superseded server-side and prevents further attestations under that credential. The retirement is recorded; existing attestations remain verifiable.

10. Young Users

HIPKit is designed for adult creators of professional content. We do not knowingly collect data from children under 13. The HIP protocol itself has no age restriction — minors can use the protocol's free tools at hipprotocol.org at no cost.

11. International Users

HIPKit is operated from the United States. Data is processed through Cloudflare's global network and Stripe's payment infrastructure. By using HIPKit, you consent to the processing of your data in these systems. Where applicable law requires additional protections (GDPR, CCPA, etc.), HIPKit operates in good-faith compliance with the data-handling principles described in this policy: minimal collection, narrow third-party processing, no sale of data, and transparency about retention.

12. Protocol vs HIPKit (Product Boundary)

This privacy policy applies to HIPKit, a commercial product operated at hipkit.net. It is important to distinguish HIPKit (the product) from the HIP protocol itself.

The HIP protocol layer — the ledger, the worker that registers attestations, the verifier that validates them — does not see, store, or transmit identity data. The protocol receives only a one-way deduplication hash, a tier label, and a pathway identifier. No documents, no biometric data, no personally identifiable information ever reaches protocol-layer code or ledger entries.

HIPKit, as a commercial product, sits on top of the protocol and adds paid features (credit packs, batch tools, certificates, portfolio enumeration, embeddable badges). The protocol-layer attestations created via HIPKit are also visible at the protocol surface and are independently verifiable by anyone with a browser. HIPKit's paid features are gated by API key authentication and metered by credit balance.

Under Charter Deployment Principle 5 (Permissionless Proliferation), anyone may build alternative products on top of the protocol. HIPKit is one such product; it is not the only one and is not privileged in the protocol's design. Under Charter Deployment Principle 7 (Zero Institutional Cost), the protocol itself is free at the protocol surface (hipprotocol.org); HIPKit's paid pricing reflects HIPKit's institutional implementation choice, not any protocol-imposed cost. Under Charter Deployment Principle 8 (Protocol, Not Entity), HIPKit is an institutional participant in the HIP ecosystem, not the protocol itself.

For the contractual aspect of this product/protocol distinction (rather than the privacy aspect), see HIPKit Terms of Service § 1 (Service Description).

13. Operator and Successor Entity

HIPKit is operated by Peter Rieveschl as an individual at the time of this update. The HIPKit name, brand, and product code are owned by the operator personally; the protocol-layer code at github.com/human-integrity-protocol/hip-protocol is published openly under its repository licenses.

If HIPKit's commercial operations are assigned to a limited-liability company or other successor entity formed to hold them — for example, a U.S.-formed LLC at the time of public launch — the successor will be bound by this policy with respect to data already collected under it, and any change in the operator entity will be noted with an updated effective date at the top of this page. The successor entity name, when formed, will appear in this section. A superseding privacy policy, if any, will be published here before any new collection practices begin.

14. Ledger Anchoring

HIPKit attestation records, series records, and collection records currently carry an additional ledger_proof field that anchors the record to the Bitcoin blockchain via OpenTimestamps. The ledger proof is derived from the record's content hash and timestamp at write-time and submitted to the OpenTimestamps calendar service; once the calendar attestation is confirmed in a Bitcoin block (typically 1–6 hours after submission), the proof can be independently verified against the Bitcoin chain by anyone with a Bitcoin node and the OpenTimestamps verifier.

This anchoring is a tamper-evidence mechanism, not a data-collection one — no additional information about you or your file is added to the public record. The Bitcoin chain receives only an aggregated commitment hash, not your content hash directly. Records created prior to the ledger-anchoring rollout do not yet carry a ledger proof and are being backfilled administratively.

The Steward Node specification at SN-SPEC-v0.md describes the planned protocol-layer extension that decentralizes record persistence beyond a single operator. Once Steward Nodes are activated, copies of HIPKit-originated records will propagate to independent operators per that specification.

15. Sunset and Continuity

If HIPKit-the-product is wound down or its operations are sunset, the data described in § 6 (Data Retention) will be handled as follows:

• Attestation records, series records, collection records. The HIP protocol's verification surface is designed to outlast any single operator. Once the protocol's Steward Node tier (see § 14) is activated, HIPKit-originated records held by HIPKit can be migrated to Steward Nodes for continued public verification. Until that tier is activated, HIPKit will publish a final read-only snapshot of records (covering content hashes, classifications, signatures, timestamps, and any optional thumbnails) to a public archive (such as a GitHub release or an Internet Archive snapshot) before any wind-down completes.
• Account data, Stripe customer references, credit balances, API key hashes. These will be deleted no earlier than thirty (30) days after wind-down notice and after a final accounting period sufficient to satisfy refund obligations under the Terms of Service.
• Notice. A wind-down or operator-transfer notice will appear at hipkit.net and on the HIPKit GitHub repository at least thirty (30) days before any non-reversible step is taken. Any updated privacy policy that applies under a successor operator will be published here.

16. Changes to This Policy

We may update this policy from time to time. Material changes will be noted with an updated date at the top of this page.

17. Contact

For privacy-related questions or data requests, contact us at support@hipkit.net or via the HIP Protocol GitHub repository. For non-privacy questions about your relationship with HIPKit (terms, billing, refunds, acceptable use), see the HIPKit Terms of Service.