Skip to content

Bot Virus v1

Objective

Build a containerized browser bot that completes the supplied task while passing the challenge's enabled anti-bot checks. The score is based on the runner's evaluation of the submitted image, not on a locally reported value.

Evaluation flow

  1. Retrieve the current input from GET /task.
  2. Produce the required miner_output containing bot.py and Dockerfile.
  3. Send the input and output to POST /score using X-API-Key.
  4. Inspect the latest evaluator feedback at GET /result.

Only the score endpoint requires authentication. Task retrieval, result retrieval, health, and API docs endpoints are public to the challenge network.

Requirements

  • Supply exactly bot.py and Dockerfile.
  • Build for linux/amd64.
  • Make the bot robust to fresh sessions and browser/runtime variation.
  • Keep the image self-contained; the runner builds and executes untrusted miner containers in an isolated environment.
  • Follow the live OpenAPI schema. Payload fields may evolve between challenge versions, so do not copy an old request body blindly.

Submission rules

Network access

Network calls are not allowed in the submitted script. Keep the submission self-contained and do not depend on external services, downloads, APIs, or network-hosted assets at evaluation time.

Required files and limits

The score request must contain exactly the two required files. Their content is validated before evaluation:

File Maximum lines Validation
bot.py 2,000 Checked by Ruff using the challenge's TOML configuration.
Dockerfile 500 Must be supplied as the image definition.

The line limits apply to the submitted file contents. Exceeding either limit causes the submission to be rejected.

Implementation freedom

The two submitted files are the entry point, not a limit on your implementation. You may put the main logic in bot.py, generate additional files inside the image from the Dockerfile, or use another language such as JavaScript, Python, or Go. For example, bot.py may start a program created by the Dockerfile through subprocess or an equivalent process-launching mechanism.

The same submission rules apply regardless of language: preserve the required file names and limits, avoid network calls, and keep all required runtime components inside the built image.

Scoring

The runner applies two layers of checks:

  • Simple Bot is the first layer. It is a pass/fail gate containing common bot-detection checks.
  • Browser-web is the main check. Its configured browser sessions determine the submission's score.

Failures to build or run the image, timeouts, a failed Simple Bot gate, and failed browser-web checks affect the score according to deployed challenge config. Use GET /result for evaluator feedback; it is the authoritative result for a submission.

Local check configuration

Set these Boolean fields in the challenge repository's .env to enable or disable the local evaluation layers independently:

BV_CHALLENGE_SIMPLE_BOT_CHECK_ENABLED=true
BV_CHALLENGE_WEB_CHECK_ENABLED=true

Use true to enable a check and false to disable it. At least one check must remain enabled. These settings are for local testing; production evaluation uses the deployed challenge configuration.

API discovery

The deployed challenge exposes Swagger UI at /docs, ReDoc at /redoc, and the OpenAPI contract at /openapi.json. Use these endpoints to verify current payload schema and authentication requirements.