FINCHIP

Open Protocols for the AI Economy

Exploring EVM standards for AI Autonomous Governance.

FEATURED PROTOCOL

Skills, agents, and tasks on-chain. Trust, decisions, registries, swarms, and economic units.

ERC-8338Skill
Draft proposal

Token-Bound Executable Skills

Bind an executable skill package to a token with verifiable content, version history, and publication controls.

ERC-8338
Draft proposal

Token-Bound Executable Skills

Bind an executable skill package to a token with verifiable content, version history, and publication controls.

Skill PackageFiles + Metadata
Content BindingHashes + Version
Integrity CheckVersion + Hash
Core Problem

A mutable download URL cannot prove which executable files a skill token represents.

Technical Mechanism

The proposal anchors the primary document hash, package hash, and version on an ERC-721 token. A runtime can retrieve a package through a replaceable URI and check its bytes against those commitments. Publication authority is separate from token ownership; optional confidentiality remains a package property.

  1. 01
    Create Skill

    Create and structure the executable skill content.

  2. 02
    Bind Token

    Record the skill document hash, package hash, and version on the token.

  3. 03
    Validate Skill

    Verify the skill and confirm content integrity.

  4. 04
    Publish Update

    Publish an update and create a new version record.

Public draft specification in the discussion thread; not a Final standard.

Status source Checked
View Specification
ERC-8414Task
Draft proposal

Token-Bound Task Tenders

Represent task requirements, reserved rewards, submission, and acceptance through a token-bound tender.

ERC-8414
Draft proposal

Token-Bound Task Tenders

Represent task requirements, reserved rewards, submission, and acceptance through a token-bound tender.

Task VaultTask NFT + Reward Escrow
SubmissionWork Result
SettlementAcceptance + Payment
Core Problem

Task requirements, reserved rewards, and acceptance rules are fragmented across application-specific systems.

Technical Mechanism

Each tender is an ERC-721 token with a dedicated reward vault. Versioned package commitments identify the requested work. Ownership, publication, and acceptance authority are separate. Pending deliveries reserve rewards, and bounded judgment rules define settlement and refund behavior.

  1. 01
    Task as an Asset

    Each task is represented as an ERC-721 token.

  2. 02
    Reward Locked On-Chain

    Reward funds are locked in the Task Vault in advance.

  3. 03
    Programmable Acceptance

    Support human, Agent, and Verifier-based acceptance.

  4. 04
    Trust-Minimized Settlement

    Submission, acceptance, and payment execute on-chain.

Public draft specification in the discussion thread; not a Final standard.

Status source Checked
View Specification
ERC-8419KYA
Draft proposal

Know-Your-Agent (KYA) Framework

A verifiable trust framework for AI Agents across protocols and marketplaces.

ERC-8419
Draft proposal

Know-Your-Agent (KYA) Framework

A verifiable trust framework for AI Agents across protocols and marketplaces.

Agent SubjectAddress / Agent ID
Trust AssertionIssuer + Level
Policy CheckAccess Decision
Core Problem

Agent identity alone does not provide portable trust conclusions with known issuers, validity, and revocation.

Technical Mechanism

Scheme and assertion registries describe how an agent was checked and by whom. Relying parties choose trusted issuers and evaluate their own policies. Optional proof-based profiles can verify conditions without disclosing the underlying facts; they do not make the subject anonymous.

  1. 01
    Verifiable Agent Trust

    Standardize trust assertions for AI Agents across security, compliance, reputation, and other domains.

  2. 02
    Flexible Trust Schemes

    Different issuers can define independent verification schemes, levels, evidence, and expiration rules.

  3. 03
    Policy-Based Access

    Protocols and marketplaces can allow or restrict Agents based on trusted issuers and minimum KYA levels.

  4. 04
    Privacy-Preserving Verification

    ZK-KYA enables Agents to prove they meet required conditions without revealing sensitive underlying data.

The author identifies the proposal as Draft in the public discussion; not a Final standard.

Status source Checked
View Specification
ERC-8434Agent
Draft proposal

Agent Identity (AID)

ERC-8434 anchors Agent identity to a blockchain address, connecting registration, liveness, and verifiable profile information.

ERC-8434
Draft proposal

Agent Identity (AID)

