Verify your provider setup

After registering your provider and bid (and a new model only if you had to mint one), you want to know before any consumer hits you that everything works. There is no built-in setup wizard yet. This page walks the same five checks the support team uses to verify a provider when someone posts in Discord asking “can you check if my setup is OK?”. If you used MyProvider, confirm Model Configuration Sync already wrote the on-chain modelId into models-config.json / MODELS_CONFIG_CONTENT before Step 1.

Step 1 — Local health

Your proxy-router is up and listening:

curl http://localhost:8082/healthcheck

Expected:

{ "status": "healthy", "version": "v7.0.0", "uptime": "..." }

On provider nodes the response also includes a models array — the periodic model health self-report covering your whole ecosystem of configured models and active bids. For every model in models-config.json that has an active bid from your wallet, the proxy-router sends a small test prompt on a schedule (default hourly, see MODEL_HEALTH_CHECK_INTERVAL in env-proxy-router) and caches the result. Probes are paced a few seconds apart (MODEL_HEALTH_CHECK_PROBE_DELAY, default 2s) so a provider with many models doesn’t burst its own backend into a rate limit. Active bids whose model is missing from models-config.json are also listed, so a bid you’re selling but cannot serve doesn’t go unnoticed:

{
  "models": [
    {
      "modelId": "0xe086...",
      "modelName": "llama-3.3-70b",
      "modelType": "LLM",
      "hasActiveBid": true,
      "bidId": "0x3f2a...",
      "status": "healthy",
      "lastHealthy": 1751871600,
      "lastChecked": 1751871600,
      "latencyMs": 412,
      "promptCorrect": true
    },
    {
      "modelId": "0x85670d...",
      "modelName": "mistral-31-24b",
      "modelType": "LLM",
      "hasActiveBid": true,
      "bidId": "0x9c41...",
      "status": "no_model_configured",
      "lastChecked": 1751871600
    }
  ]
}

modelName is the model’s public name as registered on-chain (not the private backend model string from models-config.json, which is never exposed). status is one of:

Status	Meaning	Action
`healthy`	Probe succeeded (LLM answer graded via `promptCorrect`)	—
`unhealthy`	Probe failed — see `errorKind` and `httpStatus` below	Fix the backend; consumers opening a session hit the same failure
`no_bid`	Configured model has no active bid; not probed	Post a bid if you want to sell it
`no_model_configured`	Active bid exists but the model is missing from `models-config.json`	Add the model entry or delete the bid — consumers can open sessions against this bid and get errors
`skipped`	Model type other than LLM/embedding; not probed	—

The self-report has its own operational reference — schedule, tuning, backend impact, and diagnosis recipes — at Model health self-report. For unhealthy models, errorKind narrows the failure and, when the backend answered with an HTTP error, httpStatus carries the exact upstream status code:

errorKind	Meaning	Typical `httpStatus`
`timeout`	Probe hit the per-model timeout	—
`connection`	Could not reach the backend `apiUrl` at all	—
`rate_limited`	Backend is up and configured, but throttled the probe	`429`
`bad_response`	Backend answered with an error or empty completion	`402` (billing), `400`/`404` (bad model config), `5xx`

Logs should show:

INFO  proxy state: running
INFO  HTTP  http server is listening: 0.0.0.0:8082
INFO  TCP   tcp server is listening: 0.0.0.0:3333

If anything here is wrong, stop and fix it before the next steps — see troubleshooting.

Step 2 — Public TCP reachable

Consumers connect to your :3333 over the public internet. From a machine outside your network:

# Replace with your provider's registered endpoint (host:port, no protocol)
nc -vz your-provider.example.com 3333

Expected: Connection succeeded. If it times out, your firewall / security group / NAT is blocking; consumers will see your bid but never get inference.

Step 3 — On-chain provider record

Confirm the marketplace recognises your registration:

# Replace with your provider wallet address (lowercase 0x…)
curl -sS -u 'admin:admin' \
  'http://localhost:8082/blockchain/providers' \
  | jq '.providers[] | select(.Address=="0xYOUR_PROVIDER")'

You should see your Address, Endpoint (the host:port you registered, no protocol), Stake, and IsDeleted: false. Same trick for your model:

