# Providers
This section provides a comprehensive guide for anyone who wants to join the OpenSeed network as a compute provider — a Seller. Whether you are running enterprise GPU infrastructure, a small server farm, or a single consumer GPU at home, the path to becoming an active OpenSeed Seller is designed to be quick, low-overhead, and immediately rewarding.
### The Provider Opportunity
Joining OpenSeed as a Seller is the most straightforward way to monetize AI compute capacity. The network provides everything needed to accept payments: the Registry for discovery, the x402 middleware for payment collection, and the state channel system for settlement. Your only contribution is the inference capability itself — the model you are running and the hardware you are running it on.
The economics of being an OpenSeed Seller are straightforward. You set a price for your inference, denominated in USDC per million input tokens and USDC per million output tokens. Every request served at your node earns you the authorized payment amount. You keep one hundred percent of what you earn — there are no platform fees, no commission structures, no revenue sharing with OpenSeed. Your earnings accumulate in validated SpendingAuth signatures and are converted to USDC in your wallet when you choose to settle.
The market dynamics of the OpenSeed network provide natural pricing guidance. If you price significantly above market rates, your routing score's price component will be low and your traffic will be limited. If you price competitively relative to your quality level — measured by your reputation score — you will attract consistent, high-volume routing. The Dashboard provides real-time market pricing data that helps you position your node competitively.
### Step One: Hardware and Model Selection
The first decision in becoming an OpenSeed Seller is what to offer. This means choosing both the hardware on which you will run inference and the model you will serve.
On the hardware side, the key specification is GPU VRAM. The model you can serve is fundamentally constrained by how much VRAM your GPU has available. As a general guide, consumer cards with 8GB of VRAM can serve highly quantized small models in the 7-8 billion parameter range. Cards with 16-24GB can serve more capable quantized models in the 13-34 billion parameter range. Cards with 48GB or more can serve very capable quantized models in the 70 billion parameter range. Larger models or less quantized versions require correspondingly more VRAM, up to multiple GPUs for frontier-class model sizes.
On the model side, model selection should be driven by a combination of what your hardware can run comfortably and what models have significant demand on the network. The Registry provides visibility into what models are being requested by Buyers, which helps inform your model selection decision. Popular models in the Llama 3 and Mistral families consistently attract significant routing traffic. Specialized models — coding-optimized, multilingual, domain-specific — may attract premium pricing from Buyers with specific needs.
For local model serving, Ollama is the recommended inference server for most Seller operators. It handles model downloading, quantization selection, hardware optimization, and OpenAI-compatible API serving with minimal configuration. Advanced operators may prefer alternatives like llama.cpp with a custom API wrapper, vLLM for higher throughput, or TGI (Text Generation Inference) for production deployments.
For API reselling, any upstream provider that offers an OpenAI-compatible API can be wrapped as an OpenSeed Seller node. The Seller SDK handles the x402 payment middleware regardless of what the upstream endpoint is.
### Step Two: Configuring Your Seller Node
The Seller node is configured through the openseed-sdk. The configuration covers your node's identity, pricing, model offering, upstream endpoint, wallet address, and tunneling preferences.
\[Full Seller node configuration instructions and parameter reference will be documented here]
Key configuration decisions include your pricing structure. Setting competitive pricing requires understanding the current market. The Dashboard shows real-time pricing from active Sellers offering similar models, which you can use as a benchmark. A new Seller entering the market may choose to price slightly below the market average initially to build up their reputation score with a base of traffic before adjusting to market rates.
Your settlement wallet address is configured at the node level. This is the Base Mainnet address where your earnings will be deposited when you initiate settlement transactions. It should be a wallet you fully control, separate from any hot wallet or exchange deposit address.
Your node's public name and description are metadata fields that appear in the Registry and in Buyers' Dashboard views. A clear, accurate description of your offering — including the model's capabilities, any specializations, and your infrastructure characteristics — helps Buyers understand what they are routing to and may contribute to higher routing priority from Buyers who have specific preferences.
### Step Three: Launching and Registering
With your configuration complete, launching your Seller node is a single command.
\[Full launch command and startup sequence will be documented here]
On startup, the Seller node performs several initialization steps. It loads your configuration, initializes the payment channel state, starts the inference endpoint wrapper with x402 middleware, and — if tunneling is enabled — spawns the tunnel connection and waits for a public URL to be assigned. Once the public URL is available, the node sends its first heartbeat to the Registry, registering your offering and making it immediately visible to Buyers.
Within seconds of a successful startup, your node appears in the Registry's active peer list. Buyers who query for the models you offer will see your node in their routing options, and your composite score — initially a blend of default values and any historical reputation data if you have run the node before — determines your routing priority.
### Monitoring, Optimization, and Growth
Once your node is live, ongoing management is primarily a matter of monitoring performance metrics and optimizing your configuration based on what you observe.
The Dashboard provides real-time visibility into your node's performance. Key metrics to monitor include your current reputation score and its components — latency, reliability, and uptime — as well as your traffic volume, earnings rate, and channel utilization.
Your latency score is the most actionable metric for hardware optimization. If your latency score is lower than you would like, consider whether your inference server is configured optimally for your hardware — whether you are using the appropriate quantization level for your VRAM, whether you have configured the inference server's threading and batching parameters appropriately, and whether there is other load on your GPU or CPU that could be reduced.
Your reliability score is the most important metric for long-term reputation. A single session of poor reliability — caused by hardware instability, an overloaded upstream API, or software bugs — can take time to recover from as the rolling reputation window incorporates the new data. Investing in hardware stability, monitoring uptime, and handling edge cases in your inference serving code pays dividends in sustained routing volume.
Your uptime score rewards nodes that stay online consistently. If you are running a home-lab node that you occasionally power down, consider whether you can maintain higher uptime during peak network hours by scheduling maintenance during periods of lower traffic.
### Settlement and Earnings Management
Settling your earnings — converting your accumulated SpendingAuth signatures to USDC in your wallet — is done through either the Dashboard or the CLI.
\[Full settlement command reference will be documented here]
The optimal settlement frequency depends on your volume and preferences. High-volume Sellers who accumulate significant earnings quickly may choose daily settlement to maintain liquidity. Lower-volume Sellers may find weekly or threshold-based settlement more gas-efficient. The Dashboard shows your current unrealized earnings balance and provides a gas cost estimate for settlement at your current accumulation level, helping you make informed settlement timing decisions.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.openseed.gg/integrations/providers.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.