Open-weight models have become strong enough that much of the industry now runs on them. The Stanford AI Index 2025 reported that the gap between open-weight and closed models on some benchmarks fell from 8% to 1.7% in a single year. For the people who build these models, that success brings a problem. Once the weights are released, the builder has almost no visibility into how they are served, by whom, under what terms, or whether the thing called by their model's name is their model at all.
This article covers what model builders should expect from the infrastructure that serves their work, and why those expectations are best met by infrastructure that is itself open.
"Open" covers a range of licenses
Openness in models comes in degrees. The Open Source Initiative's Open Source AI Definition 1.0, released in October 2024, asks for the freedom to use, study, modify and share. It also requires detailed information about training data, the full code used to train and run the system, and the parameters. Many popular "open" models do not meet that definition. They are open-weight, released under custom licenses with conditions.
Those conditions are real obligations. The Llama 3.1 Community License, for example, requires anyone who distributes the materials or a product or service containing them to "prominently display 'Built with Llama'". Licensees whose products had more than 700 million monthly active users on the release date must request a separate license from Meta. Other families add acceptable-use policies, territory limits, revenue thresholds or non-commercial clauses.
A serving platform that treats every model as "open, therefore anything goes" breaks these terms at scale. One that records each license's conditions with the model and enforces them in the serving path respects them at scale.
Provenance: which weights actually ran
The first thing a builder needs is assurance that what is served under their model's name is their model. Substitution is easy and tempting: a heavier quantization, a smaller sibling, a fine-tune with different behavior, or a corrupted download. Users cannot tell from the outside, and the builder takes the blame for poor output.
Three mechanisms close this gap.
Pinned manifests. Every file of a model is listed with its size and cryptographic hashes, fixed to a specific commit at its origin, and combined into a single Merkle root. A node that loads a file whose bytes differ from the manifest refuses to serve it.
Independent corroboration. A manifest is trusted when several independent observers report the same hashes from several independent origins, such as the builder itself, a model hub commit and storage providers. A contradicting observation is kept as a signed, attributable conflict rather than discarded.
Per-response binding. Each response carries a receipt, signed by the serving machine, that names the model hash and engine it ran. Weight substitution then becomes provable from a single response.
Licenses enforced in the serving path
License terms belong in the model's catalog entry, in machine-readable form. Four behaviors follow from that:
- Tiered admission. Permissive models load freely. Models with attribution or custom commercial terms require the operator to accept them explicitly, and non-commercial models require a separate opt-in.
- Paid-serving flags. A model whose license restricts serving for pay is only ever served free of charge.
- Composite licenses. When the weights carry several licenses, such as a text encoder under its own terms beside the main checkpoint, the most restrictive tier applies, and every license must be accepted.
- Conditions travel with the model. Display duties, revenue thresholds, required authorizations and territory limits are returned with the catalog entry, so the apps built on top can meet them.
Gated models without a central gatekeeper
Many strong checkpoints are gated: the builder requires each user to accept the license before downloading. On a centralized hub the hub enforces the gate. On a peer-to-peer network, weights move between machines, and the gate has to move with them.
The rule that works is simple. A node fetches gated weights only after its operator accepts the license. It fetches them only from other nodes whose operators have also accepted it, as recorded in each node's signed endpoint record. And it never passes license-bound bytes to a node that has not accepted. The builder's gate then holds across the whole network, not just at the first download.
Attribution and the EU's GPAI rules
In the EU, the AI Act's obligations for providers of general-purpose AI models have applied since 2 August 2025, and the Commission's enforcement powers, including fines, since 2 August 2026, as the Commission's guidelines page sets out. The guidelines clarify the conditions under which open-source providers are exempt from certain obligations. The voluntary GPAI Code of Practice, published on 10 July 2025, covers transparency and copyright for all GPAI providers, and safety and security for models with systemic risk.
For builders, documentation passed downstream only works if the downstream infrastructure keeps it attached to the weights. A catalog entry that carries the license, the source commit and the builder's own signed attestation of what they released does exactly that.
What this means for open-model builders
Ask the platforms that serve your models four questions. Can a user prove which of your weights produced a response? Are your license conditions recorded and enforced, or only linked to? Does your gate hold after the first download? Can you sign your own attestation of what you released, so that what others observe can be checked against it? Infrastructure that answers yes protects both your reputation and your terms.
Where Tenzro fits
Tenzro is an open network where machines sell AI work using open models. It is live in preview, and governance decides the steps to testnet and mainnet. It does not ship models of its own: every model it serves is a third-party checkpoint. What is built:
- A signed catalog. Entries record the engine family, the license and its tier, whether the weights are gated, and the SHA-256 of every file, fixed to a commit at the origin. They are signed by bonded catalog publishers. Files whose bytes do not match are refused. If two trusted publishers describe the same model differently, neither version is served.
- Provenance manifests. Per-file SHA-256 and BLAKE3 hashes form a BLAKE3 Merkle root. A manifest is verified when at least two observers across at least two origins agree. Origins include the model's creator signing under its own identity.
- License enforcement. License tiers gate registration, conditions are returned with the entry, the most restrictive tier applies to composite licenses, and models whose license restricts paid serving are served only free of charge.
- Gated weights. Operators accept a license explicitly. Gated bytes move only between nodes whose signed records list that acceptance, and they are fetched from other nodes by content hash, never from the origin.
- Receipts. Each response's signed receipt names the cataloged model hash and engine.
Call-chain attribution on settlements names the app, agent and tool behind a payment. A dedicated per-call share for model builders is not part of the current documentation.