ERC-8434 anchors Agent identity to a blockchain address, connecting registration, liveness, and verifiable profile information.

Address AnchorBlockchain Address
Agent BindingERC-8004
AID ProfileIdentity + History
Core Problem

Agent registration alone does not establish liveness or connect an address to a verifiable, time-bounded profile.

Technical Mechanism

An address anchors the identity. Binding and liveness records determine dormant, active, stale, or retired states. Profile facets carry provenance, validity, and integrity information, while existing registries supply identity and trust records.

  1. 01
    Address-Anchored Identity

    Use a blockchain address as the anchor for Agent identity.

  2. 02
    Live Agent State

    Resolve dormant, active, stale, or retired states from binding and liveness records.

  3. 03
    Verifiable Profile

    Resolve profile facets with provenance, validity, and integrity information.

  4. 04
    Composable History

    Bring together skill, task, and trust records through a common identity.

Assigned ERC number with a public draft and proposal PR; not a Final standard.

Status source Checked
View Specification
ERC-8436Decision
Draft

Agent Collective Decision Framework

ERC-8436 lets agents, humans, and contracts form collective decisions under explicit authorization and verifiable rules.

ERC-8436
Draft

Agent Collective Decision Framework

ERC-8436 lets agents, humans, and contracts form collective decisions under explicit authorization and verifiable rules.

Decision PolicyRules + Authorization
Collective VoteK-of-N + Composition
Final RecordDecided / NoDecision
Core Problem

A single reviewer or multisignature does not capture composable decision procedures, appeals, or a no-decision outcome.

Technical Mechanism

Versioned policies define authorized participants, composition rules, timing, and finality. Issue records bind a question to a policy. The registries record decisions; relying contracts enforce their own committed effects and retain control over assets.

  1. 01
    Frozen Decision Policies

    Bind each issue to an immutable policy version with defined thresholds, timing, and authorization.

  2. 02
    Composable Voting Bodies

    Combine fixed-roster votes or authorized reports with ALL, ANY, K-of-M, or VETO rules.

  3. 03
    Finality & Appeals

    Track provisional and final results, including NoDecision, under policy-defined appeal rules.

  4. 04
    Consumer-Controlled Effects

    Relying contracts execute committed effects. The decision registry never moves assets.

Draft on the official Ethereum EIP/ERC site; not a Final standard.

Status source Checked
View Specification
ERC-8444Registry
Draft

Agentic Resource Discovery (ARD) Onchain

Agentic Resource Discovery (ARD) Onchain makes skills, tasks, agents, and registries discoverable through verifiable records.

ERC-8444
Draft

Agentic Resource Discovery (ARD) Onchain

Agentic Resource Discovery (ARD) Onchain makes skills, tasks, agents, and registries discoverable through verifiable records.

Resource AnchorToken / Address
DescriptorMetadata + Hash
Registry LookupSearch + Resolve
Core Problem

Resource discovery needs verifiable links to on-chain authority, descriptors, and current resource state.

Technical Mechanism

CAIP-based anchors identify skills, tasks, agents, and registries. Descriptor hashes provide integrity checks, while adapters resolve live state. Domain bindings add endorsements. After a controller change, the new controller must adopt the descriptor before it is returned to discovery.

  1. 01
    Address-Based Authority

    Address-derived controllers authorize records. Verified domain bindings add endorsements, not ownership.

  2. 02
    Stable Resource Anchors

    Identify resources with CAIP-19 or CAIP-10 anchors. URNs serve as aliases, not identity.

  3. 03
    Verifiable Descriptors

    Commit descriptor content with JCS and SHA-256 so gateways can check metadata integrity.

  4. 04
    Live Value Resolution

    Read prices, escrow, credit, and identity state from anchored contracts through kind adapters.

Draft on the official Ethereum EIP/ERC site; not a Final standard.

Status source Checked
View Specification
ERC-8447Swarm
Draft proposal

Swarm AI Framework

ERC-8447 defines purpose-bound agent collectives with explicit membership, shared objectives, and a declared collaboration structure.

ERC-8447
Draft proposal

Swarm AI Framework

ERC-8447 defines purpose-bound agent collectives with explicit membership, shared objectives, and a declared collaboration structure.

