The commitments beneath the cryptography.

Every tenant's signing key is a secp256k1 asymmetric key held inside Google Cloud KMS, provisioned with protectionLevel: HSM. The private key bytes never leave the HSM boundary — LearnCoin's signing worker submits the 32-byte SHA-256 digest of a canonicalized credential and KMS returns a DER-encoded ECDSA signature. Application code never holds the private key in any form.

Per-tenant keys mean a compromise of one tenant's key does not affect any other tenant. Keys are exposed publicly only as verificationMethod fragments in the LearnCoin DID document — never as raw private material.

GDPR Article 17 (right to erasure) is fundamentally incompatible with immutable blockchain storage, so LearnCoin never anchors personally identifiable information to the chain. The on-chain footprint is strictly: Merkle root of the credential batch, issuer DID reference, issuance timestamp, transaction ID. That is the complete on-chain footprint.

Recipient legal name, email, tenant-supplied external identifiers, submission data, analytics, and attachments all stay off-chain in Supabase under tenant-scoped Row Level Security (RLS). The pseudonymous recipient ID inside the signed JSONLD (urn:uuid:…) cannot be re-associated with the recipient once the mapping row is erased.

On a GDPR erasure request, LearnCoin deletes the Supabase row mapping the email to the pseudonymous ID. The recipient's own downloaded copy of the credential still verifies cryptographically — that's a self-sovereign object we can't delete, which is the point. LearnCoin can demonstrate complete erasure on LearnCoin's side to a DPA.

Revocation and erasure are different assertions by different parties. Revocation is the issuer saying "I no longer endorse this credential"; erasure is the recipient saying "remove my PII." LearnCoin models both as independent state transitions, and the verification page atlearncoin.me/c/{id} renders the full four-way matrix: unrevoked/not-erased (normal rendering), unrevoked/erased (name redacted, achievement preserved), revoked/not-erased (full revocation tombstone with reason), revoked/erased (minimal both-honored tombstone).

A GDPR erasure never forces revocation. A revocation never forces erasure. The two decisions belong to different parties.

LearnCoin commits to WCAG 2.2 AA compliance on every public credential page from first production shipment. This is a sales blocker for EU public-sector buyers — and the right default regardless. Color contrast, alt text on credential images, keyboard navigation, and screen-reader labeling are part of the exit criteria for every verification-page release.

Competitor verification pages commonly fail WCAG on contrast, alt text, and keyboard nav. That gap is not a LearnCoin feature — it's a baseline.

LearnCoin commits to perpetual verification. Credentials issued in year N continue to verify in year N+10 as long as the underlying blockchain exists and the issuer DID resolves. LearnCoin holds the operational responsibility of keeping the DID document resolvable, the verification libraries patched against CVEs, and the Blockcerts forks we maintain up to date.

Upstream dependencies (Blockcerts libraries, cert-schema, explorer-lookup) are forked into the barcelova GitHub organization with Dependabot alerts enabled. If the upstream stewards stop funding Blockcerts development, LearnCoin inherits maintenance responsibility for the parts it depends on. Mitigation: fork posture from day one, not something we have to scramble to do later.

• We don't charge for verification. Ever. This is a contract commitment, not a feature gate.
• We don't run a secondary marketplace for credentials. Credentials are not NFTs to trade; sharing is just sharing a URL.
• We don't sell recipient data. Recipient PII is subject to the tenant's own contract with their recipients; LearnCoin is a data processor for tenants.
• We don't lock credentials into LearnCoin-specific tooling. Any Blockcerts verifier, any OB 3.0 importer, any W3C VC tool works.
• We don't ship group credentials. OB 3.0 mandates one recipient per credential; team challenges are modeled as N individual credentials cross-referenced via a LearnCoin extension. This mirrors Accredible's operational failure with group badges.