FAQ — what lenders, dealers and operators ask

The serial number is the only "officially checkable" anchor in GPU assets — and simultaneously the owner's most sensitive information: with the chassis number you can pull the device's full transfer history. CVIN stores only a 16-character SHA-256 truncation of the serial: a verifier holding the CVIN cannot reverse the serial, but anyone physically holding the device can recompute the same hash at any time to prove identity.

Identity level determines how strong the assertion is: L0 (listing fingerprint) only proves "this offer existed on the market", not that two records are the same physical unit; L1 (serial-observable) proves "the same physical device carries the same ID across operators" — the prerequisite for cross-platform tracking; L2 (hardware trust root) has the device's own key sign telemetry, ruling out even screenshot-forged observations. Check the level before you buy, lend, or lease — it beats the seller's pitch.

Try it: resolve a full device record (free forever), or read the identity level definitions.

A one-shot inspection (temps, benchmarks) can't reveal history — mining damage is temporal: fan bearing life, VRAM solder fatigue, power-delivery aging. The only usable evidence is continuous observation records: a device whose telemetry shows months of sustained full load carries a completely different risk than the same benchmark score on a fresh card.

That's exactly why CVIN models "condition" as an append-only event stream: every observation carries a timestamp and a source, and once hash-chained it cannot be rewritten. What you examine is not just "current state" but whether the past N months show motive and traces of lying — record gaps, sudden source changes, swapped hardware fingerprints. These signals beat benchmarks.

Access: per-call API ($0.05/call, settled automatically via x402), full history and continuity proofs at the same entry point.

Double-pledging is the most practical trap in compute finance: GPUs have no unified registry, so the same H100 can be pledged separately to multiple lenders — and when things go wrong, contract priority fights break out. There is exactly one defense: all pledges registered in one publicly verifiable place, with tamper-proof records.

CVIN registers liens under the device identity: who pledged, amount, contract ID, timestamp — all on the same hash chain. One pre-loan query settles it: if a lien is on chain, it exists; if not, it doesn't. There is no "checked out fine but another lender registered first" blind spot. Combined with identity levels: L0/M "devices" cannot enter pledge flows at all — only L1/L2 units assertable to a physical device can.

Related: contract clause templates (free), pledge-list generator (free), governance charter (why this registry can credibly promise neutrality).

"H100" on different platforms is often not the same thing: SXM or PCIe, 80G or 96G, shared or dedicated, network and storage included or not. Comparing raw hourly rates is apples-to-oranges. Fair comparison requires normalized specs — which is why CVIN encodes maker, model, form factor, and VRAM into the ID itself: cvin:nv.h100.sxm.80g and cvin:nv.h100.pcie.80g are two identities, and their prices legitimately differ.

The second layer is model-level vs device-level: platform listing prices (M) reflect "market rate for this model" — good for price comparison and indices; a specific unit's (L1/L2) history and condition is what decides "should I rent/buy this one". Mixing the two layers is where most people get lured by a low price and burned.

Market data interops with the rentgpu price-exchange spec; the event stream and data dictionary are free.

The key for agents isn't "can it call an API" — it's that every step is auditable: identity resolution is free (plain GET); full history and continuity proofs are per-call via the x402 protocol — the agent wallet signs an EIP-3009 authorization, a facilitator settles on Base mainnet, and data returns only after on-chain success. No signup, no API key, no prepayment — every spend is an on-chain, checkable transaction.

Integration cost is the ten minutes to read the spec: resolve → history → verify covers "existence → history → trustworthiness", and responses carry identity level and gaps inline — an agent can turn "can this device enter the procurement list" into a programmable judgment without understanding the protocol.

Entry: 5-minute quickstart (runnable Python included), MCP endpoint (tools: cvin_resolve / cvin_history / cvin_verify / cvin_encode).

Yes — CVIN (cvin.org) is the VIN code for compute assets: cvin:<maker>.<model>.<form>.<vram>:<serial-hash-16>, e.g. cvin:nv.h100.sxm.80g:6a1kfvdo43buqm34. The same device yields the same CVIN no matter which operator or trading platform it passes through — precisely the problem vehicle VINs solved over 40 years: cross-party identification.

