Skip to content

aip-0012.md

Latest commit

 

History

History
183 lines (125 loc) · 4.23 KB

aip-0012.md

File metadata and controls

183 lines (125 loc) · 4.23 KB
Raw

AIP-0012: On-chain AI Attestation Anchoring

AIP:     0012
Title:   On-chain AI Attestation Anchoring
Author:  Avian Network Developers
Status:  Draft
Type:    Standards Track
Category: Application / Transaction Metadata
Created: 2026-06-07
Requires: AIP-0010, AIP-0011

Abstract

This AIP defines an optional method for anchoring AI attestation reports on the Avian blockchain.

The full AI report SHOULD remain off-chain. The blockchain MAY store a compact commitment containing the report hash, report CID, target reference, model ID, and attestor signature.

This allows Avian wallets, explorers, marketplaces, and indexers to verify that an AI attestation existed at or before a specific block height without requiring Avian consensus nodes to execute AI models.

Motivation

AI attestations are useful when they can be verified, timestamped, and linked to Avian blockchain objects.

Off-chain storage alone can be modified, deleted, or disputed. On-chain anchoring provides a durable timestamp and integrity commitment while keeping the base chain lightweight.

Specification

1. Anchoring Method

An AI attestation anchor SHOULD be encoded as metadata in a standard Avian transaction output.

The recommended logical payload is:

{
  "schema": "avian.ai.anchor.v1",
  "attestation_id": "sha256-attestation-id",
  "target": {
    "type": "asset",
    "identifier": "ASSET_NAME",
    "txid": "optional-target-txid",
    "vout": 0,
    "cid": "optional-target-cid"
  },
  "model_id": "avian-asset-validator-v1",
  "attestor": "AVN_ADDRESS_OR_ID",
  "report_hash": "sha256-report-json",
  "report_cid": "optional-ipfs-cid",
  "created_at": "2026-06-07T00:00:00Z"
}

2. Compact Binary Encoding

Implementations SHOULD support a compact binary encoding for on-chain use.

The binary payload SHOULD include:

magic bytes
schema version
target type
target identifier hash
model id hash
attestor id hash
report hash
optional report CID hash
timestamp
signature

The exact binary encoding MAY be defined in a later implementation AIP if required.

3. OP_RETURN or Asset Metadata Carrier

Anchors MAY be placed in an OP_RETURN output or another non-spendable metadata carrier supported by Avian policy.

A future Avian-specific opcode or metadata convention MAY be introduced, such as:

OP_AVN_AI_ATTEST

However, this AIP does not require a new opcode.

4. On-chain Size

Anchors SHOULD be compact.

Large reports, prompts, model outputs, image analysis, or detailed evidence MUST NOT be stored directly on-chain.

Recommended on-chain data:

attestation ID
report hash
report CID or CID hash
model ID or model hash
target reference
attestor identity
signature or signature reference

5. Indexer Handling

Explorers and indexers SHOULD detect AI attestation anchors and associate them with the referenced target.

For example:

asset -> AI reports
cid -> AI reports
transaction -> AI reports
psbt -> AI reports
address -> AI reports
block -> AI reports

6. Consensus

This AIP introduces no consensus changes.

A transaction containing an AI attestation anchor is valid only if it satisfies normal Avian transaction rules.

Nodes are not required to validate the semantic correctness of the AI report.

Rationale

Anchoring creates a permanent, timestamped proof that an AI attestation existed.

Keeping large reports off-chain avoids unnecessary chain bloat while still allowing strong integrity checks.

Backwards Compatibility

This AIP is backwards compatible.

Non-upgraded nodes see AI anchoring transactions as normal transactions containing metadata.

Security Considerations

Anchoring a report does not make the report true.

Applications MUST distinguish between:

anchored
verified signature
model recognized
attestor trusted
result accepted

These are separate states.

A malicious actor may anchor false reports. Consumers SHOULD verify signatures, attestor reputation, model registry status, and agreement from multiple attestations.

Future Work

Future AIPs may define:

  • A compact binary format
  • Native wallet support
  • Explorer indexing rules
  • Model registry anchoring
  • Revocation anchors
  • Challenge anchors
  • Post-quantum attestation signatures