Scoring Methodology

How AttestSeal computes trust scores from publicly observable evidence.

Why independent, not a payment rail

AttestSeal is not a payment processor. We never move money. We never route a transaction. We are an independent attestation layer that sits beside the payment rail -- agents, payment protocols, and merchants cite us before a transaction happens. This separation is intentional.

Payment processors have a structural conflict of interest when scoring the merchants they process for. A rail that marked a paying customer as DENY would cannibalize its own revenue. A neutral third-party trust attestation -- scored from public evidence, signed cryptographically, cited by name in the payment flow -- is the primitive that compositional agent commerce needs. That is the role AttestSeal fills.

The signed evidence bundle we return is designed to be cited by payment protocols (AP2, MPP, Coinbase x402) without putting us on their critical path. Any party that trusts our Ed25519 public key can verify the attestation offline, after the fact, without contacting our API at all. That is not a feature a payment rail can replicate without first divesting their merchant relationships.

Principles

Evidence first, score second. Every trust score is a weighted summary of observable signals. The API returns the raw signal data alongside the score so agents can inspect, override, or weight signals differently for their own risk models. The score is a convenience; the evidence bundle is the product.

Versioned and reproducible. Every score includes a scoringModel field (currently attestseal-v1.5.1-weights). Raw signal data is stored separately from computed scores. When the scoring algorithm changes, every domain can be re-scored from stored data without re-crawling. Score changes are explicit, not silent.

Cryptographically signed. Every response is signed with Ed25519. The public key is published in the DID document. Agents and payment protocols can verify that a score was issued by AttestSeal and was not tampered with after issuance.

Signal categories and weights

Thresholds

Safety gate (v1.5.1). Even at 70+, a domain is held back from PROCEED if any of the following flags are present: NO_SSL, MALWARE_DETECTED, PHISHING_DETECTED, SPAM_LISTED, RECENTLY_COMPROMISED. These represent active risk that no positive evidence can outweigh. The gate prevents an attacker from gaming the threshold by stacking soft signals while skipping a baseline like SSL.

Confidence and cautionReason

A trust score alone does not tell an agent why a domain is not a clear PROCEED. Two new fields on every response make the call operational:

confidence (high / medium / low). Reflects how complete the evidence is, not how strong the signals are. A domain with six populated signals scored low is confidence: high, cautionReason: weak_signals -- the site genuinely looks thin. A domain with blocked content fetch and WHOIS timeout is confidence: low, cautionReason: incomplete_evidence -- we could not collect enough to judge. These are different risks to an agent and they deserve different policy.

cautionReason (set only when recommendation is CAUTION). One of:

• incomplete_evidence: content blocked, WHOIS unavailable, or fewer than three signals fully collected. The score is limited by missing data, not by bad data.
• weak_signals: we collected evidence across the categories and it is genuinely thin. The site needs improvement (privacy policy, DMARC, valid certificate, etc).
• new_domain: the domain is under one year old. Time is the missing signal; registration with verified business identity shortens the path to PROCEED.
• infrastructure: a CDN, API endpoint, or tracking domain scored against merchant criteria. The consumer-merchant model does not fit; the site owner can change siteCategory to api_service for a scoring model appropriate to their use case.

Agent integrations should branch on these fields explicitly. A CAUTION with confidence: low is reasonable to proceed on for small-dollar transactions. A CAUTION with new_domain is worth confirming with the user even at low value. Neither behaves like a blanket DENY.

Both fields are included in the Ed25519-signed payload. An agent cannot claim they did not know the reason -- the attestation carries it, cryptographically bound to the score.

Brand anchor (v1.5.1)

Domains that satisfy ALL four of the following conditions qualify for a brand-anchor floor based on their Tranco bucket:

1. Tranco rank in the top 50,000 (verified by billions of real-user requests across Cloudflare, Umbrella, Majestic, Quantcast)
2. Domain age of 5+ years
3. Clean reputation (no malware, phishing, or spam listings)
4. Valid SSL certificate

v1.5.1 introduced per-bucket floors so the most established brands score visibly higher than the anchor threshold rather than clustering at the floor:

This compositional anchor uses signals that cannot be purchased, spoofed, or fabricated. Long-term presence in the Tranco top-50K is the digital equivalent of a decades-long credit history: the sheer volume of real-user traffic required to reach that ranking makes gaming infeasible.

Any active safety signal (malware detected, phishing flag, spam listing, no SSL) instantly revokes the anchor, regardless of the domain's Tranco rank or age. This is the same safety-gate logic that applies to the PROCEED threshold itself.

