DCENT_OS API & Ports Reference — REST, WebSocket, 4028, MCP

Identity & status — evidence ledger dated 2026-09-01

AVAILABILITY: RELEASEDMATURITY: EXPERIMENTAL

All 13 Antminer models in the registry are publicly released on the Experimental channel. Experimental is public firmware for testing and informed, non-critical use; it is not Stable or GA and is not recommended for an irreplaceable fleet.

The verified artifact ledger currently contains files for exact Antminer S9 + Antminer S19j Pro lanes. Binary scope is separate from release status; every lane retains its own installation and recovery limits.

DCENT_OS is local-first: the dashboard, the REST and WebSocket APIs, a CGMiner-compatible API on TCP 4028, and a built-in MCP server all run on your LAN. No cloud, no account, no phone-home. This page is the endpoint reference — the network surfaces, the authentication model, the single error envelope, and every path the firmware mounts. The endpoint tables are generated from the dcentrald router source by a committed script, so they cannot drift from the firmware.

Network surfaces

DCENT_OS (Antminer builds) — the network surface, with an evidence label per row
Surface	Port	What it’s for	Evidence
Web dashboard, and the API proxy in front of the daemon	TCP 80	Three-mode local UI (Space Heater / Mining / Hacker), setup wizard, config editing. It also reverse-proxies every `/api/*` request to the daemon, which is why the examples on this page carry no port number.	Verified (source) — `server.py` defaults to `--port 80 --bind 0.0.0.0` and forwards `/api/*` to `127.0.0.1:8080`. It does not add credentials of its own: your `Authorization` header is forwarded, not replaced.
REST API (`dcentrald`)	TCP 8080, and on 80 through the dashboard proxy	Telemetry, configuration, tuning, diagnostics — the 241 paths listed below. Same paths either way.	Verified (source) — the axum server’s own module doc states port 8080; the proxy target in `server.py` is the same port.
WebSocket API	TCP 8080 at `/ws`	Live telemetry streaming alongside REST: pool URLs, temperatures, hashrate.	Verified (source) — the route is registered on the daemon’s router. Note the port: the :80 proxy forwards `/api/*` only, so a WebSocket client should connect to `:8080` directly. Not yet observed on live hardware.
CGMiner-compatible API	TCP 4028	Drop-in monitoring for existing tooling — explicitly `pyasic` and Home-Assistant friendly.	Verified — root `README.md`.
MCP server	`POST /mcp`, same HTTP surface as the REST API	AI-native control surface: read-only monitoring for any agent; authenticated owner sessions for control.	Verified — `/mcp` is one of the mounted paths in the generated route inventory, and it requires a bearer session like everything else.
SSH	TCP 22 (standard)	Management access; up from first boot (“dashboard, SSH, and API up; hash power off”).	Verified (service, `docs/INSTALL/README.md`) / Inferred (port number — not stated in the docs).
Stratum V1/V2	outbound only (e.g. `:3333` in the config examples)	Pool connection — an outbound client, not a listening service. Multi-pool failover with anti-flap failback on V1; the native SV2 stack is present in the source behind an explicit readiness gate.	Verified — root `README.md`; `docs/CONFIGURATION.md` pool examples.

