Onchain Model Card: The Claim Can Change While the Hash Cannot

Onchain Model Card

Disclosure: AI tools were used for source collection and editorial review. The article was written by a human author, who checked the facts, code, and conclusions.

Crypto risk disclosure: This article is a technical explanation, not investment advice. It is not a recommendation to buy, sell or hold any cryptoasset.

The dangerous version of an onchain model card is a permanent pointer aimed at a claim that can quietly change somewhere else. A model page can be improved, corrected, softened, or stripped of claims. Meanwhile the chain entry keeps looking stable, even though the evidence behind it has already moved.

That is the AI x crypto problem in one sentence. The job of Onchain Model Card is to make model-card claims harder to rewrite silently, not to pretend that a hash turns a model card into proof of safety, license rights, benchmark truth, training-data provenance, or runtime behavior.

Change Failure

The failure starts with a sentence that sounds harmless: "This model is approved for support triage." A team later edits the card to say "experimental support triage," but the old onchain reference still points users toward the same model name.

Onchain Model Card needs a stricter object than a name. That object should record which card bytes were reviewed, which claim set was anchored, who issued the statement, what the statement replaced, and what the statement refuses to prove.

Card Scope

Model cards are reporting documents, not magic attestations. Model Cards for Model Reporting frames model cards around intended use, evaluation, limitations, and context.

That kind of support is useful, and narrow. A model card can explain how a model is meant to be used. It does not prove that the model is safe, licensed, unbiased, or behaving the same way once it sits inside a production system.

Repository Scope

In real developer workflows, a card is often a mutable repository document. Hugging Face Hub Model Cards describes model cards as Markdown files with metadata and text descriptions, commonly rendered from a model repository README.

That practical shape is exactly why the onchain receipt needs version control. Record only a repository URL and the receipt captures a place to look, not the claim text that anyone actually reviewed.

Receipt Artifact

The practical artifact is a claim receipt, not a model biography.

{
  "receipt_type": "ai.model_card_claim_receipt.v1",
  "card_subject": "org/model-name",
  "model_repository": "https://example.invalid/org/model-name",
  "source_revision": "full_commit_or_release_identifier",
  "card_path": "README.md",
  "claim_extraction": [
    "intended_use",
    "limitations",
    "datasets",
    "license_field",
    "evaluation_summary",
    "version_note"
  ],
  "canonicalization": "RFC8785-JCS-for-extracted-json-claims",
  "source_card_digest": "sha256:<raw_readme_or_card_bytes>",
  "claim_set_digest": "sha256:<selected_claim_fields>",
  "digest_uri": "ni:///sha-256;<claim_set_digest>",
  "issuer": "did:example:issuer-key-context",
  "signature_profile": {
    "path": "choose_one",
    "vc_data_integrity": "proof + verificationMethod profile",
    "eip712": "typed-data domain + fields profile"
  },
  "signature_profile_limits": "do not mix VC proof fields, RFC8785 canonical JSON, and EIP-712 typed data as one interchangeable profile",
  "supersedes": "previous_receipt_hash_or_null",
  "effective_from": "2026-06-02T00:00:00Z",
  "limits": [
    "card claims only",
    "not model weight identity",
    "not benchmark truth",
    "not license validation",
    "not runtime attestation"
  ],
  "optional_onchain_anchor": "author-modeled transaction_receipt_or_event_log_pointer"
}

The receipt stays deliberately smaller than the model card. Onchain Model Card earns its keep when it anchors the reviewed claim set and its limits, not when it tries to squeeze every model fact into a chain event.

Canonical Bytes

Hashing a claim set means extraction has to happen before canonicalization. The receipt should not pretend to hash the meaning of a free-form Markdown card. It should instead list the card fields it pulled out, serialize those claims as JSON, and hash the canonical representation of that.

RFC 8785 gives one JSON canonicalization scheme, and RFC 6920 supports the broader idea of naming information with hashes.

The key word is information. A digest can identify the raw card bytes, or the extracted claim-set bytes. What it cannot tell you is whether the benchmark was fair, whether the dataset was lawful, or whether a deployment used the same runtime controls.

Claim Statement

Structured claims need issuer context. Verifiable Credentials Data Model 2.0 and Verifiable Credential Data Integrity 1.0 are useful patterns for claim statements and integrity-protected data.

Even then, the boundary has to stay visible. A signed claim says an issuer made a statement over specific data. It does not make the statement true.

The receipt also should not collapse every signing path into one label. VC Data Integrity, RFC 8785 canonical JSON, and EIP-712 typed data are separate implementation choices, each with its own representation rules.

Issuer Context

The receipt should name the issuer separately from the model. DID Core gives a standards-based way to think about decentralized identifiers and verification material.

None of that identity layer is a trust shortcut. A DID or key context can help a verifier find verification material, but the reader still has to decide whether the issuer is even allowed to make the model-card claim.

Ethereum Profile

An Ethereum-adjacent implementation can use typed structured signing instead of a raw string signature. EIP-712 is useful because domain separation and typed fields reduce ambiguity in what was signed.

That signing profile should stay optional here. Onchain Model Card is about auditable control over claim change. It is not arguing that every model card must commit to one chain, one wallet pattern, or one signature scheme.

Chain Pointer

The onchain part should be a pointer to the receipt, not a truth label. Ethereum JSON-RPC documentation for eth_getTransactionReceipt includes transaction receipt logs, and the Solidity ABI specification explains how events use topics and data.

That source support is narrow. A transaction receipt or an emitted event can help a reader find the anchored receipt. The chain pointer still cannot prove that the model-card claims are accurate, current, licensed, or safe.

Metadata Precedent

Machine-learning metadata already has version and checksum habits. MLCommons Croissant is dataset-focused, but its version/checksum pattern shows why reproducibility needs more than a friendly name.

The precedent only goes so far. A dataset checksum does not graduate into a model-card standard, and a model-card digest does not turn into a dataset provenance proof.

Change Diff

The receipt earns more of its keep once the new card is required to point back at the old one. A reviewer can then inspect a change as a diff, instead of trusting whatever the newest page happens to say.

Field	Old receipt	New receipt	Reader question
Source revision	abc123	def456	What changed in the extracted card claims?
Claim set digest	sha256:old...	sha256:new...	Which claim fields moved?
Intended use	support triage	experimental support triage	Did the claim narrow?
Evaluation note	internal benchmark	internal benchmark plus caveat	Was evidence added or weakened?
Supersedes	null	sha256:old_receipt...	Is the replacement explicit?
Chain pointer	tx/log A	tx/log B	Where was each receipt anchored?

This diff is the core developer control. The chain anchor matters because a change cannot pretend to be the same claim once the digest moves.

Refusal Checklist

The receipt should refuse more than it proves.

Tempting label	What the receipt can support	What the receipt must refuse
Verified model card	These card bytes or claim fields were anchored	The claims are true
Approved model	An issuer signed a card claim	The model is safe
Reproducible model	The card source and revision were recorded	The weights, data, and runtime are identical
Licensed model	A license field existed in the card	The license is valid for this use
Benchmark-backed model	A benchmark claim appeared in the card	The benchmark was fair or current

That checklist is what keeps the receipt honest. Onchain Model Card should make claim drift visible, not promote documentation into certification.

Final Rule

The safest sentence is boring: "This chain record anchors this model-card claim set, by this issuer, at this version, with these limits." That sentence is narrow enough to audit.

That is the useful boundary for AI x crypto systems. A model-card hash can keep quiet claim changes from disappearing. It cannot tell a user that the model deserves any trust.