From f34e105f95479e3a888804f072d4b1ac8057aa72 Mon Sep 17 00:00:00 2001 From: "Claude (regen agent)" Date: Wed, 15 Apr 2026 14:19:11 +0000 Subject: [PATCH] docstring: clarify that `faucet` is not reachable on deployed public chains MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The existing comment on `faucet()` reads: /// Facility extrinsic for user to get taken from faucet /// It is only available when pow-faucet feature enabled /// Just deployed in testnet and devnet for testing purpose The third line is inaccurate as of today's deployed runtimes. The dispatchable is gated behind `#[cfg(feature = "pow-faucet")]`, and the repository's `Dockerfile` enables that feature only in the `local_builder` stage (see `Dockerfile` line ~86: `cargo build --workspace --profile release --features "pow-faucet"`). The runtimes deployed to the public `test` (testnet) and `devnet` networks are built without that feature, so this call is compiled out of the `Call` enum and does not appear in chain metadata on either network. This was verified empirically by a subxt metadata dump against `wss://test.finney.opentensor.ai:443` and `wss://dev.chain.opentensor.ai:443`: SubtensorModule (pallet index 7) exposes 70+ calls but no `faucet`, and a cross-pallet scan for `faucet|drip|tao` returned only three unrelated `AdminUtils::sudo_set_tao_flow_*` parameter setters. The confusion this docstring causes is not theoretical: the downstream `btt` CLI shipped a `wallet faucet` command that called this dispatchable by name and silently failed on testnet with `Call with name 'faucet' not found in pallet 'SubtensorModule'`. The command has now been removed from `btt` (see https://github.com/ErgodicLabs/btt/pull/80), but the upstream docstring that misled it is still in place and will mislead the next reader who tries to do the same thing. This PR replaces the stale third line with an accurate, verifiable statement of which runtimes actually carry the call, plus a pointer to the documented end-user path for obtaining tTAO on testnet (ask in the Bittensor Discord, per `bittensor-subnet-template/docs/running_on_testnet.md` §4). No code change, no runtime change, no feature change — only the comment gets honest. See also: https://github.com/opentensor/subtensor/issues/2591 --- pallets/subtensor/src/macros/dispatches.rs | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/pallets/subtensor/src/macros/dispatches.rs b/pallets/subtensor/src/macros/dispatches.rs index b098b58425..a03db788e6 100644 --- a/pallets/subtensor/src/macros/dispatches.rs +++ b/pallets/subtensor/src/macros/dispatches.rs @@ -1209,9 +1209,22 @@ mod dispatches { Self::do_register_network(origin, &hotkey, 1, None) } - /// Facility extrinsic for user to get taken from faucet - /// It is only available when pow-faucet feature enabled - /// Just deployed in testnet and devnet for testing purpose + /// Facility extrinsic for user to get taken from faucet. + /// + /// Only present in runtimes built with the `pow-faucet` cargo feature, + /// which this repository's `Dockerfile` enables only in the + /// `local_builder` stage. The deployed `test` (testnet) and `devnet` + /// runtimes are built **without** this feature, so this dispatchable + /// is compiled out of the `Call` enum and is not reachable on-chain + /// on any public Opentensor network. Clients that want a working + /// on-chain faucet must run a local `node-subtensor` built with + /// `--features pow-faucet`. + /// + /// See also the documented user path for obtaining tTAO in + /// , + /// `docs/running_on_testnet.md` §4 ("Get faucet tokens"), which + /// instructs testnet users to request tokens via the Bittensor + /// Discord community rather than calling this extrinsic. #[pallet::call_index(60)] #[pallet::weight((Weight::from_parts(91_000_000, 0) .saturating_add(T::DbWeight::get().reads(27))