⚠️ Validation Data Profile (PENDING SPECIFICATION)

🚨 CRITICAL NOTICE
This specification is UNSTABLE and PENDING FINALIZATION.
The ERC-8004 Validation Registry specification is still under active development and may change significantly based on ongoing discussions with the TEE/ZK community. This document represents the current working draft but should not be considered final for production deployment.
Key uncertainties:
TEE attestation format and requirements (to be revised)
Full contract ABI and function signatures (preview only)
Event structure and indexed parameters (may change)
Off-chain JSON schema (subject to revision)
Status tracking: See official ERC-8004 repository for latest specification updates and timelines.
For production use: Wait for final v1.1 release before implementing Validation Registry integrations.

Description

Recommended offchain data profile for ERC-8004 validation records. This document provides implementation-agnostic guidance for structuring validation request and response data referenced by the requestURI and responseURI fields in ERC-8004 Validation Registry contracts.

Current state: v1.1-preview based on SpecsJan26Update (Jan 2026). See official progress for latest updates.

Specification Maturity

Component	Status	Ready for Production?
Identity Registry	✅ STABLE	Yes
Reputation Registry	✅ STABLE	Yes
Validation Registry	⚠️ UNSTABLE	No - Under development (see official repo)

Recommendation: Design your validation architecture but keep data migration paths flexible as the specification evolves.

Relationship to EIP-8004

This is not part of the official EIP-8004 specification, which only defines:

Smart contract interface (Validation Registry)
Onchain fields: validatorAddress, agentId, requestUri, responseUri, response, tag
URI references to offchain data

This profile provides recommended offchain JSON structures for better interoperability across ERC-8004 implementations.

Terminology

This document follows conventions defined in Conventions. For attachment file patterns, see Attachment Pattern Standard.

Intended Audience

Validators creating validation requests and responses
Indexers and explorers building Validation Registry systems

Overview
Format Compatibility Approach
Validation Request Profile
Validation Response Profile
Known Custom Formats
Attachment Pattern
Parse Status Indicators
Migration Guide
Examples

Overview

Onchain vs Offchain Data

Stored Onchain:

validatorAddress (address) - Who validates
agentId (uint256) - Which agent
requestHash (bytes32) - Hash of request data
response (uint8) - Validation score (0-100)
responseHash (bytes32) - Hash of response data
tag (string) - Validation category
lastUpdate (uint256) - Unix timestamp

Emitted in Events (not stored):

requestURI - Location of detailed request data
responseURI - Location of detailed response data

Indexers: Use event parameters to fetch offchain URIs and retrieve complete validation data.

Offchain Data (referenced by URI):

Detailed validation criteria and methodology
Proof data (zkSNARK, TEE attestation, etc.)
Test results and supporting evidence
Resource usage and performance metrics

Format Compatibility Approach

Non-normative: This section describes 8004scan's recommended approach to handling diverse validation formats.

Level 1: Recommended Profile ✅

Parse Status: success (no issues) or warning (minor suggestions)

The community-recommended profile format for maximum interoperability.

When to Use:

New validation systems
Multi-chain deployments
Public registries requiring interoperability
Integration with multiple ERC-8004 tools

Benefits:

✅ Better indexing and searchability
✅ Frontend displays all metadata
✅ Compatible with standard tooling
✅ Easier integration across platforms

Level 2: Known Custom Formats 🟡

Parse Status: known_custom

Recognized specialized formats that don't conform to ERC-8004 but are widely used.

Supported Formats:

Groth16 zkSNARK Proof - Complete zero-knowledge proofs
PLONK Proof - (Future support planned)
STARK Proof - (Future support planned)
Halo2 Proof - (Future support planned)

When to Use:

Existing production systems (e.g., ZyFi protocol)
Specialized proof requirements
Migration period from custom to standard

Limitations:

⚠️ Limited metadata extraction
⚠️ Manual format interpretation required
⚠️ May not appear in some filtered views

Level 3: Unknown Formats ⚠️

Parse Status: unknown

Valid JSON that doesn't match any recognized pattern.

Handling:

Data stored as-is in offchain_request_data / offchain_response_data
Displayed as raw JSON in UI
No automatic metadata extraction

Recommendation: Consider migrating to Level 1 (Recommended Profile) for better interoperability, or contact the community to add Level 2 support for your format.

