With the amount of new subnets being added it can be hard to get up to date information across all subnets, so data may be slightly out of date from time to time

Subnet 58

Handshake

Alpha Price
Value
Market Cap
Value
Neurons
Value
Registration Cost
Value
TAO Liquidity
Value
Alpha in Pool
Value
Total Alpha Supply
Value
% Alpha Staked
Value

ABOUT

What exactly does it do?

Handshake58 (Subnet 58, “Handshake”) is an agent-first payments and inference marketplace designed to let autonomous AI agents discover providers and pay per request using USDC on Polygon via the DRAIN payment-channel protocol, while using Bittensor as a cryptoeconomic validation layer to score providers and distribute subnet incentives to those with provable real usage.

The product combines two core layers. First, a Polygon settlement layer: agents open a USDC payment channel once, then send unlimited off-chain signed vouchers per request (effectively “gasless micropayments” after channel open), and providers claim earned USDC on-chain; the system documents a $0.01 USDC session fee per channel and a 0% protocol fee on payments, with the channel contract deployed on Polygon mainnet and verified on PolygonScan.

Second, a Bittensor validation and incentive layer: Subnet 58 validators scan on-chain “ChannelClaimed” events from the DRAIN channel contract to measure real paid usage, combine this with live availability checks (including wallet-ownership proof), and then set Bittensor weights so providers/miners who deliver actual service earn subnet rewards. The subnet implementation explicitly documents a reward split of 41% miners, 41% validators, and 18% subnet owner in its reference miner/validator stack.

Overall, Handshake positions itself not just as a paywall for individual API calls, but as a reusable payment channel that can power high-frequency agent workflows (streams, swarms, voice bots) and reduce the operational friction of integrating many different AI services into autonomous agent systems.

Handshake58 (Subnet 58, “Handshake”) is an agent-first payments and inference marketplace designed to let autonomous AI agents discover providers and pay per request using USDC on Polygon via the DRAIN payment-channel protocol, while using Bittensor as a cryptoeconomic validation layer to score providers and distribute subnet incentives to those with provable real usage.

The product combines two core layers. First, a Polygon settlement layer: agents open a USDC payment channel once, then send unlimited off-chain signed vouchers per request (effectively “gasless micropayments” after channel open), and providers claim earned USDC on-chain; the system documents a $0.01 USDC session fee per channel and a 0% protocol fee on payments, with the channel contract deployed on Polygon mainnet and verified on PolygonScan.

Second, a Bittensor validation and incentive layer: Subnet 58 validators scan on-chain “ChannelClaimed” events from the DRAIN channel contract to measure real paid usage, combine this with live availability checks (including wallet-ownership proof), and then set Bittensor weights so providers/miners who deliver actual service earn subnet rewards. The subnet implementation explicitly documents a reward split of 41% miners, 41% validators, and 18% subnet owner in its reference miner/validator stack.

Overall, Handshake positions itself not just as a paywall for individual API calls, but as a reusable payment channel that can power high-frequency agent workflows (streams, swarms, voice bots) and reduce the operational friction of integrating many different AI services into autonomous agent systems.

PURPOSE

What exactly is the 'product/build'?

Handshake58 operates as a decentralised “AI provider marketplace” where AI agents can discover providers by model/service, open a USDC payment channel on Polygon, and then pay per request using signed off-chain vouchers rather than credit cards, subscriptions, or per-request on-chain transactions. The marketplace positions this as a native payment mechanism for autonomous agents: open once, transact many times at near-zero incremental cost, and close anytime to recover unused USDC.

The system’s economic design is built around payment channels and voucher-based micropayments. The public documentation states that the agent’s only recurring on-chain actions are (a) depositing USDC into a channel and (b) closing/settling the channel, while each individual service request carries a signed voucher that authorises an increased cumulative amount. This enables extremely small per-request payments (the site claims ~$0.0001 increments) without paying gas for every request, and it is explicitly motivated by agent use cases involving continuous streams and high-frequency calls.

Handshake58 is not limited to a single inference provider. Its marketplace and templates are designed for a broad catalogue of AI services and backends, with ready-to-deploy provider templates documented for OpenAI, Anthropic, xAI Grok, OpenRouter (200+ models), and “custom” backends including vLLM/Ollama/Together/Fireworks/LiteLLM. The marketplace documentation also describes the catalogue expanding beyond chat LLMs into other paid agent tools (e.g., image/video generation, web scraping/data extraction, OCR, TTS, workflows), delivered through the same payment-channel mechanism and accessed via a single MCP server integration.

