Onchain Model Cards: Preventing Silent Rewrites of AI Claims

Onchain model cards were designed to solve a critical problem in AI governance: preventing the silent revision of model claims without detection. Yet, as the technology gains traction, a subtle flaw emerges—one that allows the underlying evidence to shift while the onchain record appears unchanged.

This discrepancy stems from a fundamental mismatch between how model cards are used in practice and how onchain records are interpreted. A model card might initially state that a model is "approved for support triage," only for the documentation to later clarify that it is "experimental"—without the onchain reference ever reflecting that change. The result? A stable hash pointing to an outdated or evolving claim.

The Core Problem: Silent Edits Break Trust

Model cards are living documents, frequently updated to reflect new insights, corrections, or shifts in intended use. However, when these changes occur without updating the onchain record, the discrepancy creates a false sense of security. Users and developers may rely on outdated or incorrect information, assuming the onchain hash guarantees accuracy.

For example, a team deploys a model with an onchain model card stating it is suitable for production use. Months later, an internal audit reveals performance issues, and the card is revised to indicate "experimental" status. Yet, the original onchain record remains unchanged, potentially misleading downstream users who check the hash for trust signals.

What an Onchain Model Card Should Anchor

An effective onchain model card must do more than record a hash—it must explicitly capture the exact claim set it intends to validate. This includes:

• The specific bytes of the model card that were reviewed
• The precise claims extracted and their canonicalized form
• The issuer’s identity and their authority to make the claim
• The version or revision of the card being referenced
• A clear definition of what the receipt does not prove (e.g., safety, licensing, or runtime behavior)

Without these details, the onchain record risks becoming a misleading artifact—a static pointer to a dynamic document.

Structured Receipts: The Practical Solution

The solution lies in structured claim receipts, which serve as lightweight, verifiable summaries of the model card’s claims. These receipts are intentionally smaller than the full model card, focusing only on the extracted claims and their cryptographic proofs.

A well-designed receipt might look like this:

{
  "receipt_type": "ai.model_card_claim_receipt.v1",
  "card_subject": "org/model-name",
  "model_repository": "
  "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"
  },
  "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"
  ]
}

Key components of this receipt include:

• Claim extraction: Only the relevant claims (e.g., intended use, limitations) are hashed, not the entire document.
• Canonicalization: The extracted claims are serialized using a standard like RFC 8785 to ensure consistent hashing.
• Limits: The receipt explicitly states what it does not cover, preventing overreliance on its guarantees.
• Versioning: The supersedes field tracks updates, ensuring users can see the evolution of claims over time.

Why Hashing the Full Model Card Isn’t Enough

Hashing the entire model card (e.g., a README.md file) only confirms that the document hasn’t been altered—it does not validate the accuracy or meaning of the claims within. A model card might describe a model as "highly accurate," but the hash does not verify whether that benchmark was fair, whether the dataset was lawfully sourced, or whether the model behaves the same way in production.

Instead, the focus should be on extracting structured claims and hashing those, not the raw text. This approach aligns with established standards like RFC 8785 (JSON Canonicalization Scheme) and RFC 6920 (Named Information), which provide frameworks for identifying and referencing specific pieces of information.

The Role of Issuer Identity and Verifiable Credentials

Structured claims require an issuer—a recognized entity that vouches for the accuracy of the claims. Standards like the Verifiable Credentials Data Model 2.0 and Verifiable Credential Data Integrity 1.0 offer frameworks for creating and verifying signed claims. However, these standards alone do not confer trust—they merely provide the tools to express and validate claims.

The issuer’s identity must be decoupled from the model itself. Using decentralized identifiers (DIDs), as defined in DID Core, allows verifiers to look up the issuer’s verification material. Yet, even with a DID, the ultimate decision about whether to trust the issuer remains with the user.

Ethereum and Typed Signing: Practical Implementation

For Ethereum-based implementations, EIP-712 offers a structured approach to signing claims. Unlike raw string signatures, EIP-712 enables typed data structures, reducing the risk of misinterpretation. This is particularly useful for onchain model cards, where clarity in claim representation is critical.

However, EIP-712 should not be mixed with other signing profiles (e.g., VC Data Integrity or RFC 8785 canonical JSON) in a single receipt. Each profile has its own rules, and conflating them can lead to inconsistencies or vulnerabilities.

The Path Forward: Transparency Over Assumptions

Onchain model cards hold promise as a tool for AI governance, but their effectiveness depends on rigorous standards and clear boundaries. By focusing on structured claim receipts—rather than raw hashes—they can provide verifiable, tamper-resistant records of what was actually reviewed and endorsed.

The technology is still evolving, and the community must prioritize education and standardization to ensure these systems are used responsibly. Without these guardrails, the risk remains: a hash that looks trustworthy, but a claim that has quietly changed.