Validation Request Profile

Schema

json

{
  // Required
  "agentRegistry": "eip155:84532:0x8004C269D0A5647E51E121FeB226200ECE932d55",
  "agentId": 56,
  "validatorAddress": "eip155:84532:0x4baf957830423f36978039e32d95ee958aa0560c",
  "createdAt": "2025-12-20T05:00:38Z",
  "validationType": "zkml-proof",

  // Recommended
  "reasoning": "Request validation for agent rebalancing logic",
  "deadline": "2025-12-21T05:00:38Z",

  // Optional: Type-specific payloads
  "job": {
    /* Crypto-economic validation */
  },
  "teeRequest": {
    /* TEE attestation validation */
  },
  "zkmlRequest": {
    /* zkML proof validation */
  },
  "bounty": {
    /* Incentive structure */
  },
  "attachments": [
    /* Supporting evidence */
  ]
}

Recommended Schema (Level 1)

json

{
  // ============ REQUIRED FIELDS ============
  "agentRegistry": "eip155:84532:0x8004C269D0A5647E51E121FeB226200ECE932d55",
  "agentId": 56,
  "validatorAddress": "eip155:84532:0x4baf957830423f36978039e32d95ee958aa0560c",
  "createdAt": "2025-12-20T05:00:38Z",
  "validationType": "zkml-proof",

  // ============ RECOMMENDED FIELDS ============
  "reasoning": "Request validation for agent rebalancing logic",
  "deadline": "2025-12-21T05:00:38Z",

  // ============ OPTIONAL: VALIDATION TYPE PAYLOADS ============

  // For crypto-economic validations
  "job": {
    "taskDescription": "Validate portfolio rebalancing logic",
    "expectedOutputFormat": "JSON schema with rebalancing recommendations",
    "testDataUri": "ipfs://Qm...",
    "successCriteria": "Optimal allocation within 2% of benchmark"
  },

  // For TEE attestation validations
  "teeRequest": {
    "attestationType": "sgx",
    "requiredEnclave": "ProductID:1,SecurityVersion:2",
    "measurementHash": "0x..."
  },

  // For zkML proof validations
  "zkmlRequest": {
    "circuit": "zyfi-rebalancing-validation",
    "publicInputs": ["4190804445", "1"],
    "verifierAddress": "0x4baf957830423f36978039e32d95ee958aa0560c"
  },

  // ============ OPTIONAL: BOUNTY ============
  "bounty": {
    "amount": "1000000000000000000",
    "token": "eip155:84532:0x...",
    "conditions": "Paid upon successful validation within 24 hours"
  },

  // ============ OPTIONAL: ATTACHMENTS ============
  "attachments": [
    {
      "name": "Test Dataset",
      "uri": "ipfs://Qmxxx...",
      "mimeType": "application/json",
      "size": 50000,
      "description": "Sample portfolio data for rebalancing validation",
      "uploadedAt": "2025-12-20T05:00:00Z"
    }
  ]
}

Required Fields

Field	Type	Format	Description
`agentRegistry`	string	CAIP-10	Agent's identity registry address (e.g., `eip155:84532:0x8004C...`)
`agentId`	number	uint256	Agent token ID
`validatorAddress`	string	CAIP-10	Validator's wallet address (e.g., `eip155:84532:0x4baf...`)
`createdAt`	string	ISO 8601	Request creation timestamp
`validationType`	string	enum	One of: `crypto-economic`, `tee-attestation`, `zkml-proof`

Recommended Fields

Field	Type	Description
`reasoning`	string	Explanation of why validation is needed
`deadline`	string (ISO 8601)	Expected response deadline

Optional Fields by Validation Type

Crypto-Economic (job object):

taskDescription - What the agent should do
expectedOutputFormat - Format specification
testDataUri - Test data location
successCriteria - How success is measured

TEE Attestation (teeRequest object):

attestationType - TEE type (e.g., "sgx", "sev", "tdx")
requiredEnclave - Enclave requirements
measurementHash - Expected measurement

zkML Proof (zkmlRequest object):

circuit - Circuit identifier
publicInputs - Public inputs array
verifierAddress - Verifier contract address

Validation Response Profile

Recommended Schema (Level 1)

json

