Uhpenry Snapshot Policy
Legal terms governing the creation, update, verification, retention, and evidentiary use of Snapshots, Snapcharges, and Snapgates on Uhpenry.
This Snapshot Policy (“Policy”) governs the creation, use, verification, modification, retention, and legal effect of Snapshots, Snapcharges, and Snapgates on the Uhpenry platform (“Platform”). By using Uhpenry, including initiating or completing any Snapgate or Snapcharge, you agree to be bound by this Policy in conjunction with the Uhpenry Terms of Service and Privacy Policy.
Except as expressly provided herein, capitalized terms used but not defined in this Policy have the meanings given in the Terms of Service.
1. Definitions
1.1 Snapshot. A Snapshot is the Platform's persistent record that captures the complete state of a Snapgate and its related Snapcharge(s) at a point in time. A Snapshot contains, at minimum, the frozen project state, the associated Snapgate, the list of Snapcharge objects, user and owner identifiers, and related metadata.
1.2 Snapgate. A Snapgate is a controlled access point (checkout-like container) used to initiate and group Snapcharge transactions. A Snapgate records access controls, moderation history, and access telemetry (for example: times, counts, and locations of access).
1.3 Snapcharge. A Snapcharge is an individual transactional record (payment/license event) created under a Snapgate. A Snapcharge contains the transaction details, chosen delivery method (e.g., download or invite), version information (tag or commit), and the Snapcharge verification history.
1.4 Verification / Verification Record. A Verification is the Platform's cryptographic evidence attached to a Snapcharge at the time a transactional state is sealed or updated. Verifications record an integrity proof and a signer proof and are annotated with a timestamp and a reason (for example: initial, final, update, refund).
2. Relationships and Scope
2.1 One-to-One Snapgate↔Snapshot. Each Snapgate is associated with exactly one Snapshot. Each Snapshot is associated with exactly one Snapgate. This association is unique and immutable outside of Platform-managed transactional updates.
2.2 One-to-Many Snapgate→Snapcharges. A Snapgate may contain one or more Snapcharges. Each Snapcharge belongs to exactly one Snapgate.
2.3 Scope of Verification. Cryptographic verification applies to individual Snapcharges (their verification records). While Snapshots contain Snapcharges and Snapgate data, the Platform's signed proofs are recorded at the Snapcharge level and form the verifiable chain that supports the Snapshot's evidentiary value.
3. Creation, Update, and Immutability
3.1 Snapshot Creation. When a Snapcharge is completed, the Platform automatically generates or updates the Snapshot associated with the Snapgate. The Snapshot captures the frozen project state and all transactional metadata relevant to that Snapcharge.
3.2 Snapcharge Sealing (Immutable Receipt). When a Snapcharge reaches a finalized transactional stage (for example, paid/completed), the Snapcharge record is cryptographically sealed via the Platform's verification process. A sealed Snapcharge represents an immutable transactional receipt for the stage it records.
3.3 Updates by Transaction Only. Snapshots and their contained data may be updated only via authorized transactional events, for example: newly completed Snapcharges, refunds, or other transactional corrections. Snapshots are not altered arbitrarily; any update is recorded as a new verification state with a recorded reason (e.g., update, refund).
3.4 No Deletion. Snapshots are retained in the Platform's storage and are not deleted by Platform or user action. The Platform does not expose an external delete operation for Snapshots. Snapshots remain associated with their Snapgate even if user accounts are deleted; in such cases the Snapshot will not receive further updates.
4. Verification Process (Summary)
4.1 Deterministic Hashing. For each Snapcharge verification event the Platform calculates a deterministic cryptographic hash of the Snapcharge data snapshot.
4.2 Two-Stage Signing (“Integrity” + “Signer”). The Platform performs a two-stage cryptographic sealing of the Snapcharge:
-
Integrity proof: the deterministic Snapcharge hash is sealed in a signed integrity token (a signed JWT using the Platform's integrity key).
-
Signer proof: a deterministic hash of the integrity proof is sealed in a signed signer token (a signed JWT using the Platform's signer key).
4.3 Verification Record. Each verification record stored with a Snapcharge contains at least: the integrity
{ hash, token, kid }, the signer{ hash, token, kid }, acreatedAttimestamp, and areason(one ofinitial,final,update,refund).4.4 Public Verification and Key Rotation. Uhpenry publishes its public verification keys and key rotation history in an open, auditable repository for independent verification of Snapshot/Snapcharge proofs:
🔗 https://github.com/uhpenry/key-signing4.5 Verification Validation. Verification succeeds only when (a) the signed tokens validate against the published public keys, (b) the integrity hash matches the recalculated Snapcharge data hash, and (c) the signer hash matches the recalculated integrity object hash. The Platform will withhold completion, delivery, or access if verification fails.
5. Reasons for Verification and Effect
5.1 Reason Codes. Each verification record is annotated with a reason indicating the transactional context: initial, final, update, or refund.
5.2 Semantic Effect.
-
initial, preliminary sealing (may be used when transaction processing begins). -
final, definitive sealing for a completed transactional stage. -
update, applied when a transactional field is legitimately changed (for example version selected, metadata corrected). -
refund, applied when a refund or partial reversal alters the enforceable state.5.3 Legal Effect. A finalized Snapcharge verification (for example,
final) constitutes the Platform's recorded evidence of the transaction and the terms in effect at that moment. Subsequentupdateorrefundverifications are recorded as new states in the Snapshot's verification history.
6. Snapgate Moderation, Access, and Enforcement
6.1 Access Controls. A Booth may configure a Snapgate to control access (for example download limits, invitation rules, or visibility settings). Access granted pursuant to a Snapcharge is subject to the Snapshot, the Snapcharge terms, and any applicable enforcement action.
6.2 Moderation & Revocation. If a Booth reports a User for a terms violation, the Platform and/or Booth may revoke access rights associated with the Snapcharge and Snapgate. Access revocation and moderation actions are recorded and may be reflected in the Snapshot and Snapgate history.
6.3 Activity Logging. Snapgates record access telemetry (including access times, counts, and access locations) that may be used in dispute resolution and enforcement.__
Refer to Snapgate Moderation Policy for further information.
7. Retention, Export, and Evidence
7.1 Retention. Snapshots and Snapcharge verification histories are retained by Uhpenry for the lifetime of the Platform unless otherwise required by law.
7.2 Export and Independent Verification. Users and Booths may export Snapcharge receipts and Snapshot data. Exported materials, together with the public keys published in the key-signing repository, enable independent verification of the Snapcharge proofs.
7.3 Evidentiary Use. Snapshots and sealed Snapcharges constitute primary Platform records and may be used by Uhpenry, Users, Booths, or courts as evidence in internal and external dispute resolution.
8. Privacy and Compliance
8.1 Data in Snapshots. Snapshots may contain personal data (for example user and owner identifiers, emails, and access metadata). Processing and retention of such data comply with applicable data protection laws, including GDPR and CCPA where applicable.
8.2 Requests for Access or Deletion. Requests that implicate Snapshot data will be handled consistent with applicable law and this Policy. Because Snapshots are persistent and may be required for legal or contractual reasons, some deletion or alteration requests may be denied to the extent permitted by law.
9. Future Anchoring and Enhancements
9.1 Blockchain or External Anchoring. Uhpenry may elect to anchor Snapshot or Snapcharge proof hashes on external public ledgers or timestamping services to strengthen verifiability. Any such anchoring will be additive and shall not materially change the substantive content of existing Snapshot records.
9.2 No Implicit Change to Rights. Implementation of external anchors does not by itself change the rights, obligations, or evidentiary value set forth in this Policy.
10. Disputes, Remedies, and Amendments
10.1 Dispute Handling. In disputes concerning access, refunds, or enforcement, Uhpenry will rely on the Snapshot and Snapcharge verification history as the authoritative Platform record.
10.2 Remedies. Uhpenry may enforce remedies (including access revocation, suspension, or other measures) based on the Snapshot and Snapgate records and the Platform's dispute procedures.
10.3 Amendment of Policy. Uhpenry reserves the right to amend this Policy. Material changes will be communicated in advance. Continued use of the Platform after notice constitutes acceptance of the revised Policy.
11. Contact
For questions regarding this Policy, verification exports, or to request Snapshot data, contact: support@uhpenry.com.
Last updated: August 14, 2025