Subnet 58’s role is the trust and incentive layer for this marketplace. Handshake58 explicitly states that providers are “scored trustlessly” through Bittensor Subnet 58, and its subnet reference implementation defines scoring as a function of provable on-chain paid usage (DRAIN channel claim events) plus an availability/verification component. The result is a “proof of service” mechanism: if agents actually pay a provider through the protocol and the provider is reachable/verified, that provider’s subnet score rises and earns greater rewards.

Handshake58 also defines two provider tiers that map directly to this trust model. “Bittensor Miners” run Subnet 58 miner software and are auto-registered/auto-verified for the marketplace, earning subnet rewards based on real DRAIN usage and receiving priority listing. “Community Providers” can list an existing DRAIN-compatible API (including a required /v1/pricing endpoint tied to a Polygon wallet), but must pass admin review and do not earn Bittensor rewards.

Handshake58 is implemented as a full-stack system that combines (1) a Polygon USDC payment-channel protocol (DRAIN), (2) a marketplace directory and discovery APIs, (3) a standardised provider API surface that feels OpenAI-compatible for ease of agent adoption, (4) provider templates to deploy compatible services quickly, and (5) a Bittensor subnet (SN58) that continuously scores providers based on objective, difficult-to-fake signals and pushes those scores on-chain as staking weights.

From a user (agent operator) perspective, the core “product” is that one wallet and one integration unlock a catalogue of paid AI services. The documentation strongly emphasises MCP (Model Context Protocol) as the primary integration: users install drain-mcp, set a DRAIN_PRIVATE_KEY for a Polygon wallet holding USDC, and the MCP server handles provider discovery, channel management, voucher signing, and requests automatically. This is positioned as reducing “integration overhead” for agents that would otherwise need many separate accounts and API keys.

Tokenomics (alpha/TAO flows)

Handshake58’s official documentation describes provider incentives as “TAO rewards from Bittensor emissions,” and the subnet reference implementation states an emissions split of 41% miners, 41% validators, and 18% subnet owner.

On-chain market tokenomics (liquidity, circulating alpha, emissions %) are viewable via Bittensor explorers; for example, tao.app displays Subnet 58’s Alpha/TAO liquidity and an emission parameter at the time of access (values are dynamic and change over time).

In the payment protocol itself, the marketplace describes a $0.01 USDC session fee per channel and 0% protocol fee, with the fee wallet returned by the config endpoint.

Integration points with other services
Handshake58 is designed to integrate into agent tooling and a wide range of AI service providers:

  • MCP integration: the official docs support Claude Desktop and Cursor MCP configuration via the drain-mcp server, positioning MCP as the recommended route for agents.
  • Provider backends: official templates support OpenAI, Anthropic, xAI, OpenRouter, and Bittensor/Chutes inference, plus custom backends such as vLLM/Ollama/Together/Fireworks/LiteLLM.
  • Marketplace/catalog expansion: the machine-readable docs explicitly describe a catalogue intended to include non-chat services like web scraping/data extraction, OCR, and TTS, implying providers can expose diverse paid agent tools through the same protocol.

 

A key documentation gap is https://handshake58.com/skill.md, referenced as “full protocol documentation.” It could not be fetched in this environment (tool returned an error), so any deeper implementation specifics that exist only there are unspecified in this report.

Handshake58 operates as a decentralised “AI provider marketplace” where AI agents can discover providers by model/service, open a USDC payment channel on Polygon, and then pay per request using signed off-chain vouchers rather than credit cards, subscriptions, or per-request on-chain transactions. The marketplace positions this as a native payment mechanism for autonomous agents: open once, transact many times at near-zero incremental cost, and close anytime to recover unused USDC.

The system’s economic design is built around payment channels and voucher-based micropayments. The public documentation states that the agent’s only recurring on-chain actions are (a) depositing USDC into a channel and (b) closing/settling the channel, while each individual service request carries a signed voucher that authorises an increased cumulative amount. This enables extremely small per-request payments (the site claims ~$0.0001 increments) without paying gas for every request, and it is explicitly motivated by agent use cases involving continuous streams and high-frequency calls.

