Claim Schema

The schema defines the precise key-value pairs that constitute a claim. This includes:

• Subject Identifier: The entity the claim is about (e.g., a wallet address, DID).
• Issuer Identifier: The authority making the claim.
• Claim Properties: The specific attributes being attested (e.g., isKYCVerified: true, membershipTier: "gold").
• Metadata: Timestamps, schema version, and context URIs.

It enforces data integrity by specifying the expected data type (string, integer, boolean) and validation constraints for each field. For example:

• A birthDate field must be an ISO 8601 date string.
• A score field must be an integer between 0 and 1000.
• A countryCode field must be a valid ISO 3166-1 alpha-2 code. This ensures all claims conforming to the schema are machine-readable and interoperable.

Often implemented using JSON-LD (Linked Data), the schema links its fields to globally unique URIs that define their meaning. This prevents ambiguity. For instance, the property address could be linked to https://schema.org/address instead of a proprietary definition. This creates a verifiable data graph where terms have shared, unambiguous meanings across different systems.

Schemas are versioned (e.g., MyCredentialV1.0.0) and typically stored on-chain or in content-addressable storage (like IPFS) to ensure immutability and non-repudiation. Once published, the schema's hash (e.g., a schemaId) becomes its permanent identifier. Applications can trust that a claim referencing a specific schemaId conforms to a known, unchangeable structure.

By adhering to common schema formats like W3C Verifiable Credentials or EIP-712 for typed signing, claim schemas enable cross-platform interoperability. A credential issued by one organization (e.g., a DAO membership card) can be understood and verified by any application that recognizes the schema, breaking down data silos.

A real-world schema for a Proof of Personhood attestation might define:

jsonCopy
{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "ProofOfPersonhoodCredential"],
  "credentialSubject": {
    "id": "did:ethr:0x...",
    "isUniqueHuman": true,
    "verificationProtocol": "Worldcoin Orb",
    "verificationDate": "2023-10-05T12:00:00Z"
  }
}

The schema ensures every credential has these exact fields with proper types.

A standardized schema for verifying a user's identity and compliance status, often required for regulated DeFi access. This schema typically includes:

• Fields: fullName, dateOfBirth, countryOfResidence, kycProvider, kycLevel, expiryDate.
• Validators: Checks for issuer signature, expiry, and accredited provider list.
• Use Case: Grants access to permissioned pools or higher transaction limits based on verified identity.

A portable, user-controlled financial reputation credential. This schema structures off-chain credit data for on-chain use.

• Fields: creditScore, scoreProvider (e.g., Experian, Equifax), timestamp, riskTier, debtToIncomeRatio.
• Validators: Ensures data is recent (e.g., < 30 days old) and signed by a trusted oracle or institution.
• Use Case: Underwriting for undercollateralized lending protocols without exposing raw personal data.

A schema attesting that a credential holder is a unique human, often used for Sybil resistance in governance or airdrops.

• Fields: uniqueHumanId, verificationMethod (e.g., video attestation, government ID), verificationDate.
• Validators: Confirms the claim is issued by a recognized proof-of-humanity system like Worldcoin or BrightID.
• Use Case: One-person-one-vote DAO governance or fair token distribution.

A verifiable credential for professional licenses, certifications, or guild membership.

• Fields: accreditationName, issuingAuthority, dateIssued, dateExpires, credentialId.
• Validators: Verifies the issuer is the legitimate accrediting body and the credential is not revoked.
• Use Case: Permissioned access for smart contract auditors, legal advisors, or certified developers within a protocol's ecosystem.

A schema summarizing a wallet's historical on-chain behavior as a reputation proxy.

• Fields: totalVolume, protocolsUsed, ageOfAccount, successfulRepayments, defaultCount.
• Validators: Checks that the attestation is generated and signed by a credible analytics oracle (e.g., Chainscore, Cred Protocol).
• Use Case: Building a DeFi Passport to access tailored financial products based on proven track record.

A claim that verifies an individual's membership and activity level within a Decentralized Autonomous Organization.

• Fields: daoName, memberSince, role, contributionScore, proposalsVoted.
• Validators: Confirms the claim is signed by the DAO's official governance module or designated signer.
• Use Case: Gating access to private channels, weighted voting power, or reward distribution based on participation.

A Claim Schema defines the essential fields and data types for a claim. Key components include:

• Issuer: The decentralized identifier (DID) of the entity making the claim.
• Subject: The DID of the entity the claim is about.
• Credential Type: A unique identifier for the schema (e.g., VerifiableCredential).
• Claims Data: The specific attributes being attested, structured as key-value pairs.
• Proof: The cryptographic signature or zero-knowledge proof that validates the claim's authenticity and integrity.

Claim Schemas are the backbone of Verifiable Credentials (VCs), a W3C standard for digital credentials. A VC is a tamper-evident credential whose issuer can be cryptographically verified. The schema ensures interoperability by standardizing the credentialSubject object, which contains the actual claim data, allowing any compliant verifier to understand and process the credential without prior agreement with the issuer.

Schemas can be stored and referenced in different ways:

• On-Chain Schema: The schema's structure (like a JSON Schema) is registered on a blockchain (e.g., Ethereum's EIP-712 for typed data, or a dedicated registry). This provides immutability and global consensus on the data format.
• Off-Chain Schema: The schema is hosted on a traditional web server or decentralized storage (like IPFS). The schema's URI is referenced in the claim, requiring verifiers to fetch it. This offers flexibility but depends on the URI's availability.

To ensure discoverability and prevent duplication, schemas are often published to Schema Registries. These are decentralized directories, often implemented as smart contracts or on IPFS, that map a unique Schema ID (like a hash or a DID) to the full schema definition. Projects like the Verifiable Credentials Data Model rely on such registries so verifiers can resolve a schema URI to understand how to validate a claim's data structure.

In Decentralized Identity (DID) systems, Claim Schemas enable portable, user-controlled credentials. For example, a university can issue a DegreeCredential using a standardized schema. The graduate can then present this VC to an employer, who verifies the schema and the cryptographic proof. This eliminates the need for centralized credential verification services and gives users control over their data.

Schemas are critical for building on-chain reputation systems and gated access. A DAO might define a ContributorCredential schema to attest to a member's work. Smart contracts can then be programmed to read claims conforming to this schema, automatically granting voting power or access to a token-gated channel based on the attested reputation score or role.