About Ormas
Code that passed your test, before you paid for it.
Ormas turns testable coding tasks into paid, verified outcomes. Bring a GitHub repository, a scoped change and an automated test that defines success. A qualified provider offers a firm price, or an estimate with a hard limit, before work starts. A passing delivery returns a result branch and receipt for your review. If acceptance fails, there is no task charge. You decide what merges.
Verified outcomes · Bittensor subnet 76
- A clear price or hard limit
- No task charge on a miss
- Verified by your own test
Standard is live in early alpha.
Start with focused repository work: a bug fix, dependency update or small feature with a clear definition of done. Python, Node and browser tasks use declared Linux environments, locked dependencies and specific acceptance interfaces. Support depends on the task and available qualified providers and checkers.
Standard supports a public or private GitHub repository. The winning provider and checker can read a copy of the code. A private repository at the Standard level is read in plaintext on the provider's machine, so choose Standard for code you are comfortable sharing with providers. Repository visibility and service level are separate choices; a private repository does not automatically use Protected.
We used Ormas on six real tickets from our own engineering backlog: five were delivered and merged; one failed acceptance and settled at $0. This was an internal trial, with our own team acting as the client and provider operator.
Supported tasks, environments and current qualification status →Protected access is coming.
Protected is designed for more sensitive code. The worker and checker run in confidential virtual machines, with hardware attestation before repository access. The worker is restricted to approved inference providers. Operator-run Protected jobs have reached production; broader client access and onboarding for independent providers are in testing.
Protected is being built with inference from SayGM, Bittensor subnet 28, and Engy, subnet 53. Routes differ: confidential inference hardware, an attested gateway and a provider's zero-retention policy offer different privacy protections. This is composability on Bittensor: inference from one subnet helps produce a coding outcome on another. The provider privacy policy and external rollout are still being finalized.
Standard, Protected and the current access boundaries →When to use Ormas
Send a bounded ticket with a test that fails on the base commit for the right reason, when you can wait while work runs elsewhere. Keep quick edits, exploration and urgent debugging in your current agent. Split large refactors into testable tasks first. Delivery time and savings compared with your own agent are not guaranteed.
Choose between inline work, a subagent and Ormas →Providers and verification
Ormas rewards a delivered, accepted outcome rather than a model score or inference volume. We built the mechanism around the cost of repeated attempts and unfinished work. A provider commits to a firm price or a hard limit, and earns through a change that passes the client's test. That gives it a reason to improve the whole process: model choices and mixes, its harness and agent loop, planning, checking and repair, hardware and energy costs. Better execution can support a more competitive bid and more reliable delivery. If the task fails acceptance, the provider bears its cost. Its methods stay private. Inference is the input the provider optimizes. The outcome is the product.
Providers are the miners of Bittensor subnet 76. Operator-run and external providers participate. Each provider and checker must qualify for the environment it serves; registration alone does not establish support or available capacity. A provider finishing its work is not itself a payment decision; the settled receipt records the result and charge.
Deliveries are checked against the client's agreed tests. Verification is currently operated by Ormas. The test runs in a fresh environment that the provider cannot edit; checker and provider ownership may be shared.
Provider setup and the coming Protected rollout →How it works
Your agent prepares the task.
From Claude Code, Codex, GrokBuild or your own harness: a GitHub repository, the change, the test that proves it, and the files it may touch. Ormas freezes the test and required environment before bids.
A firm price. Or an estimate with a limit.
Your ceiling at submission is a maximum, never the price; an offer within it can be accepted automatically. A qualified provider commits to a firm price or an estimate with a hard limit before work starts, and works against the agreed test, which it cannot edit.
Pass → branch + receipt. Fail → no task charge.
Your test is rerun against the delivered commit in a fresh environment. Review the result branch and the settled receipt, which records the outcome and actual charge. You decide what merges.
A clear price. A defined result.
Add credits when you want to run. You are charged the firm price or the provider’s settled price, never above its hard limit. Failed acceptance has no task charge. There is no per-task platform markup. The only Ormas fee is 5.5% when you buy credits, shown as its own line at checkout.
Your acceptance tests become purchase orders; your reviewers see work only after it passed the test you wrote.