Handshake58 is not limited to a single inference provider. Its marketplace and templates are designed for a broad catalogue of AI services and backends, with ready-to-deploy provider templates documented for OpenAI, Anthropic, xAI Grok, OpenRouter (200+ models), and “custom” backends including vLLM/Ollama/Together/Fireworks/LiteLLM. The marketplace documentation also describes the catalogue expanding beyond chat LLMs into other paid agent tools (e.g., image/video generation, web scraping/data extraction, OCR, TTS, workflows), delivered through the same payment-channel mechanism and accessed via a single MCP server integration.

Subnet 58’s role is the trust and incentive layer for this marketplace. Handshake58 explicitly states that providers are “scored trustlessly” through Bittensor Subnet 58, and its subnet reference implementation defines scoring as a function of provable on-chain paid usage (DRAIN channel claim events) plus an availability/verification component. The result is a “proof of service” mechanism: if agents actually pay a provider through the protocol and the provider is reachable/verified, that provider’s subnet score rises and earns greater rewards.

Handshake58 also defines two provider tiers that map directly to this trust model. “Bittensor Miners” run Subnet 58 miner software and are auto-registered/auto-verified for the marketplace, earning subnet rewards based on real DRAIN usage and receiving priority listing. “Community Providers” can list an existing DRAIN-compatible API (including a required /v1/pricing endpoint tied to a Polygon wallet), but must pass admin review and do not earn Bittensor rewards.

Handshake58 is implemented as a full-stack system that combines (1) a Polygon USDC payment-channel protocol (DRAIN), (2) a marketplace directory and discovery APIs, (3) a standardised provider API surface that feels OpenAI-compatible for ease of agent adoption, (4) provider templates to deploy compatible services quickly, and (5) a Bittensor subnet (SN58) that continuously scores providers based on objective, difficult-to-fake signals and pushes those scores on-chain as staking weights.

From a user (agent operator) perspective, the core “product” is that one wallet and one integration unlock a catalogue of paid AI services. The documentation strongly emphasises MCP (Model Context Protocol) as the primary integration: users install drain-mcp, set a DRAIN_PRIVATE_KEY for a Polygon wallet holding USDC, and the MCP server handles provider discovery, channel management, voucher signing, and requests automatically. This is positioned as reducing “integration overhead” for agents that would otherwise need many separate accounts and API keys.

Tokenomics (alpha/TAO flows)

Handshake58’s official documentation describes provider incentives as “TAO rewards from Bittensor emissions,” and the subnet reference implementation states an emissions split of 41% miners, 41% validators, and 18% subnet owner.

On-chain market tokenomics (liquidity, circulating alpha, emissions %) are viewable via Bittensor explorers; for example, tao.app displays Subnet 58’s Alpha/TAO liquidity and an emission parameter at the time of access (values are dynamic and change over time).

In the payment protocol itself, the marketplace describes a $0.01 USDC session fee per channel and 0% protocol fee, with the fee wallet returned by the config endpoint.

Integration points with other services
Handshake58 is designed to integrate into agent tooling and a wide range of AI service providers:

  • MCP integration: the official docs support Claude Desktop and Cursor MCP configuration via the drain-mcp server, positioning MCP as the recommended route for agents.
  • Provider backends: official templates support OpenAI, Anthropic, xAI, OpenRouter, and Bittensor/Chutes inference, plus custom backends such as vLLM/Ollama/Together/Fireworks/LiteLLM.
  • Marketplace/catalog expansion: the machine-readable docs explicitly describe a catalogue intended to include non-chat services like web scraping/data extraction, OCR, and TTS, implying providers can expose diverse paid agent tools through the same protocol.

 

A key documentation gap is https://handshake58.com/skill.md, referenced as “full protocol documentation.” It could not be fetched in this environment (tool returned an error), so any deeper implementation specifics that exist only there are unspecified in this report.

WHO

Team Info

The clearest publicly verifiable individual associated with Handshake58 in the official sources is Artur Markus. The thesis page lists “Artur Markus” as the author and refers to him as the “Creator of the DRAIN Protocol,” which is the payment-channel protocol underlying Handshake58.

In the official GitHub ecosystem, Artur Markus appears as the GitHub user kimbo128, with the profile explicitly naming “Artur Markus,” describing him as a senior software architect, and linking to a personal website (as listed on the GitHub profile).

The Handshake58 GitHub organisation lists two public repositories (HS58 and HS58-subnet) but does not expose public organisation members (“This organization has no public members”), so the broader team roster beyond visible contributions is unspecified from authoritative sources.

