Public Transparency Log
Append-only, Merkle-anchored registry of every sealed claim. Tamper-evident by design.
Registry Guarantees
Append-Only
Entries can only be added, never modified or deleted. Merkle tree structure makes any tampering detectable.
Publicly Auditable
Anyone can download the log, rebuild the Merkle tree, and independently verify integrity.
Inclusion Proofs
Compact Merkle proofs verify membership without downloading the full log.
Consistency Proofs
Prove newer log versions are strict supersets of older ones. Detects split-view attacks.
Signed Tree Heads
Every tree head is operator-signed. Clients pin known-good heads to detect unauthorized changes.
Timestamped
Each entry records submission time. Combined with Merkle ordering, provides verifiable proof of existence.
Recent Log Entries View all in Explorer →
| Index | Leaf Hash | Timestamp |
|---|---|---|
| #1 | — | 2026-01-25 22:25:03 |
Auditor Verification Guide
How to independently verify trust evidence using VLI
Why This Matters
Traditional audit evidence — screenshots, PDFs, exported logs — can be altered after the fact. There is no cryptographic binding between the evidence and the moment it was captured. VLI changes this by sealing evidence at capture time using Ed25519 signatures and SHA-256 digests, then anchoring each claim in a public Merkle-tree registry. As an auditor, you verify independently. You do not need to trust the client, the platform, or any intermediary.
What You'll Need
- ClearKey CLI — the open-source verification tool:
go install github.com/VerifyLinkInfra-cloud/clearkey@latest -
A
bundle.jsonfile from your client (exported from VAV, shared via link, or downloaded from the Marketplace as a sample).
Step-by-Step Workflow
1 Receive the bundle
Your client provides a bundle.json file. This can arrive via a VAV share link,
email attachment, or direct download. The bundle contains signed claims, evidence digests,
and the public key of the sealing identity.
2 Verify the bundle
Run ClearKey against the bundle. This checks every signature and re-computes every digest from the raw evidence.
clearkey verify-bundle audit.bundle.json
Output will list each claim with its verification status. A clean bundle shows VERIFIED
for every entry. Any mismatch means the evidence or metadata was altered after sealing.
3 Check SOC 2 coverage
If the bundle targets SOC 2 controls, summarize which controls have sealed evidence and which have gaps.
clearkey soc2 summarize audit.bundle.jsonOutput maps each control (CC1.1, CC6.1, etc.) to the claims that cover it, with timestamps and verification status.
4 Inspect individual claims
Drill into specific claims to see full metadata: signer identity, capture timestamp, evidence type, raw digest, and the Ed25519 public key.
clearkey inspect audit.bundle.json
Use --claim N to inspect a single claim by index, or pipe output to
jq for structured filtering.
5 Cross-check the registry
Verify that each claim was recorded in the public transparency log. This confirms the evidence existed at the stated time and has not been retroactively inserted.
clearkey registry verify --entry N --registry https://verifylinkinfra.com/registry-apiYou can also browse the registry visually using the Explorer. A valid inclusion proof means the claim is anchored in the Merkle tree and cannot be removed or altered without detection.
Understanding Verification Results
VERIFIED
Signature is valid. Evidence digest matches the sealed value. All referenced evidence files are present and intact. This claim has not been altered since sealing.
VERIFIED_PARTIAL
Signature is valid and the digest matches, but one or more evidence references are missing from the bundle. The claim metadata is authentic, but you cannot independently confirm all attached evidence. Request the missing files from the client.
UNVERIFIED
Verification failed. Either the signature does not match, the digest was recomputed to a different value, or the claim structure is malformed. Do not rely on this claim as audit evidence.
SAPI Trust Levels
Every sealed claim is bound to a SAPI identity. The trust level indicates how thoroughly that identity has been verified.
| Level | Meaning | What it proves |
|---|---|---|
| 0 | Unverified | Bare Ed25519 keypair. No identity binding. Proves only that the same key signed the data. |
| 1 | Email Verified | The signer demonstrated control of a specific email address at registration time. |
| 2 | Domain Verified | The signer demonstrated administrative control of an organization's domain (DNS TXT record). |
| 3 | Identity Verified | Real-person identity confirmed via a third-party identity provider (ID.me). Government ID was checked. |
| 4 | Attested | VLI has independently vouched for this identity through direct verification. Highest assurance level. |
Try It Now
Download a sample bundle from the Marketplace and verify it locally with ClearKey, or open one directly in the browser-based Bundle Viewer.
Sample Bundles Open Bundle ViewerVLI Trust Protocol
The cryptographic specification behind VerifyLink Infrastructure
Overview
The VLI Trust Protocol defines how digital evidence is sealed, anchored, and verified. It is an open specification — anyone can implement a compliant client or server. The protocol combines three well-understood cryptographic primitives into a coherent trust pipeline:
- Ed25519 — digital signatures for identity binding and tamper detection
- SHA-256 — content-addressable digests for evidence integrity
- Merkle trees — append-only transparency logs for public auditability
All structured data uses RFC 8785 JSON Canonicalization Scheme (JCS) to ensure deterministic serialization before signing. This eliminates ambiguity — the same logical document always produces the same byte sequence and therefore the same signature.
Cryptographic Primitives
| Primitive | Algorithm | Purpose |
|---|---|---|
| Signatures | Ed25519 (RFC 8032) | Binds each claim to a specific identity. 32-byte public keys, 64-byte signatures. Deterministic — no random nonce required. |
| Digests | SHA-256 (FIPS 180-4) | Content-addressable fingerprints for evidence files. Any change to the file produces a completely different digest. |
| Serialization | RFC 8785 JCS | Canonical JSON encoding. Sorted keys, no whitespace, deterministic number formatting. Applied before every signing operation. |
| Transparency | Merkle Hash Tree (RFC 6962) | Binary hash tree over log entries. Enables compact inclusion and consistency proofs without downloading the full log. |
| Encoding | Base64url (RFC 4648 §5) | URL-safe encoding for binary values (signatures, digests, public keys) in JSON payloads. |
Trust Pipeline
Evidence flows through four stages from creation to verification:
1. Seal
The sealing client computes a SHA-256 digest of the raw evidence, constructs a claim object containing the digest, metadata (timestamp, evidence type, framework mappings), and the signer's public key. The claim is then serialized using JCS and signed with the signer's Ed25519 private key. The resulting bundle contains the claim, signature, and optionally the raw evidence.
2. Anchor
The signed claim is submitted to the VLI registry server. The server appends the claim's leaf hash (SHA-256 of the signed claim) to the transparency log. The Merkle tree is recomputed and a new Signed Tree Head (STH) is produced. The server returns an inclusion proof and the updated STH.
3. Store
Sealed bundles are stored in the Verification Audit Vault (VAV). VAV organizes evidence by bucket and provides share links for auditors. Storage is optional — bundles are self-contained and can be verified offline using only the registry for anchoring.
4. Verify
Any party can verify a bundle by: (a) re-computing the SHA-256 digest of the evidence and comparing it to the claim, (b) verifying the Ed25519 signature against the signer's public key, and (c) checking the inclusion proof against the registry's current Signed Tree Head.
Claim Structure
A sealed claim is a JSON object with the following fields:
| Field | Type | Description |
|---|---|---|
version | string | Protocol version. Currently "1.0". |
claim_id | string | Unique identifier (UUID v4) for this claim. |
timestamp | string | ISO 8601 UTC timestamp of when the claim was sealed. |
signer | object | Contains public_key (base64url Ed25519) and optional sapi_id for identity binding. |
evidence | object | Contains digest (base64url SHA-256), content_type, filename, and size. |
metadata | object | Optional. Framework mappings (e.g. SOC 2 controls), labels, description. |
signature | string | Base64url Ed25519 signature over the JCS-canonicalized claim body (all fields except signature). |
Registry Protocol
The transparency log server exposes a minimal API conforming to the following operations:
| Endpoint | Method | Description |
|---|---|---|
/v1/log/entries | GET | List log entries with pagination. Returns leaf hashes, timestamps, and indices. |
/v1/log/entries | POST | Submit a new signed claim for anchoring. Returns index and inclusion proof. |
/v1/log/tree/head | GET | Get the current Signed Tree Head: root hash, tree size, timestamp, operator signature. |
/v1/log/tree/proof | GET | Get an inclusion proof for a given leaf index against a specified tree size. |
/v1/log/tree/consistency | GET | Get a consistency proof between two tree sizes. |
Security Properties
- Tamper evidence — Any modification to a sealed claim or its evidence invalidates the Ed25519 signature and breaks the Merkle inclusion proof.
- Non-repudiation — The signer's Ed25519 private key is required to produce a valid signature. With SAPI identity binding, the claim is tied to a verified real-world identity.
- Transparency — The append-only Merkle log ensures all claims are publicly visible. Split-view attacks are detectable via consistency proofs and gossip protocols.
- Offline verification — Bundles are self-contained. Signature and digest verification require no network access. Only registry anchoring checks need connectivity.
- Forward integrity — Once a claim is anchored, it cannot be removed from the log. Even if the signer's key is later compromised, existing claims remain valid up to their anchoring timestamp.
Reference Implementations
The protocol is implemented in Go. ClearKey is the open-source CLI for sealing, verifying, and interacting with the registry. The core library can be embedded in any Go application.
ClearKey CLI Live Registry