Open algorithms, open data.
Sim Latency Algo Competition
Optimize the UR protocol. Submissions evaluate against a branch of the code and the winner becomes the next baseline and earns SN1α. Spanning six rounds, one week each, launching soon. Let's go!
The protocol is a decentralized-native, multi-IP, multi-transport system designed to scale to millions of miners per network operator. Each algorithm area below is published with its source and, where applicable, anonymized data sets for independent analysis.
URTRANSPORT1Performance
Multi-hop routing via TCP transports focused on global accessibility. UDP and peer-to-peer stream upgrades are supported with integration of WebRTC, XRay, and WireGuard planned.
Current approach
The transport is built for accessibility first, so that every person in the world can connect. Multi-hop routing runs over TCP transports through a central hop. UDP transports such as H3 and DNS are implemented but disabled: in real-world use they underperformed the TCP path in this setup. A multi-miner hop with a peer-to-peer stream upgrade is implemented and currently disabled as well. Transport selection and the stream upgrade path live in transport.go and transfer_stream_manager.go.
Implementation
Research directions
Integrate established protocols such as WebRTC, XRay and WireGuard as stream upgrades on the multi-miner hop, and re-enable UDP transports where measurements show they help. The matching algorithm may also start to distinguish hops that have a public IP and port from hops that do not, to balance speed against connection quality. Each of these can be trialled on an experimental network operator before it becomes the default.
UREXTENDER1Accessibility
N-layer TLS encryption (N≥2) where each outer layer uses a self-signed cert with SNI spoofing to an intermediary IP, forwarding to another hop or an end-to-end TLS connection. Anyone can host an extender on any domain.
Current approach
The core network stack supports N-layer TLS encryption, with N at least two. Each outer layer can use a self-signed certificate for a chosen host name to reach an intermediary IP, which forwards the traffic to another hop or to an end-to-end TLS connection with the network operator's domain, so the connection looks like ordinary traffic to that host name. Anyone can host an extender on a domain they control. The users of one extender share a common rate limit, adjustable case by case.
Implementation
Research directions
Extenders can be added to a protocol grant list that allocates a share of incentives across the participating extenders; the onboarding details will be published when the list opens. Every miner already takes the extender role alongside egress. The open questions are how to measure an extender's reach where it matters most without exposing its users, and how the outer layers should rotate host names and certificates as blocking adapts.
UR-FP2Client–Miner Matching
Sampling algorithm that loads a 10× random sample of potential miners and shuffles proportional to reliability × client score. Sybil resistance is guaranteed by the constraint that reliability sums to at most 1 per IP subnet.
Current approach
The matching system loads a random sample of candidate miners from memory, about ten times the number it needs, and shuffles it in proportion to reliability × client score to produce the finalists. Its protection against miner aliasing (Sybil attacks) is a cap per IP subnet: the reliability scores of all miners in one subnet sum to at most 1, so splitting one connection into many identities does not raise its share of matches. The entry point is FindProviders2.
Implementation
Research directions
Distinguish hops with a public IP and port from hops without one when matching, to trade speed against connection quality explicitly rather than through reliability alone. The reliability and client-score weights and the size of the sample are the natural inputs for an experimental operator to vary against the anonymized block exports described below, with the per-subnet cap kept fixed as the Sybil bound.
UR-MULTIMulti Client
Heuristic sweep algorithm managing a window of miners. Locks traffic into the top available tier based on transfer thresholds rather than protocol analysis.
Current approach
A heuristic sweep manages a window of miners and locks traffic into the miners of the highest available tier. Decisions are made on transfer thresholds, how much a miner has actually moved, rather than on inspecting the protocol inside the tunnel, so the router never needs to look at application traffic. The window is what lets one client keep several miners in play at once and move traffic between them as their measured transfer changes.
Implementation
Research directions
The thresholds and tier boundaries are hand-set today. Open questions for an experimental operator: whether they should be derived from measured transfer distributions instead, and whether the window should also take in the per-miner liveness and latency statistics that validators now produce (see Routing Verification), so a client can avoid a weak link before paying for it with its own traffic.
UR-TRANSFERTransfer
Reliable delivery window tuned for high-latency environments. Protocol retransmits are disabled since the window provides reliable delivery. Distributes traffic across transports by ranked performance.
Current approach
A reliable transfer window is tuned for high-latency environments. Because the window itself provides reliable delivery, protocol retransmits into the transfer layer are disabled: a TCP stream carried through the tunnel is not retransmitted on top of it. Traffic is distributed among the available transports according to their ranked performance and availability, so a slow or failing transport loses share rather than stalling the stream.
Implementation
Research directions
Open questions: how the window should size itself across the spread of real-world latencies rather than for one fixed profile, how transports should be re-ranked as their performance changes mid-stream, and how the transfer layer should cooperate with the stream upgrades planned for the transport (see Performance) when one hop is peer-to-peer and the next is not.
UR-IPIP Egress
Minimal-memory IP stack implementation. Assumes reliable peer communication via the transfer layer, so retransmits are optimized accordingly.
Current approach
The IP stack is designed to run with minimal memory, so a miner can serve as egress on a phone or a small device. It assumes reliable communication with the peer through the transfer layer, which lets its own retransmit handling be optimized away rather than duplicated. The safety layer (see Safety) sits in the same path, so every packet is checked before it leaves the miner.
Implementation
Research directions
Open questions: how much further the memory footprint can fall on the smallest devices, and how the egress stack keeps its guarantees once the transfer layer's reliability assumptions are relaxed for the peer-to-peer stream upgrades planned for the transport. As with the transport, changes are trialled on an experimental operator before they become the default.
UR-PSUB2Reward Allocation
Independent validators score every operator pool by demand and measured quality; Bittensor's Yuma Consensus turns those scores into emission. Within a pool, settlement v2 splits each cycle by verified usage alone into cumulative accounts that never expire: the operator commits a Merkle root, the validator audits it, and every miner claims directly from the settlement contract.
Current approach
Rewards are the UR subnet's emission on SN25. Each operator's miners form one pool with one miner UID. Every tempo, independent validators score each pool by implied usage × measured quality (the operator's audited usage priced at the conviction-zero rate and truncated as its capped deposit is, times the pool's miner quality from the validator's own trails, clamped to [0.75, 1]) under commit-reveal, and Yuma Consensus turns the median into emission. Before settlement v2, the operator ranks its miners by usage × reliability, commits a Merkle payout root each epoch, and each miner claims its share directly from the settlement contract before it expires. From settlement v2's switch epoch, each epoch's share follows verified usage alone and accrues to one account per payout wallet that never expires; a root pays only after the validator approves it and a 14,400-block challenge window passes, and one claim collects everything accrued. The top fleets by routable-IP breadth hold their own UIDs and are paid natively. Providers receive the momentum share of the miner allocation, 10% at launch, split between the top fleets and the pools by θ; the Network Capacity Reserve receives the rest. While the published price is 0, no deposits are collected and every pool carries the same implied demand, so measured quality alone steers the pool channel.
Implementation
Research directions
θ is a published governance parameter: start tail-weighted (θ ≈ 0.3), instrument the realized pay per tier, and widen it as the top-miner set and the independent-validator quality consensus mature, under the constraint that the lowest-paid top-level miner still earns at least the highest-paid pool miner. The swing that quality has on pool weight is capped at bootstrap and ramped. A validator effort bounty is designed but parked, to be built only if the live network shows independent coverage needs it. Decentralizing the validator set beyond the owner majority is a deliberate later governance step.
UR-CONTRACTPermission
Transfer between parties requires an encrypted contract with escrowed balance and a permission set. Both sides must close with acknowledged byte counts; disagreements trigger a forced resolution process.
Current approach
Transfer between an initiator and a companion requires a contract encrypted with the destination client's secret key. The contract holds a fixed transfer balance in escrow and defines the permissions between both parties. The companion can create paired contracts for return traffic, and multi-hop paths send stream-open and stream-close events to the intermediaries. After use, both parties close the contract with an acknowledged byte count. If either side does not close, or the totals disagree, contract resolution determines the outcome; if either side reports abuse, future transfer between those parties is blocked.
Implementation
Research directions
The bytes settled on closed contracts are also each miner's usage in its pool's payout ledger, so the accuracy of the closed byte counts feeds rewards. Open questions: how to settle a disagreement between two closing counts without a trusted third total, how paired return contracts should be sized for asymmetric traffic, and how an abuse report should be weighed when the two parties' counts have disagreed before.
UR-SEC1Safety
Port block list and IP block list protecting the miner network. Does not perform protocol inspection. Miners route only encrypted traffic.
Current approach
The safety layer uses port and IP block lists. It does not inspect application protocols: miners route only encrypted traffic, so there is nothing to inspect, and the block lists are what let a miner reject traffic that conflicts with common regulation directions such as CFAA and DMCA and drop known-malicious destinations. The lists apply on the miner, so a user's traffic meets the same rules on every exit.
Implementation
Research directions
Open questions: how block lists should be distributed and updated across a fleet without a central point that can see traffic, whether the safety layer should learn per-destination reputation from anonymized egress data rather than static lists, and what a miner should be able to add to its own lists without splitting the network's behavior across exits.
UR-VERIFY1Routing Verification
Validators walk server-assigned chains of miners, proving live egress from each hop with four Ed25519 signatures. Per-step completion and latency statistics find the weakest link and become the quality signal that steers pool emission.
Current approach
A validator seeds a trail through a miner of its choice and calls /verify; the server derives the hop from the request's source IP, never from a claim. Each next hop is drawn uniformly at random, without replacement, and revealed only after the current hop confirms, so a path cannot be precomputed. Four Ed25519 signatures bind the trail: SEED and EXTEND by the validator, ASSIGN and FINAL by the server, which also stamps every hop time. A failure is attributed to the one hop that was never reached, latency is recorded per step at confirmation, the validator-chosen seed hop is excluded, and each miner is reported by a Wilson-score completion interval and latency percentiles once it has enough exposure.
Implementation
Research directions
A completed trail proves live sequential transit to one known destination, not honest relay of user traffic, and per-hop self-dealing is bounded only statistically, by an independent validator population. The roadmap to payout-grade measurement: proof-of-routing through neighbor attestation, destination diversity so a miner cannot optimize the single measured path, validator Sybil resistance through stake, and a hierarchical hazard model for attribution. Until then the statistics are liveness and latency monitoring and provisional scoring.
Anonymization
The network's payout block is 7 days, and the exports of each algorithm's inputs and outputs are anonymized per block. Every client id and IP-subnet hash is replaced with a simple integer counter, so an identity is consistent inside one block but carries nothing across blocks and nothing back to a production id. City metadata is not included. The block exports are prepared for publication but not published yet; this page will link them when they are.
For researchers and builders
UR wants users to be able to opt into experimental algorithms through federated network operators. A new operator joins the same incentive system that pays today's miners, and a miner can serve as many operators as it likes. The app will offer every user the option to enter an alternate operator domain. Access details for experimental operators will be published when the program opens, and this page tracks the current default algorithm and the experimental directions. For security research, follow the Vulnerability Disclosure Policy.
Audits
Peer audits of the protocol and its implementations.
- ScheduledEncryption audit 2026Cure53Scheduled for November – December 2026Scope: encryption design and implementation correctness.Results will be published by UR and Cure53.
- Peer auditMASA L2 2025Leviathan Security GroupCompleted May 2025