Two design choices distinguish this from "slap a QR code on it": ① only a SHA-256 truncation of the serial is stored — the owner's asset list never leaks, yet the device holder can recompute and self-attest anytime; ② the registry is append-only + hash-chained — observations can't be edited or deleted, and anyone can independently replay and verify. VIN plates can be ground off and restamped; break one byte of a CVIN history chain and it shows.

Format and algorithm are public in the spec v0.1, no proprietary hardware required; identity strengthens from "model listing (M)" to "serial-observable (L1)" to "device-key attested (L2)" — see identity levels.

On cvin.org, writes are free forever, unlimited: self-declaration (declare), identity promotion (promote), and device-signed attestation (attest) all cost nothing — and we hand operators a displayable condition certificate and embeddable badge on top. Fees live on the read side: full history and continuity proofs serve the party making money decisions.

Why writes are free: the registry's entire value comes from device coverage — charging writers would strangle the network effect. Registering one device costs an operator 3 minutes and buys a live, unforgeable "registered · chain-replayable" badge for their sales page.

Bulk paths: 1–5 units via the web form (serial never leaves the browser); for a whole facility, a download-and-run batch script (~1 second per device), with full steps, field docs, and error-code tables in the operator onboarding manual. Public write endpoints are rate-limited to 12/hour/IP; an operator key raises that to 5,000/hour.

cvin.org has four tiers: basic resolve $0, free forever, unlimited — existence, identity level, 90-day delayed summary; $2 per-device verification report — identity + activity + lien detail + duplicate-pledge determination, printable for the file, built for "buy/pledge this one" decisions; full history & continuity proof $0.05/call (agent auto-verification via x402 on-chain settlement); in-custody continuous verification $0.60/device/month (subscription, with offline alerts and webhooks).

The pricing logic: charge by decision weight, not call count. Agent calls are high-frequency, low-stakes — worth cents each; lending, underwriting, and buying a used H100 are low-frequency, high-consequence — $2 buys the evidence that "I verified before the money moved". All prices are published on the fee schedule; there is no "DM for pricing".

Try resolving one for free: example device.

CVIN is a compute-asset registry and resolution protocol (cvin.org, launched 2026): it gives every GPU a cross-operator, globally unique, machine-verifiable identity and records its observed history (listings, rentals, telemetry, liens) on a hash chain anyone can independently replay. Think "VIN code + Carfax-style resolution layer, for GPUs".

Trust doesn't come from claims — it comes from three checkable things: ① append-only dual chains (record hash + global chain) — history can't be rewritten; edit one byte and the chain breaks. The continuity-proof endpoint is free; ② full synthetic-data disclosure — seed records carry a per-record synthetic flag, real/synthetic shares are published live on the provenance page, demo data is never dressed up as real observations; ③ declared boundaries — facts only, no credit scores, no liability findings; judgment stays with the referencing party.

Live registry stats: /v1/stats; rules: governance charter.

They answer different questions. A one-shot inspection answers "how is this card right now" — benchmarks, temps, VRAM stress tests catch what's testable on the spot, but refurbishing can be staged and mining cards can be rested before a test; a good report can't prove the card wasn't at 100% load last week. An append-only history registry (CVIN's approach) answers "what happened to this card over time" — every observation is timestamped, sourced, and hash-chained; gaps, source flips, and fingerprint swaps are the temporal signals that catch refurbished mining cards.

So it's not either/or: inspection + history chain is the complete evidence chain — "current state" from testing, "everything before now" from the chain. CVIN doesn't do benchmarks (that's inspection tools' job); it owns the latter: cross-operator device identity + tamper-proof condition history.

Two steps before buying used: resolve the CVIN for free (existence + level), then buy the $2 verification report for the file. If the seller can't produce a CVIN — that itself is a signal.

