Table of Contents
Engy has added Gamma payments for AI inference credits on Bittensor Subnet 53, letting customers fund their accounts from a Bittensor wallet. Each Gamma adds $1 in credit plus a 5% bonus, giving a customer spending 100 Gamma $105 to use on the platform.
The integration follows the Opentensor Foundation’s introduction of Gamma Tokens, a native payment system for Bittensor subnet services. Engy’s implementation connects those onchain credits to an existing inference account, with browser checkout for users and a separate signed-request flow for agents.
Engy serves open AI models through an open GPU network, routing requests to workers running the requested model. Its OpenAI- and Anthropic-compatible interfaces allow developers to use existing clients and tools. Gamma changes how customers fund that service; the payment flow does not replace authentication on Engy’s inference API.
From Gamma Deposits to Inference Credits
Gamma is a dollar-valued service credit held on Bittensor, rather than a token sent to a provider’s wallet. Customers mint it by burning a subnet’s Alpha tokens, either from existing stake or by supplying TAO that buys and burns Alpha. Under Bittensor’s Gamma rules, one Gamma is created for each dollar of burned Alpha value calculated by the protocol.
The Alpha burn occurs when Gamma is minted. Spending Gamma later destroys the credits instead of transferring Gamma, TAO, or Alpha to the service operator. Engy then adds the corresponding inference balance and bonus to the customer’s account after the spend reaches finality on Bittensor.
That creates two distinct balances: the customer’s onchain Gamma deposit and the website credits used to pay for inference. Gamma remains tied to its original subnet and cannot be transferred to another coldkey or converted back into TAO or Alpha.
Each deposit belongs to a coldkey, the wallet account that controls its funds and permissions, and is identified by a dedicated hotkey. The hotkey is an operational signing key that can authorize service requests. Bittensor instructs customers to create a separate deposit hotkey rather than reuse a staking hotkey or coldkey.
For Engy, the deposit must name the spender published by its service. Its service description identifies Subnet 53 and the service hotkey to use with the --service-hotkey option when minting Gamma or changing a deposit’s spender. A deposit configured for a different spender cannot pay Engy until that permission is updated.
Browser Checkout Waits for Finalized Spending
The Gamma checkout flow starts under Credits → Add credits. Customers enter a whole-dollar amount, select Gamma, and connect the browser-wallet account that owns the deposit’s coldkey. The website discovers that account’s deposits on Subnet 53 and displays their spendable Gamma.
After selecting a deposit, the customer reviews the amount and bonus, then confirms the order in the wallet. The wallet signs an order-confirmation transaction with the coldkey and displays the TAO network fee. Private keys remain in the wallet, but the funding account needs enough TAO for that transaction as well as sufficient Gamma and daily spending allowance for the top-up.
Engy verifies the finalized confirmation, submits the Gamma spend, and adds the credits only after that spend is finalized. Signing the order alone does not increase the inference balance, and a rejected or skipped spend adds no credits.
The confirmation transaction must be included in a block before the order’s 30-minute deadline and reach finality. A valid confirmation can still be recovered after the deadline, and an authorized payment continues processing until it succeeds or fails. Engy automatically recovers finalized confirmations even if the checkout dialog is closed. Customers can revisit an unfinished order through View previous payment status rather than immediately creating another payment.
Agent Payments and Spending Permissions
Agents can create an unsigned top-up order by sending {netuid, hotkey, usd} to POST /api/v1/gamma/topups with an Engy account token. That token identifies the account receiving the inference credits; creating the order does not authorize a Gamma deduction.
The agent then signs the exact returned requestBody bytes with the deposit hotkey using btauth/1 authentication and submits those bytes to the returned path. This requires Engy to register the hotkey’s trusted sr25519 or ed25519 signing scheme through support.
The order’s status separates authorization from settlement: ready means the payment is authorized, while credited means the onchain spend finalized and the account balance was updated. Signatures must fall within a window of 10 seconds in the past or two seconds in the future. Retries need a fresh nonce and signature but should reuse the same order ID. If a response is lost, the agent should query that order before opening another one. These endpoints add website credits, not hotkey-based access to inference endpoints.
The spender permission also determines the customer’s exposure. Engy checks each order’s confirmation before spending through its GammaSpend proxy, but Bittensor itself does not verify a customer wallet signature for every deduction. It checks only the named spender, deposit balance, and daily cap.
A compromised proxy key could consume Gamma from deposits naming it as spender, within those balances and caps. Customers can limit that authority with a daily spend cap and stop future spending by changing the deposit’s spender through Bittensor tooling.