{
  // ============ REQUIRED FIELDS ============
  "requestHash": "0x5c1a08c66c0489030f05990a83534280ee08da7cd944dc353bf4b661c5c96657",
  "validatorAddress": "eip155:84532:0x4baf957830423f36978039e32d95ee958aa0560c",
  "agentId": 56,
  "response": 100,
  "createdAt": "2025-12-20T06:00:00Z",

  // ============ RECOMMENDED FIELDS ============
  "result": "passed",
  "reasoning": "Agent successfully passed all validation tests",
  "confidence": 0.95,

  // ============ OPTIONAL: VALIDATION TYPE PROOFS ============

  // For crypto-economic validations
  "executionProof": {
    "outputUri": "ipfs://Qmyyy...",
    "executionTime": "2.5s",
    "resourceUsage": {
      "cpu": "0.8 cores",
      "memory": "512MB",
      "network": "10MB"
    }
  },

  // For TEE attestation validations
  "teeAttestation": {
    "quote": "0x...",
    "quoteSignature": "0x...",
    "reportData": "0x...",
    "timestamp": "2025-12-20T05:30:00Z"
  },

  // For zkML proof validations
  "zkmlProof": {
    "proof": {
      "pi_a": ["...", "...", "1"],
      "pi_b": [[...], [...], ["1", "0"]],
      "pi_c": ["...", "...", "1"],
      "protocol": "groth16",
      "curve": "bn128"
    },
    "publicSignals": ["4190804445", "1"],
    "verifiedAt": "2025-12-20T05:45:00Z"
  },

  // ============ OPTIONAL: ATTACHMENTS ============
  "attachments": [
    {
      "name": "Validation Report",
      "uri": "ipfs://Qmzzz...",
      "mimeType": "application/pdf",
      "size": 2048000,
      "description": "Comprehensive validation report with test results",
      "uploadedAt": "2025-12-20T05:50:00Z"
    }
  ]
}

Required Fields

Field	Type	Format	Description
`requestHash`	string	bytes32 hex	Hash of the validation request (from on-chain contract)
`validatorAddress`	string	CAIP-10	Validator's wallet address (e.g., `eip155:84532:0x4baf...`)
`agentId`	number	uint256	Agent token ID
`response`	number	0-100 (uint8 onchain)	Validation score
`createdAt`	string	ISO 8601	Response creation timestamp
`tag`	string	-	Validation category (e.g., `security-audit`, `tee-attestation`, etc.)

Recommended Fields

Field	Type	Values	Description
`result`	string	`passed`, `failed`, `partial`	Validation result
`reasoning`	string	-	Explanation of the result
`confidence`	number	0.0-1.0	Confidence level in the result

Known Custom Formats

Groth16 zkSNARK Proof

Format Type: groth16_zksnark
Parse Status: known_custom
Use Case: Zero-knowledge proof validation (e.g., ZyFi rebalancing)

json

{
  // ============ PROOF STRUCTURE ============
  "proof": {
    "pi_a": ["8070450532247928943", "1234567890123456789", "1"],
    "pi_b": [
      ["...", "..."],
      ["...", "..."],
      ["1", "0"]
    ],
    "pi_c": ["...", "...", "1"],
    "protocol": "groth16",
    "curve": "bn128"
  },

  // ============ PUBLIC SIGNALS ============
  "publicSignals": ["4190804445", "1"],

  // ============ VERIFICATION INFO ============
  "verifierAddress": "0x4baf957830423f36978039e32d95ee958aa0560c",
  "validationRegistryAddress": "0x8004C269D0A5647E51E121FeB226200ECE932d55",

  // ============ METADATA ============
  "chainId": 84532,
  "circuit": "zyfi-rebalancing-validation",
  "version": "1.0",
  "timestamp": 1734675235991
}

Known Usage:

ZyFi Protocol: 8,000+ validations on Base Sepolia
Circuit: zyfi-rebalancing-validation
Verifier: 0x4baf957830423f36978039e32d95ee958aa0560c

Detection Criteria:

Has proof object with pi_a, pi_b, pi_c fields
Has publicSignals array
Has verifierAddress or validationRegistryAddress

Attachment Pattern

Overview

The attachment pattern allows adding multiple evidence files to validation requests or responses.

For complete attachment schema and guidelines, see Attachment Pattern Guidelines.

Quick Reference

typescript