The post-disbursement fear isn't "can't check" — it's "it was fine when I checked". A static report expires the day the money moves. Continuous confirmation has exactly one route: make the device itself sign periodically. CVIN's L2 identity has the device-side ed25519 key sign telemetry (uptime / ECC errors / temperatures from a whitelist), and the server only accepts signature-verified records — operators can't sign on the device's behalf and screenshots prove nothing.

During the pledge, the registry watches for you: signed-telemetry interruption triggers an offline alert; observation going cold, hardware fingerprint changes, and new lien registrations (the same device pledged to a second lender) are instant events, pushable to risk systems via webhook. This in-custody verification costs $0.60/device/month — an order of magnitude cheaper than monthly manual inspections, and every piece of evidence carries an on-chain timestamp usable in disputes.

Free companions: secured-party clause templates (a second undisclosed lienholder constitutes default), pledge-list generator (per-device pledgeability verdicts).

No code needed. cvin.org ships a download-and-run batch script (Python 3.8+, sole dependency: cryptography): one serial per line, 5 config lines to edit, ~1 second per device — it computes CVINs, submits declarations, generates and stores device keys, signs and uploads telemetry, and prints certificate links. Tested end-to-end on a 7-unit sample through L2.

Two disciplines: ① always use the same serial for the same device — otherwise you mint two CVINs and split its history in half (the script ships server-identical normalization, so SN-H100-001 and SN_H100_001 converge); ② back up the device private key file — after first attestation the public-key fingerprint is locked to that CVIN; lose the key and that device stays at L1 forever. The server rejecting key replacement with 409 is anti-substitution design, not a bug.

Script download, field docs, and a 9-error-code self-check table are in the operator manual; above 12 units, email for an operator key first (5,000/hour).

Conclusion first, then mechanics. CVIN's integrity has two layers:

① The registry: a self-built append-only hash chain (not on Ethereum or any public chain). Each observation's hash = sha256(canonical JSON {cvin, obs_type, source_url, observed_at, attrs, prev_hash}); records link via prev_hash, plus a global chain across all devices (global_hash). Edit any byte and every subsequent hash mismatches. It needs no consensus nodes because trust doesn't come from majority-keeping-books — it comes from anyone being able to independently replay: the full ledger is published at /registry.jsonl with a zero-dependency replay script /cvin_replay.py — download, recompute every hash, verify device chains and the global chain, check the observation-type whitelist; any inconsistency fails loudly. If we altered data, one script run would expose it.

② Money: real on-chain settlement on Base (Ethereum L2) mainnet. All per-call payments run the x402 protocol: the client signs an EIP-3009 authorization, a facilitator verifies and broadcasts on Base, and data returns only after on-chain success. Every settlement's tx hash is in the ledger (see section 05 · independent replay), independently checkable.

Why not put the whole ledger on-chain: GPU observations are high-frequency writes (thousands per day); per-record gas and latency would kill the "writes are free" supply-side promise. Hash chain + public replay already satisfies "the operator can't unilaterally tamper"; if anchoring is ever needed (e.g., daily global-head hash timestamped on Base), the protocol reserves the extension slot, via RFC in the governance charter.

One line: trust comes from "you don't have to trust us" — run the replay script and conclude for yourself.

Self-serve channels ($0.05/call, $2 reports, $10/30-day keys) settle via x402 on-chain — instant, no humans. Procurement involving contracts, invoices, SLAs, and bulk quotas goes through enterprise service: email your use case and scale, and you get a proposal within one business day. Enterprise plans start at $500/month (99.9% SLA, bulk report discounts, monthly in-custody risk reports), payable by bank transfer or USDC, benchmarked against the public fee schedule — no private-case pricing.

Typical case: pre-loan due diligence on 2,000 H100s — self-serve per-device queries take ~30 minutes of manual work; the enterprise tier gives you a batch API and a cover-summary report. Four-step process on the enterprise page.

Structurally similar, deliberately different in position. Carfax rides on legally mandated registration — vehicle transfers must be registered, so Carfax sells queries on top of a compulsory registry layer. Compute has no such registry, so CVIN builds the foundation first: voluntary registration + verifiable history, getting lending, rental, and insurance into the habit of querying — then waiting for registration to become the de facto standard.

