Key features and design points include:

TAO-Only Liquidity & Yield: Liquidity providers (LPs) supply only TAO tokens to Tenex’s pool. In return they earn sustainable yields from two sources: (1) continuous Bittensor miner emission rewards (just as if their TAO were staked on the network), and (2) a share of Tenex’s protocol fees (from trading, borrowing, and liquidation activities). Because the pool is single-sided (TAO only), LPs are not exposed to impermanent loss against another asset, and they don’t directly hold the volatile subnet tokens (alpha) – they benefit purely from TAO rewards and fees.

Leveraged Long Positions: Traders on Tenex can deposit TAO as collateral and then borrow additional TAO (up to 10× leverage) based on their eligibility, using the borrowed TAO to automatically purchase a target subnet’s alpha token. By doing so, a trader effectively goes long on the subnet token with amplified exposure. For example, a 5× leverage means the user’s position value in the subnet’s token is five times their own collateral. Tenex enforces a health ratio on each position – essentially a minimum collateral-to-debt ratio (initial margin ~120%, maintenance margin ~110%) – to manage risk. If the position’s value drops such that this ratio falls below the threshold, it gets liquidated to protect the liquidity pool.

Long-Only Design: Tenex deliberately does not allow shorting (no borrowing of assets to sell). This design choice is meant to support the Bittensor ecosystem by preventing any leveraged short pressure on dTAO (dynamic TAO) or subnet token markets. Traders can only take long positions, i.e. bets on the upward movement of subnet token values. This ensures that all borrowed TAO is ultimately used to buy subnet tokens, creating buy pressure or liquidity for those tokens rather than sell pressure.

Tiered Leverage via Tenex Token: Tenex introduces its own Tenex “alpha” token (the subnet’s native token), which serves a utility role in the protocol. Holders of Tenex’s token are placed in tiers that determine their maximum allowed leverage and fee discounts. For example, without holding any Tenex tokens a user might be limited to 2× leverage, whereas holding a certain threshold (e.g. 100k tokens) grants access to 10× leverage and lower trading fees. This creates a mechanism to reward community members: those who acquire and hold the Tenex token can trade with higher leverage and pay reduced fees, aligning incentives for long-term participation.

Dynamic Fees and Buybacks: Tenex employs a dynamic fee structure for both trades and loans: trading fees (around 0.3% per trade by default) can be discounted by tier, and borrowing interest rates adjust based on utilization of the liquidity pool (with a lower base rate when the pool is under-used and higher rates as it becomes more utilized). A portion of all fees (about 90% of protocol revenue) is funneled into an automated buyback program. This means Tenex periodically uses the accrued fees to buy back its own Tenex tokens on the market, which are then slated for vesting or staking, thereby supporting the token’s demand. This buyback loop, combined with governance participation rights for token holders, is intended to bolster the Tenex token’s value and encourage users to invest in the ecosystem long-term.

Safety Mechanisms: Given the inherent risks of leverage, Tenex’s design includes multiple risk controls. It has a “circuit breaker” concept where, for example, if the TAO liquidity pool utilization exceeds 90%, the protocol halts new borrowing to avoid over-leveraging. There are also rate limits on how fast liquidity can be added or removed (to prevent flash loan exploits), slippage limits on trades, and an emergency pause ability that the owners can invoke in extreme scenarios. Additionally, liquidations are handled by incentivized liquidator bots – they receive a cut (40%) of a fixed liquidation fee when they successfully liquidate an unhealthy position, ensuring the system can promptly wipe out risky positions and repay the TAO pool.

Tenex is implemented as a set of smart contracts integrated into Bittensor’s blockchain (Subtensor), along with off-chain scripts for miners and validators. Technically, it’s an EVM-based protocol deployed on Bittensor’s network (Bittensor introduced EVM compatibility in late 2024), meaning Tenex’s logic is written in Solidity and runs on a Bittensor subnet with its own validator set. The architecture is modular and upgradeable, ensuring the system can evolve safely:

The core logic resides in a UUPS upgradeable contract (proxy pattern) called TenexiumProtocol.sol, with separate modules handling specific functions. For example, there’s a PositionManager for opening/closing positions, a LiquidityManager for handling deposits/withdrawals and reward calculations for LPs, a LiquidationManager to execute liquidations, a FeeManager for fee accrual and distribution, and a BuybackManager automating the token buybacks. This modular design improves maintainability and security by isolating critical features into well-defined contracts.