Nothing here phones home: every listening surface above is LAN-only (source: docs/FAQ.md, “Does it phone home”). The site’s own /wp-json/dc/v1/* API is a different thing entirely — that is this website’s data API, not the firmware’s.

The MCP server, precisely

DCENT_OS ships a built-in MCP (Model Context Protocol) server so a local AI agent can monitor — and, with owner authentication, control — the miner. The trust boundary as the repository states it: read-only monitoring for any agent; authenticated owner sessions for control. The dashboard’s Companion pairs this with your own local LLM (LM Studio / Ollama) — your model, your machine, no cloud — and proposes guarded actions you explicitly approve. The transport is a single POST /mcp on the same HTTP surface as the REST API, and it is not auth-exempt.

Works with your existing tooling

pyasic / Home Assistant: point them at the CGMiner-compatible API on port 4028 — the compatibility target the README names explicitly.
Prometheus: the miner exposes /metrics, which is auth-exempt only while the metrics_require_auth flag is off. Fleet-level metrics come from the bench side instead: DCENT_Toolbox’s dcent serve daemon exposes /metrics (binding 127.0.0.1 by default) plus a /status JSON endpoint on the machine running the toolbox.
Anything that speaks cgminer JSON: dashboards and monitors built for stock or cgminer-era APIs can read DCENT_OS through the same 4028 socket.
Your own client: generate it from the OpenAPI document — and read what that document does and does not give you first, because the answer is not flattering.

Companion tool — DCENT_Toolbox: DCENT_Toolbox command reference.

Everything above is the map. Everything below is the reference: how to authenticate, what an error looks like, what each operating mode makes reachable, and every path the firmware mounts.

Start here: ask your own miner

DCENT_OS describes itself. Before reading any table, get the answer from the unit in front of you — that answer is always current, even if this page is not.

curl -s http://<MINER_IP>/api/index | jq '{schema, route_count, surface_count}'

You should see a JSON object whose schema is exactly dcentos.api.index.v1, with surface_count of 5 and a route_count in the low seventies:

{
  "schema": "dcentos.api.index.v1",
  "route_count": 72,
  "surface_count": 5
}

The five surfaces are dcent-rest, pyasic-axeos-rest, v1-firmware-aliases, cgminer-tcp and websocket.

If you get 401 Unauthorized instead, you have not created a session yet — jump to Authentication and come back. If the connection is refused outright, the miner is not running DCENT_OS or is not on the address you tried.

Two numbers, one firmware. /api/index reports route_count: 72, and the tables below list 241. Both are correct and they answer different questions. The 72 are the declared compatibility surface — the routes the firmware advertises to fleet tooling, each carrying a support grade and a mutates flag. The 241 are every path the HTTP router actually mounts, including debug and reverse-engineering surfaces no fleet tool should call. If you are writing an integration, build against the 72. If you are auditing the firmware, read the 241.

Authentication

There is no auth server and no account. On first boot you set a password; DCENT_OS stores it as an argon2id hash in /data/dcent/auth.json on the miner itself. Everything after that is a bearer session token.

1. Check whether setup has been done

curl -s http://<MINER_IP>/api/auth/status

You should see a JSON body indicating whether a password has been set. This endpoint needs no authentication, by design — it is how the setup wizard knows which screen to show.

2. Create a session

curl -s -X POST http://<MINER_IP>/api/auth/session \
     -H 'Content-Type: application/json' \
     -d '{"password":"YOUR_PASSWORD"}'

You should see a JSON body containing a session token. If you see the canonical error envelope with HTTP 401, the password is wrong. Note that POST /api/auth/setup is rate limited to 3 attempts per 60 seconds per IP address — if you are scripting first-boot provisioning, pace it.

3. Use the session

TOKEN='paste-the-token-here'
curl -s http://<MINER_IP>/api/status -H "Authorization: Bearer $TOKEN"

You should see HTTP 200 and a JSON telemetry body. If you see 401 with WWW-Authenticate: Bearer realm="dcentrald", the token is missing, expired, or revoked.

Session lifetime, exactly

Bearer session limits, read from the daemon source
Limit	Value	What happens
Absolute TTL	30 days	A session can never live longer than this, however active it is.
Idle timeout	8 hours	An unused session expires early. Long enough that an open dashboard tab never logs out; short enough that a forgotten `curl` token does not stay live.
Concurrent sessions	32	Issuing session 33 evicts the oldest active record.
Setup rate limit	3 / 60 s / IP	Applies to `POST /api/auth/setup`.
Lost the password	Hold reset 15 s	Physically deletes the auth file and clears the password. Requires hands on the unit — there is no remote reset, and that is deliberate.

Endpoints that need no authentication

Seven API paths, plus the dashboard itself, are reachable without a token. This list is read from the daemon’s is_auth_exempt() function, not from the module comment above it, because the two disagree — and publishing the comment would ship a wrong, security-relevant table:

GET /api/auth/status — has a password been set
POST /api/auth/setup — set the initial password, only when none exists
POST /api/auth/session — create a session
GET /api/setup/status — setup wizard state
GET /api/safety/warnings — safety warnings
GET /api/system/update/metadata — update metadata
GET /api/donation/info — the donation pool URL, payout address and block-explorer link
GET / and /static/* — the dashboard itself

Those seven are the open rows in the tables below; the other 234 paths are bearer. /api/donation/info is open on purpose: you can verify our donation claims on-chain before you even finish the setup wizard, without logging in.

/metrics is a special case: it is exempt only while the metrics_require_auth configuration flag is off. Turn the flag on and it requires a bearer token like anything else.

WebSocket authentication

Browsers cannot set an Authorization header on a WebSocket upgrade, so /ws accepts the same bearer token as a ?token= query parameter. When [api].websocket_tickets = true is set, you can instead redeem a one-time ticket from GET /api/auth/ws-ticket. /ws is not unauthenticated — it streams live pool URLs, temperatures and hashrate. Connect to it on port 8080: the dashboard’s port-80 proxy forwards /api/* and nothing else.

Operating modes change what is reachable

DCENT_OS runs in one of three modes, and the mode gates the API surface before the handler ever runs. A 403 here is a policy answer, not a bug.

Mode-conditional API access
Mode	Reachable	`/api/debug/*`
Home	Status, pools, config, system info, `/api/home/*`, sleep/wake, diagnostics	403 with a mode explanation
Standard	Everything in Home, plus stats, profiles, history	403 with a mode explanation
Hacker	Everything	Allowed — and write operations additionally require `{"confirm": true}` in the body

You should see, when you call a debug endpoint outside Hacker mode, an HTTP 403 whose body names your current mode and the mode the endpoint requires. That body is machine-readable, so tooling can tell “you are not allowed” apart from “this does not exist”.

Errors are one shape, always

Every non-success response is normalised into a single envelope by a response layer wrapped around the whole router, so you write one error handler and it works everywhere. It is the one named schema in the OpenAPI document, ApiErrorBody, and every operation declares it for 4XX and 5XX.

{
  "error": "human-readable message",
  "detail": "optional extra context",
  "code": "pool_validation",
  "suggestion": "Check the pool URL format, worker name, and failover split settings."
}

You should see error always present; detail, code and suggestion are omitted entirely when empty rather than sent as null. Branch on code, never on the prose in error.

Every `code` value the daemon emits
`code`	Meaning
`config_validation`	The submitted configuration failed validation.
`pool_validation`	Pool URL, worker name or failover split is malformed.
`pool_config_write_failed`	Pool config was valid but could not be persisted.
`error_body_unavailable`	The daemon could not read the underlying error body to normalise it.
`legacy_error`	An older-format error was wrapped into this envelope.
`unclassified_error`	A failure with no more specific code.

Versioning

The API contract version is dcentos.api.v1. It is returned by GET /api/index as api_contract_version and is the value to assert against in a fleet tool. Individual payloads additionally carry their own schema tags — for example the route catalog is dcentos.api.index.v1 — so a consumer can pin a payload shape independently of the overall contract.

A small number of endpoints are explicitly namespaced under /api/v1/ (capabilities, firmware update, system upgrade and their status routes). Those are the paths whose shape is committed to hardest.

There is a second, blunter version signal in the tables below. Each row is marked pinned or not pinned, meaning present or absent in the test-pinned route snapshot the build asserts against. 19 of the 241 paths are mounted but not pinned. They are the newest surfaces, and they are the ones most likely to move under you.

Machine-readable specification

An OpenAPI 3.1.0 document covering every path and operation below is generated directly from the dcentrald Rust source: dcentos-openapi.json. Feed it to your client generator, your test suite, or your agent.

It is deliberately honest about one thing, and you should know it before you spend an afternoon: the security scheme, the error schema, the auth-exempt set, the contract version and every path and method are derived from source, but per-endpoint success response bodies are not. Handlers build most payloads inline, so there is no single type to reflect, and inventing shapes for hundreds of operations would be documenting fiction. Every operation therefore carries x-dcent-response-schema: "not-derived", and those are being filled in from evidence, endpoint by endpoint. We would rather ship a spec you can trust than a spec that is complete.

Each operation also carries x-dcent-source, the file in the daemon that registers it, so you can read the handler instead of guessing at its output. The module map is at the end of this page.

How this reference compares to Braiins OS+

Braiins publishes an OpenAPI 3.1.0 document for Braiins OS+ at developer.braiins-os.com/latest/openapi.json. We fetched both documents on 2026-08-20 and parsed them with the same code. On the axis that decides whether you can generate a usable client — the shape of a success response — theirs is the better artifact, and not narrowly. Ours is better on two narrower axes. Both are in the table, because a comparison you can only publish in one direction is not a comparison.

Both OpenAPI 3.1.0 documents, parsed the same way on 2026-08-20
Measured	DCENT_OS	Braiins OS+
Spec version	`dcentos.api.v1`	`1.7.0`
Paths / operations	241 / 258	54 / 63
Named schemas in `components.schemas`	1 (the error envelope)	158
Operations with a typed 200/201 body	0 of 258	56 of 63
Operations with a one-line summary	0 of 258	63 of 63
Operations with a prose `description`	0 of 258	61 of 63
Operations with a typed 4XX/5XX error body	258 of 258	0 of 63
Operations carrying provenance back to a source file	258 of 258 (`x-dcent-source`)	0 of 63
Deprecation flags	0	8
Declared security scheme	`bearerSession`	none declared
Spec served by the miner itself	not yet	yes — `GET /api/v1/docs/openapi.json`

Read that honestly, in both directions. What we do not declare is a typed success body, on any of the 258 operations, nor a single line of per-operation documentation. So a client generated from our document knows precisely how every call can fail and nothing whatsoever about what it returns. A client generated from theirs is typed, documented and deprecation-aware across 63 operations — and their miner will hand you that document over its own API, which ours does not yet do. If you need generated models today, use theirs, and treat it as the standard this page is trying to reach.

What our document has that theirs does not: every one of the 258 operations declares a typed error body, and every one names the file in the daemon that registers it. Along with the declared and explained security scheme, one error envelope with a closed set of six code values, an auth-exempt list read from the function rather than from the comment that disagrees with it, a per-path mark for whether the route is covered by the pinned snapshot, and a machine-readable claims contract the firmware serves about itself, that is what this document is for right now: auditing a firmware you can read, rather than generating a client you cannot. And the missing shapes are missing out loud — x-dcent-response-schema: "not-derived" on all 258 operations, rather than 258 plausible guesses. Closing that gap is firmware work; it happens in dcentrald, not in this page’s copy.

Credit where it is owed on a second axis entirely: Braiins authored and open-sourced Stratum V2, the protocol most of this industry now builds against.

Try it with no miner at all

You do not need hardware to explore the API. The dashboard ships a mock server that replays realistic telemetry on your own machine:

cd DCENT_OS_Antminer/dashboard
npm ci && npm run build
python3 scripts/preview-with-mocks.py --port 4173

You should see the build finish without errors and the script print a listening address; opening http://127.0.0.1:4173 then shows the real dashboard UI backed by mock telemetry. If npm ci fails, you are missing Node — that is the only prerequisite. The mock definitions inside that script are themselves a fast map of the endpoints the dashboard actually exercises; count them yourself rather than trusting a number on a web page.

For a second no-hardware option that exercises real client code paths rather than the UI, DCENT_Toolbox has dcent simulate, which runs a fake miner on loopback so the whole toolbox works against it. See the Toolbox command reference.

The claims contract the firmware emits about itself

Most firmware pages make claims in the vendor’s voice. DCENT_OS ships a machine-readable competitive-claims contract inside the mining daemon, served over the miner’s own REST API at GET /api/competitive/readiness. It is a function in the shipped source, not a marketing asset: competitive_decentralization_gate() in dcentrald/dcentrald-api/src/rest.rs — locate it with grep -n "fn competitive_decentralization_gate" against the public GPL-3.0 repository rather than a line number, because line numbers drift between checkouts.

The reason it is worth reading is not the flattering fields. It is the unflattering ones.

Selected fields from the shipped contract
Field	Value	What it means for you
`license_required`	`false`	No licence to buy.
`license_server_required`	`false`	Nothing phones a licence server before the miner will hash.
`activation_required`	`false`	No activation step, online or offline.
`mandatory_fee`	`false`	No mandatory fee exists in the code path.
`fee_route`	`"transparent_donation"`	What does exist is a donation, and it is named as such.
`donation.default_enabled`	`true`	The donation is ON by default. We would rather you read that here than discover it.
`donation.default_percent`	`2.0`	Two percent of hashrate, time-sliced on a 3,600-second cycle.
`donation.disable_supported`	`true`	One line of config turns it off, and 0% is a one-click preset in the setup wizard.
`donation.pool_visible`	`true`	The destination pool is shown, not hidden.
`donation.donation_off_test_status`	`"not_run"`	We have not yet run the automated test that proves the off-switch stays off. Stated, not omitted.
`donation.current_state_source`	`"not_read_by_static_contract"`	This contract reports defaults, not what your machine is doing right now.
`home_miner_safe`	`false`	Status `"partial"`. It is a public beta and it says so in its own API.
`write_surfaces[].audit_status`	`"partial"`	The MCP raw-hardware write gate still needs a follow-up audit before promotion.
`offline_behavior`	`"local_first"`	Setup, dashboard, diagnostics and the local APIs work with no internet.

Why no competitor can copy this format. Three reasons compound. The honest values are adverse — a closed firmware would have to write license_server_required: true. The contract is only checkable because the source is open; a closed vendor asserting false in JSON has added an assertion, not evidence. And the persuasive weight is carried entirely by the admissions: "not_run", "not_read_by_static_contract", home_miner_safe: false, audit_status: "partial". A page that cannot say "not_run" cannot borrow the format.

Evidence grade. The field names and values above are Verified — read from the shipped source in the public repository at commit 6f61603. The route is Verified against the test-pinned route snapshot. What we have not observed is a live response from real hardware running a current build, so treat the runtime shape as Unknown until you call it on your own miner. That is exactly the check this page is asking you to make.

Verify our fee claim without logging in

One endpoint on this firmware is deliberately left unauthenticated: GET /api/donation/info. It returns the donation pool URL, the payout address and a block-explorer link. The source comment says why in plain words — “No auth required so operators can verify the firmware’s donation claims even before completing the setup wizard.” You can check where the 2% goes, on-chain, before you have finished setting the machine up.

curl -s http://<miner-ip>/api/donation/info

You should see a JSON object containing pool_url, payout_address, explorer_url and "trust_model": "trust_but_verify" — with no bearer token in the request. Every other telemetry endpoint on this list, including the WebSocket, requires one.

Every endpoint this firmware mounts

DCENT_OS mounts 241 HTTP paths and 258 operations (path × method: 170 GET, 84 POST, 2 PUT, 2 DELETE). Every row below is extracted from the axum router in the dcentrald source by a committed script, not typed by hand. Rows marked open need no authentication; everything else requires a bearer session. Rows marked not pinned are mounted by the router but absent from the test-pinned route snapshot.

The sixteen groups below are ours, not the specification’s: the raw document splits into 52 path families, eighteen of which hold a single path, which is a filing system rather than a reference. Nothing has been left out to make the grouping tidy — the group counts sum to exactly 241 paths and 258 operations, the build refuses to publish if they do not, and the leftovers are listed under Everything else rather than dropped.

Contract version: dcentos.api.v1. The OpenAPI 3.1.0 document covers all of these — 241 paths, 258 operations, the auth model and the error enum. Every operation carries x-dcent-response-schema: "not-derived": handlers return impl IntoResponse and build payloads inline, so there is no single Rust type to reflect, and emitting a guessed 200 body for 258 operations would be inventing an API contract. See how that compares to Braiins OS+.

Identity and discovery

Ask the miner what it is, what it runs, and what it serves.

Identity and discovery — 26 paths, 26 operations
Method	Path	Auth	Route snapshot
`GET`	`/api/compatibility/manifest`	bearer	pinned
`GET`	`/api/dashboard/health`	bearer	pinned
`GET`	`/api/dashboard/version`	bearer	pinned
`GET`	`/api/index`	bearer	pinned
`GET`	`/api/system/api-compatibility/manifest`	bearer	pinned
`GET`	`/api/system/asic`	bearer	pinned
`GET`	`/api/system/boot_timeline`	bearer	pinned
`GET`	`/api/system/health`	bearer	pinned
`POST`	`/api/system/identify`	bearer	pinned
`GET`	`/api/system/info`	bearer	pinned
`POST`	`/api/system/restart`	bearer	pinned
`POST`	`/api/system/restore-to-stock`	bearer	pinned
`POST`	`/api/system/restore-to-stock/preflight`	bearer	pinned
`GET`	`/api/system/restore-to-stock/preflight-checks`	bearer	pinned
`GET`	`/api/system/restore-to-stock/status`	bearer	pinned
`GET`	`/api/system/stats`	bearer	pinned
`GET`	`/api/system/update/metadata`	open	pinned
`GET`	`/api/system/update/status`	bearer	pinned
`GET`	`/api/system/update_capability`	bearer	pinned
`POST`	`/api/system/upgrade`	bearer	pinned
`GET`	`/api/system/upgrade/status`	bearer	pinned
`GET`	`/api/v1/capabilities`	bearer	pinned
`POST`	`/api/v1/firmware/update`	bearer	pinned
`GET`	`/api/v1/firmware/update/status`	bearer	pinned
`POST`	`/api/v1/system/upgrade`	bearer	pinned
`GET`	`/api/v1/system/upgrade/status`	bearer	pinned

Authentication and session

Create a bearer session; check whether first-boot setup is done.

Authentication and session — 17 paths, 17 operations
Method	Path	Auth	Route snapshot
`POST`	`/api/auth/session`	open	pinned
`DELETE`	`/api/auth/session/current`	bearer	pinned
`POST`	`/api/auth/setup`	open	pinned
`GET`	`/api/auth/status`	open	pinned
`POST`	`/api/auth/ws-ticket`	bearer	pinned
`POST`	`/api/setup/complete`	bearer	pinned
`POST`	`/api/setup/quiet-hours`	bearer	pinned
`POST`	`/api/setup/skip-password`	bearer	pinned
`POST`	`/api/setup/skip-safety`	bearer	pinned
`GET`	`/api/setup/status`	open	pinned
`POST`	`/api/setup/step-economics`	bearer	pinned
`POST`	`/api/setup/step1-safety`	bearer	pinned
`POST`	`/api/setup/step2-circuit`	bearer	pinned
`POST`	`/api/setup/step3-password`	bearer	pinned
`POST`	`/api/setup/step4-mode`	bearer	pinned
`POST`	`/api/setup/step5-pool`	bearer	pinned
`POST`	`/api/setup/test-pool`	bearer	pinned

Mining status and telemetry

What the miner is doing right now.

Mining status and telemetry — 17 paths, 17 operations
Method	Path	Auth	Route snapshot
`GET`	`/api/chips`	bearer	pinned
`GET`	`/api/chips/health`	bearer	not pinned
`GET`	`/api/history`	bearer	pinned
`GET`	`/api/history/audit`	bearer	pinned
`GET`	`/api/history/shares`	bearer	pinned
`GET`	`/api/metrics/rolling`	bearer	not pinned
`GET`	`/api/metrics/rolling.csv`	bearer	not pinned
`GET`	`/api/mining/chain/presence`	bearer	pinned
`GET`	`/api/mining/handoff/state`	bearer	pinned
`GET`	`/api/mining/pipeline/manifest`	bearer	pinned
`GET`	`/api/mining/pipeline/snapshot`	bearer	pinned
`GET`	`/api/mining/pipeline/snapshot/schema`	bearer	pinned
`GET`	`/api/mining/ramp`	bearer	pinned
`GET`	`/api/mining/work/posture`	bearer	pinned
`GET`	`/api/stats`	bearer	pinned
`GET`	`/api/status`	bearer	pinned
`GET`	`/metrics`	bearer	pinned

Pools and Stratum

Pool configuration, failover, and the Stratum surface.

Pools and Stratum — 10 paths, 11 operations
Method	Path	Auth	Route snapshot
`POST`	`/api/jd/config`	bearer	not pinned
`GET`	`/api/jd/status`	bearer	not pinned
`POST`	`/api/jd/test-connection`	bearer	not pinned
`GET`	`/api/pool/sv2/handshake`	bearer	not pinned
`GET`	`/api/pool/sv2/messages`	bearer	not pinned
`GET`	`/api/pool/sv2/status`	bearer	not pinned
`GET POST`	`/api/pools`	bearer	pinned
`GET`	`/api/pools/failover_policy`	bearer	pinned
`POST`	`/api/pools/test`	bearer	pinned
`GET`	`/api/stratum/protocol`	bearer	pinned

Autotuner and tuning

Runtime frequency and voltage tuning. Values are calculated at runtime, not read from a preset table.

Autotuner and tuning — 36 paths, 38 operations
Method	Path	Auth	Route snapshot
`PUT`	`/api/autotuner/active`	bearer	pinned
`GET`	`/api/autotuner/chip-health`	bearer	pinned
`POST`	`/api/autotuner/decrement_hashrate_target`	bearer	pinned
`POST`	`/api/autotuner/decrement_power_target`	bearer	pinned
`GET`	`/api/autotuner/efficiency`	bearer	pinned
`POST`	`/api/autotuner/fleet-profile/export`	bearer	pinned
`POST`	`/api/autotuner/increment_hashrate_target`	bearer	pinned
`POST`	`/api/autotuner/increment_power_target`	bearer	pinned
`POST`	`/api/autotuner/noise-profile`	bearer	pinned
`POST`	`/api/autotuner/profitability`	bearer	pinned
`POST`	`/api/autotuner/quota`	bearer	not pinned
`POST`	`/api/autotuner/room-temp-factor`	bearer	pinned
`GET`	`/api/autotuner/saved-status`	bearer	pinned
`POST`	`/api/autotuner/set_default_hashrate_target`	bearer	pinned
`GET`	`/api/autotuner/silicon-report`	bearer	pinned
`GET`	`/api/autotuner/state`	bearer	pinned
`GET`	`/api/autotuner/status`	bearer	pinned
`GET`	`/api/autotuner/target`	bearer	pinned
`GET`	`/api/autotuner/telemetry`	bearer	pinned
`GET`	`/api/autotuner/telemetry/csv`	bearer	pinned
`GET`	`/api/autotuner/tuned_profiles`	bearer	pinned
`GET`	`/api/autotuner/visibility`	bearer	pinned
`POST`	`/api/perf/calibrate`	bearer	not pinned
`GET`	`/api/perf/efficiency`	bearer	not pinned
`GET`	`/api/profile/download`	bearer	not pinned
`POST`	`/api/profile/upload`	bearer	not pinned
`GET POST`	`/api/profiles`	bearer	pinned
`GET`	`/api/profiles/presets`	bearer	pinned
`GET`	`/api/profiles/silicon`	bearer	pinned
`GET`	`/api/profiles/silicon-table`	bearer	pinned
`GET DELETE`	`/api/profiles/silicon/:id`	bearer	pinned
`PUT`	`/api/profiles/silicon/active`	bearer	pinned
`POST`	`/api/profiles/silicon/import`	bearer	pinned
`POST`	`/api/profiles/silicon/import-json`	bearer	pinned
`POST`	`/api/profiles/silicon/reload`	bearer	pinned
`GET`	`/api/tuning/constraints`	bearer	pinned

Thermal, fans and power

Cooling, PSU and power posture.

Thermal, fans and power — 7 paths, 8 operations
Method	Path	Auth	Route snapshot
`POST`	`/api/fan`	bearer	pinned
`GET`	`/api/power/dps`	bearer	pinned
`GET`	`/api/thermal/cold_environment`	bearer	pinned
`GET`	`/api/thermal/cooling_modes`	bearer	pinned
`GET`	`/api/thermal/posture`	bearer	pinned
`GET`	`/api/thermal/supervisor`	bearer	pinned
`GET POST`	`/api/tou/schedule`	bearer	pinned

Actions and lifecycle

Reboot, sleep, wake, firmware update and restore-to-stock.

Actions and lifecycle — 13 paths, 13 operations
Method	Path	Auth	Route snapshot
`POST`	`/api/action/reboot`	bearer	pinned
`POST`	`/api/action/restart`	bearer	pinned
`POST`	`/api/action/sleep`	bearer	pinned
`POST`	`/api/action/wake`	bearer	pinned
`GET`	`/api/boot/phase`	bearer	not pinned
`GET`	`/api/boot/timeline`	bearer	not pinned
`GET`	`/api/firmware/luxos_architecture`	bearer	pinned
`GET`	`/api/firmware/luxos_responses`	bearer	pinned
`GET`	`/api/firmware/luxos_status_codes`	bearer	pinned
`GET`	`/api/firmware/luxos_web_map`	bearer	pinned
`GET`	`/api/firmware/proto_wire_types`	bearer	pinned
`GET`	`/api/firmware/vnish_overlay`	bearer	pinned
`GET`	`/api/firmware/vnish_schema`	bearer	pinned

Config, backup and audit

Read and write configuration; read the persistent audit log.

Config, backup and audit — 16 paths, 23 operations
Method	Path	Auth	Route snapshot
`GET`	`/api/audit-log`	bearer	not pinned
`GET POST`	`/api/config`	bearer	pinned
`GET`	`/api/config/backup/manifest`	bearer	pinned
`GET POST`	`/api/config/donation`	bearer	pinned
`GET`	`/api/config/export`	bearer	pinned
`POST`	`/api/config/import`	bearer	pinned
`GET POST`	`/api/config/mqtt`	bearer	pinned
`POST`	`/api/config/mqtt/test`	bearer	pinned
`GET POST`	`/api/config/power-calibration`	bearer	pinned
`GET POST`	`/api/config/psu-override`	bearer	pinned
`GET POST`	`/api/config/shared`	bearer	pinned
`GET POST`	`/api/config/webhook`	bearer	pinned
`POST`	`/api/config/webhook/test`	bearer	pinned
`GET`	`/api/donation/info`	open	not pinned
`POST`	`/api/safety/acknowledge`	bearer	pinned
`GET`	`/api/safety/warnings`	open	pinned

Hardware inventory and sensors

What silicon is actually in the box, and what its sensors report.

Hardware inventory and sensors — 7 paths, 7 operations
Method	Path	Auth	Route snapshot
`GET`	`/api/hardware/pic_info`	bearer	pinned
`GET`	`/api/hardware/psu_bypass_matrix`	bearer	pinned
`GET`	`/api/hardware/psu_catalog`	bearer	pinned
`GET`	`/api/hardware/thermal/bm1368/chip_temps`	bearer	pinned
`GET`	`/api/hardware/thermal/sensors`	bearer	pinned
`GET`	`/api/miner/pvt-table`	bearer	not pinned
`GET`	`/api/miner/type`	bearer	pinned

LEDs and physical identification

Find one machine in a room full of them.

LEDs and physical identification — 6 paths, 7 operations
Method	Path	Auth	Route snapshot
`GET POST`	`/api/led/config`	bearer	pinned
`POST`	`/api/led/locate`	bearer	pinned
`POST`	`/api/led/locate/stop`	bearer	pinned
`POST`	`/api/led/pattern`	bearer	pinned
`GET`	`/api/led/patterns`	bearer	pinned
`GET`	`/api/led/status`	bearer	pinned

Network, fleet and swarm

Host networking, LAN discovery of other DCENT_OS units, and swarm coordination.

Network, fleet and swarm — 9 paths, 9 operations
Method	Path	Auth	Route snapshot
`POST`	`/api/fleet/discover`	bearer	pinned
`GET`	`/api/fleet/miners`	bearer	pinned
`GET`	`/api/fleet/pool-stats`	bearer	pinned
`GET`	`/api/network/block`	bearer	pinned
`GET`	`/api/network/config_schema`	bearer	pinned
`POST`	`/api/network/hostname`	bearer	pinned
`GET`	`/api/network/info`	bearer	pinned
`GET`	`/api/swarm`	bearer	pinned
`POST`	`/api/swarm/room-temp`	bearer	pinned

Off-grid and solar

Running on a supply that is not the grid.

Off-grid and solar — 8 paths, 10 operations
Method	Path	Auth	Route snapshot
`GET POST`	`/api/offgrid/config`	bearer	pinned
`GET`	`/api/offgrid/presets`	bearer	pinned
`GET`	`/api/offgrid/status`	bearer	pinned
`POST`	`/api/offgrid/test`	bearer	pinned
`GET POST`	`/api/solar/config`	bearer	pinned
`GET`	`/api/solar/status`	bearer	pinned
`POST`	`/api/solar/test`	bearer	pinned
`GET`	`/api/solar/verification-history`	bearer	pinned

Integrations

MQTT, webhooks, the CGMiner shim, the home-mode surface, and the MCP endpoint.

Integrations — 9 paths, 10 operations
Method	Path	Auth	Route snapshot
`GET`	`/api/cgminer/catalog`	bearer	pinned
`GET`	`/api/home/history`	bearer	pinned
`GET POST`	`/api/home/night-mode`	bearer	pinned
`GET`	`/api/home/presets`	bearer	pinned
`POST`	`/api/home/room-temp`	bearer	pinned
`GET`	`/api/home/status`	bearer	pinned
`POST`	`/api/home/target`	bearer	pinned
`GET`	`/api/mqtt/status`	bearer	pinned
`POST`	`/mcp`	bearer	pinned

Reverse-engineering catalog

Read-only constants from the RE corpus. Nothing here touches hardware.

Reverse-engineering catalog — 21 paths, 21 operations
Method	Path	Auth	Route snapshot
`GET`	`/api/re/catalog`	bearer	pinned
`GET`	`/api/re/catalog/apw-psu`	bearer	pinned
`GET`	`/api/re/catalog/asic-commands`	bearer	pinned
`GET`	`/api/re/catalog/asic-registers`	bearer	pinned
`GET`	`/api/re/catalog/asic-registers/bm1387`	bearer	pinned
`GET`	`/api/re/catalog/asic-registers/bm1397`	bearer	pinned
`GET`	`/api/re/catalog/bb-uart-trans`	bearer	pinned
`GET`	`/api/re/catalog/bm1362-baud-init`	bearer	pinned
`GET`	`/api/re/catalog/boot-flow`	bearer	pinned
`GET`	`/api/re/catalog/boot-orchestration`	bearer	pinned
`GET`	`/api/re/catalog/diode-voltage`	bearer	pinned
`GET`	`/api/re/catalog/dspic-frames`	bearer	pinned
`GET`	`/api/re/catalog/eeprom/bhb-skus`	bearer	pinned
`GET`	`/api/re/catalog/firmware-stratum-matrix`	bearer	pinned
`GET`	`/api/re/catalog/fpga-registers`	bearer	pinned
`GET`	`/api/re/catalog/index`	bearer	pinned
`GET`	`/api/re/catalog/luxos-network-exposure`	bearer	pinned
`GET`	`/api/re/catalog/luxos-rest-commands`	bearer	pinned
`GET`	`/api/re/catalog/s21-fixture-production-warnings`	bearer	pinned
`GET`	`/api/re/catalog/thermal-model`	bearer	pinned
`GET`	`/api/re/catalog/vnish-rest-endpoints`	bearer	pinned

Diagnostics and debug

Hacker-mode surface. Every /api/debug/* path returns 403 outside Hacker mode.

Diagnostics and debug — 36 paths, 38 operations
Method	Path	Auth	Route snapshot
`POST`	`/api/debug/asic-command`	bearer	pinned
`POST`	`/api/debug/chip/frequency`	bearer	pinned
`POST`	`/api/debug/chip/voltage`	bearer	pinned
`GET POST`	`/api/debug/i2c`	bearer	pinned
`GET`	`/api/debug/log`	bearer	pinned
`POST`	`/api/debug/pid-params`	bearer	pinned
`GET`	`/api/debug/pid-state`	bearer	pinned
`POST`	`/api/debug/psu/control`	bearer	pinned
`GET POST`	`/api/debug/registers`	bearer	pinned
`GET`	`/api/diagnostics/board-health/report`	bearer	pinned
`GET`	`/api/diagnostics/board-health/result`	bearer	pinned
`POST`	`/api/diagnostics/board-health/start`	bearer	pinned
`GET`	`/api/diagnostics/board-health/status`	bearer	pinned
`GET`	`/api/diagnostics/chain`	bearer	pinned
`GET`	`/api/diagnostics/chip-health/report`	bearer	pinned
`GET`	`/api/diagnostics/chip-health/result`	bearer	pinned
`POST`	`/api/diagnostics/chip-health/start`	bearer	pinned
`GET`	`/api/diagnostics/chip-health/status`	bearer	pinned
`GET`	`/api/diagnostics/error_vocab`	bearer	pinned
`GET`	`/api/diagnostics/failure_modes`	bearer	pinned
`POST`	`/api/diagnostics/hashreport/cancel`	bearer	pinned
`GET`	`/api/diagnostics/hashreport/report`	bearer	pinned
`GET`	`/api/diagnostics/hashreport/result`	bearer	pinned
`POST`	`/api/diagnostics/hashreport/start`	bearer	pinned
`GET`	`/api/diagnostics/hashreport/status`	bearer	pinned
`GET`	`/api/diagnostics/logs/manifest`	bearer	pinned
`GET`	`/api/diagnostics/recovery_actions`	bearer	pinned
`GET`	`/api/diagnostics/reports/recent`	bearer	pinned
`GET`	`/api/diagnostics/sensor_outlier`	bearer	pinned
`GET`	`/api/diagnostics/shares/local_rejects`	bearer	pinned
`GET`	`/api/diagnostics/state_machine`	bearer	pinned
`GET`	`/api/diagnostics/troubleshoot/asic-comm`	bearer	pinned
`GET`	`/api/diagnostics/troubleshoot/fpga`	bearer	pinned
`GET`	`/api/diagnostics/troubleshoot/i2c-scan`	bearer	pinned
`GET`	`/api/diagnostics/troubleshoot/network`	bearer	pinned
`GET`	`/api/diagnostics/troubleshoot/psu`	bearer	pinned

Everything else

Paths that do not belong to a family large enough to name.

Everything else — 3 paths, 3 operations
Method	Path	Auth	Route snapshot
`GET`	`/api/competitive/readiness`	bearer	pinned
`GET`	`/api/env/recipe`	bearer	pinned
`GET`	`/api/log/backup`	bearer	pinned

Where each route lives in the source

Because the success shapes are not derived, the handler is the documentation. Every operation in the OpenAPI document carries an x-dcent-source field naming the file that registers it; here is the same information as a map. rest.rs is the bulk of the router, and the files under routes/ are the newer surfaces that were split out of it.

Which file in `dcentrald` registers each path
Source file	Paths
`dcentrald/dcentrald-api/src/rest.rs`	187
`dcentrald/dcentrald-api/src/routes/re_catalog.rs`	20
`dcentrald/dcentrald-api/src/routes/profiles.rs`	6
`dcentrald/dcentrald-api/src/routes/restore_to_stock.rs`	4
`dcentrald/dcentrald-api/src/routes/stock_parity.rs`	4
`dcentrald/dcentrald-api/src/routes/jd.rs`	3
`dcentrald/dcentrald-api/src/routes/sv2.rs`	3
`dcentrald/dcentrald-api/src/routes/boot_phase.rs`	2
`dcentrald/dcentrald-api/src/routes/perf.rs`	2
`dcentrald/dcentrald-api/src/routes/rolling_metrics.rs`	2
`dcentrald/dcentrald-api/src/routes/vf_profile.rs`	2
`(manual insert in rest/late.rs)`	1
`dcentrald/dcentrald-api/src/routes/audit_log.rs`	1
`dcentrald/dcentrald-api/src/routes/autotuner_quota.rs`	1
`dcentrald/dcentrald-api/src/routes/chip_health.rs`	1
`dcentrald/dcentrald-api/src/routes/donation.rs`	1
`dcentrald/dcentrald-api/src/routes/pvt_table.rs`	1

Paths, methods, auth exemptions and snapshot marks are extracted from the dcentrald axum router by a committed script and re-derived for this revision; the surface map, session limits and claims-contract fields are read from the public GPL-3.0 repository (commit 6f61603 for the claims contract). Ports were re-derived from server.py and the daemon’s own module documentation. No endpoint, response body or schema has been invented for this page, and no live response from production hardware has been observed. Rows are labelled Verified / Inferred / Unknown per the project’s locked evidence vocabulary.