Skip to content

IFP-100.md

Latest commit

 

History

History
executable file
·
412 lines (247 loc) · 6.21 KB

IFP-100.md

File metadata and controls

executable file
·
412 lines (247 loc) · 6.21 KB
Raw

IFP-100

Intelligence Asset Model Specification

Status: Draft v1.0
Category: Intelligence Fabric Protocol

1. Purpose

This specification defines how intelligence assets (e.g., LLMs, multimodal systems, specialized AI models) are represented within the Intelligence Fabric Protocol (IFP).

It establishes:

  • Model identification
  • Version control
  • Shard commitments
  • Ownership semantics
  • Activation rules
  • Lifecycle transitions

This document governs how models become protocol-native assets.

2. Intelligence Asset Definition

An Intelligence Asset (IA) is a protocol-registered compute artifact capable of producing inference outputs.

An IA consists of:

  • Metadata (on-chain)
  • Commitment roots (on-chain)
  • Weight shards (off-chain)
  • Execution engines (off-chain)
  • Economic configuration (on-chain)

The protocol governs metadata and economics — not the internal model architecture.

3. Model ID

3.1 Definition

Each model is identified by:

model_id ∈ Hash32

Where:

model_id = SHA256(owner_address || initial_version || shard_root)

This ensures:

  • Uniqueness
  • Collision resistance
  • Ownership binding

3.2 Immutability

model_id is immutable once registered.

New versions must not reuse previous model_id.

4. Versioning

4.1 Version Structure

Each model has:

version ∈ u32

Version increments monotonically.

4.2 Version Registration

New version requires:

  • Owner authorization
  • New shard_root commitment
  • Version increment
  • Optional governance approval (if required)

4.3 Version Compatibility

Protocol does not enforce semantic compatibility between versions.

Compatibility may be declared in metadata but is not consensus-critical.

5. Commitment Hashes

5.1 Shard Root Commitment

Each model defines:

shard_root ∈ Hash32

Where:

shard_root = MerkleRoot(shard_commitments)

Each shard_commitment:

shard_hash = SHA256(shard_data)

5.2 Purpose

Commitment hashes:

  • Prevent weight tampering
  • Bind operator execution to known artifact
  • Enable shard verification
  • Allow fraud proofs (future extension)

5.3 Integrity Requirement

Operators claiming to run a model MUST reference:

(model_id, version, shard_root)

Receipt may include optional shard reference.

6. Shard Indexing

6.1 Shard Definition

Model weights may be divided into:

N shards

Indexed:

shard_index ∈ [0, N-1]

6.2 Shard Metadata

On-chain metadata includes:

  • shard_count: u32
  • shard_root: Hash32

Actual shard contents are off-chain.

6.3 Shard Availability

Shard storage is not consensus-enforced but may be economically incentivized.

Optional future extension:

Availability proofs.

7. Owner Rights

7.1 Ownership

Each model has:

owner ∈ Address

Stored in ModelStorageLedger.

7.2 Owner Capabilities

Owner may:

  • Update version
  • Modify pricing policy
  • Modify revenue splits
  • Enable/disable vault participation
  • Activate/deactivate model
  • Transfer ownership

7.3 Ownership Transfer

Ownership transfer requires:

  • Signed transaction by current owner
  • Immediate state update
  • No re-registration of model_id

8. Activation Lifecycle

8.1 Model States

Each model has:

state ∈ { Registered, Active, Paused, Deprecated, Disabled }

8.2 State Transitions

Registered → Active
Active → Paused
Paused → Active
Active → Deprecated
Any → Disabled (if governance intervention)

8.3 State Semantics

Registered
Model exists but cannot receive prompts.

Active
Model accepts SubmitPrompt transactions.

Paused
Temporarily not accepting prompts.

Deprecated
Still usable but marked as legacy.

Disabled
Cannot receive prompts; economic routing halted.

9. Economic Configuration Binding

Each model binds:

  • pricing_policy
  • revenue_split_basis_points
  • vault_enabled flag

These parameters affect:

  • Fee computation
  • Revenue routing
  • Staking behavior

10. Model Registration Rules

Registration requires:

  • Unique model_id
  • Valid shard_root
  • Valid revenue splits (sum = 10000 basis points)
  • Owner signature

Model registration must be deterministic.

11. Minimal Model Requirements

To be considered valid:

  • shard_root must exist
  • shard_count > 0
  • version ≥ 1
  • owner != null address

12. Governance Intervention

Governance may:

  • Disable malicious models
  • Freeze revenue routing
  • Adjust economic parameters
  • Require compliance audits

Governance may NOT:

  • Modify shard_root retroactively
  • Alter finalized historical receipts

13. Model Integrity Assumptions

Protocol guarantees:

  • Commitment integrity
  • Ownership control
  • Economic routing

Protocol does NOT guarantee:

  • Model correctness
  • Model fairness
  • Model safety
  • Inference accuracy

These remain off-chain properties.

14. Interaction with SubmitPrompt

SubmitPrompt references:

(model_id, version)

Validation requires:

  • Model state == Active
  • Version exists
  • Not Disabled

Otherwise transaction fails.

15. Formal Representation

Let:

M = { model_id, owner, version, shard_root, shard_count, state, pricing_policy, revenue_split }

Model registration:

RegisterModel(S, M) → S'

State transition must preserve determinism.

16. Upgrade Path

Future extensions may include:

  • ZK model attestation
  • Proof-of-weight execution
  • Verifiable model execution claims

Such extensions must preserve:

  • Determinism
  • Commitment immutability
  • Ownership semantics

17. Conclusion

IFP-100 defines intelligence assets as:

  • Cryptographically committed
  • Owner-controlled
  • Versioned
  • Economically programmable
  • Lifecycle-governed

It transforms AI models into protocol-native economic objects.

This specification forms the foundation of decentralized intelligence markets.

End of IFP-100.