Anyone can check an ID. Almost nobody can prove, two years and one dispute later, exactly what was checked, when, by whom, and what the credential status was at that moment. That artifact is what ProntoID issues.
Site access, insurance verification, content consent, identity-gated delivery, proof of life. Different industries, identical shape — four roles, one of which the market has never served.
The person being checked. Verifies once, presents many times, retains control over what is disclosed and to whom.
Whoever asserts a fact — an insurer, a training body, a licensing authority, a performer. Signs a claim without operating infrastructure.
Whoever carries the duty to check. Needs a yes or no at the point of decision, in under a second, without handling personal data.
The regulator, court, acquirer or insurer who arrives years later and asks for proof. This is the unserved role.
The identity market sells to the verifier — a result, delivered now. ProntoID sells to the moment when someone has to defend that result. Everyone can verify. Almost nobody can prove.
A receipt is only worth money if it answers all of these to a hostile third party, years after the fact, without requiring anyone to take ProntoID’s word for it.
Six of the seven are engineering. The fifth is the one that makes this defensible.
If a credential is revoked in 2028, the party who checked it in 2026 must still be able to prove it was valid then. A current status lookup cannot do this, and a receipt that simply asserts it is worthless in a dispute.
Status changes are recorded as immutable events. Nothing is ever updated in place, so history cannot be quietly rewritten.
At a fixed interval — hourly by default — a Merkle root is computed across the entire status set, then published and timestamped.
Each receipt embeds the credential’s status leaf together with an inclusion proof against the root that was current at the moment of the check.
A third party can confirm the credential was active at check time by recomputing the path. No trust in ProntoID is required, which is the entire point.
The identity core already exists. Everything above it is thin. The receipt service is the product.
Document capture, MRZ parsing, biometric liveness and face matching. Establishes the root identity assertion once per subject.
Signed claims: subject, issuer, schema, payload, validity window, status. One table, one shape, regardless of what the claim asserts.
Append-only status events with periodic Merkle roots, timestamped and independently anchored. The basis of every point-in-time proof.
Verifier-declared requirement sets expressed as JSON. A policy resolves to a set of required claims and thresholds — nothing more.
QR, deep link, API or delegated request. Selective disclosure returns booleans and ranges rather than underlying attributes.
Generates and seals the evidence artifact, written to immutable storage under a compliance-mode retention lock and indexed for retrieval.
A verifier queries their own receipts and exports a bundle for an auditor, an acquirer or a court. Read-only, scoped, logged.
Immutability is a commercial feature, not a technical one.
Receipts are written under a compliance-mode retention lock, which means neither the verifier nor ProntoID can alter one after the fact. That is the one-line answer to why a court should believe it.
Every credential system fails the same way. The verifier checks once at onboarding and never looks again, so withdrawal becomes theoretical — a request sent into a void, with no way to know whether it landed.
ProntoID inverts it. Revocation is pushed, not polled, and the delivery is itself evidence.
The same subscription record gives the subject something no identity platform currently offers: a complete, queryable list of who holds an interest in their credentials, what they were told, and when.
This is what turns the privacy claim into something auditable rather than something promised.
Only three things vary between industries: the claim schemas, the issuer set and the policy. The ledger, presentation protocol, receipt format, revocation mechanism and audit retrieval never change.
Multi-credential site entry for construction and data centre projects, presented repeatedly across sites and main contractors.
Ski passes, equipment hire, event participation and any point of sale where cover must be confirmed before service.
Documented age, identity and consent for every person depicted, with withdrawal that propagates to platforms holding the content.
Legal service of documents, contract delivery and disclosure bundles where the receipt itself is the deliverable.
Annual confirmation for overseas beneficiaries, replacing notarised forms and embassy attendance.
Licensure, conduct certificates and competency records, portable across every employer and client who must check them.
Per-check pricing is transactional and churns with volume. Retention compounds, because the obligation to keep the evidence is statutory and the verifier cannot opt out of it.
Guaranteed retrievability across the retention window is a subscription with a legal reason to exist — the evidence is worthless to the customer if it cannot be produced on demand.
| Party | Charge | Rationale |
|---|---|---|
| Subject | Free | Consumers do not pay for credentials. No identity scheme has ever scaled on user fees. |
| Issuer | Free or paid integration | Issuers are an acquisition channel. Insurers and certifying bodies may pay for distribution. |
| Verifier | Per check, or per seat | They carry the liability, which is where the budget lives. |
| Retention | Annual, by receipt volume | The recurring line. Statutory retention periods are long and non-negotiable. |
The obvious challenge, answered in three tiers of increasing cost. Most deployments need only the first two.
Receipts are written under a compliance-mode object lock. Neither the verifier nor ProntoID can alter or delete one before the retention period expires. Immediate, inexpensive, and it removes ProntoID from the trust equation entirely.
Merkle roots are published and timestamped outside infrastructure ProntoID controls, so the sequence of status history cannot be reconstructed after the fact.
Receipts can carry qualified electronic timestamps issued under eIDAS, which carry a legal presumption of accuracy in EU proceedings. Qualified timestamps are procured from existing qualified providers — no trust service qualification is required to consume them.
Every segment runs on one behaviour: issue once, present many times, prove later, revoke if needed. Build that properly and each market becomes a configuration rather than a product.
The primitive everything else depends on. Nothing above this layer is meaningful until it is correct.
The actual product. Sealing, indexing and immutable write.
Thin by design — mostly schema validation and JSON handling.
Prove it on live users and a real liability before generalising anything.
Introduced once a second verifier exists and propagation becomes meaningful.
The real test. If this forces a change to the ledger or the receipt format, the abstraction leaked and must be fixed before a third.
An attestation receipt is a signed, tamper-evident artifact generated at the moment a verification check is performed. It records who was checked, which claims were presented, when, by which verifier, what the credential status was at that instant, and exactly what was disclosed. It is designed to remain defensible years later, in front of an auditor, regulator or court.
A verification result tells you the outcome of a check today. A receipt proves the check happened, on specified terms, at a specified time — and remains provable after the credential expires, changes or is revoked. Most identity vendors sell the result. ProntoID sells the evidence.
If a credential is revoked in 2028, a party who checked it in 2026 must still be able to prove it was valid at the time. ProntoID records status changes as append-only events, computes a Merkle root over the full status set at fixed intervals, and timestamps each root. Every receipt embeds the relevant status leaf plus an inclusion proof against the root that was current at check time.
Revocation is pushed, not polled. When a verifier performs a check they are subscribed to status changes on the claims they relied upon, for a declared interest period. A status change triggers a webhook to every subscribed verifier, and the subscription itself is recorded in the receipt — so the subject can prove who was notified and when.
Yes. Only three things vary per segment: the claim schemas, the issuer set and the verification policy. The ledger, presentation protocol, receipt format, revocation mechanism and audit retrieval are identical whether the use case is contractor site access, insurance verification, proof of life, content consent or identity-gated delivery.
Receipts are written to immutable object storage under compliance-mode retention locks, so neither the verifier nor ProntoID can alter them after the fact. Merkle roots are independently anchored and timestamped, and receipts can carry qualified electronic timestamps issued under eIDAS, which carry a legal presumption of accuracy in EU proceedings.
Only what the policy requires — typically a boolean or a range rather than the underlying attribute. A site supervisor learns that a safety certification is valid, not the certificate number. A resort learns that liability cover is active, not the policy details. Disclosure is minimised by default and every query is logged to the subject's disclosure ledger.
For the statutory retention period applicable to the verifier's obligation, which commonly runs to seven years or longer. Guaranteed retrievability across that window is provided as a subscription, because the evidence is worthless to the verifier if it cannot be produced on demand.
Selling evidence that holds up years later is not. If you carry a duty to check — and the liability that comes with getting it wrong — we should talk.
Point-in-time proofs · Propagating revocation · Immutable retention