Bittensor Validation with Proxy Pallets

By Wesley Graham, Infrastructure Engineer

At Unit 410, we prioritize security and efficiency for the dozens of networks we support (Bittensor included). Our team operates using advanced infrastructure, secure practices, and custom-built tools as illustrated by our proxy pallet solution.

Bittensor Proxy Pallet

In April 2024, proxy pallet support was added to the Bittensor network. The proxy pallet is a substrate module that allows one account (a “proxy”) to act for another (“proxied”) account with specific permissions. This is useful for cold wallet users seeking to delegate execution of certain actions to another key.

Using the proxy pallet, a coldkey can designate a proxy account to perform specific actions for the coldkey. These permissions are (link):

Owner
NonCritical
NonTransfer
Senate
NonFungible
Triumvarate
Governance
Staking
Registration
Transfer
SmallTransfer
RootWeights
Childkeys
SudoUncheckedSetCode

Unit 410 Proxy Support

ProxyArchitecture NonProxyArchitecture

A proxy can be utilized in place of frequently utilizing asset-bearing keys for common, low-risk operations like childkeying to subnets.

In the above model, a user’s coldkey retains full control and ownership, while the proxy only receives CHK-related permissions. If the above proxy key is compromised, asset transfers are programmatically disabled - which cuts off the potential for coldkey asset loss.

The recent Bybit hack illustrates the importance of transaction preparation and review - and illustrates the unintended consequences that transaction validation errors can lead to. While proxy-type accounts do not solve for this entirely, they do limit the general use of cold, asset-bearing accounts - with necessary spending protections in place to avoid catastrophe in the case of account compromise. In the case of Bybit, if the compromised multisig were a proxy account without spending permissions, attackers would not be able to siphon assets via malicious transaction bytes.

Proxy Example

// Import dependencies
const { ApiPromise, WsProvider, Keyring } = require('@polkadot/api');
const { cryptoWaitReady } = require('@polkadot/util-crypto');

// Used to represent "max balance" (100% of validator balance) being delegated to a single child key on a subnet.
const MAX_U64 = BigInt('18446744073709551615')

async function main() {
    const mnemonic = process.env.PROXY_ACCOUNT_MNEMONIC;
    const netuid = parseInt(process.env.NETUID, 10); // NetUID from environment
    const hotKey = process.env.HOT_KEY_ADDRESS;
    const coldKey = process.env.COLD_KEY_ADDRESS;
    const childKey = process.env.CHILD_KEY_ADDRESS;
    const providerEndpoint = process.env.PROVIDER_ENDPOINT;

    // Validation: Ensure all required environment variables are provided
    if (!mnemonic) {
        console.error("Error: MNEMONIC must be provided as an environment variable.");
        process.exit(1);
    }

    if (isNaN(netuid)) {
        console.error("Error: NETUID must be provided as a valid number environment variable.");
        process.exit(1);
    }

    if (!hotKey) {
        console.error("Error: HOT_KEY must be provided as an environment variable.");
        process.exit(1);
    }

    if (!coldKey) {
        console.error("Error: COLD_KEY must be provided as an environment variable.");
        process.exit(1);
    }

    if (!childKey) {
        console.error("Error: CHILD_KEY must be provided as an environment variable.");
        process.exit(1);
    }

    if (!providerEndpoint) {
        console.error("Error: PROVIDER_ENDPOINT must be provided as an environment variable.");
        process.exit(1);
    }

    // Initialize Polkadot.js and wait for crypto initialization
    await cryptoWaitReady();
    const provider = new WsProvider(providerEndpoint);
    const api = await ApiPromise.create({ provider });

    // Initialize keyring and accounts
    const keyring = new Keyring({ type: 'sr25519' });
    const proxy = keyring.addFromUri(mnemonic); // Replace with Proxy seed

    console.log(`Proxy Address: ${proxy.address}`);
    console.log(`ColdKey Address: ${coldKey}`)

    // Use proxy call for setting children
    const children = [[MAX_U64, childKey]]
    const chkTx = api.tx.subtensorModule.setChildren(hotKey, netuid, children);

    console.log('chkTx', chkTx.toHuman());

    const proxyCall = api.tx.proxy.proxy(coldKey, 'ChildKeys', chkTx);

    console.log('proxyCall', proxyCall.toHuman());

    console.log(`Sending CHK transaction for netUID ${netuid}.`);

    const proxyCallHash = await proxyCall.signAndSend(proxy);

    console.log(`Bittensor chk successfully: ${proxyCallHash.toHex()}`);
}

main().catch(console.error).finally(() => process.exit());

Note that the above script does not require a coldkey mnemonic - only a proxy account mnemonic. This means that coldkey assets are not at risk in this transfer - only proxy actions can take place.

Multi-Proxy Architecture

Childkeys follow a one-to-many relationship with proxy accounts. Proxy accounts can be uniquely used for different operations (e.g., one account for Staking, another for Childkeying). A coldkey’s active proxies can be monitored using the proxy::proxies(address) method.

api.query.proxy.proxies(coldKeyAddress, (result) => { console.log("Current proxies:", result.toHuman()); });

Proxy Risk Mitigations

While proxy accounts do provide enhanced security around direct asset loss, they should still be used with caution. For example, insecure usage of the “Staking” role can lead to the swapping of arbitrary quantities of alpha tokens (at high slippage), and insecure usage of the “Registration” role can lead to burned registration fees. Secure key practices around proxy accounts remain a top priority when using proxies.

If a proxy account compromise is detected, proxy::removeProxy(delegate, proxyType, delay) may be used to revoke permissions.

async function removeProxy() {
    const { ApiPromise, WsProvider, Keyring } = require('@polkadot/api');
    const { cryptoWaitReady } = require('@polkadot/util-crypto');

    // Environment variables
    const mnemonic = process.env.COLD_KEY_MNEMONIC; // Coldkey mnemonic (should be securely stored)
    const proxyAddress = process.env.PROXY_ADDRESS; // Address of the proxy being removed
    const providerEndpoint = process.env.PROVIDER_ENDPOINT; // Bittensor Substrate node

    if (!mnemonic || !proxyAddress || !providerEndpoint) {
        console.error("Error: Missing required environment variables.");
        process.exit(1);
    }

    // Initialize crypto
    await cryptoWaitReady();
    const provider = new WsProvider(providerEndpoint);
    const api = await ApiPromise.create({ provider });

    // Initialize keyring and coldkey account
    const keyring = new Keyring({ type: 'sr25519' });
    const coldKey = keyring.addFromUri(mnemonic);

    console.log(`Removing proxy ${proxyAddress} from coldkey ${coldKey.address}`);

    // Create removeProxy transaction
    const removeProxyTx = api.tx.proxy.removeProxy(proxyAddress, 'Any', 0);

    console.log('removeProxyTx:', removeProxyTx.toHuman());

    // Sign and send transaction
    const removeProxyHash = await removeProxyTx.signAndSend(coldKey);

    console.log(`Proxy removed successfully. Tx Hash: ${removeProxyHash.toHex()}`);
}

removeProxy().catch(console.error).finally(() => process.exit());

Conclusion

At Unit 410, we take a detailed approach to Bittensor validation. By combining performant hardware, secure practices, and innovative tooling, we have engineered solutions designed to maximize stability and uptime.

If topics and insights like this are interesting to you, check out our open roles here.