Paolo Ardoino’s plan to bring artificial intelligence into Bitcoin mining depends on a basic question: who is allowed to approve a machine changing what it is doing?
Tether’s MDK v0.11 reference agent pauses before using a tool that can act on mining equipment, waiting for human approval. But the software does not decide which person is entitled to provide that approval. That responsibility must be established by the mine operating it.
The issue comes as Tether announced on October 24 that 15 industry participants had committed to building and maintaining integrations with its Mining Development Kit (MDK), an open-source framework linking mining equipment, pools and applications.
The participants are BITMAIN, MicroBT, Canaan, Bitdeer, Foundry Digital, Luxor Technology, ACME Swisstech, Elektron Energy, EMCD, F2Pool, Heatbit, OCEAN, Proto, SpiderPool and Stratum V2.
Under the arrangement, each company will develop and maintain a Worker. These software components translate a company’s existing hardware, pool or system interface into MDK’s common language, allowing applications to connect through one interface rather than requiring a separate integration for every manufacturer.
Tether says its QVAC mining agent is already running on MDK as an early demonstration. The announcement does not state the capacity of the participating fleets, their share of Bitcoin hashrate or any measured savings.
What the reference software can do
The v0.11 reference site’s action tool accepts one named device and provides two operations: rebooting it or changing its power mode. The available settings are low, normal, high and sleep, with the handler checking which options the device supports before sending a command.
Those functions describe the example tool, not a limit on what other applications or Workers could be built with MDK.
The tool is classified as a write operation. When the agent’s execution loop reaches an approval-gated tool, it creates a pending-approval event and stops before making the call. A rejection prevents the command from being sent. The Gateway agent plugin sets a default approval period of two minutes; if no answer arrives, the request is rejected.
In v0.11, sessions and approvals are linked to the identity that created them. If no user identity is supplied, requests are made through a shared local operator account. That configuration cannot distinguish between different human approvers.
A mine using this version would therefore need to connect its own identity and permission checks to the approval process. Access to equipment data and authority to approve a power-mode change may need to be assigned to different people.
The same decisions apply to data handling. The agent reference supports local QVAC models and hosted endpoints. If a hosted provider is selected, prompts and tool results leave the site and are sent to the provider’s host. Running the agent locally and deciding where its model operates are separate configuration choices.
Software versions and access controls
The tagged v0.11 security blueprint separates direct commands from approval-gated actions. `command.request` has no Kernel-side permission check, while `action.push` relies on permissions supplied by an admitted backend caller. The Gateway, as the application’s entry point, must derive those permissions from a verified user.
The Kernel coordinates requests between applications and Workers. A key that allows a backend process to contact it proves that the process has been admitted, but does not identify the human requesting a change.
The v0.11 Worker implementation creates another boundary. Its network command interface dispatches requests without checking the caller’s key. The security blueprint warns that a peer able to reach a Worker and address its public key can submit commands directly. Whether that exposure exists depends on the mine’s network and installation; it does not show that any particular mine has exposed its Workers.
An approval in the reference chat therefore covers only that agent interaction. Other routes to the equipment require separate controls.
The newer repository code changes the position. GitHub references checked on October 24 map `v0.11.0` to commit `fae8fbce052a` and `main` to `35c144f240f0`. At the pinned `main` snapshot, Workers require admitted caller keys unless an explicit `allowAll` setting is enabled.
The `v0.12`-labelled changelog also describes Kernel roles for reading, writing and administration, opt-in MCP write tools, and declared verification of device state. However, the published security guide retrieved on October 24 still describes Workers without caller allowlists. Operators must match the guide to the code actually deployed before treating it as a description of their protections.
Governance and responsibility
MDK’s governance document gives the core team final authority over the project, 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 give a participant control over MDK releases. Equally, authority to merge upstream code does not grant permission to issue commands inside a mine.
The v0.11 security policy says 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 fixes the site’s code baseline, but configuration determines how that code is used. Later changes require their own review.
The newer changelog’s distinction between accepting a command and confirming that the device reached the requested state highlights two separate operational questions. Permission to send a power-mode instruction does not prove that the machine adopted it.
A mine’s autonomy will therefore depend on who can approve write operations, which backend programs can reach its equipment and who is responsible for adopting software updates.
