Skip to content

aip-0013.md

Latest commit

 

History

History
227 lines (166 loc) · 5.28 KB

aip-0013.md

File metadata and controls

227 lines (166 loc) · 5.28 KB
Raw

AIP-0013: Decentralized AI Worker Attestations

AIP:     0013
Title:   Decentralized AI Worker Attestations
Author:  Avian Network Developers
Status:  Draft
Type:    Standards Track
Category: Application / Worker Network
Created: 2026-06-07
Requires: AIP-0010, AIP-0011, AIP-0012

Abstract

This AIP defines a decentralized AI worker attestation model for Avian.

AI workers are independent services that run approved or declared AI models against Avian-related targets and publish signed attestations. Multiple workers may attest to the same target, allowing wallets, explorers, marketplaces, and indexers to compare agreement, disagreement, confidence, and worker reputation.

This AIP does not introduce AI into consensus and does not require full nodes to execute AI models.

Motivation

A single centralized AI service would make Avian AI attestations less trustworthy.

A decentralized worker model allows multiple independent parties to review the same target and produce signed reports. This enables stronger trust signals, reduces reliance on a single operator, and creates a foundation for future staking, reputation, challenge, and reward systems.

Specification

1. Worker Identity

Each AI worker SHOULD have a persistent identity.

A worker identity MAY be represented by:

Avian address
public key
DID-style identifier
service endpoint
operator metadata

A worker identity object SHOULD use the following structure:

{
  "schema": "avian.ai.worker.v1",
  "worker_id": "worker-public-id",
  "operator": "optional-operator-name",
  "address": "AVN_ADDRESS",
  "pubkey": "hex-encoded-public-key",
  "capabilities": [
    "asset_metadata_review",
    "cid_health_review",
    "psbt_intent_review"
  ],
  "models": [
    "avian-asset-validator-v1"
  ],
  "endpoint": "optional-service-endpoint",
  "status": "active",
  "created_at": "2026-06-07T00:00:00Z",
  "signature": {
    "algorithm": "secp256k1",
    "signature": "hex-encoded-signature"
  }
}

2. Worker Status

Worker status SHOULD be one of:

active
inactive
deprecated
revoked
testing
unknown

Applications SHOULD treat testing or unknown workers as lower trust unless explicitly configured otherwise.

3. Multi-worker Agreement

For a target to be considered strongly attested, applications SHOULD require attestations from multiple independent workers.

Example policy:

minimum workers: 3
minimum agreement: 2 of 3
maximum report age: 30 days
recognized model required: yes

This policy is application-level and not a consensus rule.

4. Attestation Sets

When multiple workers attest to the same target, an indexer MAY produce an attestation set summary.

{
  "schema": "avian.ai.attestation_set.v1",
  "target": {
    "type": "asset",
    "identifier": "ASSET_NAME"
  },
  "attestations": [
    "attestation-id-1",
    "attestation-id-2",
    "attestation-id-3"
  ],
  "summary": {
    "status": "valid",
    "agreement": "2/3",
    "confidence_average": 0.91,
    "labels": ["metadata-valid", "cid-available"]
  }
}

5. Challenges and Disputes

A worker attestation MAY be challenged if it is stale, malformed, fraudulent, or contradicted by evidence.

A challenge object SHOULD include:

{
  "schema": "avian.ai.challenge.v1",
  "challenge_id": "challenge-id",
  "attestation_id": "attestation-being-challenged",
  "reason": "cid-unavailable",
  "evidence_hash": "sha256-evidence",
  "evidence_cid": "optional-ipfs-cid",
  "challenger": "AVN_ADDRESS_OR_ID",
  "created_at": "2026-06-07T00:00:00Z",
  "signature": {
    "algorithm": "secp256k1",
    "signature": "hex-encoded-signature"
  }
}

Challenge resolution is application-level in version 1.

6. Reputation

Applications MAY maintain worker reputation based on:

  • Historical agreement with other workers
  • Successful challenges
  • Failed challenges
  • Report freshness
  • Model quality
  • Uptime
  • Operator identity
  • Stake, if future staking is introduced

Reputation is not defined as a consensus rule in this AIP.

7. Rewards

This AIP does not define native block rewards for AI workers.

Future AIPs MAY define payment mechanisms, marketplace fees, bounties, staking, slashing, or protocol-level reward distribution.

8. Consensus

This AIP introduces no consensus changes.

Avian nodes are not required to run AI workers, validate AI outputs, or enforce worker reputation.

Rationale

Decentralized AI attestations are more credible than a single centralized service.

However, adding worker selection, staking, slashing, and reward distribution directly into consensus would be premature. This AIP defines the identity and attestation foundation first.

Backwards Compatibility

This AIP is fully backwards compatible.

Security Considerations

A decentralized worker network may be attacked through:

  • Sybil workers
  • Colluding workers
  • Malicious model outputs
  • False challenges
  • Stale attestations
  • Compromised worker keys
  • Centralized model dependencies

Applications SHOULD display worker count, agreement level, model ID, report age, and worker reputation where possible.

Future Work

Future AIPs may define:

  • Worker staking
  • Slashing
  • Reward pools
  • Worker registration anchoring
  • Minimum quorum policies
  • Challenge arbitration
  • ZKML proofs
  • Deterministic inference requirements