Service Companion

Operational companion to the Caliber Rating Methodology v2.0.1. The methodology paper is the source of truth on how ratings are computed; this document covers how the service is operated, what the API contract looks like, how the on-chain primitives compose, and the provenance lesson that produced v2.0. Live numbers as of 2026-05-28: 24,219 agents indexed · 56,709 jobs · 27,894 completed · 17,807 USDC volume settled · ~900 rated under v2.0.1.

1. Where to start

• Reading for the math? → the methodology paper.
• Reading to integrate? → the Builder's Guide is the 10-minute plain-language version.
• Reading for code samples? → the /integrate quick-reference.
• Reading because you're evaluating Caliber for institutional use? → keep going.

2. System architecture

Caliber is five loosely-coupled components, each with its own failure mode. Failures in any one degrade only the surface it serves.

2.1 Data ingestion. A self-hosted Arc Network full node is the source of truth for all on-chain data. A separate indexer process (indexer/arc/) decodes every ERC-8004 IdentityRegistry, ReputationRegistry, and ValidationRegistry event, and every ERC-8183 AgenticCommerce job-lifecycle event, into a Postgres schema (packages/db/src/schema.ts). Block-by-block catch-up with checkpoints; WebSocket live subscription on top.

A third-party RPC provider is integrated as a redundant cross-check on specific endpoints. No rating depends on this third-party feed. If it becomes unavailable, degraded, or changes pricing terms, the self-hosted node remains authoritative and the service continues at full functionality. The third-party feed is logged with its version for any cross-reference it produced, so a published rating remains reproducible even if the upstream feed later changes its own methodology.

2.2 Rating engine. TypeScript modules in rating/engine/ consume indexed events and produce ratings.

• completion-rate.ts — Step 1 feature extraction: completion %, dispute %, latency CV, concentration ratios, active escrow
• credibility.ts — Step 2.1 Bühlmann-style smoothing (default credibility constant k=20)
• survival.ts — Step 2.2 forward-looking estimate with exponential decay (60-day half-life) over resolved jobs; in-flight jobs treated as censored
• flags.ts — Step 2.3 five rule-based flags
• rating.ts — Step 3 orchestrator: composes 50% reliability + 25% forward + 15% network + 10% latency → score (0-100), assigns tier, attaches confidence label

2.3 Service layer. An Express application in rating/src/ exposes the public HTTP API on port 3100 (reverse-proxied to caliber-api.poko.blue). Seven endpoints; see §4.

2.4 On-chain primitives. Three Solidity contracts on Arc Testnet (chain 5042002) make the rating consumable from any contract on the chain. Addresses in §3.

2.5 Web surface. A Next.js application at caliber.poko.blue consumes the API and renders the public explorer, the demo marketplace, the rating-trajectory chart, and the methodology paper. It holds no privileged access — the same data exposed by the API drives the explorer.

3. On-chain primitives

Three contracts. v3 was deployed 2026-05-22 alongside the methodology v2.0 internal review (current published version: v2.0.1, byte-identical on-chain — see Appendix F).

3.1 The attestation struct

struct RatingAttestation {
    bytes32 chain;
    uint256 agentId;
    address agentAddress;
    uint8   tier;             // 0=Gold … 5=Dormant
    uint8   score;            // 0–100
    uint16  interactionCount; // count backing the confidence claim
    uint8   flags;            // bitfield: counterparty | validator | sybil | volume | dormancy
    bytes32 methodologyVersion;
    uint64  asOf;
    uint64  validUntil;
    uint256 nonce;
}

EIP-712 domain: name="Caliber", version="1", chainId=5042002. The signing key is held by the off-chain rating service; it rotates only via methodology version transitions, not via key updates.

3.2 Verification semantics

RatingVerifier.requireMinRating(att, signature, maxTierAllowed, blockingFlagMask) reverts unless:

• The signature recovers to the published signer
• att.tier <= maxTierAllowed (lower = stronger)
• (att.flags & blockingFlagMask) == 0 (caller picks which flags are dealbreakers)
• att.validUntil >= block.timestamp
• att.methodologyVersion matches the current or the immediately-previous version (30-day governance window)
• The nonce hasn't been replayed for this (chain, agentId) pair

3.3 Bond table

CaliberEscrow's bond rate per tier (initial values, owner-configurable on-chain):

setBondBpsForTier(tier, bps) lets the owner update any rate, capped at 5,000 bps (50%), emitting BondBpsByTierUpdated. Material changes follow the methodology §9 governance rule (30-day notice).

4. API surface

Two HTTP endpoints. Rating service at https://caliber-api.poko.blue (Express on port 3100, Cloudflare-Tunnel proxied) hosts the read + signed-attestation endpoints. Discovery + routing surface at https://caliber.poko.blue/api/v1 (Next.js, shares the web origin) hosts the Phase 2 additions. Both CORS-open. No authentication on read endpoints; the /attest endpoint binds signatures to a fresh nonce so replay protection lives on the verifier side.

Rating service (caliber-api.poko.blue):

Discovery + routing surface (caliber.poko.blue/api): added in Phase 2.

Freshness. Single-agent ratings are computed on demand from the indexed event stream — typically under 100 ms. Bulk and distribution endpoints are cached for 5 minutes. Snapshot endpoints serve materialized rows from the rating_snapshots table populated daily at 04:00 UTC by the caliber-snapshot.timer systemd unit.

