Skip to content

aip-0011.md

Latest commit

 

History

History
177 lines (128 loc) · 4.18 KB

aip-0011.md

File metadata and controls

177 lines (128 loc) · 4.18 KB
Raw

AIP-0011: Avian AI Model Registry

AIP:     0011
Title:   Avian AI Model Registry
Author:  Avian Network Developers
Status:  Draft
Type:    Standards Track
Category: Application / Metadata
Created: 2026-06-07
Requires: AIP-0010

Abstract

This AIP defines a standard registry format for AI models used to produce Avian AI attestations.

The registry allows wallets, explorers, marketplaces, workers, and indexers to identify which model produced an attestation, which version was used, how the model is hashed, what input and output schemas are expected, and whether the model is active, deprecated, or revoked.

Motivation

An AI attestation is only useful if consumers know which model produced it.

Without a model registry, a report saying “AI verified” is vague and not independently meaningful. The Avian ecosystem needs a way to reference specific model versions, hashes, input schemas, output schemas, and activation periods.

Specification

1. Model Registry Entry

A model registry entry MUST use the following structure:

{
  "schema": "avian.ai.model_registry.v1",
  "model_id": "avian-asset-validator-v1",
  "name": "Avian Asset Validator",
  "description": "AI model profile for validating Avian asset metadata and IPFS CIDs.",
  "model_family": "qwen",
  "model_version": "1.0.0",
  "model_hash": "sha256-model-or-bundle-hash",
  "runtime": {
    "engine": "ollama",
    "version": "optional-runtime-version",
    "deterministic": false
  },
  "input_schema": "avian.ai.input.asset_review.v1",
  "output_schema": "avian.ai.attestation.v1",
  "capabilities": [
    "asset_metadata_review",
    "cid_health_review",
    "marketplace_listing_review"
  ],
  "status": "active",
  "created_at": "2026-06-07T00:00:00Z",
  "activation_height": 0,
  "retirement_height": null,
  "maintainer": {
    "name": "optional-maintainer-name",
    "address": "optional-avn-address",
    "pubkey": "optional-public-key"
  },
  "signature": {
    "algorithm": "secp256k1",
    "signature": "hex-encoded-signature"
  }
}

2. Model Status

The status field MUST be one of:

active
deprecated
revoked
experimental
testing
retired

Applications SHOULD warn users when an attestation was produced by a deprecated, revoked, testing, or experimental model.

3. Model Hashing

The model_hash SHOULD represent a deterministic hash of the model bundle.

A model bundle MAY include:

  • Model weights
  • Quantization format
  • Prompt template
  • System prompt
  • Input schema
  • Output schema
  • Runtime configuration
  • Pre-processing rules
  • Post-processing rules

For non-deterministic models, the registry MUST indicate that deterministic reproduction is not guaranteed.

4. Capabilities

The capabilities array SHOULD identify supported use cases.

Initial capability names include:

asset_metadata_review
cid_health_review
marketplace_listing_review
transaction_intent_review
psbt_intent_review
address_risk_review
mempool_anomaly_review
network_health_review
release_review
exchange_service_review

5. Registry Storage

A model registry MAY be stored:

  • In a Git repository
  • In IPFS
  • In an explorer/indexer database
  • In a signed Avian metadata document
  • Through on-chain anchoring defined by a future AIP

6. Consensus

This AIP introduces no consensus changes.

Avian nodes are not required to know, fetch, validate, or enforce model registry entries.

Rationale

Model versioning is critical for AI transparency.

A signed model registry allows the ecosystem to distinguish between a real, versioned AI attestation and an unverifiable claim.

Backwards Compatibility

This AIP is fully backwards compatible.

Security Considerations

A malicious registry entry could misrepresent a model’s capabilities, status, or hash.

Consumers SHOULD prefer signed registry entries from known maintainers or decentralized registries with multiple independent attestations.

Applications SHOULD clearly show when a model is experimental, deprecated, or revoked.

Future Work

Future AIPs may define:

  • On-chain model registry anchoring
  • Decentralized model approval
  • Model challenge and revocation procedures
  • Post-quantum signing support
  • ZKML proof support