Verified Facts Protocol: How to Help AI Stop Hallucinating About Your Company

The Problem: AI Hallucinating About Your Company

Ask ChatGPT when your company was founded. Who your clients are. What products you offer. There is a high chance you will get a wrong answer. Or a completely fabricated one.

AI systems hallucinate facts about companies every day. Wrong founding dates, fabricated client lists, nonexistent products. And businesses have had no standardized way to fight this.

The Scale of the Problem

Problem	Example
Wrong founding date	"The company was founded in 2018" (actually 2013)
Fabricated clients	"Clients include Tesla and Apple" (never happened)
Incorrect products	"The company sells a CRM system" (actually does automation)
Outdated information	"The team is 5 people" (actually 50)

This is not just a reputation issue. AI systems are becoming the primary source of information for B2B decisions. If AI gets your company facts wrong, you lose customers.

---

The Solution: Verified Facts Protocol

Verified Facts Protocol is an open protocol for publishing cryptographically signed facts about your organization in a machine-readable format. Think of it as robots.txt, but for facts.

How It Works

1. Create a JSON file with facts about your company
2. Sign each fact with an Ed25519 private key
3. Host the file at /.well-known/verified-facts.json

AI crawlers (GPTBot, ClaudeBot, PerplexityBot) discover the file through the standard .well-known mechanism and get verified facts.

File Structure

{
  "version": "1.0",
  "protocol": "verified-facts/ed25519/v1",
  "entity": {
    "name": "Your Company",
    "domain": "example.com",
    "founded": "2020",
    "url": "https://example.com/"
  },
  "publicKey": {
    "algorithm": "ed25519",
    "format": "base64-raw-32bytes",
    "value": "<32-byte-public-key-base64>"
  },
  "generated": "2026-02-22T00:00:00.000Z",
  "expires": "2026-08-22T00:00:00.000Z",
  "facts": [
    {
      "id": "fact-001",
      "claim": "The company was founded in 2020",
      "category": "company",
      "evidence": "https://example.com/about",
      "claimHash": "sha256-hash-in-hex",
      "signature": "ed25519-signature-in-base64"
    }
  ]
}

---

Technical Details

Signing Process

For each fact, 4 steps are performed:

1. Encode the claim string as UTF-8 bytes
2. Compute SHA-256 hash to get a 32-byte buffer
3. Sign the hash buffer with Ed25519 private key to get a 64-byte signature
4. Encode the signature as base64

claimBytes = utf8encode(fact.claim)
hashBuffer = sha256(claimBytes)          // 32 bytes
claimHash  = hex(hashBuffer)             // 64 hex chars
signature  = base64(ed25519_sign(key, hashBuffer))  // 88 base64 chars

Verification in Node.js

import { createHash, verify, createPublicKey } from 'crypto';

function verifyFact(claim, signature, publicKeyBase64) {
  // 1. SHA-256 hash of the claim
  const hash = createHash('sha256').update(claim, 'utf8').digest();

  // 2. Decode signature from base64
  const sig = Buffer.from(signature, 'base64');

  // 3. Reconstruct public key from raw 32 bytes
  const pubKeyRaw = Buffer.from(publicKeyBase64, 'base64');
  const pubKeyDer = Buffer.concat([
    Buffer.from('302a300506032b6570032100', 'hex'),
    pubKeyRaw
  ]);
  const publicKey = createPublicKey({
    key: pubKeyDer, format: 'der', type: 'spki'
  });

  // 4. Verify Ed25519 signature
  return verify(null, hash, publicKey, sig);
}

Browser Verification

import { verify } from '@noble/ed25519';
import { sha256 } from '@noble/hashes/sha256';

async function verifyFact(claim, signature, pubKeyBase64) {
  const msgHash = sha256(new TextEncoder().encode(claim));
  const sig = Uint8Array.from(atob(signature), c => c.charCodeAt(0));
  const pubKey = Uint8Array.from(atob(pubKeyBase64), c => c.charCodeAt(0));
  return verify(sig, msgHash, pubKey);
}

---

Why Ed25519?

Property	Value
Key size	32 bytes (256-bit)
Signature size	64 bytes
Performance	~76,000 signatures/sec
Security	128-bit equivalent
Browser support	Chrome 137+, fallback via @noble/ed25519

