Merit’s incentive mechanism revolves around a novel interplay between its miners and validators to measure and reward cross-network activity. The subnet operates as follows:

• Miner Role: A miner on Merit must first register a hotkey (a Bittensor key that identifies a miner) on subnet 73 like they would on any subnet. However, to earn meaningful rewards on Merit, that miner must also be actively mining on many other Bittensor subnets. There is no heavy AI task to perform on Merit itself; rather, the “work” miners do is their service on other subnets. The only direct task in Merit is proving they are online and responsive (a liveness check). Essentially, Merit miners are multi-subnet participants – they run nodes on various subnets and then join Merit to get rewarded for that broad activity.
• Validator Role: Validators on Merit carry out the scoring and reward assignment. Every epoch (a cycle in Bittensor’s consensus, e.g. each block or a set number of blocks), each Merit validator gathers data about all miners registered in Merit and evaluates their cross-subnet participation. The process can be summarized in steps:

1. Network Data Fetch: The validator fetches the global Bittensor network info for the epoch. This includes information on all active subnets and possibly the recent incentive earnings or activity of miners in those subnets.
2. Cross-Subnet Scan: For each miner (hotkey) on Merit, the validator checks every other active subnet (excluding the Root subnet UID 0 and Merit itself UID 73) to determine the miner’s presence and rewards in those subnets. In practice, this means looking up whether that hotkey earned incentives in subnet 1, 2, 4, 5, … etc. during the recent period. If the miner was active and earned rewards on a given subnet, that counts toward their participation.
3. Score Calculation (BMPS): The validator sums up all the incentives found for that miner across the other subnets and then divides by the number of subnets considered (total active subnets minus 2 for Root/Merit). This yields an average incentive per subnet. It then multiplies by a scaling factor (100,000) to produce the Bittensor Miner Participation Score (BMPS) for the miner. The BMPS is essentially a numeric score representing how well that miner is doing, on average, across the whole network’s subnets.
4. Liveness Check (Ping): Next, the validator performs a liveness test on the miner. Merit uses a TOTP-secured ping mechanism: the validator sends a challenge to the miner and expects a correct time-based one-time password in response. Each miner has a secret (seeded by its hotkey) that they use to generate a time-based code, and the validator can verify this code to confirm the miner is truly online and responsive. This TOTP (Time-based One-Time Password) approach ensures the ping response is not something that can be faked or replayed – the miner must produce the correct code at that moment, proving its identity and liveness. Moreover, responses are type-checked to avoid any invalid or garbage data. If the miner fails to respond correctly to the ping, the validator will treat them as offline for that epoch.
5. Ping Adjustment: Merit’s scoring gives a strong penalty for being offline. If the miner did not respond to the ping, the validator sets that miner’s BMPS to 0 for the epoch (i.e. no reward if you’re not online). On the other hand, miners who respond get to keep their calculated score. (Merit is calibrated such that the ping itself gives only a minor reward component – being online is necessary but not sufficient for high rewards. Almost all of a miner’s score comes from real work on other subnets, with just a small bonus for maintaining liveness.)
6. Weight Submission: After computing BMPS for every miner and applying the liveness adjustments, the validator normalizes the scores into weight values and submits these weights on-chain. In Bittensor, validator weight submissions determine how the subnet’s token emissions are divided among miners. Thus, a miner with a higher BMPS (as computed by most validators) will receive a greater share of Merit’s block rewards, whereas a miner with zero score (e.g. inactive or offline) receives nothing from Merit for that period.

Multiple validators on Merit perform this process independently. Bittensor’s Yuma consensus will aggregate their submitted weights to finalize the reward distribution. Notably, Merit’s incentive mechanism is dynamic and runs continuously each epoch – validators refresh all miner scores each round without needing any manual resets. This means the system quickly reflects changes: if a miner suddenly expands to more subnets (or drops offline), their Merit rewards will adjust in the very next cycle.

Key distinguishing mechanics of Merit include its cross-subnet incentive averaging and the TOTP-secured ping: Miners must be active across many subnets to maximize rewards (being a top performer in just one subnet won’t maximize your Merit score), and they cannot just register and disappear – they must prove ongoing presence via secure pings. This ensures Merit truly rewards breadth of contribution and consistent uptime. The scoring is also hotkey-specific, meaning each miner identity is scored on its own merits – you cannot combine or average scores across multiple hotkeys owned by one person. In summary, Merit validators serve as “network-wide talent scouts,” grading each miner on broad participation and weeding out those not actually online, then rewarding those who excel across the board.

Product Features and Outputs

From a user or network perspective, Merit’s “product” is a reputation and reward system rather than a traditional AI service. The subnet doesn’t provide an API to answer questions or perform inference; instead, it provides a scoring service (BMPS/BPS) and a corresponding token reward stream for miners based on that score. In effect, Merit produces a network-wide performance metric for miners:

