Verification

The receiver does the verifying. “Verify” in the sidebar has “Verify grant” and “Look up a ledger”, and the User also has “Verify record”. Verifying only reads: it reads the inputs and the chain, and shows the result on the page.

Verify grant

Put in all three things, then press “Verify” once:

1. Grant: paste a grant code, or press “Choose a file…” to pick a grant file.
2. File (optional): the work you received.
3. Terms (optional): the terms file.

Under “Advanced options” you can point each hop of the grant chain at the issuer’s ledger folder, use other nodes, registry contract or start block, or give a moment to check as of; left empty, the values in Settings and chain time apply.

Where the issuer’s ledger comes from

The full check needs the issuer’s ledger. The app looks for it in this order:

1. This machine: the issuer’s ledger on this same machine.
2. The vault: ledgers carried by grant files you added, and upstream folders you saved.
3. A record kit: the kit or grant file you point to, and the ledger carried by the grant file being checked.
4. A publish address: the issuer’s https address. Each file is fetched, and the kit is used once it passes its check.

The result card has one “Ledger source” line per hop, naming where the ledger was found; “Replace…” or “Add…” lets you give an https address, record kit, ledger folder or grant file yourself.

The six checks

Grant signature

The entry was signed by the issuer’s key, and it is a grant.

Issuer ledger intact

The issuer’s ledger links up entry by entry, and the chain is whole.

In the issuer’s ledger

The grant is an entry in that ledger, and the key that signed it is entitled to write the ledger.

Confirmed on chain

The grant, or some entry after it, is on chain.

Within validity

The moment of the check falls between the start and end the grant states.

Not revoked

After reading the issuer’s whole ledger, the grant still stands.

A check still lacking a result shows a grey light with the reason beside it, for example issuer ledger missing, nodes still to be configured, a chain read that failed for now, or awaiting confirmation on chain; below, each kind of gap gets one sentence on what to do next.

Each hop of a sublicense gets its own six lights, and between hops a light “Hop N links to hop N+1”: the downstream ledger must be opened by the grantee the upstream grant names. The chain passes when every hop passes.

The result

The result card starts with three lines:

The summary at the bottom takes one of three forms: “All match” (the grant passed all six checks, and the file and terms, where given, match), “N do not match”, and “Not everything could be checked” (everything checked matches, but the grant has gaps or reading a file failed).

“Has gaps” is a grade of its own, meaning “no answer yet”, and it always stands apart from passing. When you meet it, check again in a few minutes; if you need the work urgently, ask the other side to supply what is missing.

A check fails on evidence in hand, such as a revocation or a wrong signature; “Not revoked” rests on a complete reading of the record. Where the record has gaps, the light turns grey and the grant reads “Has gaps”.

Checking a received file

When you receive the work itself, put it into the “File” box on Verify grant and press “Verify” together with the grant: the app computes the SHA-256 of the file’s bytes and compares it with the work hash the grant points to. “Details” shows the byte count, the computed digest and the expected digest side by side. After changing the file, press “Verify” again.

The record verifier

“Verify record” under the User’s “Verify”. Drop in a record kit folder, a grant file or a single record file, and it is checked as soon as it is in. The result card has three lights:

Record kit

Whether the kit is intact and its signatures valid; a single file is verified as a single file.

Anchor proofs on chain

How many match the chain and how many are still off chain; when reading the chain fails, “Not compared with the chain”.

Issuer ledger

The ledger check result; when a kit carries part of the ledger, “This is part of the ledger”.

The “Record by record” table below has one row per record in the kit: whether the original in the kit matches its recomputed fingerprint, the on-chain state, and the first anchor block time. With a record hash filled in under “Advanced options”, the record’s three depth readings appear as well.

Looking up a ledger

Fill in “Author address” and press “Read”: the app scans the chain for that address’s anchor proofs and looks for its ledger content in the four places above, in the same order. “Overview” has four tiles: ledger status, record count, grant history and last on chain; “Entry list” lists the other ledger entry by entry, and a click on a row opens a read-only detail. When anchor proofs turn up and the ledger content is missing, the overview says so plainly and the record count reads “Not obtained”.

Due diligence

A User does due diligence on “Look up a ledger”: fill in the record hash and the validity needed under “Advanced options”, and “Overview” gains a “Grant conflict check”, which tells you whether the period you need overlaps active grants the author has already issued. “Save snapshot” writes this result to a JSON snapshot for your own files.

The scope of a result

Every check rests on one specific reading: which chain, which registry contract, from which block, and which addresses. “All passed” means all six checks passed within what was read. To widen the scope, fill in “Advanced options” and check again.

Verifying writes two things on this machine: changes to the address book, and snapshot files written by “Save snapshot”.