Caliber Rating Methodology v2.4.0

A Counterparty Performance Rating for On-Chain AI Agents

by PokoBlue · @PokoBlue99 · May 2026 Live at caliber.poko.blue

Current version: v2.4.0 · Active on Arc Testnet from 2026-10-21. Both v2.3.0 and v2.4.0 attestations verify on-chain: RatingVerifier accepts the current methodology version and the immediately previous one. That overlap has no end date, though each attestation still expires at its own validUntil (see §Versioning). Lineage: v2.0.1 (2026-05-24, first public version) → v2.1.0 (2026-06-14) → v2.2.0 (2026-10-10) → v2.3.0 (2026-10-16) → v2.4.0 (2026-10-21). Earlier versions (v1.x and internal-review v2.0) live in §Appendix F for audit only.

TL;DR

The Caliber Rating rates AI agents on Arc based on what they've actually done on-chain — jobs completed, jobs disputed, who paid them, how fast they delivered, who vouches for them. Everything comes from public events on Arc (ERC-8004 + ERC-8183). No vibes. No off-chain noise. If you can read our table below, you can audit any rating we publish.

Why This Exists

Arc is filling up with AI agents. Some are great. Some are sketchy. Some are brand new and haven't proven anything yet.

If you're about to fund an escrow, hire an agent for a job, or let one act on your behalf — you want a quick read on whether this thing actually delivers.

That's what Caliber rates. Not whether an agent is "smart." Not whether it has a cool name. Just: based on its on-chain track record, how likely is it to do the job?

What We Look At (The Core Table)

This is the foundation. Everything in our rating traces back to one of these signals. If you understand this table, you understand the whole system.

A few things this table is honest about

• We rate what's observable. No off-chain promises, marketing, or Twitter clout factors in. If it didn't emit an event, we don't see it.
• Performance is two-sided. A "success" requires a counterparty to accept the work. A "failure" requires one to reject it. We're rating the agent, but the data is jointly produced.
• Settlement is the truth signal. Until USDC actually moves, the value is just promised, not realized. We track all three states but anchor our economic metrics to settled value only.

What this table can't tell us

• Whether the work was actually good. If the evaluator was sloppy and accepted bad work, that's a "success" in our data. We inherit evaluator noise.
• Whether the agent is one person, a team, or pure code. Doesn't matter for the rating, but worth saying.
• Whether the counterparty is high-quality. A high-volume agent serving sketchy evaluators looks the same as one serving rigorous ones — for now. We'll fix this later.

How the Rating Gets Built

Three steps, left to right. Each step builds on the previous; each step is documented and reproducible.

fig. 1 — rating pipeline

The table below is the same diagram in copy-pasteable form for accessibility and indexing.

Step 01 — features (deterministic):

Step 02 — math (three techniques):

• 2.1 Credibility weighting — blends agent record with population mean. Small samples pulled toward average. Actuarial method, 1960s.
• 2.2 Forward-looking estimate — recency-weighted probability of next-job success. Skips jobs still in progress. Returns one probability.
• 2.3 Risk flags — disclosed heuristics: concentration, sybil pattern and a volume anomaly push the agent to the Watch tier; 90 days without activity makes it Dormant (see the flag table).

Step 03 — output (example):

tier        ● Silver           describes observed behaviour, not predicted default
score       78 / 100           weighted composite of Step 02 outputs
range       75 – 80            reliability part, 90% under this method's own assumptions
confidence  low                set by the number of completed jobs

Score composition (weighted sum of Step 02 outputs; revised in public):

Each step builds on the last. The detail of each step is below.

Step 1: Turn events into features

We take the raw events from the table and summarize them per agent. Things like:

• Completion rate — how often does this agent's work get accepted?
• Dispute rate — how often does it get rejected?
• Speed — how long between funding and delivery? Is it consistent or all over the place?
• Volume — how much USDC has actually settled through this agent?
• Network reach — how many different counterparties? How many different validators?
• Concentration — is this agent mostly serving one client, or spread across many?

All of this is just summarizing what happened. No predictions yet. No magic. If you ran the same SQL against the same node, you'd get the same numbers.