interface AttachmentFile {
  name: string; // Display name (required)
  uri: string; // File location (required)
  mimeType: string; // MIME type (required)
  size: number; // File size in bytes (required)
  description?: string; // Optional context
  uploadedAt?: string; // Optional timestamp (ISO 8601 UTC)
}

Common Use Cases for Validation

Test Results: Automated test output, benchmark data
Audit Reports: Security audits, code reviews
TEE Attestations: Remote attestation documents
Performance Metrics: Load test results, uptime reports

Supported File Types: PDFs, images, videos, JSON, CSV, text files, and more.

See Attachment Pattern Guidelines for detailed specifications and examples.

Parse Status Indicators

When querying validation data via the 8004scan API, each record includes a parse_status field indicating format compliance.

Status	Meaning	UI Display	Action Required
`success`	ERC-8004 compliant, no warnings	✅ Green checkmark	None
`warning`	ERC-8004 compliant, minor suggestions	🟡 Yellow warning	Review suggestions
`known_custom`	Recognized custom format (e.g., Groth16)	🟡 Custom badge	Consider migrating
`unknown`	Unrecognized format	⚠️ Grey question mark	Update to standard
`error`	Parse/fetch failure	❌ Red error	Fix URI/data

Migration Guide

From Groth16 to ERC-8004 Standard

Minimal Upgrade (wrap existing proof):

json

{
  "agentRegistry": "eip155:84532:0x8004C269...",
  "agentId": 56,
  "validatorAddress": "eip155:84532:0x4baf957...",
  "createdAt": "2025-12-20T05:00:38Z",
  "validationType": "zkml-proof",
  "zkmlProof": {
    "proof": { "pi_a": [...], "pi_b": [...], "pi_c": [...], "protocol": "groth16", "curve": "bn128" },
    "publicSignals": ["4190804445", "1"],
    "circuit": "zyfi-rebalancing-validation"
  }
}

Full Upgrade (use attachments):

json

{
  "agentRegistry": "eip155:84532:0x8004C269...",
  "agentId": 56,
  "validatorAddress": "eip155:84532:0x4baf957...",
  "createdAt": "2025-12-20T05:00:38Z",
  "validationType": "zkml-proof",
  "reasoning": "Agent rebalancing validated via zkSNARK",
  "attachments": [
    {
      "name": "Groth16 Proof",
      "uri": "ipfs://bafkrei...",
      "mimeType": "application/json",
      "description": "ZyFi rebalancing validation proof"
    }
  ]
}

Examples

Example 1: zkML Validation Request

json

{
  "agentRegistry": "eip155:84532:0x8004C269D0A5647E51E121FeB226200ECE932d55",
  "agentId": 56,
  "validatorAddress": "eip155:84532:0x4baf957830423f36978039e32d95ee958aa0560c",
  "createdAt": "2025-12-20T05:00:38Z",
  "validationType": "zkml-proof",
  "reasoning": "Validate agent's portfolio rebalancing algorithm",
  "deadline": "2025-12-21T05:00:38Z",
  "zkmlRequest": {
    "circuit": "zyfi-rebalancing-validation",
    "publicInputs": ["4190804445", "1"],
    "verifierAddress": "0x4baf957830423f36978039e32d95ee958aa0560c"
  }
}

Example 2: Validation Response with Groth16 Proof

json

{
  "requestHash": "0x5c1a08c66c0489030f05990a83534280ee08da7cd944dc353bf4b661c5c96657",
  "validatorAddress": "eip155:84532:0x4baf957830423f36978039e32d95ee958aa0560c",
  "agentId": 56,
  "response": 100,
  "createdAt": "2025-12-20T06:00:00Z",
  "tag": "zkml-proof",
  "result": "passed",
  "reasoning": "Agent rebalancing logic validated. All test cases passed.",
  "confidence": 0.95,
  "zkmlProof": {
    "proof": { "pi_a": [...], "pi_b": [...], "pi_c": [...], "protocol": "groth16", "curve": "bn128" },
    "publicSignals": ["4190804445", "1"],
    "verifiedAt": "2025-12-20T05:45:00Z"
  }
}

FAQ

Q: How are Validation Registry contracts upgraded (v1.1 and beyond)?

A: ERC-8004 uses the UUPS (Universal Upgradeable Proxy Standard) pattern for safe upgrades:

