Building the ValiDeck Prototype

Almost every big retailer runs a loyalty program and most of them did not set out to become a custodian of personal data. But that is the bargain on offer. To reward a customer for coming back, a merchant has to collect and hold names, contact details, and a purchase history tied to an identifiable person. That data carries consent obligations, breach exposure, deletion requests, and a standing conversation with a data protection officer who would rather the data did not exist. ValiDeck was built to remove the data without removing the program, by separating data integrity from data custody.

At the heart of this design lies the Privacy-Compliant eXtensible (PCX) protocol — a system in which transactions are tokenized, pseudonymized, and auditable without ever revealing who performed them. Instead of collecting personal information, ValiDeck receives only attested cryptographic proofs that confirm legitimacy. This turns privacy from a legal checkbox into an architectural property. The protocol is described in full in the PCX White Paper.

The ValiDeck Phase-I Prototype is the first live demonstration of this principle. It is deliberately scoped to a single merchant, because the value has to hold for one retailer on its own: a single business, running its own loyalty program, without holding identifiable customer data. Everything that follows is what that single deployment proves.

Prototype Objective

The Phase-I Prototype validates the PCX operational chain — attest, tokenize, pseudonymize, compute, audit — under real conditions at one merchant. Every link in that chain begins with a custodian: the party that verifies a customer’s identity, attests their public key, and issues the encrypted token. In production, that custodian is the customer’s card-issuing bank. It has already verified their identity and it holds their card, which makes it the natural party to attest the key.

Banks, however, will not open their internal custodial interfaces to a pre-commercial system. For the prototype, a Token Service Provider (TSP) occupies the Custodian Layer instead: it verifies identity against a government ID document, signs the customer’s public key, and issues the encrypted tokens that make pseudonymized transactions possible. What changes between the prototype and production is who holds the custodian role, not what the role does. The attestation format, the interfaces, and everything downstream of the custodian stay the same — which is what makes the eventual handover to banks a substitution rather than a rebuild.

This phase focuses on three deliverables:

• A payment transaction simulator that replicates point-of-sale activity and settlement events.
• A PCX-compliant data platform for recording and querying Customer Transaction Records (CTRs).
• A single-merchant live deployment, running a complete loyalty program end to end with no personal data held by the merchant or by ValiDeck.

Together, these components establish that a merchant can operate a full loyalty program — enrollment, earning, redemption, and reporting — without ever taking custody of customer identity.

Custodial and Attestation Flow

During the prototype, the Token Service Provider performs the pre-platform functions that banks or national identity frameworks will eventually assume.

1. Identity verification: the TSP confirms each user’s legal identity using a verified ID document.
2. Public-key attestation: it signs the customer’s public key, producing a certificate that proves legitimacy without exposing identity.
3. Token issuance: the TSP generates payment tokens tied to the cardholder’s payment card and encrypts them to ValiDeck’s public key.
4. Custodial separation: it retains the identity-to-key mapping in a secure environment under contract and applicable regulatory obligations.

When a token reaches ValiDeck, it is decrypted inside a protected enclave, a non-reversible reference is derived from it, and the decrypted payload is destroyed immediately. Personal identifiers never enter ValiDeck’s storage, and the plaintext token exists only transiently inside the enclave. What persists is the derived reference and the pseudonymous ValiDeck ID.

Acquiring a ValiDeck Account

Customers acquire a ValiDeck ID through the participating merchant or an onboarding portal.

1. The merchant initiates verification with the TSP (custodian).
2. The customer’s public key is generated locally on their device and submitted for attestation.
3. The TSP validates the user’s identity, signs the key, and returns an attestation certificate.
4. A ValiDeck ID is derived from the attested key and registered on the PCX server platform.
5. The customer activates their account using their key pair. No email address, phone number, password, or login credential is ever created.

Each participant therefore holds a verified cryptographic identity rather than a personal profile. The TSP retains the attestation record; ValiDeck stores only the pseudonymous ValiDeck ID.

Accessing the ValiDeck Platform

ValiDeck has no login pages, user portals, or password-based access. All interaction is mediated through the user’s edge device app, installed on their phone or computer. The app is the user’s only window into the ValiDeck environment.

When the app launches, it establishes a cryptographically authenticated session with the platform. No username, email, or phone number is required, and no credentials are typed. Only a device holding the user’s private key can interact with ValiDeck services.

The PCX server platform exposes no direct login interface. This follows from the architecture rather than from policy: the platform does not know who the user is, only that the correct keypair is being presented.

Establishing a Secure Session

To establish this app-mediated access, ValiDeck relies on a passwordless public-key challenge–response protocol:

1. When the app starts, the platform issues a cryptographic challenge.
2. The edge device signs this challenge using the user’s private key, which never leaves the device.
3. ValiDeck verifies the signature with the attested public key linked to the ValiDeck ID.
4. If the signature is valid, the session is opened, and the device may synchronize with the user’s encrypted vault.

There is no login form and no password to remember. Authentication is fully automatic and entirely cryptographic, ensuring that the platform recognizes control of a key, not a personal identity. This method reinforces the system’s core principle: a ValiDeck account is not something a user “logs into” — it is a cryptographic identity that only the user’s own device can present.

Tokenization and CTR Creation

