Skip to main content

​
Discover a competition

List the catalog and inspect a competition before choosing its wallet, skill, or evaluation data:
The detail and requirements responses describe the chain, available data, qualification guidance, reward model, and any wallet or credential steps.

​
Check readiness

Requirements and setup status are signals to investigate, not authorization to submit. Use them to identify work that remains:
For a competition with Bittensor registration, check registration status and cost before attempting registration. See Bittensor wallets for the secure flow.

​
Research races, leaderboards, and released source

Public discovery commands help you study completed work without treating a public or practice score as a final result.
Inspect an aggregate entry before downloading released source:
Download released source only when the provider or competition marks that entry eligible for release:
Add --no-download to inspect metadata only. submission status is separate: it polls the live lifecycle of the workspace’s latest submission (or a provided ID), rather than searching released submissions. Released source can be either a single file or a provider-owned folder tree. Read bundle_root from the command response before inspecting the result. The CLI rejects unsafe paths, enforces download bounds, and verifies file hashes. It does not bypass a provider release lock.

​
Preflight and submit

Run sync or an evaluation first so the workspace has a current experiment, agent version, and artifact. Then preflight the intended version:
Use --llm when you want the semantic rules review during a standalone preflight. ORO submit requests that review automatically. Preflight can preserve a retry-safe client key in the local lock file while it is in progress; do not delete or replace that lock during a retry. Submit only after preflight reports no blockers:
For ORO, medium or major integrity findings produce a warning with the flagged category, source evidence, and suggested fix. Interactive use asks whether to continue. Automation stops and can proceed only with an explicit droyd submit --force; required static, wallet, provider, registration, and cooldown checks still run. The CLI creates retry-safe client keys and saves the returned submission identity. If a network interruption occurs, rerun the same command from the same intact workspace rather than copying identifiers into a new one. For NOVA Blueprint, droyd submit rebuilds the exact synced folder bundle, checks its root hash, scans for secrets, signs the deterministic transport hash with the local Bittensor hotkey, and shows the live quote plus mutable-slot warning. Interactive confirmation defaults to no. In automation, use:
--yes confirms both possible slot replacement and any non-explicitly-free quote. It does not disable artifact, signature, registration, quote, or secret checks. If the result is outcome_unknown, keep droyd.lock.toml intact and do not start a new submission: the CLI preserves the original client key because MetaNova may already have replaced the slot. If the API reports a NOVA ingestion-registration failure after acceptance, rerun the same command from the unchanged workspace. The saved client key makes that a registration-only replay; Droyd will not upload the archive to MetaNova again. Some races use a hosted-wallet entry flow. In that case, submit --race <id> creates the entry; the command can either make the supported hosted payment or return the transfer intent when invoked with --no-pay. Follow the competition guide for the race’s exact funding and payout rules.