Schemas

Fidemark registers two schemas with the EAS Schema Registry. Both are resolver-bound to the same FidemarkResolver contract and both are revocable.

Human Content Attestation

bytes32 contentHash,
string  contentType,
address creator,
uint64  createdAt,
string  proofMethod

Field	Purpose
contentHash	SHA-256 of the attested content. Hashed client-side; raw content never leaves the attester.
contentType	MIME-style label or category. Conventional: text/article, image/jpeg, audio/wav. Free-form.
creator	The address of the human creator. Resolver-enforced to equal the transaction’s attester.
createdAt	The attester’s claim about when the content was created (Unix seconds). Cannot be more than 1 day in the future.
proofMethod	The trust layer: wallet-signed, ens-verified, etc. Resolver-enforced against an allowlist. See Trust layers.

AI Output Attestation

bytes32 contentHash,
string  modelId,
bytes32 promptHash,
string  parameters,
string  provider

Field	Purpose
contentHash	SHA-256 of the AI output.
modelId	Canonical model identifier (e.g. claude-sonnet-4-6).
promptHash	SHA-256 of the prompt: proves which prompt without revealing it. May be zero for agent flows without a discrete prompt.
parameters	JSON-stringified generation parameters. May be empty.
provider	Provider name (e.g. anthropic, openai, local).

Why these fields and not others

A few intentional omissions:

• No raw content. Fidemark is a provenance protocol, not a CDN. The content lives wherever you publish it; the chain only records its hash.
• No raw prompt. Same reason. Prompts often contain proprietary logic: the hash gates a future reveal-and-prove flow.
• No identity claims at the schema level. Identity is layered on top via proofMethod. The schemas stay neutral.
• No license / rights metadata. Out of scope for v1. Composable atop via referenced attestations.