Hugging Face supplies v1’s model identity and endpoint integration. Tulip’s protocol direction is vendor-neutral; later versions may support other registries, compute networks, and inference vendors.
Market composition
| Component | Cardinality | Purpose |
|---|---|---|
ModelID | One | Identifies the repository, commit revision, and task. |
| Model credit | One | Serves as the market asset and inference settlement unit. |
| Credit/USDG pool | One | Provides continuous on-chain price discovery. |
| Locked LP position | One | Holds the launch liquidity permanently. |
| Provider offers | Many | Publish independent endpoint commitments, tariffs, and payout addresses. |
| Inference permits | Many | Bound how much credit each user makes available for inference. |
Market lifecycle
Pin the model
In v1, the launcher selects a Hugging Face repository, a 40-character commit SHA, and a supported task. Tulip derives the
ModelID from those values.Create the credit and pool
The factory deploys the fixed-supply credit, initializes the canonical Uniswap v4 pool, and supplies a one-sided position containing only model credits.
Lock the position
The position NFT is minted directly to the Tulip liquidity locker. Principal cannot be withdrawn or migrated.
Open trading
Buyers exchange real USDG for credits. USDG enters the pool through swaps. Sellers can receive only USDG held by the pool.
Register providers
Any operator serving the exact model may register an offer and privately connect its endpoint to the Gateway.
Markets can launch unserved
Tulip markets do not require an active inference provider at launch. Bootstrapping a model endpoint can be slow, expensive, and operationally demanding. Rather than requiring compute supply to exist first, Tulip allows a model-credit market to begin trading while the model is still unserved. This lets traders signal demand before anyone commits capital to hosting the model. If a market gains traction, independent providers can see that demand, deploy the model, publish a competitive inference price, and begin earning its credits. Until a provider comes online, the credit is tradeable but cannot be used for inference. Once service begins, the same market becomes the payment layer for competing providers.Demand can arrive before supply. The market discovers which models people want. Providers decide which demand is worth serving.
Creator and provider are separate roles
The market creator controls model metadata and may schedule pool LP-fee changes within protocol bounds. Fee changes activate only after the one-hour safety delay. The creator does not control provider admission or provider tariffs. Each provider controls its own:- Endpoint operation and, in v1, a Hugging Face account.
- Tariff history.
- Payout address.
- Offer status, except protocol quarantine.
Canonical does not mean guaranteed
Canonical identity makes duplicate Tulip markets for the same pinned model impossible. It does not prove that every off-chain response was generated correctly. The Gateway verifies endpoint manifests and capabilities, meters reported usage, and binds receipts to an exact offer. Users still rely on the Gateway and provider execution for off-chain inference.Architecture and trust boundaries
Review which guarantees are enforced by contracts, the Gateway, v1’s Hugging Face integration, and the indexer.