• Tenex natively integrates with Bittensor’s chain through special precompiled interfaces. The contracts include interfaces like IStaking, INeuron, and IMetagraph, which correspond to Bittensor runtime functions. For instance, Tenex’s contracts can call into Bittensor’s staking module – this is how deposited TAO may be staked or how the protocol fetches real-time data about miners and subnet states. A custom PrecompileAdapter module abstracts these calls. This tight Bittensor integration allows Tenex to automatically stake liquidity into Bittensor’s consensus to earn mining rewards, as well as to query subnet token prices or neuron metrics directly on-chain, bridging the DeFi logic with the AI network’s data.
• Backend Components & Tools: The Tenex project provides a Python-based CLI for operations, built on the Bittensor SDK. For example, LPs (nicknamed “miners” in this context) don’t run an AI model; instead, they use the tenex.py script to associate a Bittensor mining key with their EVM wallet and to deposit or withdraw TAO liquidity. This association ties the smart-contract side to a Bittensor hotkey (a miner identity) so that any TAO emissions from Bittensor can be credited to the LP within Tenex. On the validator side, Tenex offers two modes:

1. EVM Validators: One can deploy an Ethereum-based validator contract (essentially the same code as the SubnetManager.sol module) and register it as a validator for Subnet 67. This contract-validator then runs via the provided evm_validator.py script. This approach leverages the EVM environment for validation logic.
2. Normal (Rust) Validators: Alternatively, participants can run a standard Bittensor validation node for Tenex using validator.py. They specify the Tenex subnet ID (netuid 67) and connect to Bittensor’s network (e.g., via the provided Finney network entrypoint). These validators don’t train models like typical AI subnets; rather, their role is to finalize Tenex’s blockchain transactions and maintain consensus on Subnet 67’s state (positions, loans, etc.). Essentially, validators secure the Tenex subnet, producing blocks and updating “weights” (which in an AI context usually measure performance, but here may simply ensure all validators stay in agreement since Tenex’s “commodity” is financial state rather than model output).

• Miner–Validator Architecture: Tenex repurposes Bittensor’s miner/validator framework for a financial application. Here, “miners” are liquidity providers – by depositing TAO, they effectively mine rewards (they receive TAO emissions similar to how miners would for contributing to an AI task). Each LP attaches their deposit to a Bittensor hotkey (identity), and Tenex stakes those TAO into the Bittensor network’s staking mechanism, so the protocol earns the continuous TAO inflation rewards on that stake. Those rewards are then passed back to LPs proportionally, on top of the trading/interest fees they earn. Meanwhile, validators on Subnet 67 perform the usual duties of block production and validation to run the Tenex ledger. They also likely monitor the off-chain price feeds or DEX trades of subnet tokens (since when a leveraged position is opened, Tenex needs to trade TAO for the target subnet token via an on-chain DEX). This means Tenex’s validators are ensuring that trades (swaps between TAO and the specific alpha tokens) execute correctly and that positions/liquidations are processed according to the rules.
• AI Layer (if any): Notably, Tenex is not an AI-serving subnet – it’s a DeFi subnet. Traditional Bittensor subnets have miners that produce AI outputs (like language translation, image recognition, etc.) and validators that score those outputs. In Tenex’s case, the “output” being produced could be considered the financial service (margin positions) and the “quality” is simply whether the protocol is solvent and up-to-date. There is no direct machine learning model being trained or evaluated within Tenex. However, Tenex does interact with the rest of Bittensor’s AI economy in that it creates a new use-case for the TAO token and the subnet tokens. By enabling trading of alpha tokens, Tenex provides liquidity and price discovery for the results of other AI subnets. In short, Tenex is an infrastructure layer on Bittensor that doesn’t provide AI algorithms itself but supports the AI ecosystem by incentivizing investment into subnet tokens (for example, if an AI subnet’s token becomes valuable, traders might long it on Tenex, and LPs will stake more TAO to earn fees from that activity).
• Infrastructure & Tech Stack: The smart contracts leverage OpenZeppelin libraries for security (using patterns like Ownable roles and ReentrancyGuard on external functions). The system is upgradeable (proxy/UUPS), meaning the team can deploy contract upgrades with multi-signature control, which is guarded by time-lock or multisig as a safety measure. Off-chain, the development uses Hardhat and Foundry (as evident in the repo) for testing and deployment scripts. Bittensor’s Subtensor blockchain underpins everything – Subnet 67 is registered on the chain with an owner coldkey (the Tenex team’s address), and it uses Bittensor’s consensus (Yuma) under the hood. Transactions on Tenex (like opening a position or adding liquidity) are essentially transactions on a parachain-like subnet of Bittensor, validated by the Subnet 67 validators and eventually settling to the main chain’s state (which tracks things like total stake and token issuance per subnet).

Overall, the “product” is a combination of on-chain contracts and off-chain processes:

• On-chain: the Tenexium protocol smart contracts that manage balances, positions, borrow limits, and integration points with Bittensor (staking and price feeds).
• Off-chain: the Tenex CLI tools and validator software that allow users to participate (LPs managing their TAO and traders opening/closing positions via the contract’s functions) and validators to keep the subnet running.

This design leverages Bittensor’s strengths (global decentralized network with incentivization) but adds the familiar components of a DeFi margin trading system. By building on Bittensor, Tenex can reward its LPs with the unique “miner emissions” that only Bittensor provides, while enforcing all trades and loans through transparent smart contract code.