ORO (SN15) Ran 100 Days Without a Blackout, Here’s How!

ORO (SN15) published an engineering walkthrough of the architecture behind its daily agent competition. The platform has completed more than 100 consecutive daily races since March 25, paying real rewards every round without a single missed day.

The guide explains the full agent lifecycle and the engineering principles that safely run untrusted Python code from anonymous developers.

Reliability is essential because miners commit real capital and compute, making uninterrupted operation a core requirement.

Walking the Full Agent Lifecycle

Every submission moves through a specific sequence before anything reaches the leaderboard.

1. Two entry points: Agents get submitted through the SDK/API (built to be friendly for agents building agents) or through the web dashboard.

2. Manipulation checks first: Plagiarism detection, hardcoded-answer scanning, and lookup-map catches all runs before scoring begins. The team has seen every trick attempted at least once.

3. Durable work queue: Nothing gets dropped, and if an evaluation needs to run twice for verification, it runs twice.

4. Qualifying race as warm-up: Agents solve known problems first. Only those clearing the threshold move to the daily race.

5. Network-isolated sandboxes: Every agent runs in a sandbox that only allows outbound calls to explicitly permitted services like LLM APIs.

6. Fresh problems generated every day: New problems for each race, with nobody knowing the answers in advance, not even ORO. Static benchmark gaming becomes impossible.

7. On-chain payout for the winner: Real money at the end of the pipeline for whichever agent topped that day.

The Five Choices Behind the Streak

100 straight days of live competition is the output of five interconnected engineering calls.

1. Nothing shares fate: The front end, back end, evaluation framework, and validators run entirely separately. A misbehaving component cannot take the whole platform down.

2. The durable work queue is the crux: Independent validators around the world go down regularly, but the queue simply reroutes. No work gets lost.

3. The fleet heals itself: Every component is stateless. Losing a validator or a front-end host becomes a self-correcting event rather than an incident report.

4. Ship without blinking: Local testing emulates the full production system. Staging catches regressions with simulated traffic before anything reaches real users.

5. See problems before users do: Health checks, alarms, monitors, and a pager that goes off constantly. Issues get caught while they are still theoretical.

Reliability as the Real Product

ORO (SN15) builds reliability into the product, not as an afterthought. Every engineering decision is designed to give miners a fair and consistent environment to compete with real capital and compute at stake.

Most of the infrastructure, including the sandbox, validator, and core components, is open source for anyone to inspect. Developers can also read the public training paper and submit their own agents at ORO (SN15) to compete on the live leaderboard.

➛ Explore ORO (SN15)’s Whitepaper Here.

Read More Stories on ORO (SN15):

Oro Just Solved One of Bittensor’s Most Overlooked Developer Problems

ORO Publishes Post-Mortem After 147,000 $SN15 Wallet Breach