Ridges SN62 v0.3.0 makes coding-agent competitions first-class

Ridges SN62 has released version 0.3.0 with a structural change to its coding-agent contest. Competitions are now first-class objects across the project’s upload, evaluation, scheduling, scoring and public-data paths.

The release was published on September 5. Its largest merged change is a multi-competition system that can give each contest its own lifecycle, membership, scoring policy and share of subnet emissions.

That is a meaningful software release. It is not proof that several competitions are already live, that every validator has upgraded, or that Ridges agents became better at writing code.

The old design centered one competition

Ridges evaluates software agents against programming tasks. Miners submit agent code, screening and validator systems run it, and scores feed the subnet’s incentive mechanism.

A single-competition architecture can keep those decisions implicit. One current task set, one leaderboard, one policy and one queue are enough. Adding a second contest is harder than adding another label. The system must know which version belongs to which competition, which policy judged it, where its evaluation history belongs and what fraction of rewards that competition controls.

Ridges pull request 483 moves those relationships into the data model and service behavior. Agent submissions, evaluations, pre-screening, approvals, scores and baselines are bound to competition membership. The project says that membership is immutable, while older null or contradictory records remain readable for compatibility.

The distinction protects historical interpretation. A score earned under one task set should not silently migrate into a later competition with different rules.

Uploads now carry competition identity

Version 0.3.0 makes the API and command-line upload path competition-aware. Cooldowns, version numbers and duplicate detection can be evaluated inside the selected competition rather than across an undifferentiated global stream.

Funding consumption is also described as atomic. Existing credits remain competition-agnostic until a miner redeems them for an upload. The release does not claim a new price, revenue model or demand figure.

Competition boundaries can otherwise create accidental penalties. An agent submitted to one track could be rejected as a duplicate of work intended for another, or a global cooldown could block an unrelated contest. Ridges is moving those decisions closer to the policy that owns them.

The public code establishes the implementation. Tao Outsider did not upload an agent or test the edge cases against the production service.

Scheduling has to be fair across queues

Multiple competitions also compete for validator attention. If workers always pull from the busiest queue, a smaller contest can wait indefinitely. If every competition gets equal time regardless of workload or emissions, resources can be wasted.

Ridges says screeners and validators now rotate across eligible competitions. Lifecycle states include draft promotion, activation, pause, draining and ending. Those states determine whether a competition should accept uploads or receive evaluation work.

The code moves scoring, approval, pruning and incentive decisions into stored competition policy. It also lets emission allocation be split across active competitions according to configured ratios.

That design leaves a governance question unanswered. Who sets the ratios, and how should users judge them? A technically clean split can still encode a weak priority. Future public evidence should connect each allocation to the contest’s task value, participation and evaluation cost.

Leaderboards become local to their rules

The release updates public endpoints for competition queues, leaderboards, statistics, thresholds and historical views. Another merged change exposes competition information through the agents-by-coldkey endpoint.

Ridges chose to calculate leaderboards per competition rather than produce one complex query across every contest. Live leaderboard data is cached for 15 seconds, while past competitions can remain cached for 24 hours.

Those intervals are product choices, not performance benchmarks. They say how long a reader may see cached data. They do not establish request latency, validator throughput or scoring accuracy.

Version 0.3.0 also adds descriptions and related links to competition records, plus an admin endpoint whose changes are stored in an audit table. Better metadata should make the public surface easier to interpret, particularly when two competitions evaluate different kinds of coding work.

What this changes for miners

A miner can now face competition-specific submission windows, cooldowns, versions, duplicate rules and scores. Success in one track does not automatically transfer into another.

That can make Ridges more flexible. The subnet could run a general coding contest beside a narrower task family without forcing both through identical evaluation policy. It can also make participation harder to follow if competition pages fail to state their rules, allocation ratio and lifecycle clearly.

For validators, the release increases operational state. Scheduling must respect eligibility, scoring must load the correct stored policy, and older records must remain legible without contaminating new leaderboards.

The system’s quality will depend on those boundaries holding under real queue pressure. A release note can describe fairness; only observed scheduling can show that a small eligible competition is not starved.

Current subnet context

TaoSwap showed 13 active miners on Ridges SN62 and an emission_value of 0.007423304 at the September 5 checkpoint.

That snapshot confirms current subnet participation, not v0.3.0 adoption. It does not identify validator versions, the number of live competitions, agent quality, customers or revenue.

Ridges has shipped the software layer needed to separate contests. Useful follow-up evidence would include multiple active competition records, published policies, visible allocation ratios and historical leaderboards that reconcile with validator behavior.

Until then, v0.3.0 should be read as architecture becoming available, not outcomes becoming proven.