{ "markdown": "

\n \"OTR\n

\n\n

OTR Protocol

\n\n

\n The merchant trust layer for AI agent commerce
\n Deterministic, verifiable, open-source merchant trust scoring for the agentic economy
\n Protocol v4.1\n

\n\n

\n \"npm\"\n \"MIT\n \"GitHub\n \"Issues\"\n

\n\n

\n Specification •\n Scoring Algorithm •\n Quick Start •\n Packages •\n Contributing\n

\n\n---\n\n## The Problem\n\nAI agents are increasingly making purchase decisions on behalf of consumers. The agentic commerce stack is taking shape -- but there is a critical missing layer:\n\n```\n┌──────────────────────────────────────────────────────────────────┐\n│ AI Agent Commerce Protocol Stack │\n├──────────────────────────────────────────────────────────────────┤\n│ │\n│ Visa TAP ·············· Agent Identity Verification │\n│ Google UCP ············ Structured Data Exchange │\n│ Stripe ACP ············ Payment Processing │\n│ │\n│ ┌───────────────────────────────────────────────────────────┐ │\n│ │ OTR Protocol ····· MERCHANT TRUST VERIFICATION ◀━━━━━ │ │\n│ │ \"Is this merchant safe to buy from?\" │ │\n│ └───────────────────────────────────────────────────────────┘ │\n│ │\n│ Visa TAP answers \"Who is the AI agent?\" │\n│ Google UCP answers \"What products are available?\" │\n│ Stripe ACP answers \"How do I pay?\" │\n│ OTR answers \"Should I trust this merchant?\" ◀━━ ONLY OTR │\n│ │\n└──────────────────────────────────────────────────────────────────┘\n```\n\nWithout OTR, AI agents operate blind -- unable to distinguish a legitimate retailer from a sophisticated scam site. This exposes consumers to fraud and erodes trust in the entire agentic commerce ecosystem.\n\n## The Solution\n\n**OTR (Open Trust Registry)** provides deterministic, verifiable merchant trust scores using **6 verification dimensions**, a **10-layer anti-fraud pipeline (Layer 0: Google Web Risk one-vote veto + Layers 1-9: core detection engine)**, and **three-layer immutable audit trail**. It is fully open-source (MIT), machine-readable, and designed from the ground up for AI agent consumption.\n\n### Key Properties\n\n- **Deterministic** -- Same inputs always produce identical outputs. Any validator can reproduce any score.\n- **Verifiable** -- All data sources are publicly accessible. No hidden factors or proprietary signals.\n- **Unforgeable** -- Verification dimension weighted at 40% in public assessment. SEC filings, Wikidata entries, and 10-year domain age cannot be faked.\n- **Tamper-proof** -- SHA-256 hash chain + Base L2 blockchain anchoring + IPFS monthly snapshots.\n- **Fair** -- No pay-for-trust. Scores reflect behavior, not subscription level.\n- **Category-aware** -- Three site categories (ecommerce / saas / non_commerce) with tailored scoring weights.\n- **Safety-first** -- Google Web Risk Layer 0 one-vote veto: flagged domains get score=0, status SUSPENDED.\n\n## Quick Start\n\n```bash\n# Verify any merchant instantly\nnpx @otr-protocol/validator verify nike.com\n\n# Output:\n# ┌──────────────────────────────────────────────┐\n# │ nike.com GOLD │\n# │ Trust Score: 88/100 Category: ecommerce │\n# │ OTR-ID: OTR-1C-7F3A2B9E4D1C-K4 │\n# │ │\n# │ Verification: 85 ██████████████░░ │\n# │ Security: 80 █████████████░░░ │\n# │ Governance: 72 ████████████░░░░ │\n# │ Transparency: 75 ████████████░░░░ │\n# │ Data Quality: 65 ██████████░░░░░░ │\n# │ Fulfillment: -- (COLD mode) │\n# └──────────────────────────────────────────────┘\n```\n\n### For AI Agents (MCP Server)\n\nThe OTR MCP Server uses the standard [Model Context Protocol](https://modelcontextprotocol.io) and works with **all MCP-compatible clients**.\n\n**Claude Desktop / Claude Code** -- add to `claude_desktop_config.json`:\n\n```json\n{\n \"mcpServers\": {\n \"otr\": {\n \"command\": \"npx\",\n \"args\": [\"@otr-protocol/mcp-server\"]\n }\n }\n}\n```\n\n**Cursor / Windsurf / Cline** -- same configuration in `.cursor/mcp.json` or equivalent. Any client implementing the MCP specification works out of the box.\n\nNow any AI agent can verify merchants in natural language:\n\n> *\"Is nike.com trustworthy?\"* --> OTR returns trust score 88/100, badge GOLD, and a 6-dimension breakdown (Verification, Security, Governance, Transparency, DataQuality, Fulfillment) with evidence sources.\n\n### Two MCP Tools — One Call = Complete Answer\n\n| Tool | Description | Returns |\n|------|-------------|---------|\n| `verify_merchant` | Complete merchant profile in one call | Trust score (0-100), badge, 6-dimension breakdown, safety status (Google Web Risk), site classification (ecommerce/saas/non_commerce), entity data, policy URLs, data sources |\n| `search_registry` | Search the OTR merchant registry | Paginated merchant list with scores, badges, and recommendations |\n\n**Design philosophy:** AI agents should get everything they need in a single tool call. `verify_merchant` returns trust assessment + purchase capabilities + links + policy URLs + data freshness — no need to chain multiple calls.\n\n### TypeScript SDK\n\n```typescript\nimport { OtrClient } from \"@otr-protocol/sdk\";\n\nconst otr = new OtrClient();\nconst result = await otr.verify(\"nike.com\");\n\nconsole.log(result.trustScore); // 88\nconsole.log(result.badge); // \"GOLD\"\nconsole.log(result.dimensions); // { verification: 85, security: 80, ... }\n\n// Search the registry\nconst results = await otr.search(\"electronics\", { minScore: 70 });\n```\n\n### Core Scoring Engine\n\n```typescript\nimport { calculateTrustScore } from \"@otr-protocol/core\";\n\n// Deterministic: same inputs always produce identical outputs\nconst result = calculateTrustScore({\n hasSecFiling: true,\n hasStockSymbol: true,\n stockExchange: \"NYSE\",\n hasWikidataId: true,\n trancoRank: 500,\n domainAgeYears: 15,\n // ... 40+ evidence fields\n});\n\nconsole.log(result.trustScore); // 88\nconsole.log(result.badge); // \"GOLD\"\nconsole.log(result.tier); // \"TIER_4\"\n```\n\n## Architecture\n\n```\n ┌─────────────────────────────────┐\n │ AI Agent / Application │\n │ \"Should I buy from example.com?\" │\n └──────────────┬──────────────────┘\n │\n ┌───────────────────┼───────────────────┐\n │ │ │\n ┌─────▼─────┐ ┌──────▼──────┐ ┌──────▼──────┐\n │ MCP Server │ │ REST API │ │ SDK │\n │ (stdio) │ │ /api/otr │ │ npm pkg │\n └─────┬──────┘ └──────┬──────┘ └──────┬──────┘\n │ │ │\n └───────────────────┼───────────────────┘\n │\n ┌──────────────▼──────────────┐\n │ OTR Scoring Engine │\n │ @otr-protocol/core │\n │ │\n │ ┌─────────────────────────┐ │\n │ │ 6 Dimension Evaluators │ │\n │ │ Verification | Security │ │\n │ │ Governance | Transparency│ │\n │ │ DataQuality | Fulfillment│ │\n │ └─────────────────────────┘ │\n │ ┌─────────────────────────┐ │\n │ │ 10-Layer Anti-Fraud │ │\n │ │ Domain Age | SSL | DNS │ │\n │ │ Pattern | Tranco | ... │ │\n │ └─────────────────────────┘ │\n │ ┌─────────────────────────┐ │\n │ │ Brand Fast-Track │ │\n │ │ SEC + Tranco + Wikidata │ │\n │ └─────────────────────────┘ │\n └──────────────┬──────────────┘\n │\n ┌─────────────────────────┼─────────────────────────┐\n │ │ │\n ┌────────▼────────┐ ┌──────────▼──────────┐ ┌─────────▼─────────┐\n │ Public Data │ │ Merchant Bridge │ │ Immutable Audit │\n │ Sources │ │ (Verified Only) │ │ Trail │\n │ │ │ │ │ │\n │ SEC EDGAR │ │ Product Catalog │ │ SHA-256 Hash │\n │ Wikidata │ │ Order Data (agg) │ │ Chain │\n │ Tranco List │ │ Delivery Metrics │ │ Base L2 Anchoring │\n │ DNS Records │ │ Tracking Numbers │ │ IPFS Snapshots │\n │ SSL Certs │ │ (desensitized) │ │ │\n │ Finnhub.io │ │ │ │ │\n │ Google Web Risk │ │ │ │ │\n │ Website Scan │ │ │ │ │\n └─────────────────┘ └──────────────────────┘ └───────────────────┘\n```\n\n## How Scoring Works\n\n### 6 Trust Dimensions\n\nWeights vary by site category:\n\n| # | Dimension | E-Commerce COLD | SaaS COLD | AUTH Mode | What It Measures |\n|---|-----------|:-:|:-:|:-:|------------------|\n| 1 | **Verification** | **0.40** | 0.37 | 0.10 | Stock exchange, Wikidata, GLEIF LEI, domain age, Tranco rank, payment processors |\n| 2 | **Security** | 0.15 | 0.20 | 0.10 | SSL/TLS, DMARC, SPF, DKIM, HSTS, DNSSEC, CSP, CAA, WAF, security.txt (15 signals) |\n| 3 | **Governance** | 0.20 | 0.23 | 0.10 | Privacy policy, GDPR/CCPA, terms, refund/return, shipping, cookie consent (10 signals) |\n| 4 | **Transparency** | 0.10 | 0.15 | 0.05 | robots.txt, sitemap, Schema.org, hreflang, AI crawler policy, llms.txt, about page |\n| 5 | **Data Quality** | 0.15 | 0.05 | 0.25 | E-commerce: 22 product data signals. SaaS: 12 platform signals (API docs, SLA, pricing, security certs) |\n| 6 | **Fulfillment** | -- | -- | **0.40** | Delivery speed, return window, tracking, shipping policy (COLD mode: not scored) |\n\n### What Each Dimension Measures\n\n| Dimension | Evaluates |\n|-----------|-----------|\n| Verification (V) | Is this a real, registered business? SSL certificate type, GLEIF LEI, Wikidata entity, SEC filings, domain age, payment processor detection |\n| Security (S) | Is the site technically secure? DMARC, SPF, DKIM, HSTS, CSP, WAF, DNSSEC configuration |\n| Governance (G) | Does it follow business rules? Privacy policy, refund policy, shipping policy, cookie consent, regulatory compliance |\n| Transparency (T) | Is it machine-readable? robots.txt, Schema.org structured data, llms.txt, protocol endpoint availability |\n| Data Quality (D) | Is product/service data complete? Product count, image coverage, price format consistency, category taxonomy depth |\n| Fulfillment (F) | Does it deliver on promises? Order completion rate, delivery time, return rate, dispute rate (AUTH mode only — requires merchant data) |\n\n### Why Weights Differ by Category\n\n- **E-commerce**: Verification weighted highest (0.40) because buyers need to trust the store before purchasing. Identity signals (SEC filings, Wikidata, domain age) are the strongest defense against fraudulent shops.\n- **SaaS**: Security (0.20) and Governance (0.23) weighted higher because SaaS platforms handle user data and need clear policies. Users entrust ongoing access to their information.\n- **Non-commerce**: Not scored. Sites that do not sell products or services lack applicable commerce dimensions (product data, checkout, fulfillment).\n\n### Three Site Categories\n\n| Category | Description | Scoring |\n|----------|-------------|---------|\n| `ecommerce` | Online stores selling physical/digital products | Full 6-dimension scoring with product D signals |\n| `saas` | Software-as-a-Service platforms | Tailored weights (V=37%, G=23%) with 12 SaaS D signals |\n| `non_commerce` | Non-commercial sites (Wikipedia, government, etc.) | Not scored -- returns identity signals only |\n\n### Non-Commerce Sites\n\nSites classified as `non_commerce` (e.g., Wikipedia, government portals, news sites) are not scored:\n- `trustScore`: null\n- `badge`: null\n- `scanStatus`: \"non_commerce\"\n- Basic verification data (SSL, entity info) is still returned, but no numerical trust score is assigned.\n\nReason: Non-commerce sites do not sell products or services, so trust scoring dimensions (product data, checkout, fulfillment) do not apply.\n\n### OTR-ID\n\nUnique identifier assigned to each evaluated domain.\n\n**Format**: `OTR-1{mode}-{fingerprint}-{checksum}`\n- `1` — Protocol version\n- `mode` — `C` (COLD: pre-authorization scan) or `A` (AUTH: merchant authorized)\n- `fingerprint` — 12 uppercase hex chars, derived from SHA-256 of the normalized domain (first 48 bits)\n- `checksum` — 2 Base36 chars (Luhn mod-36 validation + deterministic salt)\n\n```\nExample: OTR-1C-7F3A2B9E4D1C-K4\n```\n\n**Properties**:\n- **Deterministic**: Same domain always produces the same fingerprint\n- **Irreversible**: SHA-256 is cryptographically one-way; truncated to 48 bits, the original domain cannot be recovered\n- **Collision-resistant**: ~281 trillion possible fingerprints (2^48)\n\n**Lifecycle**:\n\n| Event | Result | Status |\n|-------|--------|--------|\n| First scan | OTR-1C generated | ACTIVE |\n| Merchant authorizes | Upgraded to OTR-1A (same fingerprint, recalculated checksum) | UPGRADED |\n| Domain identity change detected | OTR-ID revoked (set to NULL), domain re-enters cold-start | REVOKED |\n| Google Web Risk flags domain | Score forced to 0 | SUSPENDED |\n| Anti-gaming multiplier < 0.10 | Score forced to 0 | SUSPENDED |\n\nIdentity change is detected when weighted signals exceed threshold 3: GLEIF entity mismatch (3), nameserver change (2), content similarity < 30% (2), Wikidata P856 mismatch (2), domain parking > 90 days (2), SSL organization change (1).\n\n### Google Web Risk (Layer 0 Safety)\n\nGoogle Web Risk operates as a Layer 0 one-vote veto, separate from dimension scoring:\n- Flagged domain → `trustScore = 0`, `otrIdStatus = SUSPENDED`, `safety.googleWebRisk = true`\n- Does not participate in dimension weight calculation\n- Overrides all other signals regardless of their values\n\n### Two Scoring Modes\n\n```\nCOLD Mode: Public Assessment (no merchant cooperation needed)\n═══════════════════════════════════════════════════════════════\n E-Commerce: V (0.40) + S (0.15) + G (0.20) + T (0.10) + D (0.15) = Score\n SaaS: V (0.37) + S (0.20) + G (0.23) + T (0.15) + D (0.05) = Score\n\n Nike (ecommerce): V=85×0.40 + S=80×0.15 + G=72×0.20 + ... = 83 GOLD\n Scam site: V=10×0.40 + S=100×0.15 + G=90×0.20 + ... = 39 UNRATED\n ↑ can't game Verification\n\n\nAUTH Mode: Verified Merchant (merchant provides API access)\n═══════════════════════════════════════════════════════════════\n F (0.40) + D (0.25) + V (0.10) + S (0.10) + G (0.10) + T (0.05) = Score\n\n Good merchant: F=90×0.40 + D=85×0.25 + ... = 78 SILVER\n Bad merchant: F=30×0.40 + D=40×0.25 + ... = 38 UNRATED\n ↑ bad fulfillment = low score\n```\n\n### Trust Badges\n\n| Badge | Score | AI Agent Action |\n|-------|:-----:|-----------------|\n| **PLATINUM** | 90-100 | Safe to recommend with high confidence |\n| **GOLD** | 80-89 | Strong trust, recommended for AI agents |\n| **SILVER** | 70-79 | Recommend with standard caution |\n| **BRONZE** | 60-69 | Display only, suggest user verify independently |\n| **UNRATED** | 0-59 | Warn user about insufficient trust data |\n\n> Scores 95+ trigger human review recommendation. No hard cap. If safety.status is \"DANGEROUS\" (Google Web Risk), DO NOT recommend regardless of score.\n\n## 10-Layer Anti-Fraud Engine\n\nOTR prevents fraudulent sites from gaming the system through a 10-layer detection pipeline:\n\n```\nLayer 0 Safety Check Google Web Risk API — malware/phishing one-vote-veto (instant block)\nLayer 1 Domain Age Certificate history analysis (crt.sh)\nLayer 2 SSL Security HTTPS/HSTS verification, self-signed detection\nLayer 3 DNS Security DMARC, SPF, DKIM policy completeness\nLayer 4 Domain Pattern Brand impersonation (amaz0n-deals.xyz), suspicious TLDs\nLayer 5 Tranco Rank Independent traffic ranking verification\nLayer 6 Content Analysis Phishing keywords, parked domains, empty pages\nLayer 7 Redirect Chain Cross-domain redirect detection\nLayer 8 Cross-Signal Multi-signal correlation and accumulation rules\nLayer 9 Anti-Gaming Signal-brand mismatch, identity-gameable gap, template suspect\n ▼\n Layer 0 DANGEROUS = immediate rejection (one-vote-veto)\n Single CRITICAL signal = immediate rejection\n Fraud score > 30 = rejection\n Anti-gaming multiplier applied to gameable dimensions\n```\n\n### Anti-Gaming Detection Patterns (Layer 9)\n\n| Pattern | Trigger | Multiplier |\n|---------|---------|:----------:|\n| Signal-Brand Mismatch | Gameable avg ≥ 80 + no Tranco/Wikidata/SEC + Identity < 30 | 0.5x |\n| Identity-Gameable Gap | Identity < 20 + gameable avg > 70 + no established identity | 0.7x |\n| Template Site Suspect | Domain < 1yr + no Tranco/Wikidata/SEC + gameable avg > 60 | 0.5x |\n| Domain Age Gate (<6mo) | Domain under 6 months | Cap at 50 |\n| Domain Age Gate (<1yr) | Domain under 1 year | Cap at 75 |\n\n### Anti-Gaming in Practice\n\n| Scenario | Old v3 Score | New v4 Score | Change |\n|----------|:----:|:----:|:------:|\n| Nike (legitimate brand) | 83 GOLD | 83 GOLD | -- |\n| Scam site (perfect tech) | 39 UNRATED | 35 UNRATED | -4 |\n| Scam site + anti-gaming | 28 UNRATED | 22 UNRATED | -6 |\n\n## Data Integrity\n\nOTR uses a three-layer immutable audit trail to ensure that historical scores cannot be tampered with:\n\n```\nLayer 1: PostgreSQL Hash Chain (real-time, $0/year)\n├── Every score change records SHA-256 hash\n├── Each record links to previous via prev_hash\n├── Any modification breaks the chain → detectable\n└── verifyChainIntegrity() → instant verification\n\nLayer 2: Base L2 Blockchain Anchoring (daily, ~$0.37/year)\n├── Daily chain-head hash written to Base L2 smart contract\n├── Externally verifiable by anyone\n├── AWS KMS hardware security for signing keys\n└── Transaction hash stored in otr_l2_anchors table\n\nLayer 3: IPFS Monthly Snapshots (monthly, $0/year via web3.storage)\n├── Full registry exported as content-addressed JSON\n├── CID (Content Identifier) is immutable\n├── Anyone can retrieve and verify the snapshot\n└── CIDs recorded in otr_snapshots table\n```\n\n**Public Verification Endpoints:**\n```\nGET /api/otr/audit/chain-integrity Verify hash chain completeness\nGET /api/otr/verify/:domain/history Score history with trend data\nGET /api/otr/audit/l2-anchors Base L2 anchoring records\nGET /api/otr/audit/snapshots IPFS snapshot CID listing\n```\n\n## Multi-Source Consensus\n\nOTR never blindly trusts any single data source. Every external data point must pass cross-validation:\n\n```\nSource Weights (not all sources are equally trustworthy):\n google-web-risk 1.0 Google Safe Browsing → one-vote-veto on DANGEROUS\n sec.gov 1.0 Government source → highest trust\n dns-query 0.9 Infrastructure → high trust\n tranco-list.eu 0.9 Academic source → high trust\n wikidata.org 0.8 Community source → high but editable\n finnhub.io 0.7 Commercial API → moderate-high trust\n website-scan 0.6 Self-reported → moderate trust\n product-sample 0.5 Product page sampling → public but limited scope\n merchant-api 0.4 Merchant-declared → low trust (can be faked)\n\nConsensus Rules:\n ✓ 2+ sources agree → accepted (high confidence)\n ✗ Sources disagree → rejected (keep existing value)\n ⚠ Single source drift > 30% → anomaly flagged\n 🔒 3+ anomalies from one source → auto-quarantine\n```\n\n## Data Desensitization\n\nWhen merchants provide fulfillment data, OTR applies 4 levels of privacy protection:\n\n| Level | Stage | What Happens |\n|:-----:|-------|--------------|\n| L1 | Pre-transmission | Customer names → SHA-256 hash, addresses → country+city only, emails/phones/payments → deleted |\n| L2 | In transit | TLS 1.3 + HMAC-SHA256 signature + nonce anti-replay |\n| L3 | Server-side | Instant aggregation to statistics, raw data never persists |\n| L4 | Audit trail | Only metadata logged (timestamps, counts), never content |\n\n## Why OTR?\n\n| Feature | OTR | Trustpilot | BBB | Google Merchant |\n|---------|:---:|:---:|:---:|:---:|\n| AI-native API (MCP Server) | **Yes** | No | No | No |\n| Deterministic scoring | **Yes** | No | No | No |\n| Open-source algorithm (MIT) | **Yes** | No | No | No |\n| No pay-for-trust | **Yes** | No | No | Yes |\n| Multi-source verification | **6 dimensions** | 1 (stars) | 1 (grade) | Partial |\n| Anti-gaming detection | **10-layer** | No | No | No |\n| Machine-readable output | **Full JSON** | Partial | No | Partial |\n| Immutable audit trail | **3-layer** | No | No | No |\n| Category-aware scoring | **3 types** | No | No | No |\n| Conformance test suite | **Yes** | N/A | N/A | N/A |\n| Data desensitization | **4-level** | N/A | N/A | Partial |\n\n## Packages\n\n| Package | Description | npm |\n|---------|-------------|-----|\n| [`@otr-protocol/core`](packages/core) | Deterministic scoring engine -- the reference implementation | [![npm](https://img.shields.io/npm/v/@otr-protocol/core.svg?style=flat-square)](https://www.npmjs.com/package/@otr-protocol/core) |\n| [`@otr-protocol/mcp-server`](packages/mcp-server) | MCP Server for AI agents (Claude, Cursor, Windsurf, Cline) | [![npm](https://img.shields.io/npm/v/@otr-protocol/mcp-server.svg?style=flat-square)](https://www.npmjs.com/package/@otr-protocol/mcp-server) |\n| [`@otr-protocol/validator`](packages/validator-cli) | CLI tool for merchant verification | [![npm](https://img.shields.io/npm/v/@otr-protocol/validator.svg?style=flat-square)](https://www.npmjs.com/package/@otr-protocol/validator) |\n| [`@otr-protocol/sdk`](packages/sdk) | TypeScript client SDK for application integration | [![npm](https://img.shields.io/npm/v/@otr-protocol/sdk.svg?style=flat-square)](https://www.npmjs.com/package/@otr-protocol/sdk) |\n\n## Conformance Testing\n\nAny OTR implementation must pass the standard conformance test vectors:\n\n```bash\nnpm run conformance\n```\n\nThe test suite validates **determinism**: identical inputs produce identical outputs across all implementations (TypeScript, Python, Go, Rust). This ensures a merchant's trust score is the same regardless of which validator computed it.\n\nTest vectors in [`conformance/test-vectors.json`](conformance/test-vectors.json) cover:\n- Site category detection (ecommerce / saas / non_commerce)\n- Scoring mode detection (COLD vs AUTH)\n- Individual dimension scoring with category-specific weights\n- Badge and tier assignment (PLATINUM/GOLD/SILVER/BRONZE/UNRATED)\n- Anti-gaming detection and penalty application\n- Google Web Risk safety override\n- Non-commerce exclusion\n- Edge cases (empty data, null fields, boundary values)\n\n## Scoring Integrity\n\nOTR Protocol maintains the integrity and independence of merchant trust scores through these commitments:\n\n1. **No Score Selling** -- Trust scores cannot be purchased, sponsored, or commercially influenced. No premium tiers, sponsorships, or partnerships affect scoring.\n2. **No Pay-for-Trust** -- Subscription status has zero impact on OTR scores. Free-tier merchants and enterprise customers are evaluated identically.\n3. **No Human Override** -- All scores are computed algorithmically. No individual can manually adjust any score.\n4. **Algorithmic Transparency** -- The entire algorithm is open-source (MIT). Anyone can audit, verify, and reproduce any score. Re-scanning the same domain produces the same score (deterministic pipeline).\n5. **Data-Driven Only** -- Scores reflect independently verifiable signals. Merchant-submitted data is marked `verified=false` with `scoringWeight=0` and requires corroboration from at least 2 independent authoritative sources.\n\n**Enforcement:** Open-source code + conformance tests + governance process + 10-layer anti-gaming detection with compounding multipliers.\n\n### Mission\n\nOTR exists to create a fair, transparent trust layer for the AI agent commerce era. Any merchant -- regardless of size or brand recognition -- can earn trust through verifiable performance. The only way to improve a score is to improve actual trust signals.\n\n## Public Data Sources\n\nOTR evaluates merchants using publicly accessible data only (COLD mode). No merchant cooperation required.\n\n| Source | Data | Verifiable |\n|--------|------|-----------|\n| DNS Records | SPF, DMARC, DKIM, DNSSEC, MTA-STS, CAA | Yes — standard DNS queries |\n| SSL/TLS Certificates | Type (DV/OV/EV), issuing CA, organization | Yes — certificate transparency logs |\n| HTTP Headers | HSTS, CSP, X-Frame-Options, Permissions-Policy | Yes — any HTTP client |\n| Website Content | Policy pages, product catalog, Schema.org markup | Yes — public web pages |\n| Tranco List | Domain popularity ranking (top 1M) | Yes — tranco-list.eu (academic) |\n| WHOIS / crt.sh | Domain age, certificate history | Yes — public registries |\n| Wikidata | Entity verification via P856 (official website) | Yes — wikidata.org (CC0) |\n| GLEIF | Legal Entity Identifier (LEI), ISO 17442 | Yes — gleif.org |\n| SEC EDGAR | US regulatory filings | Yes — sec.gov |\n| Finnhub / OpenFIGI | Stock exchange listings, ticker resolution | Yes — finnhub.io / openfigi.com |\n| Google Web Risk | Malware, phishing, unwanted software detection | Yes — Google API |\n\n## Roadmap\n\n| Phase | Status | Description |\n|-------|:------:|-------------|\n| Phase 1 | **Complete** | Open-source scoring engine, MCP Server, CLI, SDK, conformance tests |\n| Phase 2 | **Complete** | Hash chain integrity, L2 anchoring, IPFS snapshots, multi-source consensus, data desensitization, score decay, Google Web Risk Layer 0 safety, 3 site categories (ecommerce/saas/non_commerce), SaaS D-dimension 12 signals, COLD/AUTH scoring modes |\n| Phase 3 | Planned | IETF Internet-Draft standardization, Python/Go SDKs, academic paper |\n\n## Contributing\n\nWe welcome contributions. See [CONTRIBUTING.md](CONTRIBUTING.md) for detailed guidelines.\n\n**Key requirements for scoring algorithm changes:**\n1. RFC-style proposal in `spec/`\n2. Updated conformance test vectors\n3. Determinism verification\n4. Review by maintainers\n\n## License\n\n[MIT](LICENSE) -- ORBEXA\n\n---\n\n

\n Protocol Specification •\n Scoring Algorithm •\n Governance Model •\n Contributing Guide •\n Code of Conduct\n

\n\n

\n Built by ORBEXA -- Infrastructure for Agentic Commerce\n

\n", "bytes": 28628, "sha": "3de7df508c08bbf2d0dd0170e96d93eefc6281591a3a8dfb2cb8a9e2e4c76947", "repo_slug": "yb48666-ctrl/otr-protocol-by-orbexa", "fonte": "repo", "truncated": false, "api": "https://agentalog.com/api/listings/mcp_io_github_yb48666_ctrl_otr_protocol_6ec64038/readme" }