Tether’s effort to integrate artificial intelligence into Bitcoin mining centers on a critical human decision: who may authorize a machine to alter its own operations? The MDK v0.11 reference agent halts its device-action tool pending human approval, while each site must determine who is entitled to grant that permission.
This distinction gained prominence on October 24, when Tether announced commitments from 15 industry participants to build and maintain integrations with its Mining Development Kit, an open-source framework linking mining hardware, pools, and applications. A shared interface can give software a consistent path to disparate systems, though the authority to act still depends on the individual installation.
The v0.11 reference does not specify which code QVAC or participating mines have deployed. Newer code on the main branch introduces caller restrictions missing from that tagged release. Consequently, site control hinges on both who may issue commands and which upstream software the mine chooses to adopt.
From Integrations to Equipment Commands
Tether’s participant list includes BITMAIN, MicroBT, Canaan, Bitdeer, Foundry Digital, and Luxor Technology, along with ACME Swisstech, Elektron Energy, EMCD, F2Pool, Heatbit, OCEAN, Proto, SpiderPool, and Stratum V2.
Under the announced arrangement, participants will build and maintain Workers—software that converts a company’s existing hardware, pool, or system interface into MDK’s common language. Each company selects the functions it exposes. An application can then use that interface instead of requiring a separate integration for every manufacturer.
Tether notes that its QVAC mining agent already runs on MDK as an early demonstration. The announcement provides no figures on participating fleet capacity, share of Bitcoin hashrate, or measured savings.
The v0.11 reference site’s action tool accepts one named device and offers two operations: rebooting it or changing its power mode. Available power-mode options are low, normal, high, and sleep, with the handler verifying which modes a device supports before transmitting the command.
These capabilities represent the example’s scope, not a ceiling for every application or Worker built with MDK.
The reference tool is explicitly classified as a write operation. When the agent’s execution loop encounters a tool requiring approval, it emits a pending-approval event and pauses before invocation. A rejection blocks the call. The Gateway agent plugin specifies a default two-minute approval window, after which an unanswered request defaults to rejection.
The v0.11 plugin binds sessions and approvals to the identity that created them. If no user identity is supplied, requests fall back to a shared local operator, meaning the approval pause does not distinguish one person from another.
A mine deploying this version must therefore attach its own identity verification to the approval surface. The individual permitted to view equipment data and the individual permitted to approve a power-mode change must each hold permissions established by the site.
The same deployment logic applies to data. The agent reference supports both local QVAC models and hosted endpoints; with a hosted provider, prompts and tool results leave the site for that provider’s infrastructure. Running an agent locally and selecting where its model executes are separate configuration decisions.
The Command Path Changes the Permission Check
The tagged v0.11 security blueprint distinguishes direct commands from approval-gated actions. Direct command.request calls carry no Kernel-side permission check. The separate action.push route relies on permissions supplied by an admitted backend caller, so the Gateway—the application’s entry point—must derive those permissions from a verified user.
The Kernel coordinates requests between applications and Workers. A key permitting a backend process to contact it establishes that process’s admission, but it does not identify the human requesting a change.
The v0.11 Worker implementation introduces another boundary: its network command interface dispatches requests without checking the caller’s key. The tagged blueprint warns that any peer able to reach a Worker and address its public key can submit commands directly. Whether that exposure exists depends on the network and installation; it does not confirm that a particular mine exposes its Workers.
Accordingly, an approval within the reference chat covers that specific agent interaction. Restricting every route to equipment requires controls across all other entry points as well.
Newer repository code alters this picture. GitHub references checked on October 24 map v0.11.0 to commit fae8fbce052a and the main branch to 35c144f240f0. At the latter pinned snapshot, Workers require admitted caller keys unless an explicit allowAll setting is enabled.
In the tagged v0.11.0 release, the WorkerRuntime’s RPC entry point performs no caller-key check, making network reachability and site controls material boundaries. In the main snapshot, a nonempty admitted-key set is established at startup, supported by a connection firewall and per-request peer-key check unless allowAll is enabled. With checks active, revocation restricts subsequent requests on existing connections, though it does not cancel work already dispatched.
The v0.12-labelled changelog additionally describes Kernel roles for reading, writing, and administration, opt-in MCP write tools, and declared verification of device state.
The security guide published on October 24 still describes Workers without caller allowlists. An operator must reconcile the guide with the deployed code before accepting either as an accurate description of the site’s protections.
Release Authority Stays with the Project
A mine’s software selection also ties it to MDK’s release governance. The project’s governance document assigns final project authority to the core team, final technical authority over merges, architecture, and release planning to the Lead Maintainer, and final authority over strategic direction and the roadmap to the Community Manager.
An integration commitment does not confer authority over MDK’s releases on any participant. Likewise, authority to merge upstream code does not establish permission to issue commands inside a mine.
This makes reviewing updates an operating responsibility. The v0.11 security policy states that fixes are handled on a best-effort basis for the latest main commit, while older commits and tagged releases may not receive them. Selecting a version pins the site’s code baseline, while configuration determines how that code is used. Subsequent changes require their own review.
The newer changelog’s distinction between accepting a command and confirming the resulting device state illustrates what is at stake. Permission to send a power-mode instruction and evidence that the machine reached the requested mode answer separate operational questions.
A mine’s autonomy depends on who can approve writes, which backend programs can reach equipment, and who adopts software updates.