Ed25519 was chosen for its compact signatures (64 bytes vs 256+ for RSA), fast verification, and widespread library support. The protocol is algorithm-agnostic by design — future versions will support Ed448 and post-quantum algorithms.

---

Live Example: 6 AppStar Domains

AppStar has deployed the Verified Facts Protocol across 6 domains with 56 verified facts:

Domain	Facts	Link
appstar.com.ru	20	Open JSON
appstarsecurity.ru	8	Open JSON
appstarcrm.ru	7	Open JSON
appstarseo.ru	7	Open JSON
appstarsmm.ru	7	Open JSON
appcourses.ru	7	Open JSON

Every fact is signed with the same Ed25519 key and can be verified using the online validator: appstar.com.ru/ru/verified-facts/

---

Experiment Results

We ran an experiment: we asked ChatGPT about facts from our verified-facts.json.

What We Found

1. ChatGPT does not read the JSON directly yet — GPTBot crawls the site but does not specifically parse .well-known/verified-facts.json
2. Structured data helps — having a consistent JSON with facts helps AI give more accurate answers
3. External confirmation works — ChatGPT verified our claims through Google Play Store and other sources
4. Consistency is key — when the same facts are repeated on the website, in JSON, in Schema.org, AI trusts them more

Key Takeaway

The Verified Facts Protocol works right now as a single source of truth for your website. Even without direct AI provider support, having a structured facts file:

• Ensures data consistency across all pages
• Provides machine-readable format for any parser
• Is ready for integration once AI crawlers start supporting it

---

A Call to AI Providers

We propose that AI crawlers check /.well-known/verified-facts.json when indexing a domain:

Crawler	Company	Proposal
GPTBot	OpenAI	Parse verified-facts.json when crawling
ClaudeBot	Anthropic	Use facts as ground truth
PerplexityBot	Perplexity	Prioritize signed facts
Googlebot	Google	Integrate into Knowledge Graph

Benefits for AI Providers

1. Reduced hallucinations — verified facts as ground truth
2. Attribution — each fact links to evidence
3. Freshness — generated and expires fields ensure timeliness
4. Trust — cryptographic signatures prevent tampering
5. Efficiency — structured data is easier to parse than HTML

---

Getting Started

Step 1: Generate Keys

# Generate Ed25519 key pair
openssl genpkey -algorithm Ed25519 -out private.pem
openssl pkey -in private.pem -pubout -out public.pem

Step 2: Create Facts and Sign

Use the script from the GitHub repository:

git clone https://github.com/appstar-com-ru/verified-facts-protocol
cd verified-facts-protocol
npx tsx examples/generate.ts

Step 3: Host the Files

# Copy to .well-known directory of your website
cp verified-facts.json /var/www/html/.well-known/
cp public.pem /var/www/html/.well-known/verified-facts-key.pub

Step 4: Verify

npx tsx examples/verify.ts https://yourdomain.com/.well-known/verified-facts.json

---

Roadmap

• v1.0 — Ed25519 signed facts in JSON format
• Live validator at appstar.com.ru/verified-facts
• 6 production deployments
• JSON Schema published at well-known URL
• npm package verified-facts-sdk
• Blockchain anchoring (Polygon/Base) for immutable timestamps
• Proposal to AI providers (OpenAI, Anthropic, Perplexity, Google)
• IETF Internet-Draft

---

Related Standards

Standard	Relationship to Verified Facts
RFC 8615	.well-known URI convention
RFC 8032	Ed25519 signature algorithm
JSON-LD	Complementary; verified-facts is simpler and signature-focused
Schema.org	Complementary; Schema.org describes structure, verified-facts proves authorship
robots.txt	Same .well-known discovery pattern
llms.txt	Complementary; llms.txt provides context, verified-facts provides signed claims

---

Conclusion

The Verified Facts Protocol is the first step toward a world where AI systems can distinguish verified facts from hallucinations. The protocol is simple, open, and already running in production.

GitHub: github.com/appstar-com-ru/verified-facts-protocol

Validator: appstar.com.ru/ru/verified-facts/

Specification: SPECIFICATION.md