The Subnet 58 miner/validator repository lists two contributors, including kimbo128 (Artur Markus) and cursoragent (shown as “Cursor Agent”), but official role titles beyond those labels are unspecified.

The clearest publicly verifiable individual associated with Handshake58 in the official sources is Artur Markus. The thesis page lists “Artur Markus” as the author and refers to him as the “Creator of the DRAIN Protocol,” which is the payment-channel protocol underlying Handshake58.

In the official GitHub ecosystem, Artur Markus appears as the GitHub user kimbo128, with the profile explicitly naming “Artur Markus,” describing him as a senior software architect, and linking to a personal website (as listed on the GitHub profile).

The Handshake58 GitHub organisation lists two public repositories (HS58 and HS58-subnet) but does not expose public organisation members (“This organization has no public members”), so the broader team roster beyond visible contributions is unspecified from authoritative sources.

The Subnet 58 miner/validator repository lists two contributors, including kimbo128 (Artur Markus) and cursoragent (shown as “Cursor Agent”), but official role titles beyond those labels are unspecified.

FUTURE

Roadmap

Handshake58’s official materials focus more on a “thesis” and “vision” than on a dated roadmap, and there is no official timeline with milestone dates in the sources provided. Therefore, specific future milestone dates are unspecified.

What is clearly stated is that core infrastructure is already live and operational. The main website states “Mainnet Live” and describes a functioning flow—open channel, pay providers via vouchers, close channel—with contract addresses and working discovery/config endpoints. The thesis likewise asserts that the protocol and validation network are not merely conceptual, referencing deployed contracts and an active validation layer (Bittensor Subnet 58).

The near-term “product roadmap” implied by the sources is primarily ecosystem expansion: increasing the variety and density of services/providers that can be purchased by agents through the marketplace. The vision page and machine-readable docs explicitly list trajectories beyond basic chat completion—continuous streams, swarms, voice agents, OCR/invoice workflows, and paid data feeds—suggesting Handshake58 intends to be a general-purpose payment layer for many agent tools rather than only an LLM gateway. These are framed as use cases and targets rather than dated delivery commitments.

On the subnet side, the current published scoring mechanism is concrete and already implemented in the reference repository: 60% weight from DRAIN claim events over a rolling 7‑day window plus 40% from live availability checks with wallet proof, with explicit anti-gaming reasoning documented. No official source specifies when (or if) additional scoring dimensions, richer quality testing, or broader validation features will be added, so any “next scoring upgrades” are unspecified.

Finally, GitHub activity suggests rapid iteration during February 2026 (documentation and onboarding improvements recorded in commit history for HS58). This indicates ongoing build-out of templates and documentation, but the commit history does not include a formal forward-looking roadmap with agreed dates.

 

Handshake58’s official materials focus more on a “thesis” and “vision” than on a dated roadmap, and there is no official timeline with milestone dates in the sources provided. Therefore, specific future milestone dates are unspecified.

What is clearly stated is that core infrastructure is already live and operational. The main website states “Mainnet Live” and describes a functioning flow—open channel, pay providers via vouchers, close channel—with contract addresses and working discovery/config endpoints. The thesis likewise asserts that the protocol and validation network are not merely conceptual, referencing deployed contracts and an active validation layer (Bittensor Subnet 58).

The near-term “product roadmap” implied by the sources is primarily ecosystem expansion: increasing the variety and density of services/providers that can be purchased by agents through the marketplace. The vision page and machine-readable docs explicitly list trajectories beyond basic chat completion—continuous streams, swarms, voice agents, OCR/invoice workflows, and paid data feeds—suggesting Handshake58 intends to be a general-purpose payment layer for many agent tools rather than only an LLM gateway. These are framed as use cases and targets rather than dated delivery commitments.

On the subnet side, the current published scoring mechanism is concrete and already implemented in the reference repository: 60% weight from DRAIN claim events over a rolling 7‑day window plus 40% from live availability checks with wallet proof, with explicit anti-gaming reasoning documented. No official source specifies when (or if) additional scoring dimensions, richer quality testing, or broader validation features will be added, so any “next scoring upgrades” are unspecified.

Finally, GitHub activity suggests rapid iteration during February 2026 (documentation and onboarding improvements recorded in commit history for HS58). This indicates ongoing build-out of templates and documentation, but the commit history does not include a formal forward-looking roadmap with agreed dates.