Machine Credit Rating (MCR) is a letter rating, modeled on traditional credit agencies, that summarizes a machine’s financial standing from its on-chain history. Any application can query a machine’s MCR through the public MCR API: no authentication, no permissions. It travels with the machine across chains.Documentation Index
Fetch the complete documentation index at: https://docs.peaq.xyz/llms.txt
Use this file to discover all available pages before exploring further.
Rating scale
MCR ratings use a familiar AAA-to-NR scale. The integermcr_score (0-100, rounded) maps to a letter via fixed thresholds:
| Rating | mcr_score | Meaning |
|---|---|---|
| AAA | ≥ 95 | Highest credit quality |
| AA | ≥ 85 | Very high credit quality |
| A | ≥ 75 | High credit quality |
| BBB | ≥ 60 | Investment grade |
| BB | ≥ 45 | Below investment grade |
| B | ≥ 30 | Minimum rated |
| NR | 0 | Not rated. Score below 30, or machine is unbonded |
| Provisioned | 0 | Newly registered. Not enough history to score yet. |
NR and Provisioned return mcr_score = 0; the mcr letter and bond_status field on /mcr/{did} distinguish the two.
Lifecycle: Provisioned graduation
A freshly registered, bonded machine is Provisioned: on-chain, but not yet rated. It graduates onto the rated scale once it has both:- Enough events: a sustained set of qualifying events. Activity-only machines (sensors, drones without revenue) can graduate via activity alone; revenue is not required.
- Enough history: the first-to-last event span covers a sustained operating window.
mcr: "Provisioned" with mcr_score: 0, regardless of how strong the underlying activity is.
Ratings are not assigned. They’re earned. A machine’s standing reflects what it has done on-chain.
How the score is computed
The MCR server fetches every event from theEventRegistry, normalizes revenue values to USD cents via FX at the event’s timestamp, and combines them into a 0–100 integer score that maps to a letter rating. The exact weighting is not published.
The score is built from a small set of inputs:
Bond. Every bonded machine receives a baseline contribution. An unbonded machine returns (0, "NR") immediately. Bond is the floor for any score at all.
Revenue and activity. Two factors derived from the event history. Each rewards consistency (regular cadence), depth (sustained activity over many events), and tenure (longer-running machines). Revenue is daily-aggregated: events are summed per UTC calendar day, and only days that meet a minimum economic threshold count toward revenue.
Trust level. Per-event trust tiers, with revenue events weighted by economic value. Higher tiers contribute more; 0 self-reported, 1 on-chain verifiable, 2 hardware-signed. See Trust levels.
A long-running self-reported machine earns a small graduation bonus on its trust contribution after sustained operation, but it remains below the on-chain tier.
Freshness. Recency decay applied to the trust contribution. A machine that hasn’t reported recently scores progressively lower; a sustained dormancy gap clamps freshness at a floor until the machine demonstrates renewed activity over a recovery window. Recovery is earned, not granted by a single recent event.
Negative event flag. While an active flag is set on the machine, the trust contribution is reduced for a fixed window from the flag timestamp; the penalty expires automatically after the window closes.
The final score is clamped to [0, 100] and rounded to an integer before mapping to a letter.
Revenue trend
/mcr/{did} exposes a revenue_trend field with one of four values, derived from short-term vs longer-term moving averages over qualifying revenue events:
| Value | Meaning |
|---|---|
"up" | Recent revenue is materially above the longer-term baseline |
"stable" | Recent revenue tracks the longer-term baseline |
"down" | Recent revenue is materially below the longer-term baseline |
"insufficient" | Not enough qualifying revenue events to compute a trend |
Multi-currency revenue
Revenue events submitted in any ISO 4217 currency get FX-normalized to USD by the MCR server before scoring. Passcurrency directly to submitEvent and supply value as the currency’s minor-unit integer (cents for USD/HKD, whole units for JPY/KRW); the server fetches the historical rate at the event’s timestamp and stores both origin_value and the computed usd_value (USD cents). Two distinct degradation paths show up on the wire:
- Unsupported currency. The per-event
amount_statusbecomes"unsupported_currency". The revenue value is ignored when scoring (treated as $0). This is a partner-input error, not infra failure, so it does not flipmcr_degraded. - FX infrastructure failure. When the MCR server has to fall back to a stale snapshot (
fx_source = "stale_latest") or has no FX at all (fx_source = "default_usd_fx_outage"), the event’samount_statusbecomes"fx_unavailable"and the top-levelmcr_degraded: trueflag flips on/mcr/{did}, so consumers can distinguish a degraded score from a quiet machine.
Cross-links
- Events: the revenue and activity records that feed MCR
- Trust levels: what each
trust_levelmeans at submit time - GET /mcr/{did}: fetch a machine’s current rating
- Qualify function: the function that exposes MCR end-to-end