solidity

// Current deployment (v1.1)
address proxyAddress = 0x...;  // Permanent address
address implV1 = 0x...;        // v1.1 implementation

// When upgrading to v1.1+
address implV2 = 0x...;        // New implementation
// Owner calls: proxy.upgradeTo(implV2)
// Users continue using same proxy address (0x...)

Key guarantees:

Permanent address: The proxy address never changes
- All validation records reference fixed registry address
- Off-chain indexers continue working without migration
Storage layout preservation: Upgrades MUST NOT change field order
- Existing validation records remain valid
- New fields added at end only
Event compatibility: New events additive only
- Old indexers continue processing events
- New indexers see full history
Backwards compatibility: Function signatures stable
- recordValidation() signature guaranteed across upgrades
- New features added via new functions

For indexers:

Continue listening to same contract address
New validation types appear in events
Old validation records accessible via historical queries
No need to re-index on upgrade

For validators:

URI format (requestUri, responseUri) is stable
Off-chain data format guidelines (this document) apply across versions
Submit validation responses to same contract address always

⚠️ Validation Data Profile (PENDING SPECIFICATION)

Description

Specification Maturity

Relationship to EIP-8004

Terminology

Intended Audience

Table of Contents

Overview

Onchain vs Offchain Data

Format Compatibility Approach

Level 1: Recommended Profile ✅

Level 2: Known Custom Formats 🟡

Level 3: Unknown Formats ⚠️

Validation Request Profile

Schema

Recommended Schema (Level 1)

Required Fields

Recommended Fields

Optional Fields by Validation Type

Validation Response Profile

Recommended Schema (Level 1)

Required Fields

Recommended Fields

Known Custom Formats

Groth16 zkSNARK Proof

Attachment Pattern

Overview

Quick Reference

Common Use Cases for Validation

Parse Status Indicators

Migration Guide

From Groth16 to ERC-8004 Standard

Examples

Example 1: zkML Validation Request

Example 2: Validation Response with Groth16 Proof

FAQ

Q: How are Validation Registry contracts upgraded (v1.1 and beyond)?

See Also

⚠️ Validation Data Profile (PENDING SPECIFICATION)

Description ​

Specification Maturity ​

Relationship to EIP-8004 ​

Terminology ​

Intended Audience ​

Table of Contents ​

Overview ​

Onchain vs Offchain Data ​

Format Compatibility Approach ​

Level 1: Recommended Profile ✅ ​

Level 2: Known Custom Formats 🟡 ​

Level 3: Unknown Formats ⚠️ ​

Validation Request Profile ​

Schema ​

Recommended Schema (Level 1) ​

Required Fields ​

Recommended Fields ​

Optional Fields by Validation Type ​

Validation Response Profile ​

Recommended Schema (Level 1) ​

Required Fields ​

Recommended Fields ​

Known Custom Formats ​

Groth16 zkSNARK Proof ​

Attachment Pattern ​

Overview ​

Quick Reference ​

Common Use Cases for Validation ​

Parse Status Indicators ​

Migration Guide ​

From Groth16 to ERC-8004 Standard ​

Examples ​

Example 1: zkML Validation Request ​

Example 2: Validation Response with Groth16 Proof ​

FAQ ​

Q: How are Validation Registry contracts upgraded (v1.1 and beyond)? ​

See Also ​

Description

Specification Maturity

Relationship to EIP-8004

Terminology

Intended Audience

Table of Contents

Overview

Onchain vs Offchain Data

Format Compatibility Approach

Level 1: Recommended Profile ✅

Level 2: Known Custom Formats 🟡

Level 3: Unknown Formats ⚠️

Validation Request Profile

Schema

Recommended Schema (Level 1)

Required Fields

Recommended Fields

Optional Fields by Validation Type

Validation Response Profile

Recommended Schema (Level 1)

Required Fields

Recommended Fields

Known Custom Formats

Groth16 zkSNARK Proof

Attachment Pattern

Overview

Quick Reference

Common Use Cases for Validation

Parse Status Indicators

Migration Guide

From Groth16 to ERC-8004 Standard

Examples

Example 1: zkML Validation Request

Example 2: Validation Response with Groth16 Proof

FAQ

Q: How are Validation Registry contracts upgraded (v1.1 and beyond)?

See Also