Building the ValiDeck MVP

Today’s loyalty programs are fragmented and intrusive. Each merchant maintains its own silo, requiring customers to share personal data, download proprietary apps, or carry physical cards. Every registration increases privacy risk and produces redundant, incomplete datasets. ValiDeck was conceived to solve this structural inefficiency by separating data integrity from data ownership.

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 transforms privacy from a legal checkbox into an architectural guarantee.

The ValiDeck MVP serves as the first live demonstration of this principle — showing that merchants can collaborate, regulators can audit, and customers can earn rewards without compromising their identity.

MVP Objective

ValiDeck MVP’s goal is to validate the PCX operational chain: attest → tokenize → pseudonymize → compute → audit under real merchant conditions. Because banks will not open their internal custodial interfaces at this stage, a Token Service Provider (TSP) will act as the temporary Custodian Layer. The TSP will verify identity, attest customers’ public keys, and issue encrypted tokens that enable pseudonymized transactions.

This phase will focus on creating 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 controlled merchant cohort across five sectors: Food & Beverage, Consumer Electronics, Apparel, Personal Care, and Home Improvement.

Together, these components will validate that privacy, interoperability, and lawful visibility can coexist on one technical foundation.

Custodial and Attestation Flow

During the MVP, the Token Service Provider will perform all critical 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 one-way encrypted payment tokens tied to the cardholder’s payment card.
  4. Custodial Separation: It retains the identity-to-key mapping in a secure environment under strict NDA and regulatory compliance.

When tokens reach ValiDeck, they are decrypted inside Trusted Execution Environments (TEEs), converted into pseudonymous indexes, and the plaintext is immediately destroyed. ValiDeck never sees personal identifiers — only cryptographically validated derivatives.

Acquiring a ValiDeck Account

Customers acquire a ValiDeck Account ID (VAID) through any participating merchant or 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 VAID is derived from the attested key and registered on the ValiDeck platform.
  5. The customer activates their account using their key pair. No email, phone number, password, or login credentials are ever created.

This structure ensures that each participant has a verified cryptographic identity, not a personal profile. The TSP retains the attestation record, and ValiDeck stores only the pseudonymous VAID.

Accessing the ValiDeck Platform

Unlike traditional digital platforms, ValiDeck does not provide login pages, user portals, or password-based access. All interaction with the platform is mediated through the user’s edge device app, installed on their mobile phone or computer. The app becomes the user’s secure window into the ValiDeck environment.

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

The ValiDeck platform itself does not expose any direct login interface; the edge app is the only mechanism through which users can access their encrypted vault and system functions. This design aligns with ValiDeck’s privacy-first architecture: the platform never knows who the user is — it only verifies that the correct cryptographic keypair is being used.

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 VAID.
  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 custodial logic:

  • The TSP creates a card token and encrypts it with ValiDeck’s public key for delivery.
  • Inside the TEE, ValiDeck decrypts the payload and immediately derives a jurisdiction-specific token index using a keyed cryptographic hash.
  • The raw token number is discarded and never stored on the platform. Only the token index is persisted and linked to the customer’s VAID.

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 performs the same indexing step inside the TEE: it computes the token index from the incoming tokenized payload and uses that index to locate the correct VAID. This ensures that transaction processing remains deterministic and fully pseudonymous while keeping the original token numbers out of ValiDeck’s database.

Merchant Visibility and Rewards

Merchants enrolled in the MVP will access category-level summaries rather than individual CTRs. For example, a coffee chain will see aggregate spending patterns across the beverage category but not the activity of individual customers or competitors. This preserves competitive neutrality while enabling shared market intelligence.

Customers, in turn, earn rewards for:

  • Purchases made at participating merchants, and
  • Consenting to contribute anonymized CTRs to aggregated analytics.

Reward points are recorded under each customer’s VAID and persist in the production environment. Merchants benefit from deeper behavioral insights, customers gain transparency and privacy, and regulators obtain real-time auditability.

Key Recovery and Continuity

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

  1. The user re-verifies identity with the TSP.
  2. The TSP re-attests a new public key, revoking the previous one.
  3. ValiDeck re-derives the VAID from the new attested key and links it to prior pseudonyms using cryptographic continuity proofs.
  4. The old key is retired, but all transaction data remains intact and auditable.

This procedure mirrors bank-level key rotation, ensuring both user continuity and system integrity without exposing private data.

Governance and Transition

All MVP operations will run under a sandbox governance program simulating the future Supervisory Authority’s role. Every token decryption, pseudonymization, and API call emits a cryptographic audit hash, making compliance a measurable system property rather than a policy declaration.

Once validated:

  • Custodianship transitions from TSPs to regulated banks or government identity frameworks.
  • Governance shifts from sandbox oversight to formal regulator supervision.
  • Architecture remains unchanged, ensuring continuity and interoperability.

Through this staged evolution, ValiDeck demonstrates that a privacy-first, cryptographically verifiable loyalty infrastructure can operate securely before full regulatory integration — establishing the foundation for a universal data exchange built on verified trust rather than shared identity.

Scroll to Top