Swarm CharterPurpose + Commitment
Member AdmissionAdmit & Accept
Swarm LifecycleForm → Run → Dissolve
Core Problem

Agent groups need an interoperable record of membership, objectives, commitments, and lifecycle boundaries.

Technical Mechanism

A swarm combines a frozen executable specification with a versioned charter. Admission and acceptance establish membership. Phase rules describe collaboration, while declared fallback timers preserve an exit path. Decisions and external task obligations are integrated through adapters.

  1. 01
    Committed Spec & Charter

    Freeze executable rules at formation and link a versioned charter with objective and commitment hashes.

  2. 02
    Two-Sided Membership

    Admission requires authority approval and member acceptance. Eligibility checks and voluntary exits bound membership.

  3. 03
    Phase-Based Collaboration

    Define membership boundaries, admission rules, and collaboration structure for each phase.

  4. 04
    Objectives & Exit Rules

    Record attainment and outcomes separately from settlement. Declared fallback timers preserve an exit path.

Assigned ERC number; editor review pending according to the public thread update. Not a Final standard.

Status source Checked
View Specification
ERC-8454AIFi
Draft proposal

AIFi Unit Framework

ERC-8454 defines versioned economic units with explicit resource boundaries, economic roles, and verifiable observation and valuation records.

ERC-8454
Draft proposal

AIFi Unit Framework

ERC-8454 defines versioned economic units with explicit resource boundaries, economic roles, and verifiable observation and valuation records.

Unit BoundaryResources + Rights
Economic RolesRoles + Conditions
Valuation ReceiptMethod + Result
Core Problem

Economic observations require explicit resource boundaries, versions, perspectives, and valuation methods.

Technical Mechanism

Versioned units describe resources, rights, obligations, and economic roles. Observation records reconcile flows within a declared boundary. Valuation receipts identify the unit version, method, perspective, and snapshot used; they are not a promise of investment value.

  1. 01
    Versioned Unit Boundaries

    Define resources, rights, obligations, and interfaces. Nested units reference fixed versions.

  2. 02
    Composable Economic Roles

    Assign conditional roles to units, ports, or elements. Describe behavior and structure separately.

  3. 03
    Reconciled Observations

    Reconcile records per asset. Missing data is not zero, and internal transfers are not economic flows.

  4. 04
    Verifiable Valuation Receipts

    State the assessed version, perspective, method, snapshot, and result. Evaluators choose their own methods.

Draft proposal in ethereum/ERCs PR #2095; editor review pending. Not a Final standard.

Status source Checked
View Specification
ERC-8468Safety
Draft proposal

Agent Safety Framework (ASF)

ERC-8468 links versioned safety requirements to scoped agent commitments and makes their current status checkable at execution.

ERC-8468
Draft proposal

Agent Safety Framework (ASF)

ERC-8468 links versioned safety requirements to scoped agent commitments and makes their current status checkable at execution.

Safety SpecificationVersion + Requirements
Safety BindingSubject + Scope
Status CheckVerdict + Response
Core Problem

Safety commitments need a verifiable link between a specific requirement version, agent, scope, enforcement point, and current intervention state.

Technical Mechanism

A versioned Safety Specification declares requirements, evidence, enforcement locations, and responses. A Safety Binding records adoption for a subject and scope. Consumers check its current result at the point of effect, including suspensions and standing stops.

  1. 01
    Versioned Specifications

    Pin safety constraints, evidence, enforcement locations, and response rules to an immutable version.

  2. 02
    Scoped Adoption

    An adopter accepts one version for a subject and scope, with a validity window and named interveners.

  3. 03
    Point-of-Effect Check

    Consumers read Satisfied, NotSatisfied, or Unknown, with reasons and active response requirements.

  4. 04
    Intervention Rights

    An authorized intervener can suspend a binding. Its standing stop remains until the intervener or its named lifter releases it.

Number assigned and proposal PR open; the public discussion describes a draft, not a Final standard.

Status source Checked
View Specification
ERC-8471Dispute
Draft proposal

AI Dispute Resolution Framework (ADRF)

ERC-8471 provides a framework for resolving specific claims about AI systems, resources, and services under pre-committed rules.

ERC-8471
Draft proposal

AI Dispute Resolution Framework (ADRF)

