GTVS Protocol Specification

Transaction Trust

Established by the Proof Token. The token proves that a business-customer interaction occurred. The protocol does not verify the nature of the transaction — only its existence.

Identity Trust

Established by email verification (OTP). The reviewer proves control of an email address. The address is immediately hashed after verification — the system retains only the irreversible hash.

Behavioral Trust

Established by the Reviewer Trust Score. RTS increases with consistent, verified behavior over time. Factors include: account age, review volume (logarithmic), review quality, behavioral consistency, identity verification level, and dispute history. The exact weights are proprietary.

Institutional Trust

Established by business certification. Businesses verify their identity through email, domain ownership (DNS TXT records), and protocol declaration. Each level increases the public certification status displayed on their profile.

Reviewer Identity

Reviewers are identified by the SHA-256 hash of their email address. The system never stores plaintext email. After OTP verification, the email is immediately converted to a one-way hash. The reviewer is pseudonymous — identifiable across reviews (same hash = same person) but not deanonymizable from the hash alone.

Business Identity

Businesses are identified by a unique slug and authenticated by an API key. Business identity is progressively verified through certification levels: email verification (OTP), domain verification (DNS TXT record), protocol declaration (dedicated DNS subdomain), and profile publication.

Proof Token Verification

Tokens are validated on submission: must exist, must be in ACTIVE status, must not be expired, must not be previously used. Upon use, the token is permanently marked USED with a timestamp. One token — one review, enforced at the database level.

Email Verification

Six-digit OTP sent to the claimed email address. Code expires after a defined period. Rate-limited per email and per IP. After successful verification, the email is hashed and the OTP is destroyed.

Domain Verification

Three-tier DNS verification using standard TXT records. Tier 1: ownership proof (unique token on main domain). Tier 2: protocol declaration (structured record on _veribureau subdomain, analogous to DMARC). Tier 3: profile publication. DNS is queried in real-time; records are not cached by the protocol.

Audit Chain Verification

Any party can verify the entire audit chain via public API or download the full chain for offline verification. The system iterates all records, recomputes each hash from the previous record, and confirms chain continuity. A discontinuity indicates that records have been altered. The verification endpoint returns: chain validity, total records, root hash, and timestamp.

Unverified Review Submission

Not possible without a valid Proof Token. Tokens are generated only by authenticated businesses. Each token is single-use. Automated creation is rate-limited and monitored.

Unauthorized Review Submission

A third party cannot generate tokens for another business. Even if tokens were obtained, the resulting reviews would come from new reviewers with minimal RTS, producing negligible score impact.

Coordinated Inauthentic Behavior

Coordinated review campaigns using many accounts are mitigated by the nonlinear weight function. New accounts have minimal influence. Building trust requires months of consistent, verified behavior across multiple businesses.

Score Manipulation by Operator

The operator (VeriBureau) cannot alter scores. CBS is computed deterministically from review data. Any manual alteration would require modifying the audit chain, which would break its cryptographic integrity and be publicly detectable.

Data Tampering

The audit chain makes tampering detectable. Each record contains a hash of the previous record. Altering any historical record invalidates all subsequent hashes. The chain is publicly verifiable.

Identity Duplication

Creating multiple identities is mitigated by email verification (one hash = one identity) and the logarithmic review volume factor in RTS (diminishing returns from more reviews).

Review Suppression

Reviews cannot be deleted by anyone — including the operator. The audit chain is append-only. Disputes add context but do not remove reviews. This is enforced architecturally.

Merkle Tree and Inclusion Proofs

Records are grouped into Batches. Each Batch constructs a binary SHA-256 Merkle Tree from canonical record hashes (RFC 8785). The Merkle Root commits to all records in the batch. Inclusion Proofs allow verification that a specific record exists in a batch without downloading the entire chain — logarithmic in size.

GET /api/v1/audit/proof/:recordId

RFC 3161 Trusted Timestamps

Each batch is timestamped by an independent RFC 3161 Timestamp Authority. This provides cryptographic proof of existence at a specific point in time, independent of the VeriBureau operator. The timestamp response can be verified offline using standard OpenSSL tools.

Ed25519 Signatures

All signed audit records use Ed25519 digital signatures. The public signing key is available at /signing-key.pub.

Key Rotation

The signing key can be rotated through a secure protocol: the old key signs the new key, and the new key signs the old key. This bidirectional binding is recorded in the audit chain. Historical records remain verifiable against the key that signed them.

DNS Anchoring

The current audit chain root hash is published as DNS TXT records across three independent domains. This provides an external, tamper-evident reference point outside the VeriBureau infrastructure.