Paolo Ardoino’s push to bring AI into Bitcoin mining has a human decision at its center: who may authorize a machine to change what it is doing? Tether’s MDK v0.11 reference agent pauses its device-action tool for human approval, while the site must establish who is entitled to give it.
That distinction matters as Tether announced commitments from 15 industry participants on October 24 to build and maintain integrations with its Mining Development Kit, an open-source framework connecting mining equipment, pools and applications. A common interface can give software a consistent way to reach different systems. Permission to act still depends on the installation.
The v0.11 example does not establish which code QVAC or participating mines have installed. Newer main-branch code adds caller restrictions absent from that tag. Site control therefore turns on both who may issue commands and which upstream software the mine adopts.
From integrations to equipment commands
Tether’s list includes BITMAIN, MicroBT, Canaan, Bitdeer, Foundry Digital and Luxor Technology. It also names 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 translates a company’s existing hardware, pool or system interface into MDK’s common language. Each company chooses the functions it exposes. An application can then use that interface rather than require a separate integration for every manufacturer.
Tether says its QVAC mining agent already operates on MDK as an early demonstration. The announcement gives no 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: reboot it or change its power mode. The power-mode options are low, normal, high and sleep, with the handler checking which modes that device supports before sending the command.
Those are the example’s capabilities, rather than a ceiling on every application or Worker someone could build with MDK.
The reference tool is explicitly marked as a write. When the agent’s execution loop encounters a tool classified as requiring approval, it emits a pending-approval event and pauses before invoking it. Rejection prevents the call. The Gateway agent plugin documents a default two-minute approval window, with an unanswered request resolving to rejection.
The v0.11 plugin binds sessions and approvals to the identity that created them. When no user identity is supplied, requests use a shared local operator. In that configuration, an approval pause does not distinguish one human from another.
A mine assembling this version must therefore connect its own identity checks to the approval surface. The person allowed to view equipment data and the person allowed to approve a power-mode change need permissions established by the site.
The same deployment choice applies to data. The agent reference supports local QVAC models and hosted endpoints; with a hosted provider, prompts and tool results leave the site for that endpoint’s host. Running an agent locally and choosing where its model runs 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 have no Kernel-side permission check. The separate action.push route uses permissions supplied by an admitted backend caller, so the Gateway, the application’s entry point, must derive them from a verified user.
Here, the Kernel coordinates requests between applications and Workers. A key allowing a backend process to contact it establishes that process’s admission. It does not identify the human asking for a change.
The v0.11 Worker implementation adds another boundary to consider: its network command interface dispatches requests without checking the caller’s key. The tagged blueprint warns that a peer able to reach a Worker and address its public key can submit commands directly. That exposure depends on the network and installation; it does not establish that a particular mine exposes its Workers.
Consequently, an approval in the reference chat covers that agent interaction. Restricting every route to equipment requires controls around the other entry points as well.
The newer repository code changes this picture. GitHub’s references checked October 24 map v0.11.0 to commit fae8fbce052a and main to 35c144f240f0. At the latter pinned snapshot, Workers require admitted caller keys unless an explicit allowAll setting is enabled.
| Software examined | Worker caller check | Operating implication |
|---|---|---|
| Tagged v0.11.0, fae8fbce052a | No caller-key check in WorkerRuntime’s RPC entry point. | Network reachability and site controls are material boundaries. |
| Main snapshot, 35c144f240f0 | Nonempty admitted-key set at startup, connection firewall and per-request peer-key check, unless allowAll is enabled. | With checks active, revocation restricts subsequent requests on existing connections. It does not establish cancellation of dispatched work. |
Its v0.12-labelled changelog also describes Kernel roles for reading, writing and administration, opt-in MCP write tools and declared verification of device state.
Meanwhile, the published security guide retrieved October 24 still describes Workers without caller allowlists. An operator needs to match the guide to the deployed code before treating either as the description of a site’s protections.
Release authority stays with the project
A mine’s choice of software also connects it to MDK’s release governance. The project’s governance document gives the core team final project authority, the Lead Maintainer final technical authority over merges, architecture and release planning, and the Community Manager final authority over strategic direction and the roadmap.
An integration commitment does not itself grant a participant authority over MDK’s releases. Equally, authority to merge upstream code does not establish permission to issue commands inside a mine.
That makes reviewing updates an operating responsibility. The v0.11 security policy says fixes are handled on a best-effort basis for the latest main commit and that older commits or tagged releases may not receive them. Choosing a version pins the site’s code baseline, while configuration determines how that code is used. Subsequent changes need their own review.
The newer changelog’s distinction between command acceptance and confirmation of 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 different operational questions.
A mine’s autonomy depends on who can approve writes, which backend programs can reach equipment, and who adopts software updates.