The engine reads each agent's jobs created in the last 30 days and its feedback from the last 30 days, both measured in blocks, and every validation it has received. An agent registered fewer than 14 days ago, or with fewer than 5 of these in total, is not rated: it has no tier, and its page says why. An agent's age is from its registration date; where the index holds no date, from its registration block, counted back from the chain head at Arc's 0.5-second block time (from v2.3.0; before it, the fallback used 1 second per block from the newest registration, which doubled such an agent's age). Validator diversity and the validator-concentration flag read every feedback record and validation the agent has ever received, and cross-chain presence reads the owner's agents on other chains as they are when the rating is computed. Feedback published by Caliber Factor's own outcome contracts is left out of the feedback count, feedback volume and the validator figures (Appendix F, 25 September 2026).

From v2.4.0, Caliber's own agents are not rated, and a job whose client is Caliber's own counts toward no agent's rating. "Caliber's own" means the wallets on Caliber's own-wallet lists and every labelled Caliber test or demo account. Such an agent's page says it is one of Caliber's own test agents and not rated, and no attestation is signed for it. The volume-anomaly and dormancy flags still read every job the agent was provider for, Caliber clients' included: they measure activity, not evidence. The formula, weights, tier gates and confidence cutoffs are unchanged.

Provider-controlled jobs (v2.2.0). A completed job is left out of an agent's evidence when the provider could have controlled its outcome: (a) its evaluator, the address that approved the work, is the provider itself; (b) its evaluator received USDC from the provider in an earlier block than the one in which the job completed; or (c) its client is not the provider and received USDC from the provider in an earlier block than the one in which the job completed.

What "provider" means. It is the address the job pays; on Arc, that is the agent's owner.

What counts as a transfer. Any USDC transfer of more than zero counts, native or ERC-20, at any earlier time. A transfer of zero is not counted: anyone can make one appear to come from any address. It can be a payment for something else, so (b) and (c) are deliberately broad. They see only a direct transfer from the provider's own address; money sent through another wallet or a contract is not traced.

Where the data comes from. On Arc, every USDC movement, native or ERC-20, emits one Transfer event from the system address 0xfffffffffffffffffffffffffffffffffffffffe. Caliber copies the provider's outgoing transfers into its own index, read today from the Arc testnet explorer. It is refreshed each day before the rating run. Where a provider's outgoing transfers have not all been read (its history was cut off, or a transfer came after the last daily read), (b) and (c) apply to what was read. A gap can only leave a job counted; it never leaves one out.

What leaving out means. A job left out is removed from every input the engine derives from jobs: completion_rate, dispute_rate, delivery latency (p50 and cv), settled_usdc_volume, unique_counterparties, counterparty_hhi and self_deal_share (Step 1); the forward-looking estimate (Step 2.2); the interaction count and the confidence line; and the job-based flags. It is as though the job had not been recorded.

What is not affected: jobs that did not complete (rejected and expired jobs still count against the agent whoever controlled them, and open jobs are treated as before); feedback; validations. A job whose client is the provider itself stays subject to the sybil-pattern flag as before. It is left out only when (a) or (b) also holds.

Step 2: Apply the math

Three techniques. Each does specific work.

1. Smoothing for small samples.

Here's a common trap: Agent A has 4 jobs, all successes (100%). Agent B has 200 jobs, 180 successes (90%).

Naive ranking says A is better. Reality says B has actually proven something and A might just be lucky.

We fix this by blending each agent's individual record with the population average, weighted by how much data we have. New agents with thin history get pulled toward the average. Agents with long history get to stand on their own record.

The technique is called credibility weighting. Insurance actuaries have used it since the 1960s. It's the right tool for sparse data.

2. Forward-looking estimate.

A backward-looking completion rate is fine, but you actually want to know: what's the chance the next job goes well?

So we run a model that:

• Weights recent jobs more than old ones
• Skips jobs that are still in progress: only finished jobs count

You get one probability, with no range of its own. How much data stands behind it is the confidence line (§How sure we are). We don't pretend to know more than we do.

3. Risk flags.

Statistics assume nobody's gaming the system. On-chain, that's not safe. So we add some heuristic flags on top:

These are rules, not models. We disclose every one. If any of the first four fires, the agent is pushed to the Watch tier regardless of its other numbers. Dormancy outranks them: a dormant agent is rated Dormant.

Step 3: The actual rating

What you see on the site is always three things together — never one in isolation.

The tier

Why two columns: the production min-jobs values (50/20/5) are the methodology's intended bar — they require a real track record before assigning a quality tier. Arc Testnet has not yet accumulated enough genuine agent-to-agent commerce for those thresholds to populate meaningfully. The testnet values (2/2/1) are an interim calibration so the system is demonstrably operational from day one. As real economic activity accumulates, the testnet column will be retired and the production thresholds activated. See §Appendix F · Calibration history for the schedule.

We don't use AAA/AA/BBB letter grades on purpose. Those grades come from credit rating agencies and carry decades of meaning about default probability that we cannot back up with this data. The medal scheme is intentional: Gold > Silver > Bronze is a hierarchy every culture recognises at a glance, with no inherited semantics about probability of default.

The score

A number from 0–100. It's a weighted combination of:

• 50% — smoothed completion reliability (Step 2.1)
• 25% — forward-looking success probability (Step 2.2)
• 15% — network endorsement (validator diversity, attestations, net of adverse evidence)
• 10% — operational reliability (latency consistency)

These weights are our starting point. We'll adjust as we get more data and we'll publish every change.

Adverse evidence (v2.1.0). The network-endorsement sub-score is built from three components, each capped: validator diversity (up to 50 points, +10 per unique validator), feedback volume (up to 30 points), and cross-chain presence (up to 20 points). As of v2.1.0, the feedback-volume component is computed net of adverse evidence: a negative validator observation — an on-chain feedback_events record with score < 50, such as a signed conformance breach — subtracts 40 positive-feedback-equivalents for each adverse observation before the 30-point cap is applied. Concretely:

net_feedback   = max(0, positive_feedback_count − 40 × adverse_feedback_count)
feedback_score = min(30, net_feedback)

The net is floored at 0, so the sub-score never goes negative. Because the feedback-volume component caps at 30 points, a weight of 40 means a single verified adverse observation zeroes out an agent's entire accumulated feedback-volume credit — producing a visible score drop and a tier_down when the agent sits near a tier floor. The rationale: a signed, on-chain-attested breach of a pre-agreed delivery spec is a strong, deliberate adverse signal — categorically heavier than casual positive sentiment, because it is a counterparty putting their signature behind "this agent did not deliver what was agreed." A thumbs-up is cheap; a signed breach is not.

How sure we are

Every rating ships with a confidence line. Things like:

• "High confidence — based on 247 completed jobs over 9 months"
• "Moderate confidence — based on 31 completed jobs"
• "Low confidence — only 6 jobs observed; score anchored to population average"
• "Watch flag: concentration on single counterparty"

This isn't optional. If you hit our API, you get the score AND the confidence in the same response. Anyone hiding their confidence level is selling you something.

The score range

From v2.3.0, every rating with at least one finished job in the window carries a score range: the uncertainty in the reliability part of the score, on the jobs observed so far, at 90% under this method's own assumptions. It comes from the same smoothing as the score. Step 2.1 counts the population's completion rate as 20 jobs' worth of evidence and adds the agent's own completed and failed jobs. The smoothed reliability is the middle of the resulting distribution (a Beta distribution), and the range is its 5th to 95th percentile, carried through the reliability's 50% weight. The forward estimate, network and latency are held at their values. The range is given in whole points.

The tier is assigned on the score, not on the range, and nothing that reads a tier, such as Caliber Factor's agent-quality gate, reads the range. A range that reaches across a tier floor says the tier could differ on the record so far. Because the population counts as 20 jobs, a short record's range carries that assumption as well as the agent's own jobs. An agent with no finished job in the window has no range: a missing range means no evidence, not certainty. The range is published with the score in the rating API and in each rating's JSON and markdown. It is not part of the signed attestation.

Reproduce Anything

The whole point of doing this on-chain is that you don't have to trust us. You can rebuild any rating yourself.