When customers tokenize their payment cards, the process mirrors the custodial logic:

• The TSP creates a card token and encrypts it with ValiDeck’s public key for delivery.
• ValiDeck decrypts the payload inside a protected enclave and derives a non-reversible reference from it.
• The raw token number is discarded and never stored. Only the derived reference is persisted and linked to the customer’s ValiDeck ID.

The one-way property belongs to the derived reference, not to the transport: the token is encrypted in transit so that only ValiDeck can open it, and the reference computed from it cannot be inverted back to the token. Each transaction produces a Customer Transaction Record (CTR) formatted as a PCX Data Packet, containing timestamp, merchant ID, loyalty status, item list, value, and an integrity hash. This standardized packet makes CTRs machine-readable, cross-domain, and self-verifiable. For every transaction, ValiDeck repeats the same step: it derives the reference from the incoming tokenized payload and uses it to locate the correct ValiDeck ID. Transaction processing stays deterministic and fully pseudonymous, and the original token numbers never enter ValiDeck’s database.

Merchant Visibility and Rewards

The merchant sees what it needs to run a loyalty program and nothing more: category-level and program-level summaries, redemption activity, and reward liability — never an identifiable customer record. The merchant issues rewards against a pseudonymous ValiDeck ID, so the program operates without the merchant holding a customer database at all.

Customers earn rewards for purchases at the participating merchant, and may separately consent to contribute their transaction records to aggregate analytics. Reward points are recorded under each customer’s ValiDeck ID and persist across the transition to production. The same primitives support additional participating merchants later, with each merchant’s activity remaining opaque to every other. That capability is latent in the protocol and requires no change to the single-merchant deployment described here; it is not a precondition for any of it to work.

Key Recovery and Continuity

Because ValiDeck holds no passwords or personal identifiers, account recovery depends on the custodian’s attestation records:

1. The user re-verifies identity with the TSP.
2. The TSP re-attests a new public key and revokes the previous one.
3. ValiDeck derives a new ValiDeck ID from the new attested key and links it to the prior pseudonym using a continuity proof.
4. The old key is retired. The reward balance and the audit trail carry across to the new identifier without interruption.

This linkage is the one deliberate exception to pseudonym separation, and it is worth being precise about it. The continuity proof links a user’s own successive identifiers to each other so that their reward balance and history survive the loss of private key. It is generated only on a user-initiated recovery, only after the custodian has re-verified that user, and it links nothing beyond that single user’s prior and current identifiers. It gives neither ValiDeck nor the merchant any ability to link a pseudonym to a real-world identity, which remains solely with the custodian.

Re-attestation restores the customer account but does not by itself restore the ability to read what is inside it. Every customer’s transaction records are encrypted with a single key that belongs to that customer alone. ValiDeck stores the encrypted records but retains nothing that opens them. There are two ways to reach that key, and the customer controls both. The everyday route is the app on the customer’s device. The app holds the private key, and the private key unseals its copy of the customer’s key without the customer ever thinking about it. The backup route is a recovery code, issued once when the account is created and meant to be written down and kept somewhere safe, in the same spirit as the recovery codes issued by banks and phone manufacturers. The code itself is never sent to ValiDeck. What the platform holds is a second sealed copy of the customer’s key that only that code can unseal.

It is worth being precise about what changes and what does not. The key that encrypts the records is generated once, when the account is created, and it never changes. If it did, every record already encrypted under it would become unreadable. There is one such key and two sealed copies of it, each opened by a different route. Recovery recreates the link between the customer’s device and the key that opens the records — the recovery code unseals its copy of that key, and the app re-seals the same key to the newly attested public key, so the everyday route works as before.The records are untouched throughout. The copy held against the recovery code is written once and never disturbed, which is why the same code keeps working however many times a customer has to replace a key.

When a customer replaces a lost device, the custodian attests a new key and the code unseals the customer’s key so that a fresh copy can be sealed to the new public key. The records themselves are never decrypted, moved, or re-encrypted during this, which is why recovery takes the same moment whether the customer has a month of history or ten years of it. A customer who loses both their device and their recovery code cannot recover their transaction history, and neither can ValiDeck. That is the price of an architecture in which nobody but the customer can read the records, and we consider it the right one.

Governance and Transition

Prototype operations run under a sandbox governance program that models the supervisory arrangements a production deployment would sit under. Every token decryption, pseudonymization, and API call emits a cryptographic audit hash, so compliance becomes a measurable system property rather than a policy declaration. Audit records are produced continuously and can be examined on demand by the merchant, by an external auditor, or by a supervisory authority acting within its mandate. No party holds a standing live view of customer activity, and the audit trail records system behavior, not identifiable individuals.

Once the single-merchant deployment is validated, three things change and one does not:

• Custodianship transitions from TSPs to regulated banks or government identity frameworks.
• Governance shifts from sandbox oversight to formal regulatory supervision.
• Additional merchants join, each isolated from the others.
• The architecture stays the same, which is what makes each of the above a substitution rather than a rebuild.

Through this staged progression, ValiDeck demonstrates that a privacy-first, cryptographically verifiable loyalty program can be operated by a single merchant today — and that the same foundation extends, without redesign, to a broader data exchange built on verified trust rather than shared identity.