Skip to main content
In version 1, Tulip identifies a model by its Hugging Face repository, immutable commit revision, and task. Human-readable names are metadata; the ModelID is the canonical key used by contracts and services.
The huggingface identity namespace is Tulip’s first integration, not a permanent vendor restriction. Future versions may add other registries through new namespaces without changing existing v1 ModelIDs.

​
ModelID derivation

The registry computes:
uint16(2) is the identity schema version used by the v1 implementation. It is not the Tulip product version.
The revision must be a 40-character hexadecimal Git commit SHA. Branch names and moving tags are rejected.

​
Why revisions are pinned

A Hugging Face repository can change over time. Pinning a commit ensures that:
  • Providers know which weights and repository artifacts to deploy.
  • Users can inspect the exact public model card and files.
  • A later repository update cannot silently change an existing market.
  • A materially different revision receives a different ModelID, credit, and pool.

​
Canonical market binding

The registry allows one market binding per ModelID. A creator-bound commitment protects the launch parameters from mempool copying. In a later block, the reveal creates the model, credit, pool, and locked position atomically. If the model already exists, launch reverts. The on-chain model record stores the repository, revision, task, creator, credit token, pool ID, locked position ID, curve preset, metadata commitment, fee share, and listing status.
Tulip pins repository identity. It does not place model weights on-chain and does not claim ownership of the upstream model.