ProofReg certificate verification — without ProofReg

This specification is CANON: the memo formats below are frozen (2026-07-04) and will never change. Extensions may only add new key=value pairs; parsers must ignore unknown keys.

1. What is anchored, where

ProofReg writes two kinds of memos on the public XRP Ledger:

The dedicated anchor account carries only certificate anchors, so its transaction list stays small and searchable. It never changes; if it is ever compromised, the successor account is announced publicly and that announcement is itself anchored from the old account.

2. Memo formats (frozen)

2.1 File registration (tx1)

PROOFREG|sha256=<64 lowercase hex>[|label=<text>][|reg=<text>]|id=<PR-YYYY-NNNNNN>[|ref=<PR-YYYY-NNNNNN>]

• sha256 — SHA-256 fingerprint of the registered file.
• label, reg — optional public label / self-declared registrant.
• id — the ProofReg certificate id of this registration.
• ref — optional; present on a Duo party-B registration (tx1b) and carries party A's certificate id.

2.2 Certificate anchor (tx2 / tx3)

PROOFREG-CERT|v=1|id=<PR-YYYY-NNNNNN>|sha256=<64 lowercase hex>|kind=solo|issued=YYYY-MM-DD
PROOFREG-CERT|v=1|id=<PR-YYYY-NNNNNN>|sha256=<64 lowercase hex>|kind=duo|issued=YYYY-MM-DD
PROOFREG-CERT|v=1|id=<PR-YYYY-NNNNNN>|sha256=<64 lowercase hex>|kind=dossier|issued=YYYY-MM-DD

• id — the certificate id printed on the certificate. For a Duo (linked) certificate this is party B's registration id, which carries both tx1b and tx3.
• sha256 — SHA-256 fingerprint of the certificate PDF file, byte-exact as delivered by email.
• kind — solo (one party), duo (linked two-party certificate) or dossier (self-anchored bulk dossier).
• With kind=dossier, id is the certificate id of the dossier PDF; any PRB-... bulk number lives in the PDF only, not in the memo.
• issued — the issue date printed on the certificate.

The memo prefixes differ on purpose: file anchors (PROOFREG) and certificate anchors (PROOFREG-CERT) can never be confused.

3. The four verification steps (as printed on every certificate)

1. Open any public XRP Ledger explorer and look up the fixed anchor account above.
2. Browse that account's transactions around the issue date.
3. Find the transaction whose memo carries this certificate ID (format PROOFREG-CERT).
4. Compute the SHA-256 of this PDF file and compare it with the sha256 in that memo. Equal = genuine.

These steps require nothing from ProofReg — not its website, not its cooperation, not its continued existence. The verify page at verify.proofreg.com is the convenient path, never the only path.

4. The filename convenience layer

After anchoring, the certificate file is named ProofReg_<certificate-id>_<anchor-transaction>.pdf. A filename is not part of a file's bytes, so this does not affect the fingerprint. If the file still carries its original name, the anchor transaction can be read directly from it. The filename is convenience, never proof: renaming breaks nothing, and a forged certificate wearing a genuine transaction name betrays itself the moment its fingerprint fails to match the anchored one.

5. Scope of the proof (frozen certificate footer)

Solo: "Independent proof that this fingerprint existed on the XRP Ledger before this timestamp. ProofReg does not link this fingerprint to a verified identity and does not assess the content."

Duo: "Independent proof that both parties each held a byte-identical copy of this file before their own ledger timestamp. It does not prove they agreed, read or approved it — it proves they had the same document. ProofReg does not link these registrations to verified identities and does not assess the content."

Specification version v1 — frozen 2026-07-04. Extensions add keys only; existing keys never change.