• The Bittensor Miner Participation Score (BMPS) – sometimes simply called the Bittensor Participation Score (BPS) in community discussions – is the core output. This score condenses a miner’s multi-subnet activity into a single number. A high BMPS indicates the miner is contributing meaningfully across many subnets, whereas a low score means narrow or no participation.
• Merit Token Emissions: Like other subnets, Merit receives a portion of Bittensor’s block reward (TAO emissions) and distributes these to its miners and validators. Thus, the “product” for miners is actually additional TAO token earnings allocated by the Merit subnet. These earnings are proportional to the weights (which are derived from BMPS) that validators set. Essentially, Merit functions as an incentive pool that pays miners for their ecosystem-wide work.

In terms of tools or interfaces provided, Merit is fully integrated into the Bittensor ecosystem:

• Open-Source Mining/Validating Software: The Merit team has released software for miners and validators (open-source on GitHub) to participate in subnet 73. Miners run a Python script/module (merit.scripts.run_miner) which handles responding to Merit pings and registering on the subnet, and validators run run_validator which executes the scoring algorithm each epoch. These scripts and the underlying framework constitute the reference implementation of Merit’s protocol – effectively a toolset that miners/validators use to interface with the subnet.
• No Separate End-User App: There is no standalone end-user application for Merit (for example, no web app where a normal user would query Merit for AI output – since its output is a score, not an AI service). However, the data Merit produces (scores and reward distributions) can be observed via Bittensor’s explorers and dashboards. Community-built dashboards (like TaoStats or Backprop’s dTAO Terminal) list Merit (SN-73) and show metrics like its miners, validators, and token statistics. This allows the community to monitor Merit’s performance and the “Merit scores” of various miners indirectly.
• APIs and Integration: Merit doesn’t expose a bespoke API of its own beyond the standard Bittensor RPC interface that all subnets use. Validators call the ping endpoint and gather data via the Bittensor protocols, which are part of the Bittensor SDK. For developers or researchers, the open-source code provides insight into how to calculate BMPS, which could be repurposed in analysis tools. For example, delegators (TAO stakers) might use Merit’s public data to inform decisions – a high Merit score could signal a miner worth delegating to, because it implies broad contributions.

Overall, Merit provides a framework for cross-network meritocracy within Bittensor. It enables what we might call a “reputation token”: while not a separate cryptocurrency, the Merit rewards (paid in TAO) are effectively backing a quantitative reputation (the BMPS). The subnet thereby empowers other ecosystem services by highlighting who the most active and valuable miners are. In the future, this concept could be extended – for instance, one could imagine a Merit leaderboard or integration where the Bittensor governance or Root subnet takes Merit scores into account. For now, its concrete outputs remain the score and the reward distribution that miners receive for their participation.

Technical Architecture and Design Details

Merit’s architecture follows the standard Bittensor subnet design – it is composed of miners and validators running off-chain code that interfaces with the on-chain consensus – but it has unique aspects in what that off-chain code does. Here are the key technical components and design choices:

Incentive Mechanism Code: The entire logic of Merit’s scoring resides in its off-chain incentive mechanism (defined in the Merit GitHub repository). This includes:

• Cross-Subnet Data Aggregation: Code that iterates through all subnets to fetch each miner’s incentives. The implementation likely utilizes the Bittensor SDK or substrate calls to retrieve mining statistics. Given Bittensor’s design, each validator might query the chain state or use the SDK to get the list of active subnets and perhaps the recent emission amounts per miner in those subnets. (If direct queries are inefficient, an alternative is that Merit’s validators run lightweight clients for each subnet to detect if a given miner got a reward – but this is an ongoing area of optimization as the network grows.)
• BMPS Calculation: The algorithm for computing the Bittensor Miner Participation Score is straightforward mathematically: BMPS = (Sum of miner’s incentives across all other subnets / Number of subnets considered) × 100,000. This is implemented in the validator’s code each epoch. The choice of 100,000 as a multiplier is arbitrary but ensures the scores are scaled to a convenient range. The scores are then normalized to weights (likely by dividing each miner’s score by the sum of scores of all miners, or using Bittensor’s standard weight normalization procedure) before submission.
• Liveness Ping Protocol: One of Merit’s notable technical features is the TOTP-secured liveness check. The validator and miner both have a way to generate a time-synchronized one-time code based on the miner’s hotkey (or a secret derived from it). When a validator “pings” a miner, it expects the miner’s response to include this time-based code. According to the documentation, “TOTP-Secured Pings verify real miner presence using hotkey-seeded secrets”, and responses are type-checked for validity. This means each miner doesn’t just return a dummy acknowledgement – it must calculate a correct code (e.g. a 6-digit number that changes every 120 seconds) that the validator also independently calculates. Only if the codes match is the miner considered truly live. This mechanism prevents any would-be attacker from impersonating miners or replaying old responses, thereby upholding the integrity of Merit’s uptime verification.
• Secure and Fair Scoring: The incentive mechanism deliberately gives minimal weight to the ping itself (just a binary pass/fail for being online) and maximal weight to actual work (cross-subnet incentives). The team highlights this as a “Fair Scoring System: Ping rewards are minor compared to true network participation.”. So, technically, the code might assign a very small base score to miners that respond to pings, to differentiate live vs. dead nodes, but the bulk of the BMPS comes from the cross-subnet average. This ensures fairness – a miner cannot simply stay online 24/7 and earn much from Merit unless they also contribute across subnets.