Response shape. Every successful rating response includes methodology_version, computed_at, view (PIT or TTC), tier, score, confidence, confidence_label, flags, interaction_count, and a full factors object listing the inputs to the score computation. Refusal responses use HTTP 422 with a structured reason field (insufficient_interactions, insufficient_history, unknown_identity, rating_below_threshold, confidence_below_threshold).

Reproducibility. Every published rating can be re-derived from the public rating/engine/ code and the indexed event stream alone. The methodology version and the source block range are recorded with each response.

5. Data quality and sample-size disclosures

Live numbers as of 2026-05-22. The methodology paper §"Honest Disclaimers" is the canonical disclosure; this section is the data snapshot at the time of publication.

Indexed population. 18,481 agents observed on Arc Testnet's ERC-8004 IdentityRegistry. This is the full universe.

Searchable population. 2,298 agents have fetchable IPFS metadata and a published name; 1,786 of those land in one of the eight visible Discover categories (Trading 778, Validation 451, Research 209, Payments 138, Utility 88, On-chain Assistants 71, Autonomous Services 36, Content & Social 19). The other ~88% of the index registered with placeholder URLs (e.g., arc-agent.example.com/...) or shared CIDs that resolve to non-metadata content (most often a JPEG image, not JSON). This is a permanent floor on what /discover can browse; raw search across all 18K names + addresses remains available.

Rateable population. 728 agents meet the methodology's minimum data requirement (≥ 5 interactions across feedback + validations + jobs; ≥ 14 days of on-chain history). 625 agents have current PIT snapshots; 103 are refused by the engine's confidence floor.

Current tier distribution (2026-05-22):

The Watch concentration reflects the testnet's economic reality — most agents serve a small set of clients (counterparty-concentration flag fires) or have at least one self-deal job in their history (the v2.0 SybilPattern rule fires above 30% self-deal share with <5 unique clients). These flags are accurate, not noise; the threshold values are tuned for the dataset's current shape.

Active escrow under rated agents: $5,680.80 USDC. This is observed escrow, not a probability-weighted expected loss. Caliber v2.0 does not publish an expected-loss claim — that framing was retired in the v1 → v2 pivot (see §7).

6. Operating the service

6.1 Process model

6.2 Deploys

deploy/deploy.sh rebuilds the indexer + web, copies all service units to /etc/systemd/system/, reloads nginx, restarts services. The script needs sudo once; everything else cascades. Cloudflare Tunnel routes caliber.poko.blue → :3000 and caliber-api.poko.blue → :3100.

6.3 Contract redeploys

contracts/script/Deploy.s.sol redeploys all three contracts when the attestation struct changes (i.e. methodology version bumps). Costs ~$0.13 USDC per full redeploy on Arc Testnet. After deploy: update indexer/shared/chain-config.ts, web/src/lib/contracts/addresses.ts, .env (RATING_VERIFIER_ADDRESS), and the three ABI files in web/src/lib/contracts/abis/.

7. The v1 → v2 pivot (provenance lesson)

The earliest published Caliber methodology (v1.0, v1.0.1-tuning) used credit-rating vocabulary — Caliber-AAA … Caliber-D, PD/LGD/EAD/EL framing, a logistic-form scorecard. Three contracts were deployed under that methodology. The Builder's Guide and this companion both originally described it.

We rejected it before any external integrator built against it, for one reason: the dataset does not support credit-rating-grade claims. Credit rating agencies calibrate against decades of default data across millions of obligors; we have months of testnet data across roughly 16,000 agents with most having fewer than 10 jobs. Borrowing the vocabulary of credit rating (PD, LGD, EAD, EL, AAA/AA/BBB) without the evidence base was overclaiming. Any reviewer with five minutes of risk experience would have caught it.

The v2.0 methodology — counterparty performance rating with credibility-weighted reliability, survival analysis, and rule-based risk flags — fits the data we actually have. Reliability engineering and actuarial credibility theory are appropriate to sparse data and honestly disclosable. Tier names (Gold / Silver / Bronze / Pending / Watch / Dormant) describe what was observed without borrowing authority from regulatory letter grades.

What was preserved across the pivot:

• The architecture (self-hosted node, indexer, Postgres schema, service layer, web surface)
• The brand (Caliber)
• The on-chain primitive pattern (verifier + gateway + escrow), though all three were redeployed under the new struct
• The reproducibility principle (every rating re-derivable from open code)

What was retired:

• The PD/LGD/EAD/EL framing
• The Caliber-AAA … Caliber-D tier scale
• The logistic-regression scorecard
• The budget × PD × LGD bond formula (replaced by the tier-stepped table in §3.3)

The v1.x code is preserved at the git tag methodology-v1.0.1-final for archaeology.

8. Compliance posture and licensing

What Caliber is not. Not a bank credit-rating agency, not an NRSRO, not a regulatory capital input, not investment advice, not an endorsement. Consumers using Caliber in regulated contexts must perform their own model validation.

Licensing. Methodology under CC BY 4.0. Engine and contract source under MIT. Required attribution when reused: Caliber by PokoBlue, with a link to caliber.poko.blue/methodology where the medium supports it.

Operator. Service operated by PokoBlue (x.com/PokoBlue99). The engine, contracts, indexer, web app, and SDK are open source on GitHub under MIT. The methodology paper is licensed CC BY 4.0. The methodology paper plus the published factor breakdown in every rating response is sufficient for anyone to independently reproduce any published rating.

Caliber Rating Service Companion · methodology v2.0.1 · updated 2026-05-24