EFFECTIVE: 2026-03-23 | VERIDAQ_PRIV_V1.0 | APPLIES TO ALL PORTALS AND API ACCESS
Veridaq is built so that student personally identifiable information (PII) never appears on the blockchain in readable form. This is not a feature we added after the fact. It is a structural property of the system that cannot be disabled.
Because data is hashed with Poseidon before submission, the public ledger contains only opaque bytes32 values that cannot be reversed. The raw student data exists in exactly one place: the institution's backend server, encrypted at rest with AES-256-GCM, decrypted for milliseconds during proof generation, then discarded.
This architecture means Veridaq can comply with GDPR Article 17 (right to erasure) even though the blockchain is immutable. The on-chain commitments contain no PII, so their permanence poses no privacy risk. If the institution deletes the encrypted data on their backend, the commitments become orphaned hashes with no meaning.
Veridaq collects different categories of data depending on the user role. Each category has different retention policies and security requirements.
Student credential data is protected by two layers of encryption: at rest on the backend server and in transit between services.
Each student record is encrypted with AES-256 in Galois/Counter Mode before being stored in the PostgreSQL database. GCM provides authenticated encryption, which means the ciphertext cannot be tampered with without detection.
Encryption process: 1. Generate a random 96-bit IV (initialization vector) 2. Encrypt the plaintext with AES-256-GCM using the encryption key from environment variable 3. Prepend the IV to the ciphertext 4. Store IV + ciphertext + auth tag in PostgreSQL TEXT column Decryption reverses this: extract IV, decrypt, verify auth tag. The encryption key is NEVER stored in the database.
The AES-256 encryption key is stored in the NODE_ENV or a secrets manager. It is loaded into memory at server startup and never written to disk, logged, or transmitted over the network. The backend server uses a single encryption key shared across all institutions in the current version.
Key rotation requires re-encrypting all existing credential records. This is a planned feature for future versions. In the meantime, the encryption key should be treated as a secret of the highest sensitivity.
All API traffic between the frontend and backend is encrypted with TLS 1.3 in production. The development environment uses HTTP for local testing, but HTTPS is enforced in production with automatic redirect from port 80 to 443. The JWT cookies are marked Secure in production and are only sent over encrypted connections.
The institution uploads student records through the backend API. The backend computes a Poseidon hash of the student record plus a random blinding factor. This hash is a fixed-size field element that is submitted to the CredentialRegistry contract on Base Sepolia. The original data never leaves the backend.
Because the hash is one-way and the blinding factor is secret, no one can recover the original data from the on-chain value. The hash is collision-resistant and second-preimage resistant. Even if an attacker knows the student's name and CGPA, they cannot match it against the on-chain commitment without the blinding factor.
The only algorithm that runs on-chain is the BN254 pairing check for Groth16 proof verification. No student data is ever passed to the blockchain in readable form. Not in plaintext, not encrypted, not anywhere.
Stores: Full student records encrypted with AES-256-GCM. Institution profiles. Employer profiles. Verification history.
Never stores: Encryption keys in database. Raw passwords.
Stores: AES-256-GCM encrypted ciphertext only. Hashed passwords. Metadata.
Never stores: Raw student data. Private keys. Plaintext credentials.
Stores: Poseidon hash commitments (32 bytes). Nullifiers (32 bytes). Proof verification results.
Never stores: Student names, matric numbers, CGPAs, classifications, course codes, or any personal identifier.
Veridaq uses cookies exclusively for JWT session management. We do not use cookies for tracking, analytics, advertising, or any third-party service.
Stored in a cookie that JavaScript cannot read. Prevents XSS-based session theft. Expires after 7 days of inactivity.
Never stored in a cookie or localStorage. Held in JavaScript memory and attached to API requests via Authorization header. Expires after 15 minutes.
If you are a data subject in the European Union or European Economic Area, you have the following rights under the General Data Protection Regulation.
You can request a copy of all personal data we hold about you. We will respond within 30 days.
If your data is inaccurate, you can request correction. For credential data, contact the issuing institution directly.
You can request deletion of your personal data from our backend. We will delete all records within 30 days. Note: on-chain Poseidon hashes cannot be deleted but contain no PII.
You can request that we stop processing your data while a dispute is resolved.
You can request your data in a machine-readable format (JSON).
You can object to processing of your data for legitimate interests or direct marketing.
Institutions can request deletion of their backend data through the support endpoint. Upon deletion:
The Poseidon hash commitments submitted to Base Sepolia are permanent. The blockchain is immutable by design. However, because these hashes contain no PII and are computationally hiding, their permanence poses no privacy risk. They are meaningless 32-byte strings without access to the original data and blinding factor.
If a data breach is detected, Veridaq follows a structured incident response process that aligns with GDPR Article 33 and 34 requirements.
The security team identifies the breach through monitoring alerts, user reports, or automated scanning. Initial assessment within 2 hours.
The affected server or service is isolated. Access tokens are revoked. If the backend is compromised, the encryption key is rotated and all credential data is re-encrypted.
Affected data subjects are notified within 72 hours. The supervisory authority is notified if required by GDPR Article 33. Notification includes: nature of the breach, categories of data involved, and recommended mitigation steps.
Root cause analysis is completed within 14 days. Security patches are deployed. A post-mortem is published for affected stakeholders.
Veridaq uses the following third-party services. Each has been reviewed for GDPR compliance and data processing agreements are in place where required.
| Service | Purpose | Data Shared | Jurisdiction |
|---|---|---|---|
| Base Sepolia (Coinbase) | Blockchain execution and proof verification | Poseidon hash commitments only | Global (L2 is permissionless) |
| Alchemy | RPC endpoint for blockchain interaction | Transaction data (no student PII) | United States (Standard Contractual Clauses in place) |
| Neon (production) | PostgreSQL database hosting | Encrypted credential data (AES-256-GCM ciphertext) | US / EU (configurable region) |
| Upstash | Redis queue and cache | Job metadata, session cache (no PII) | US / EU (configurable region) |
Role-based access control (RBAC) with three roles: Admin, Institution, Employer. Each role can only access its own data and routes.
Passwords are hashed with bcrypt at cost factor 12. Minimum 8 characters, must include uppercase, lowercase, digit, and special character.
Auth endpoints are rate limited to 5 attempts per IP per 15 minutes. API endpoints are rate limited to 100 requests per minute per user.
All verification requests are logged with unique IDs, timestamps, and transaction hashes. Logs are immutable and append-only.
All npm and Foundry dependencies are scanned for known vulnerabilities before deployment. Weekly automated scans.
JWT secrets, encryption keys, and API tokens are rotated every 90 days. Emergency rotation can be triggered on demand.
We may update this privacy policy from time to time. Material changes will be communicated through the contact email on file for institution and employer accounts. Continued use of the platform after changes constitutes acceptance of the updated policy.
The version number at the top of this document indicates the current revision. Historical versions are available on request. The effective date is the date the policy was last modified.
If you have questions about this privacy policy, want to exercise your GDPR rights, or need to report a security concern, contact the Veridaq team:
Data Protection Officer
Veridaq Project
Department of Cybersecurity Science
Federal University of Technology, Minna
Niger State, Nigeria
privacy@veridaq.xyz