Here's what you need:

1. An Arc node — self-hosted or RPC provider
2. The contract addresses for ERC-8004 and ERC-8183, and the USDC Transfer events from the system address 0xfff…fffe (v2.2.0)
3. Our feature definitions (the methodology paper documents every input)
4. Our math — the formulas in this paper (Caliber's own implementation is private; the paper is the specification)
5. Our rating composition rules from Step 3

We publish today:

• ✅ Raw event data via the public API
• ✅ Computed features per agent (factor breakdown in every rating response)
• ✅ The composition weights (50/25/15/10 — documented above)
• ✅ Final ratings with every component broken out
• ✅ Methodology version stamped on every API response

Source code: the methodology paper is licensed CC BY 4.0 and published on this site. Contract source is verified on the Arc Testnet explorer for each contract Caliber deploys; the per-agent splitters are created by the splitter factory, whose verified source includes the splitter's (checked 1 October 2026). The engine, indexer, web app and SDK are private; the former public repository is archived. The Caliber brand and the canonical issuer signing key (0xbF017698BB2c936D54a74DCABF68Df42800bAA84) are reserved — only attestations signed by the canonical signer are recognised by the deployed RatingVerifier as "Caliber ratings."

If you run the same inputs against your own implementation and get a different rating, we want to hear about it. That's the point.

The Attestation Primitive

The product is the attestation, not just the rating.

Caliber publishes every rating as a signed EIP-712 attestation that any contract on Arc can verify and consume. The rating describes an agent's track record; the attestation makes that description composable into on-chain logic. Any contract on the chain can read a signed Caliber claim and do something with it — gate access, require collateral, weight a vote, route payments, set fees, condition disbursements.

This is what makes Caliber a trust primitive rather than a dashboard. We compute and sign; the network builds on top.

What the attestation carries

Each EIP-712 RatingAttestation carries: the agent's chain + on-chain ID + wallet address, the tier (0–5 enum), the score (0–100), the interaction count, the flags bitfield, the methodology version, a freshness window, and a replay-protection nonce. A contract that verifies the signature against the published Caliber signer key knows the claim is current, complete, and untampered.

Reference implementations

We built two reference contracts to show what consuming an attestation can look like:

• RatingGateway — a thin wrapper over ERC-8183 createJob() that refuses jobs whose providers fall below a caller-chosen tier threshold (or trigger blocking flags). This is access gating: the application decides who is allowed to participate.
• CaliberEscrow — a tier-stepped performance-bond escrow. Agents lock USDC collateral when accepting a gated job, sized by their tier. The bond returns on completion or slashes to the original client on rejection/expiry. This is commitment device: the application creates an additional consequence for failure beyond the ERC-8183 protocol's default refund.

These are examples, not the methodology's outputs. Other contracts can consume the same attestation differently — and we expect they will. A staking module could weight votes by tier. A marketplace could set listing fees inversely to tier. A payment router could disburse to Gold agents at lower latency. The attestation is the primitive; the integrations are open-ended.

A note on bonds vs. rating

A bond is a commitment device, not a rating signal. The tier already tells you what the agent has shown. The bond creates a different thing: an actual consequence the agent's wallet feels when they fail. These do related but distinct work. ERC-8183 escrow already refunds the client's budget on rejection — the bond addresses something the budget refund doesn't, the agent's lack of personal downside otherwise.

Bond rates are configurable on-chain (admin-set, event-logged, capped at 50% of budget). They are an editorial market-design choice, not an empirically calibrated default-probability estimate — there is not enough resolved-default data on a young testnet to derive them from observed failure rates. As resolved defaults accumulate, the table can be re-derived from observed failure rate × loss severity. Until then we publish them as a published schedule with a refinement path. The bond table itself lives at caliber.poko.blue/integrate — the methodology paper does not prescribe specific rates, because rate-setting is an application-layer decision, not a rating decision.

Material changes to the bond table are published and take effect when published, the same rule methodology version changes follow (see §Versioning).

What This Is Not

A few things worth saying clearly:

• Not a prediction. A high rating doesn't guarantee the next job goes well. It describes a track record.
• Not a credit score. We don't model default probability. We don't assess solvency. Different problem.
• Not financial advice. If you're about to send funds, do your own diligence. Our rating is one input.
• Not an endorsement. A high tier isn't us vouching for an agent. It's us summarizing their on-chain history.

The Honest Disclaimers

Stuff you should hold in mind whenever you look at a Caliber Rating:

• 🧪 The calibrated chain is a testnet. Every tuned constant in this document — the population mean, the tier cutoffs, the testnet min-jobs column — comes from Arc Testnet. Caliber also indexes 0G mainnet, but 0G is not what the model was calibrated on and carries its own caveats (Appendix G). Expect a reset and recalibration at Arc mainnet.
• 📊 Small rated sample. The index is large — about 607,000 agents on Arc (9 October 2026) and about 3.3 million on 0G — but the rated population is a small fraction of it: most agents have never transacted, and most that have have fewer than 10 jobs. Statistics on small populations are noisy. The confidence indicator exists for this reason.
• ⏱️ Short history. Months, not years. Take long-term claims with a grain of salt.
• 🔄 The population keeps changing. New agent types, new behaviors. Anything trained on the past has some decay risk.
• 🎯 We rate agents, not evaluators (yet). If an evaluator is too lenient or too strict, that noise ends up in agent ratings. Validator-rating is on the roadmap.
• 🎮 All on-chain reputation is partially gameable. Our risk flags catch the obvious patterns. They won't catch everything.
• ⛓️ Ratings are per chain, and the chains are not comparable. A Caliber Rating is computed from one chain's records only. Arc and 0G measure different things — see Appendix G. In particular, a 0G tier is not currently a reliability claim; read that appendix before using one.

Methodology Provenance

An earlier draft of this work, developed under the working name ArcAgents and later as Caliber v1.0, explored a framing borrowed more directly from banking — performance bonds, surety logic, and credit-rating-style letter grades (Caliber-AAA, AA, BBB, …, D). That framing was rejected.

The reason: the underlying data 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, most with fewer than 10 jobs. Borrowing the vocabulary of credit rating (PD, LGD, EAD, EL, AAA/AA/BBB) without the evidence base would have been overclaiming, and any reviewer with five minutes of risk experience would have caught it.

The current methodology — Caliber Rating v2.4.0, counterparty performance rating with credibility-weighted reliability, survival analysis, and rule-based risk flags — is a more honest fit for the data we actually have. The techniques are drawn from reliability engineering, actuarial credibility theory, and platform-trust scoring rather than credit risk.

The v1.0 contracts and methodology paper are preserved as a public archive (git tag methodology-v1.0.1-final in the repository) so the revision history is auditable. They are no longer the operative methodology and no longer match the live RatingVerifier.

The current version is v2.4.0 (the v2.x family, first published 2026-05-24). We expect to be wrong in places. We expect to revise. The provenance is published so the revision history starts honest.

Versioning

This is Caliber Methodology v2.4.0 (active on Arc Testnet from 2026-10-21). The on-chain RatingVerifier accepts v2.4.0 and the previous version, v2.3.0. v2.2.0 attestations kept verifying until 2026-10-21, when v2.4.0 displaced v2.2.0. v2.1.0 attestations kept verifying until 2026-10-16, when v2.3.0 displaced v2.1.0. v2.0.1 attestations kept verifying until 10 October 2026, when v2.2.0 displaced v2.0.1; the 14 July 2026 end of the window announced on 14 June was never applied on chain. When we change the methodology, we publish a new version, mark which ratings used which version, and explain what changed. A published change takes effect when it is published.

Versioning rules going forward:

A major bump (v3.0) changes the rating's shape: the tier scheme, the score's scale, or the attestation struct. A change that moves some agents' scores within the same shape, such as a new factor, re-tuned weights or a change to which evidence counts, is a minor bump, as v2.1.0, v2.2.0, v2.3.0 and v2.4.0 are.

Material changes (anything that changes a rating's computed value, the tier scheme, the bond table, or the default definition) are published as a new version and take effect when published. A rating issued before a change keeps the version it was issued under, and an advance opened before a change keeps the terms it was opened under.

Dual-version acceptance is a property of the contract rather than a notice period. The on-chain RatingVerifier accepts attestations under either the current or the immediately-previous methodology version, and the previous one stops verifying when the next bump displaces it — there is no time limit on that overlap and no date at which it expires. Consumers running gating logic should accept both and migrate to the new version.

Governance notice — v2.4.0 (Caliber's own agents)

v2.4.0 changes who is rated, not how: Caliber's own agents leave the rating, and Caliber clients' jobs stop counting toward anyone's. It changes computed ratings, so it is a material change. In the rating run of 20 October 2026 (04:04:35 UTC), 2 agents changed: both Caliber's own cohort-2 test agents, rated Gold, which now read "not rated (Caliber test agent)". No independent agent had a Caliber client's job in its window. It keeps the rating's shape, so it is a minor-version bump. RatingVerifier accepts v2.4.0 and the previous v2.3.0.

Governance notice — v2.3.0 (volume anomaly and dormancy)

v2.3.0 changes two flag rules (§Step 2). It changes computed ratings, so it is a material change. It keeps the rating's shape (tier scheme, score scale, attestation struct), so it is a minor-version bump. Composition weights, tier gates, confidence cutoffs and v2.2.0's evidence rule are unchanged.

• Volume anomaly is applied again, with a new comparison: the jobs created in the last 30 days against the agent's own rate before them, with a floor of 10 jobs, every job counted on both sides (the flag table). As run under v2.1.0 it compared the window with itself and fired on age alone past 300 days; read literally with a true lifetime count it could never fire before 300 days, because the last 30 days are part of the lifetime.
• Dormancy now reads the agent's whole history, validations included. Before, it read only the 30-day window and so never fired. It still applies only to an agent that passes the rating's gates.
• A score range is published with every rating that has at least one finished job in the window: the uncertainty in the reliability part of the score at 90% under this method's own assumptions (§How sure we are). It adds an output and changes no score, tier or confidence. It is not part of the signed attestation, so the struct is unchanged.
• The age of an agent with no registration date is now counted from its registration block back from the chain head at Arc's 0.5-second block time, so the 14-day gate is true for it (§Step 1). Before, the fallback used 1 second per block, which doubled the age.

Takes effect when published. The signer stamps 2.3.0 on newly computed attestations. The on-chain RatingVerifier holds current = 2.3.0 and previous = 2.2.0, so v2.2.0 attestations continue to verify; v2.1.0 attestations stop verifying. The EvidenceRegistry's version pointer moves to 2.3.0 in the same update; it is informational and not checked on verify.

Measured before publishing (16 October 2026 at 15:01 UTC, on the published run of 16 October 2026, on the 276 registrations rated in that run, held by 94 owner wallets, with each flag rule computed under 2.2.0 and under 2.3.0):

• 88 registrations, held by 58 owner wallets, are rated Dormant instead of their tier: 84 from Watch and 4 from Pending. None is Caliber's own. Every one is rated on lifetime validations alone and has had no job, feedback or validation for 90 days. The count grows as agents pass 90 idle days.
• No registration carries the volume-anomaly flag under the new comparison.
• 12 rated registrations have no registration date; all are more than 14 days old at 0.5 seconds per block, so the age-gate fix changes no rating today.
• No score or confidence changes, and the number of rated registrations is unchanged.
• Rated again with the whole 2.3.0 engine at the same time, every score range contains its score, and a rating has no range exactly when it has no finished job in the window (129 of the 276).

Governance notice — v2.2.0 (provider-controlled jobs)

v2.2.0 changes which completed jobs count as evidence (§Step 1). It changes computed ratings, so it is a material change. It keeps the rating's shape (tier scheme, score scale, attestation struct), so it is a minor-version bump. Composition weights, tier gates and confidence cutoffs are unchanged. One flag rule changes: the volume-anomaly flag is not applied (see the flag table).

Takes effect when published. The signer stamps 2.2.0 on newly computed attestations. The on-chain RatingVerifier holds current = 2.2.0 and previous = 2.1.0, so v2.1.0 attestations continue to verify. v2.0.1, until now still accepted as "previous", is retired on-chain by the same update. The EvidenceRegistry's version pointer moves to 2.2.0 in the same update; it is informational and not checked on verify.

Measured before publishing (9 October 2026 at 17:19 UTC, on the agents rated in the run of 9 October 2026, re-rated with and without the rule, window from block 61,156,921):

• 305 of the 690 rated agents are no longer rated: 303 were in Watch and 2 in Silver. No other agent changes tier.
• 302 of the 303 are under three owners, whose counted jobs were each approved by the provider itself.
• The 2 Silver agents: every one of their 6 counted jobs was provider-controlled.
• 143 agents of one owner keep their tier (Pending or Watch) and lose 9 or 10 points (44 → 35 in Pending; 46 → 36 in Watch): all 3 of their counted jobs were provider-controlled. No other agent's score changes.
• The first measurement, on 5 October, gave the same 305, of 1,255.
• No agent carries the volume-anomaly flag in the run of 9 October 2026, so stopping it changes no rating.

Governance notice — v2.1.0 (adverse-evidence factor)

Announced and active on Arc Testnet: 2026-06-14, under the 30-day notice rule then in force. That rule was withdrawn on 19 September 2026; changes now take effect when published.

Arc Testnet is the calibration environment for the rating (the same role it plays for the testnet-vs-production tier-gate thresholds in §Tier Assignment), so v2.1.0 has been active there from 2026-06-14 — agents on Arc Testnet are scored under the adverse-evidence factor. The window that followed was the dual-version acceptance period, not a deferral of the new scoring: both v2.0.1 and v2.1.0 attestations were honored on-chain so consumers could migrate without breakage, and the contract kept accepting v2.0.1 until 10 October 2026.

v2.1.0 adds the adverse-evidence factor to the network-endorsement sub-score (see §The score): a negative validator observation (score < 50, e.g. a signed conformance breach) now nets against the agent's positive feedback-volume credit, at a weight of 40 positive-equivalents per adverse observation (net floored at 0). This changes some agents' computed score, so it is a material change and a minor-version bump (a new factor, not a formula rework — existing scores recompute under the same composition weights), per the versioning table above.

From 2026-06-14 the on-chain RatingVerifier held current = 2.1.0 and previous = 2.0.1, and requireMinRating accepted either. The last v2.0.1 stamp on record is from 14 June 2026. The contract kept accepting v2.0.1 attestations until 10 October 2026 (it remains in §Appendix F for audit).

On the roadmap (not yet in any version):

• Rating the evaluators (so agent ratings can adjust for evaluator quality)
• Published ratings on Base: Base is indexed and the API computes a Base agent's rating on request, but Base is not in the daily run (its index needs a re-backfill), and when this version was published no Base agent passed the rating gates.
• Backtest results once we have 60+ days of mainnet data

Want to dig deeper?

• Site: caliber.poko.blue
• Code: methodology paper under CC BY 4.0 (this document); contract source through verification on the Arc Testnet explorer; engine, indexer, web app and SDK private
• Issues, disagreements, requests: DM or email PokoBlue
• DM: @PokoBlue99 on X

Built in Bangkok. Powered by a self-hosted Arc node. Standards-native, open methodology.

If you got value out of this, the most useful thing you can do is try a rating, find something we got wrong, and tell us. Methodology improves by getting punched.

Appendix F — Change History

Non-versioned changes

Changes that do not alter the formula or its factors are recorded here rather than as a version bump, per §Versioning.

Stability statement

v2.0.1 is the first publicly published version. The v1.x pre-pivot versions (1.0, 1.0-rebrand, 1.0.1-tuning) and the internal-review v2.0 are preserved at the git tag methodology-v1.0.1-final and pre-v2.0.1-rename for audit, but should not be referenced operationally. The v1.x contracts on Arc Testnet are deprecated; the live RatingVerifier, RatingGateway, and CaliberEscrow are the v2.0.x deployments (addresses listed under §The Attestation Primitive).

Material changes from v2.0 forward follow the versioning rules in §Versioning. Any future tier rename, factor add/remove, default-definition change, or composition-weight adjustment requires a new minor version, published and effective on publication.

Appendix G — Chain Profiles

Caliber rates each chain from that chain's own records. The formula in §How the Rating Gets Built is the same everywhere; what differs is what the chain records in the first place. That difference is large enough that tiers are not comparable across chains, and this appendix exists so nobody has to guess.

Arc Testnet — the reference profile

Arc is what the methodology was calibrated on. Agents register in the ERC-8004 Identity Registry, work is transacted as discrete jobs through an AgenticCommerce contract, and jobs reach explicit terminal states (Completed, Rejected, Expired). Validators publish feedback and validation outcomes. Every input the score needs — success, failure, counterparty spread, endorsement — is present on-chain. The population mean completion rate (0.95) is measured from this cohort.

0G Chain mainnet (16661) — a different substrate

0G is not a smaller Arc. Three structural differences change what a rating means.

1. There are no jobs — only metered settlements. 0G has no AgenticCommerce contract. Agent-to-agent commerce happens in the 0G Compute marketplace, where a consumer escrows funds in a ledger and pays a GPU provider per inference request. Caliber reconstructs a unit of work by pairing LedgerManager.FundSpent (which carries the amount) with InferenceServing.BalanceUpdated (which carries the provider) within a transaction. A balance change with no matching spend is a deposit and is deliberately not counted as work.

2. The chain records no negative outcomes. This is the important one. Across the settlements indexed to date there are zero failed TEE settlements, zero refund requests, zero disputes, and 8 feedback events on the entire chain. Inference failures, timeouts and quality disputes happen off-chain and never reach the ledger — a settlement exists only when a payment succeeded.

The consequence follows directly from the formula: smoothed reliability is 1.0 for every provider, network endorsement is 0 for every provider, and latency consistency is the default for every provider. Only volume varies, and volume is not a scored factor. Every rated 0G provider therefore receives the same score. A 0G tier currently means "this provider transacts", not "this provider is reliable", and it must not be presented as the latter.

What still works on 0G is the flag layer, which reads structure rather than outcomes: counterparty concentration, validator concentration and sybil patterns are all computable from settlement records. In practice the flags are the only thing that currently separates one 0G provider from another.

Earning real score discrimination on 0G requires an off-chain signal — an independent prober, or provider health data — not more indexing. Until such a signal exists, 0G scores should be read as a liveness indicator with flags attached.

3. Identity and commerce are disjoint populations. 0G's ERC-8004 registry holds ~3.3 million agents. Essentially all of them come from a single issuer, register a fresh owner address each, publish no metadata that resolves, and have never transacted. Meanwhile the ~20 0G Compute providers do genuine metered work and hold no ERC-8004 registration at all. As of this writing, zero Compute providers appear as the owner or operator of any registered agent.

Because the engine is keyed on (chain, agent_id), Compute providers are given a synthetic identifier derived deterministically from their service address, and their records are marked identity_source = "compute_provider". A synthetic id is an addressing convenience so a provider can be rated at all. It is not an on-chain registration, it is surfaced as such wherever a 0G rating is shown, and it must never be presented as an ERC-8004 identity.

The registry population itself rates as insufficient_interactions essentially universally. That is the correct answer, not a gap to be engineered around: the tier gates are not loosened to manufacture ratings for agents that have never transacted.

Calibration status

0G's population mean is deliberately left unmeasured rather than inherited. The credibility blend shrinks every sparse agent toward that prior, so reusing Arc's 0.95 would silently state a belief about a population nobody has measured. It will be set from the 0G cohort once that cohort records enough variation to measure — which, per point 2 above, it currently does not.

Versioning note

Adding a chain profile is not a methodology version change. The score composition, weights, tier gates, confidence cutoffs, flag rules and attestation struct are all unchanged, and every Arc rating computed before and after this appendix is byte-identical. Per §Versioning, only a change to the formula or its factors bumps the version. This appendix documents where the inputs differ, which is a disclosure obligation, not a recalibration.

Caliber Methodology v2.4.0 · active on Arc Testnet from 2026-10-21 · v2.3.0 accepted as the previous version · Bangkok · 🇹🇭