Parent-company inheritance

Subdomains operated by a well-known parent inherit the parent's brand bucket when the registry confirms the relationship and the subdomain itself has valid SSL and clean reputation. For example, an Amazon-operated subdomain on cloudfront.net inherits Amazon's top-100 bucket. The registry of recognized parents lives in parent_companies.json; subdomains of unrecognized parents do not inherit.

assuranceBasis

Every PROCEED call carries an assuranceBasis field naming WHY the domain qualified, so agents can branch on the type of evidence behind the recommendation rather than treating all PROCEED calls identically:

• well_known_tranco_anchor — brand anchor fired (top-50K + age + clean rep + SSL)
• earned_proceed — consumer merchant earned PROCEED on signal merit alone
• api_service_earned — scored as an API service rather than a consumer merchant; different signal weights apply
• tenant_platform_earned — tenant subdomain on a recognized platform with its own signal evidence
• infrastructure_earned — CDN/DNS/network-infrastructure domain meeting infrastructure-appropriate criteria
• tracking — tracking pixel or analytics endpoint; always held back from PROCEED regardless of score
• not_recommended — CAUTION or DENY calls use this basis

The assuranceBasis is part of the Ed25519-signed payload, so an agent's policy logic can rely on it the same way it relies on the score itself.

Content-unscorable domains

Some sites block automated content fetching through bot protection (Cloudflare Enterprise, DataDome, PerimeterX). When the content signal cannot be collected, the scoring model drops content from the weighted sum and renormalizes the remaining five signals to sum to 100%. The response includes crawlability: "blocked" and the CONTENT_UNSCORABLE flag.

AttestSeal uses a six-tier fetch escalation ladder to maximize content collection:

1. Direct HTTP with realistic browser headers
2. Headless Chrome via Playwright (renders JavaScript)
3. Playwright through rotating residential proxy
4. Real Chrome on residential ISP via Tailscale
5. Internet Archive Wayback Machine (archived snapshots)
6. Protocol probe (fetches the site's 404 error shell, which typically contains footer links)

Registration and KYC

Site owners can register their domain to earn additional identity points through verified fields: business name, EIN/tax ID, address, phone, social profiles. Each verified field contributes independently to the identity score. Registration raises the practical ceiling above what automated signals alone can reach.

Future KYC tiers (enhanced verification, government ID, continuous monitoring) will raise the identity ceiling further, creating a clear incentive structure for merchants who want to maximize agent transaction conversion.

What the score does NOT measure

• Product quality. A site can score PROCEED and sell low-quality products.
• Business ethics. Fraud that doesn't manifest in technical signals (bait-and-switch, counterfeit goods) is not detectable from public data alone.
• Future state. Scores are point-in-time snapshots. A site that scores PROCEED today could be compromised tomorrow.
• Compliance. The score is not a legal certification. It is evidence-based assessment, not a guarantee.

Transparency

Every attestation is logged in a per-domain hash chain (tamper-evident transparency log). Auditors can verify the chain at /v1/log/{domain}/verify. The scoring model version, raw signal data, and computed score are all available via the API for independent verification.

The Ed25519 signing key's public component is published in the DID document. Key rotation follows a documented 12-month schedule with a 2-week overlap period.

Open methodology and open dataset

The scoring code, signal collectors, and test suite are public at github.com/AttestSeal/attestseal. The current scoring engine is server/app/scoring.py; the parent-company registry is parent_companies.json. The current scoring spec is spec/SCORING-V1.5.md (covers per-bucket brand floors, PROCEED-at-70 with safety gate, assuranceBasis taxonomy, parent-company inheritance). The historical v1.4 design notes remain at spec/SCORING-V1.4.md.

The full trust dataset for the Tranco top-1M will be published under CC-BY-4.0 — see /dataset for status. The dataset is the reference; the API is the distribution layer.

Security vulnerability reports go to [email protected]. Our disclosure policy is at /security. Signing key compromises, signature-verification bypasses, and transparency-log hash-chain tampering are the highest-severity issues we triage.

v1.5.1 distribution

Live numbers from the current registry (Tranco top-1M, scored under attestseal-v1.5.1-weights):

Top-100 PROCEED rate: 76 of 100 (the 24 in CAUTION are SSL-less infrastructure backbones such as DNS roots, CDNs, and update servers — not consumer payment endpoints). Top-1K: 68% PROCEED. Top-10K: 66% PROCEED. The long tail stays mostly CAUTION because consumer-facing signals are genuinely sparse, not because the model is conservative. Live counters are available at api.attestseal.com/stats.