ERC-8471 provides a framework for resolving specific claims about AI systems, resources, and services under pre-committed rules.

Dispute PolicyRules + Methods
Case & EvidenceClaim + Findings
RulingResult + Authority
Core Problem

A contested AI service, resource, or action needs a specific claim, prior obligation, bound resolution method, and authorized outcome.

Technical Mechanism

A Dispute Policy binds question types to formal, evidence-based, or judgment methods. The obligation source binds that policy and authorizes effects. A case records claims, findings, and a ruling; named executors carry out permitted effects.

  1. 01
    Defined Claims

    File a specific claim about an identified object and an obligation declared before the event.

  2. 02
    Bound Authority

    A source binds a policy and specifies which effects and executors it authorizes.

  3. 03
    Flexible Methods

    Resolve questions through formal verification, evidence rules, or judgment methods.

  4. 04
    Recorded Outcomes

    Record the ruling and its provenance. Authorized executors enact and report effects.

The public discussion identifies this as a Draft proposal in ethereum/ERCs PR #2123; not a Final standard.

Status source Checked
View Specification
ERC-8489Communication
Draft proposal

Agent Information Flow Paradigm (AIFP)

ERC-8489 defines verifiable rules for how agents observe, contribute to, and redistribute information in a channel, independently of its transport.

ERC-8489
Draft proposal

Agent Information Flow Paradigm (AIFP)

ERC-8489 defines verifiable rules for how agents observe, contribute to, and redistribute information in a channel, independently of its transport.

Flow ParadigmRules + Version
Channel AdoptionContext + Effective Time
Role BindingScope + Validity
Core Problem

Agents need a way to verify who can read, contribute, or redistribute information across different communication systems.

Technical Mechanism

A content-addressed paradigm defines how information flows and which rules apply. A channel adopts one paradigm version at a given time. Role bindings record the scope, basis, and validity of participation under that version.

  1. 01
    Versioned Flow Rules

    Declare discovery, observation, contribution, and redistribution rules in a versioned descriptor.

  2. 02
    Channel Adoption History

    Record when each paradigm version takes effect so past actions can be evaluated under the applicable rules.

  3. 03
    Scoped Participation

    Bind a participant to a role with a scope, basis, validity interval, and governing rule version.

  4. 04
    Four Verification Outcomes

    Distinguish satisfied, not satisfied, undeterminable, and verifier error when checking admission rules.

The public draft is under review in ethereum/ERCs PR #2152.

Status source Checked
View Specification
ERC-8490Meditation
Draft proposal

Agent Meditation Mechanism

ERC-8490 proposes a registry where agents record their own maintenance as a versioned history, with state commitments and completion times for each layer.

ERC-8490
Draft proposal

Agent Meditation Mechanism

ERC-8490 proposes a registry where agents record their own maintenance as a versioned history, with state commitments and completion times for each layer.

Maintenance PolicyVersion + Minimum Rules
State CommitmentsFour Agent Layers
Completion CheckpointLayer + Completion Time
Core Problem

An agent’s maintenance history is hard to verify when state changes and completion times are scattered across systems.

Technical Mechanism

The registry records versioned maintenance policies, an optional controller-defined minimum, and state commitments for four layers. Per-layer completion checkpoints allow consumers to check maintenance status against the applicable policy.

  1. 01
    Four Maintenance Layers

    Track runtime, memory and skills, tasks and roles, and cognition as four distinct layers.

  2. 02
    Versioned Policies

    Record the agent’s maintenance policy and any minimum requirements set by its controller.

  3. 03
    Committed State History

    Commit each layer’s state and keep a root for every registered state version.

  4. 04
    Verifiable Completion

    Record per-layer completion times so consumers can determine maintenance status.

The public draft is under review in ethereum/ERCs PR #2155.

Status source Checked
View Specification
Open proposals. Evolving through public review.

Building with Open Standards

FINCHIP explores open technical standards for the emerging AI Agent economy, focusing on interoperability, verifiability, and decentralized coordination.

Open Standards

Open technical specifications.
Built for anyone to build on.

Interoperability

Shared interfaces across
platforms and protocols.

Verifiability

Verifiable identity, behavior,
and results.

Decentralization

Open infrastructure for
decentralized coordination.