Check the invoice without seeing it.

The registry adds its own signature to every state change through Optima Prime, so the record of who said what, and when, can't be quietly edited later.

Invoice fields are low-entropy. A plain hash of a supplier tax ID, an invoice number and an amount can be guessed by brute force in minutes. A shared secret key doesn't fix that either, because every member would need the key and any of them could run the guesses.

Countersign uses an oblivious pseudorandom function (OPRF) over the ristretto255 group. Your side blinds the fields before they leave; the registry applies its secret key to a value it can't read; your side removes the blind. The result is a fingerprint only computable with the registry's help, one rate-limited query at a time.

# on the lender's or supplier's side
fields = normalise(supplier_tax_id, customer_tax_id, invoice_no,
                   issue_date, amount_cents, currency, due_date)
P      = hash_to_group(fields)          # ristretto255 point
r      = random_scalar()
B      = r * P                          # blinded; reveals nothing

# at the registry (never sees fields or P)
Z      = k * B                          # k = registry key

# back on your side
F      = hash(fields, (1/r) * Z)        # = hash(fields, k * P)
fingerprint = "cs1:" + F

Normalising matters as much as the cryptography: the same invoice must give the same fingerprint whether it came from a PDF, a CSV row or an accounting system. Tax IDs, invoice numbers, dates and amounts each get one canonical form before hashing.

Planned The registry key k is split between independent key holders, so no single party, including us, can compute fingerprints alone.

One fingerprint can only say "same" or "different". To catch a $180 invoice resubmitted as $9,000, each invoice gets several fingerprints over different groups of fields:

A check returns one of: never seen (no record, which is not a pass), registered and unchanged, registered but fields differ, already pledged to another lender, or countersigned by the customer.

Signing at issue stops later changes and double sales. It can't stop a supplier from inventing an invoice. Only the customer knows whether it owes the money, so the customer's confirmation is the core of the product.

1. Countersign finds and verifies the customer's payables contact itself. The supplier never supplies it.
2. The customer gets a link. No account, no app.
3. They confirm with a passkey (WebAuthn: Face ID, Touch ID, Windows Hello or a security key). The passkey signs a challenge built from the invoice fingerprint, the amount and a hash of the pay-to account.
4. That signature is attached to the invoice's record and to the lender's receipt.

Because the pay-to account is part of what the customer signs, a later request to send the money somewhere else needs a new countersignature from the customer. Large payables teams can register a hardware security key instead; Optima Prime already verifies those as standard OpenSSH signatures.

"Who pledged first" is only worth something if the registry can't reorder or hide entries. Every pledge and release is appended to a Merkle tree, in the style of Certificate Transparency (RFC 6962). The tree's head is signed and time-stamped by an independent RFC 3161 time-stamp authority.

Any member can ask for an inclusion proof (my pledge is in the log) and a consistency proof (today's log extends yesterday's without rewriting it). Entries hold fingerprints and blinded member IDs, so the log can be audited without exposing anyone's book.

Countersign signs through Optima Prime, our signing server. Its /v1/attest endpoint signs a statement that a given key attested a given SHA-256 at a given time, without ever seeing the data behind the hash. That is exactly the shape of an invoice fingerprint.

Every receipt carries two signatures over canonical JSON: Ed25519 and the post-quantum ML-DSA-87, so the evidence stays checkable for the years a dispute can run. The public keys are published, and a receipt can be verified offline with open tools.

{
  "statement":  "check",
  "fingerprint":"cs1:7f3a91c0e24b0d8f55a1c9e73b02aa64",
  "result":     "fields_differ",
  "member":     "m_9c2e",                 // blinded
  "time":       "2026-10-10T16:42:09Z",
  "signatures": { "ed25519": "…", "ml_dsa_87": "…" }
}

Field names above are illustrative. The receipt format is being finalised.

A hit tells a lender that a match exists. It never says which lender holds it. Identities are released only with the holder's consent or under legal process, under a written member rulebook.

Countersign is closed source. The receipts aren't: their format and the public keys are published, so checking one never depends on trusting our code.

• If someone inside the customer's payables team is in on the fraud, their countersignature is a lie too. Confirmation history across lenders and matching against actual payments help, but nothing fully stops collusion.
• Detecting a double sale needs the other lender to be a member. An empty network only protects your own book.
• A receipt is evidence. It does not perfect a lien or set legal priority between lenders.