Miner Implementation: On the miner side, running a Merit miner node is lightweight. The miner software needs to:

• Register on the Merit subnet (paying the registration cost on-chain like any subnet).
• Possibly maintain a TOTP generator using its credentials so that it can answer ping challenges. This means it likely has a small routine that computes the one-time code every so often. The dependency on time implies miners should have their system clock reasonably synchronized (perhaps why the installation recommends an NTP service).
• No heavy model serving is required: Unlike, say, a text-generation subnet where miners load large language models to answer prompts, Merit miners do not host a model for inference. Their “service” is effectively being a live participant – which is verified by ping – and their real service is external (on other subnets).
• Axon and Endpoints: In Bittensor, every miner runs an Axon server that listens for requests from validators. For Merit, the Axon likely exposes a simple endpoint (perhaps called Ping or similar) that validators call. The response to this call is the TOTP code or some structured response that the validator validates. The codebase mentions “Type-Checked Responses”, implying the Axon ensures the response is of the correct data type/format (for example, expecting an integer within a certain range).

Validator Implementation: Merit’s validators run a continuous loop each epoch:

• They likely use Bittensor’s metagraph (a global data structure of all neurons in all subnets) to get the list of miners and their states. Bittensor’s subtensor node can provide a list of neurons (miners/validators) registered in each subnet. The validator might retrieve the list of all active subnets and then for each subnet, check which of those miners (from Merit’s list) are present and what their incentive level is. There may be optimized calls for this in the Bittensor API.
• Validators also run a background thread or schedule for pings. The code allows setting a –ping_frequency (default 120 seconds) for how often to ping miners. This suggests that instead of pinging just once at epoch boundary, validators continuously ping in the background. They might maintain a record of whether each miner responded in the last interval. By the time of weight submission, they know which miners have been responsive recently. This approach provides a more robust measure of uptime (multiple checks) and can tolerate brief disconnects. A miner likely has to miss all pings in an epoch to be marked offline.
• Once weights are calculated and submitted on-chain, the rest is handled by the on-chain consensus (Yuma) to finalize emissions to miners and validators.

Integration with Bittensor Chain: Merit relies on the Bittensor substrate chain for critical functions:

• Registration and Identity: Miners/validators join Merit by registering their hotkeys on the chain under netuid 73 (paying a nominal TAO fee). This on-chain registry is what validators use to know who the Merit miners are.
• Emission Distribution: The chain, via Yuma consensus, takes the weight matrices from validators and mints the appropriate TAO rewards to miners and validators each block. Merit’s design ensures its weights reflect cross-network performance, but the actual token distribution is done by base Bittensor mechanisms.
• Subnet Emission Allocation: The root subnet (UID 0) determines what percentage of TAO emissions go to each subnet. As of now, Merit’s emission percentage is likely “Unknown” or minimal (since it’s new, it might not yet have a large allocation until it proves value). Over time, if Merit is deemed very valuable, root validators could vote to increase its emission share. (At launch, many subnets have small slices, e.g. single-digit percentages. Merit’s slice would be among those.)

Optional Health Monitoring: The documentation mentions “Background Health Monitoring: Optional miner uptime history tracking”. This indicates that Merit’s validator software may have the capability to log each miner’s ping history and keep a longer-term record of uptime. This could be purely informational (for the team or miners to review their performance) or potentially could feed into future versions of the incentive algorithm. For now, it’s noted as optional, meaning a miner’s past uptime isn’t directly affecting current rewards beyond the epoch’s immediate ping. But it reflects a design consideration to monitor reliability over time.

No Coldkey Aggregation: It’s worth noting a deliberate architectural choice: Merit scores by hotkey, not by coldkey. In Bittensor, a coldkey is an owner key that can have many hotkeys (mining identities) under it. Merit does not aggregate scores of multiple hotkeys even if one person controls many. Each hotkey is treated as an independent miner. This discourages any strategy of splitting one’s effort into many keys to game the system. A miner who wants a high Merit score is incentivized to concentrate their effort into a single hotkey that is active everywhere, rather than fragmenting into separate identities.

In summary, Merit’s architecture is relatively lightweight in terms of AI computation (no models running), but heavy in terms of network data processing and coordination. Validators act almost like analytics engines, crawling the Bittensor network to measure contributions. The security model is enhanced by using TOTP for miner identity verification, an unusual but effective choice in a decentralized compute network. The result is a subnet that piggybacks on others – technically Merit is a meta-subnet that monitors and rewards the rest of the network. This meta quality means it touches many parts of the system, making its correct functioning important for fairness across Bittensor.