Machine Credit Rating

A Moody’s-style score that summarizes a machine’s creditworthiness from its on-chain history.

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.

Rating scale

MCR ratings use an AAA-to-NR scale. The integer mcr_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.

Both 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.

Until both gates are cleared the machine returns 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 the EventRegistry, 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. For a machine homed on Solana the events live in the Solana EventRegistry program and are indexed after confirmation; until then the MCR response carries a rating_unavailable reason, for example no_events_yet. Branch on the field being present, not on one value. See Solana onboarding: after onboarding.

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.

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

revenue_trend is null for a machine homed on Solana whose events the MCR cannot read (the response carries rating_unavailable), and the SDK query helpers type it as nullable: null / None means not computable and must not be read as "stable".

Multi-currency revenue

Revenue events in a supported ISO 4217 currency get FX-normalized to USD by the MCR server before scoring. Pass currency 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 converts the value to USD cents. Only revenue events worth at least 1,000 USD cents ($10) after conversion are summed into total_revenue (USD cents) on GET /mcr/{did}. The MCR API returns no per-event rows, so per-event conversion results are not in any response. Three cases affect the score:

• Unsupported currency. An event in a currency outside the server’s supported list is marked unsupported_currency and adds no USD revenue (treated as $0). This is a partner-input error, so it does not set mcr_degraded.
• Stale FX rate. When every FX source fails and the server holds an earlier stored rate for the currency pair, it converts the event at that stale rate and the revenue still counts. For a machine homed on peaq, /mcr/{did} then returns mcr_degraded: true and the response is not cached, so consumers can tell a degraded score from a quiet machine.
• No FX rate. When no rate is available at all, the event is marked fx_unavailable and adds no USD revenue. mcr_degraded stays false and the response is cached as usual.

For a machine homed on Solana, mcr_degraded is always false.

See Submit events: currency and value units.

Cross-links

• Events: the revenue and activity records that feed MCR
• Trust levels: what each trust_level means at submit time
• GET /mcr/{did}: fetch a machine’s current rating
• Qualify function: the function that exposes MCR end-to-end