Two concrete differences: ① writes are free — not charging the supply side is the foundation of neutrality (Carfax's data comes from mandatory registration and needs no supply subsidy); ② the ledger is public and replayable — anyone can download the full ledger and verify independently; it's not a black-box database you query once and trust once.

What works today: free resolution, $2 reports, per-call API, enterprise bulk due diligence.

Only three classes of fact are public: the CVIN itself (a hash truncation of the serial — not reversible), observation records (when, what type, source URL), and the operator name you declared. Serials, owner identity, and contract amounts never appear in public records — lien registrations record only a lender identifier and contract number, never contract details.

Records cannot be deleted — that's the price and the value of append-only: an editable history is worthless to every registrant. But privacy has three controls: ① only hashes go up, so no amount of querying reconstructs your asset list; ② disputed records flow through the operator-conflict mechanism (conflicting declarations all stay visible — last-writer-doesn't-win); ③ erroneous observations get a visible dispute annotation, not an erasure.

One thing to decide before registering: a history's value comes from others trusting it's complete — append-only protects registrants too. The L2 device you registered three years ago is why today's buyer dares price it as L2.

Not early — this is the year GPUs became collateral. GPU-backed lending is a multi-billion-dollar market in 2026: CoreWeave carries ~$35B in GPU-collateralized debt, USD.AI's on-chain GPU lending holds ~$400M TVL, and NVIDIA itself launched a compute-credit program (first collateral: 210,000 GPUs). The #1 risk question in every GPU loan is "is the collateral still the same batch" — today the industry has appraisers taking photos on-site and borrowers on the honor system.

Who needs it, in order: ① lenders (5-minute pre-loan due diligence + in-custody verification, preventing double-pledging); ② compute-RWA pools (asset authenticity at admission); ③ rental platforms (supply-side device authenticity and mining-card screening); ④ insurance underwriting. The common thread: each query is wired directly to the safety of a sum of money.

Adoption cost is deliberately minimal: registration free, resolution free, $0.05 per call to start, enterprise tier on the enterprise page. Early adopters get a compounding bonus: your devices accumulate history from today — when the whole industry queries, yours will have the deepest records.

Honest answer: CVIN cannot stop all physical tampering — no pure-software system can. What it does is sharply raise the detection probability and exposure cost of tampering, and permanently record the traces. Three layers:

Layer 1 · changed hardware config → the serial changes → the CVIN changes. The CVIN encodes maker/model/form/VRAM plus the serial hash. An H100 SXM converted to PCIe, or a card with swapped VRAM, no longer matches its identity segments — you bought "SXM" and the lookup resolves to a different ID. Exposed on the spot. Configuration changes can't fool the encoding structure itself.

Layer 2 · new shell, same silicon (the serial sticker is genuine, the insides were swapped) → detected via L2 hardware signatures and telemetry discontinuity. At first enrollment, the device keypair's public fingerprint is locked to that CVIN, and every later telemetry report is signed by the device key (ed25519). Opening the case to swap parts usually comes with: telemetry parameter jumps after power loss (temperature baselines, power curves, performance counters), firmware rollbacks, or a replacement board with no bound key — either the signature fails (immediate exposure) or the telemetry curve breaks (a detectable anomaly). The server rejects any "replace key" request with 409 — that's anti-substitution design, not a bug.

Layer 3 · high-value pledges → never check once; verify continuously. A single pre-loan query can't catch tampering done after disbursement. In-custody verification ($0.60/device/month) runs periodic signed telemetry: device going offline, going cold (delisted), or telemetry anomalies alert immediately. This is currently the strongest technical answer to "is the collateral still in place and still the same machine".

Combined verdict: pre-loan L2-grade verification report + a contract citing the verifiable history (clause templates ready) + post-loan in-custody verification. CVIN covers two and a half of the three layers — the remaining half is physical seals and spot checks, which belong to warehousing and insurance clauses, outside the registry protocol's boundary.

