Skip to main content
Tulip v1 is an early production implementation of open model-credit markets and permissionless inference. It proves the complete path from pinned model identity to credit launch, provider competition, metered usage, and on-chain settlement.
Tulip is an early version 1 implementation. V1 uses Hugging Face as its first model registry and inference endpoint vendor, but the protocol is intended to support additional model sources, GPU networks, and inference vendors in later versions. Version 1 is the beginning of the protocol, not its final integration boundary.
Subsystem API and schema version numbers track interface compatibility. They do not indicate a second Tulip product generation.

What version 1 supports

Version 1 uses Hugging Face for two specific roles:
  • Model registry. A model is identified by a Hugging Face repository, immutable commit revision, and task.
  • Inference endpoint vendor. Providers connect verified Hugging Face Inference Endpoints to the Tulip Gateway.
Hugging Face is the first supported vendor. It is not intended to remain the only model registry, compute platform, GPU provider, or endpoint vendor Tulip can support.

Demand before supply

Bootstrapping a model endpoint can be slow, expensive, and operationally demanding. Tulip v1 does not require that compute supply to exist before a model-credit market launches and begins trading. Trading gives users a way to signal demand before anyone commits capital to hosting the model. If a market gains traction, independent providers can evaluate that demand, deploy the model, publish a competitive inference price, and begin earning its credits.
Demand can arrive before supply. The market discovers which models people want. Providers decide which demand is worth serving.

Vendor-neutral direction

Tulip separates the on-chain market from the off-chain service that runs inference. Model credits, liquidity, permits, tariffs, and settlement live at the protocol layer. Endpoint inspection, routing, and metering live behind the Gateway. That separation gives future versions room to add other model registries, inference vendors, GPU networks, and execution environments without turning provider access into a permissioned marketplace. Any expansion must preserve verifiable model identity, explicit provider commitments, comparable tariffs, bounded user spending, and exact settlement. Existing v1 markets remain defined by their registered Hugging Face identity. A later version should add new identity namespaces or adapters rather than silently reinterpret an existing ModelID.

Why Tulip did not launch a Tulip token

The Tulip launchpad is specifically for launching model credits. Each credit must correspond to a real, pinned AI model and serves as that model market’s trading and inference-settlement asset. Tulip does not create AI models and does not have a model that represents the protocol. Launching a token named Tulip through the launchpad would therefore break the launchpad’s core rule: one model identity, one model credit, and one canonical market. Tulip is not a general-purpose token launcher or a meme-coin factory. A protocol-branded token without a corresponding model would not be a model credit, so Tulip did not create one.

Understand model credits

Learn what model credits represent and how providers use them for inference settlement.