Join our community of builders on Discord!

The Model Governance interface is the public control surface for deciding what AI models Lightchain supports and under what operating terms. In the Lightchain whitepaper, governance is part of the protocol's core design: the community shapes the network, model contributions are meant to flow into the AIVM through transparent processes, and economic parameters need to stay visible rather than hidden behind operators or administrators. This page turns that idea into a product workflow. It shows how models are proposed, how live models are compared, and how a single model can be inspected across pricing, usage, uptime, and supply-side support.

Governance entry point

Model Governance hero section
The hero section frames governance as community action. The headline makes the purpose explicit: model parameters are governed through DAO participation, not through a closed internal process. The Propose a New Model call to action is important because it reflects the whitepaper's governance direction. Lightchain is designed so model evolution can come from the community, and governance is the mechanism that decides what gets admitted into the network's AI execution layer.

Propose a new model

Propose a new model modal
The proposal modal shows what a governance submission needs to include:
  • the model name
  • a source or reference link
  • a suggested base fee
  • a written justification with technical detail
That structure is useful because it forces model onboarding to be both technical and economic. A model is not admitted only because it exists; it needs an understandable identity, a reason to belong on the network, and a pricing assumption the community can evaluate. From a whitepaper perspective, this is governance translated into a product action. It gives the community a repeatable path for extending the AIVM-facing model set without making the process opaque.
Governance guard-rails. Proposals for models that exceed the protocol's compute/memory bounds, or that do not correspond to a real, verifiable model artifact, will be rejected. The proposal process is intended to admit models that the network can actually serve, and reviewers should weigh each submission against those limits before voting.

Model directory

Model Governance model directory
The model directory is the searchable catalog of what the network currently exposes. Each row surfaces four decisions that governance has made visible:
  • Model name identifies the asset being governed.
  • Technical parameters describe the model's capability and operating profile.
  • Base fee shows the economic cost of routing demand to that model.
  • Status shows whether the model is currently active, paused, or failed.
This matters because model governance is not only about approval. It is also about comparability. The whitepaper emphasizes transparency and AI-native infrastructure, and this table is the simplest version of that promise: users can see what models exist, what they cost, and whether they are operational.

Filters

Model Governance filter controls
The filter controls make governance data easier to compare by capability and cost. In the screenshot, filters focus on context length and prompt pricing, which are two of the clearest model-level tradeoffs:
  • context length affects how much information a model can work with in one request
  • pricing affects how accessible that model is for real usage
This fits the whitepaper's AI-native and economically adaptive framing. Governance is not only deciding whether a model exists. It is also shaping which models are practical, competitive, and aligned with user demand.

Model details

Model summary

Model summary section
The top of the details page answers the most important questions first:
  • is the model active right now
  • what is the base fee
  • what is the context window
  • what are the model's core technical parameters
  • how much usage has it seen over time
This gives governance a fast read on whether a model is live, economically positioned, and meaningfully used. The details page also extends below this section into worker-level support, which connects model policy to real network supply. That connection matters. In the whitepaper, Lightchain is not meant to be a static registry of models. It is a live decentralized AI network, so governance only becomes meaningful when a governed model can also attract reliable worker participation and actual usage.

Activity

Model activity chart
The activity view shows how the model is being used over time. Prompt, reasoning, and completion volume are separated so governance can see not just raw demand, but the shape of demand. This is a strong fit with the whitepaper's focus on useful AI execution. Lightchain's value proposition depends on real workload flowing through the network. Activity data shows whether a governed model is actually generating meaningful traffic instead of simply existing as an approved entry in a list.

Uptime

Model uptime chart
The uptime chart turns model reliability into something the community can inspect directly. Governance is not complete when a model is approved; the model also has to remain dependable once it is serving users. This is where the interface supports accountability. If uptime degrades, the community has a reason to revisit status, routing, or broader operational policy. That matches the whitepaper's emphasis on transparent systems rather than trust-me infrastructure.

Pricing

Model pricing charts
The pricing section makes model economics visible over time. Separate views for input and output pricing show whether the model remains stable, becomes more expensive, or moves in response to demand and network conditions. That is important because the economic layer is part of governance. Lightchain's broader design treats pricing as something that must support long-term network health, fair access, and sustainable supply. A pricing chart lets the community evaluate those tradeoffs directly instead of relying on a static fee number.

Why this page matters

Taken together, the Model Governance interface expresses the whitepaper in product form:
  • model admission is community-driven instead of closed
  • technical capability is shown alongside economic cost
  • live performance is visible through activity and uptime
  • pricing is observable instead of hidden behind internal policy
That combination is what makes governance meaningful on Lightchain. The protocol is not only deciding which models exist. It is deciding which models deserve community trust, network resources, and continued demand.