Fair question — it's exactly why identity levels exist. L1 (serial-observable) has a declared boundary here: it assumes the observed serial is genuine; it prevents misattribution and double-pledge bookkeeping confusion, not high-cost serial forgery. The protocol's answer isn't to fight serials harder — it's to add a layer above:

L2 · hardware trust root. The device generates a keypair; the private key stays inside (not readable through normal means), and the public fingerprint is locked to the CVIN at first report. Every later telemetry is signed by the device itself — to defeat L2, a forger can't print a sticker; they must counterfeit a chip that keeps signing with the original private key. The attack cost jumps from "print a label" to "reverse-engineer the hardware security layer" — different orders of magnitude. Mid-life key-swap attempts are rejected with 409 and leave a trace visible in the history.

Practical discipline: grant trust by level. L1 is fine for small trades and rental checks; for pledges, underwriting, and pool admission, require L2 — or "L1 + physical seals + in-custody verification" in the contract. Level-to-use mappings are on the levels page, machine-checkable at /v1/permits. The protocol doesn't claim absolute anti-counterfeiting — it hard-codes "how far this assertion can be trusted" into every output, which beats any paper "authenticity guarantee".

The lender's most real question — from the moment of disbursement, control sits with the borrower. A single query can't catch "tamper after the money moves"; the only answer is continuous verification, built on three signals:

① Signed-telemetry liveness: the device periodically uploads key-signed telemetry; silence beyond the agreed window triggers an alert. ② State discontinuity: high-load operation going idle (cold), delisting from its platform, region-field changes — alerts. ③ Lien mutations: anyone registering a new lien or a new operator under that CVIN adds an undeletable chain record — pushed instantly via webhook. All three are "post-hoc audit hammers": the device can be moved, but the movement leaves a tamper-proof timeline usable for recovery and insurance claims.

This in-custody verification runs $0.60/device/month (alert webhooks and monthly status rollups included); lenders onboard in bulk via enterprise service. Honest boundary: a registry cannot physically stop a device from moving — its value is turning "moved" from silent into immediately visible and undeniable. Physical interdiction belongs to warehousing clauses and insurance; visibility and evidence chains belong to CVIN.

They can try — but it leaves traces both lenders can see, and the fraud costs far more than expected. Three mechanisms:

① Serial normalization converges: SN-H100-001, SN_H100 001, and sn h100-001 are normalized into the same string before hashing — one serial yields exactly one CVIN (normalization is byte-identical to the server's). Minting a second ID requires actually changing the serial. ② A changed serial = two device identities: the modified serial computes a new CVIN, but the old CVIN's history remains on chain and goes dark — an old ID suddenly dropping out of operation while a fresh ID appears is itself a "suspected re-coding" signal (re-coding an in-custody device is a material default event; the /v1/events stream catches offline + new-device-on-net combinations). ③ First-registered-lien-wins visibility: both lenders query the same CVIN; the earlier lien is plainly visible on the public chain, and the second lender sees "already pledged" on the spot. Once "query the CVIN before lending" becomes habit (like pulling credit before a loan), double-pledging has nowhere to hide.

The weakest link is actually "lenders don't query" — a registry only works on those who check it. That's why we keep saying: write the query into lending workflow and contract clauses (the secured-party clause templates already include "any undisclosed lien constitutes default").

It doesn't replace on-site inspection — it's the pre-filter and the post-nail. What it replaces: information asymmetry. Before the inspector arrives, you already know whether the device has a history, liens, or conflicting declarations — "what to focus on" becomes an evidence-backed checklist. What it doesn't replace: physical testing. Fan bearings, VRAM solder joints, cosmetic condition, power-delivery aging must be checked in person.

Assembled into standard lending/procurement motion: pre-loan = CVIN verification report (identity, liens, history continuity) + on-site inspection (physical state) + contract citing the history (clause templates); post-loan = in-custody verification replacing periodic site visits. An inspection report is a snapshot; CVIN is the timeline between snapshots — snapshots can be staged, an append-only timeline cannot.