Skip to content
UR — Apex — Subnets — News

UR Launches Apex SN1 Competition to Cut Privacy-Network Latency

Developers will compete for SN1 alpha by improving code used in UR’s live network, with approved winners setting the next performance baseline.

Table of Contents

UR, the decentralized privacy network on Bittensor Subnet 25, has launched an open competition on Apex SN1 to improve the code that connects users to its network providers. Participants will compete for SN1 alpha by reducing request latency, with approved winning patches becoming the foundation for subsequent rounds.

Submissions open October 29 at 00:00 UTC, or 8 p.m. Eastern on October 28. The season consists of six rounds with seven-day submission windows, although evaluation backlogs and preparation between rounds can extend it beyond six calendar weeks.

UR says its routing and provider-matching algorithms serve roughly 350,000 people each month. The competition brings outside developers into optimizing production code. UR supplies the networking problem and reviews the winners, while Macrocosmos’ Apex subnet handles submissions, fees, evaluation, and publication.

A Narrow Code Target Within a Larger Routing System

UR routes users’ traffic through connections contributed by other people’s devices. Finding an available provider, checking its permissions, and establishing a working path all contribute to how quickly a request completes.

The URnetwork Latency Competition rules restrict submissions to a unified Git diff. That file manages the resident-side lookup of active contracts and its short-lived cache. Contracts govern permission to transfer traffic between participants, making their lookup part of the connection path.

This is a narrower editable surface than UR’s broader routing research agenda. Its published research program covers transport selection, keeping multiple providers available to a client, peer-to-peer stream upgrades, and client-to-miner matching.

Today, UR’s multi-hop routing uses TCP transports through a central hop. UDP transports, including HTTP/3 and DNS, are implemented but disabled after underperforming the TCP path in that configuration. A multi-provider hop with a peer-to-peer stream upgrade is also implemented but switched off.

Provider selection adds another set of decisions. UR-MULTI maintains a window of miners and directs traffic toward the highest available tier using transfer thresholds, without inspecting the application traffic inside the tunnel. UR-FP2 samples candidate miners and weights selection by reliability and client score. To resist Sybil attacks, in which one participant creates multiple identities, reliability scores within each IP subnet sum to no more than one.

Those mechanisms explain the surrounding system, but contestants cannot rewrite them freely in this season. Their changes must stay within the permitted contract-manager file. UR also plans anonymized exports of algorithm inputs and outputs for research; those exports are prepared but not yet published. The competition itself uses a seeded simulated workload.

0:00
/1:12

Measuring Slow Requests Across the Full Stack

Each patch is applied to source commits frozen for its round and built offline. The evaluator then runs the UR stack, including its API, exchange, matchmaking, reliability pipeline, and accounting, alongside simulated providers and a test origin site.

The official workload uses 1,800 providers with network impairments, 200 client identities, and 80 arrivals per minute. Everything shares one 12-CPU evaluation machine, with 10 CPUs available for evaluation and two reserved for management and cleanup. A computationally expensive shortcut therefore competes for the same resources as the services it is trying to accelerate.

Scoring focuses on p95 total request time, the completion time at the 95th percentile, which captures the slower end of the request distribution. Each candidate receives nine independently reset runs, each with a 180-second measured window, and ranking uses the median of those nine p95 scores. Lower is better.

Failed requests and incomplete response bodies are charged at the fixed timeout ceiling before the percentile is calculated. A patch cannot improve its score simply by dropping difficult requests. Warm-up establishes the provider fleet and its reliability history before measurement begins, so the test measures selection and traffic delivery among established providers rather than onboarding.

Every scored entry must also pass six gates: request correctness, traffic volume, tunnel integrity, matchmaking cost, stability, and resource limits. These checks require the workload to be served through the intended network path without bypassing accounting, starving traffic, or exceeding the evaluator’s boundaries.

How Winners Raise the Baseline

Each round has one frozen nine-run control sample from the unmodified code. All candidates are compared with that same control, not a different reference measurement for each submission.

The opening round requires at least a 16.1% improvement over the control. Candidates must also pass a one-sided Welch statistical test with p ≤ 0.05, and their measured variance must support a next-round improvement threshold within the permitted range. Macrocosmos says the initial margin is calibrated to the workload’s run-to-run noise.

The highest-ranked eligible entry becomes the winner automatically when results are published. UR then reviews the patch for benchmark manipulation, fabricated measurements, unsafe behavior, credential access, and other prohibited changes. A failed review revokes the win and passes it to the next eligible entry, if one exists.

Merging the patch is a separate UR decision. Once approved for the codebase, a winning change enters the next round’s source, and its measured variance informs the next improvement threshold without weakening the incumbent margin. If no eligible winner emerges, or a winning patch has not been approved, the source and threshold carry forward unchanged.

That structure lets accepted gains accumulate rather than having every round optimize against the season’s original code. UR intends to adopt improvements into its production protocol, while the review and merge process determines which winning patches reach the codebase.

The work follows UR’s SN25 mainnet launch and introduction of a Network Capacity Reserve to fund connectivity ahead of customer demand. Its existing residential-provider network supplies the underlying connections, while operators build customer-facing services. One recent addition, Persistent AI’s Private Inference integration, will use those connections to shield users’ originating IP addresses.

Separately, UR’s mainnet rollout targets settlement v2 activation for October 30, pending final production checks and on-chain pool registration. That upgrade would remove the current limit of roughly 1,500 paid providers per settlement epoch and allocate payments by verified usage.

Entry Terms and Public Results

Each submission costs $20 and may contain up to 262,144 bytes. Apex limits each hotkey, a participant’s operational Bittensor key, to four submissions in any 24-hour window across all competitions. Identical patch bytes resubmitted within the same round reuse the existing evaluation without another charge.

Patches must use the current round’s frozen source commits, add no dependencies, and build with Go 1.27.2. Submissions license the contributed code under the Mozilla Public License 2.0, the license used by the target repository.

Comments

Latest