Integration
Hugging Face
Models, datasets, and Spaces on Hugging Face are now first-class GITSEA economic objects. A model fine-tuned from another model can stream royalties back to the base, continuously, on Base. Same primitives we expose for code repos, applied to weights.
What composes today
Every artifact on huggingface.co has a deterministic on-chain GITSEA treasury keyed by the keccak256 of its canonical hf:// URI. The contracts treat it identically to a GitHub or gitlawb repo: a bytes32 repo id, an owner wallet, a splits root, a vault balance, and full access to the rest of the protocol surface.
- Treasury per model. Anyone (a fan, a downstream user, an enterprise) can deposit
$GSEAinto a model's treasury at any time. The model creator (whoever signed the link transaction) is the only address that can withdraw. - Per-derivative royalty streams. A model fine-tuned from another model can
setStreama per-second$GSEAflow back to the base. Streams accrue continuously and settle on demand or in batches. This generalizes our code royalty-stream primitive to ML lineage. The same applies to datasets that train into models: train-time royalty bonds. - Splits across contributors. The asset.toml convention works the same way: define contributor weights in basis points, and merge / release payouts distribute atomically through
SplitsEngine. - Credit lines backed by a model. Open a credit line collateralized by the projected royalty stream of a model. Underwriters get paid in
$GSEAinterest; the borrower draws against future inference demand. - Parametric insurance. Underwrite or buy a policy against a model regression event (e.g., a fine-tune that benchmarks below the base it forked from).
Identifier scheme
The canonical form is:
hf://(models|datasets|spaces)/<org>/<name>
| Surface | Example |
|---|---|
| Model | hf://models/meta-llama/Llama-3.1-8B |
| Dataset | hf://datasets/HuggingFaceFW/fineweb |
| Space | hf://spaces/stabilityai/stable-diffusion |
The connect wizard at /app/connect also accepts the bare web URL (https://huggingface.co/meta-llama/Llama-3.1-8B) and normalizes it to the hf:// form before hashing. The on-chain repo id is keccak256(URI) and is fully deterministic, so two clients hashing the same URI will always land on the same treasury.
Linking a Hugging Face asset
- Visit
/app/connect. - Connect a wallet on Base. Skip the GitHub OAuth step (Hugging Face flows don't need it).
- On the "Pick a repository" step, pick the Hugging Face tab.
- Paste either a full huggingface.co URL or an
hf://URI. The wizard will resolve and validate it. - Drop the
asset.tomlin your model's repo (or any place you can reference at link time) and link on Base.
The treasury exists from that point on. Anyone can deposit. You can immediately set royalty streams to upstream artifacts.
Per-derivative royalty streams (the high-leverage flow)
This is the use case that doesn't exist anywhere else on the internet today.
You have a fine-tune of meta-llama/Llama-3.1-8B. Your fine-tune is generating revenue (deposits to its treasury from users, enterprise integrations, whatever the flywheel is). Set a per-second royalty stream from your fine-tune's treasury back to the base:
# Via the MCP server, in an agent prompt:
"Set a royalty stream of 0.001 GSEA per second from
hf://models/myorg/llama3-finetune-medical
to hf://models/meta-llama/Llama-3.1-8B"
The stream accrues continuously. The base model's creator receives $GSEA automatically, settled either on-demand or via the GITSEA keeper. Every fine-tune that does this turns into a perpetual revenue surface for the upstream. Stack across the model graph (base → fine-tune → quantization → distilled → ...) and the protocol becomes the substrate for an actual model-lineage royalty economy.
You can also pay forward to datasets:
"Stream 5% of my model's monthly inflow back to
hf://datasets/HuggingFaceFW/fineweb"
The dataset's treasury earns from every model that explicitly attributes it. No platform sits in the middle taking a cut. Settlement is on Base.
How identifiers map
| Concept | On Hugging Face | On GITSEA |
|---|---|---|
| Model address | https://huggingface.co/org/name | hf://models/org/name |
| Repo id (on chain) | n/a | keccak256("hf://models/org/name") as bytes32 |
| Creator identity | HF profile / org | wallet address (the address that signed linkRepo) |
| Reputation | downloads, likes, model card votes | GITSEA credit score (CreditOracle) |
| Settlement currency | none today | $GSEA on Base |
Working with both MCP servers
GITSEA ships an MCP server (@gitsea/mcp on npm) that exposes the protocol to any AI agent. Combined with Hugging Face's MCP and CLI tooling, an agent can read a model, fork it, fine-tune, link the fine-tune to GITSEA, set up a royalty stream back to the base, and settle the first epoch from one natural-language prompt.
Example agent flow:
"Fork hf://models/meta-llama/Llama-3.1-8B as a fine-tune at
hf://models/me/llama3-domain-medical. Link the fine-tune to GITSEA
under my wallet. Then set a 5% royalty stream from the fine-tune
back to the base. Show me the splits config and the on-chain receipts."
The agent calls gitsea_link_repo with the new fine-tune URI, then gitsea_set_stream with both URIs, and returns the tx hashes.
What this doesn't do (yet)
- No webhook auto-payout on model release. Hugging Face exposes a webhooks API for some events; we haven't wired the receiver yet. For v1, settlement is manual via the dashboard or an agent's MCP call.
- No on-chain attestation of HF account to wallet. Anyone can link any model URI; there's no enforcement that you actually own the HF account behind the org. The economic owner is whoever signed
linkRepo, which is the wallet that can withdraw and set splits. For now this is correct by construction (whoever links it, owns the treasury). A v2 attestation flow would let the actual HF account holder bind their identity to the wallet, enabling display badges and reputation portability. - No automatic dataset-to-model lineage detection. Streams are explicit. We're not crawling the model graph for you yet.
These are the natural next things.
Why this matters
Open-weights ML is in the same place open-source code was twenty years ago: critical infrastructure, used by everything, paid for by basically nothing. The most-downloaded base models on Hugging Face have hundreds of millions of downloads and zero direct revenue surface for their creators. Fine-tunes inherit the value; bases get the credit, the citations, and the lint at best.
GITSEA's economic primitives translate directly. A model is a repo. A fine-tune relationship is a royalty stream. A creator's reputation is a credit score. The substrate doesn't care whether the artifact is Python source or a 70B-parameter checkpoint. The contracts see bytes32. The economics are the same.
Hugging Face is where most of the world's open weights live. This integration makes the protocol literate in that substrate without asking the Hugging Face team to ship anything.
See also
- Hugging Face
- GITSEA MCP server
- Royalty streams
- The gitlawb integration (sibling write-up using the same substrate-agnostic pattern)