curl -sS -u 'admin:admin' 'http://localhost:8082/blockchain/models' \
  | jq '.models[] | select(.Owner=="0xYOUR_PROVIDER")'

And your bid:

curl -sS -u 'admin:admin' 'http://localhost:8082/blockchain/bids' \
  | jq '.bids[] | select(.Provider=="0xYOUR_PROVIDER")'

If any of these doesn’t return your record, the on-chain transaction either failed or is still pending. Check the explorer with your provider wallet address (base.blockscout.com).

Step 4 — Network discovery

Two cron-driven dashboards aggregate the marketplace into JSON snapshots. Your provider only shows up here if the cron has reached you successfully after your registration:

# Active models — populated when the verifier can reach your provider's :3333 and ping the model
curl -sS https://active.mor.org/active_models.json \
  | jq --arg p "0xYOUR_PROVIDER" '
      .models[]
      | select(any(.bidDetail[]?; .providerId | ascii_downcase == ($p | ascii_downcase)))
      | {Name, Id, Tags, bidDetail}
    '

# Active bids — same, but for bids
curl -sS https://active.mor.org/active_bids.json \
  | jq --arg p "0xYOUR_PROVIDER" '
      .bids[]
      | select(.Provider | ascii_downcase == ($p | ascii_downcase))
    '

If your bid is on chain (Step 3) but not in active_bids.json, it means the verifier could reach the chain but could not reach your :3333. Re-check Step 2. The dashboards refresh on a schedule (a few minutes); give it time before concluding it failed.

Step 5 — End-to-end prompt via the Inference API

The hosted Morpheus Inference API serves as the easiest end-to-end consumer. If a real prompt against your model name returns text, you’ve proven the full chain (consumer → API Gateway → discovery → your P-Node → your backend → response).

Sign in at app.mor.org, grab an API key.
In the dashboard’s API Test page (or any OpenAI-compatible client) pick your model name from the dropdown.
Send any short prompt.

If it streams back a response — you’re done. If the model isn’t in the dropdown, go back to Step 4. If it’s there but errors out, check your proxy-router logs for the incoming request and your backend’s logs for the forwarded request. You can also do this directly from a separate consumer-side proxy-router; see API direct.

When in doubt

The Discord #tech-support channel is the fastest path. Include:

Your provider wallet address (lowercase 0x…).
Your model ID and bid ID.
The output of Steps 1, 3, and 4.

The first thing support does is exactly the above checks; arriving with the answers shortcuts the conversation.

Common gotchas surfaced by the chat history

Symptom	Cause	Fix
Provider on chain but missing from `active_bids.json`	Public `:3333` not reachable	Open firewall / security group; verify with `nc -vz` from outside
`:3333` reachable, model still missing from `active_models.json`	The verifier couldn’t ping the model’s `apiUrl`	Confirm `models-config.json` `apiUrl` is reachable from inside the proxy-router host
Healthcheck fails with `connection refused` to BASE	Default round-robin RPC rate-limited / unavailable	Set your own `ETH_NODE_ADDRESS` (Alchemy / Infura) — see env-proxy-router
Lost ~MOR during setup	Each `postModelBid` charges a non-refundable `marketplaceBidFee` (`0.3 MOR`); reposting bids during configuration adds up	See Pricing and the “What can cost you MOR during setup” section in Quickstart

Get started

Inference API (hosted)

Concepts

Consumers

Prosumers

Providers - Resale

Providers - Full P-Node

AI knowledge

Ecosystem

Reference

Step 1 — Local health

Step 2 — Public TCP reachable

Step 3 — On-chain provider record

Step 4 — Network discovery

Step 5 — End-to-end prompt via the Inference API

When in doubt

Common gotchas surfaced by the chat history

​Step 1 — Local health

​Step 2 — Public TCP reachable

​Step 3 — On-chain provider record

​Step 4 — Network discovery

​Step 5 — End-to-end prompt via the Inference API

​When in doubt

​Common gotchas surfaced by the chat history

Step 1 — Local health

Step 2 — Public TCP reachable

Step 3 — On-chain provider record

Step 4 — Network discovery

Step 5 — End-to-end prompt via the Inference API

When in doubt

Common gotchas surfaced by the chat history