docs/validator_setup.md

Running Validator

---

Machine Requirements

To achieve optimal results, we recommend the following setup:

• Operating System: Ubuntu 24.04 LTS or higher Learn more about Ubuntu 24.04 LTS
• GPU: NVIDIA RTX A6000 with 48GB VRAM and 30 CPU Cores

---

Bootstrap System Dependencies

The bootstrap.sh script at the repository root automates the installation of core system-level dependencies:

• NVIDIA GPU drivers (default version 535)
• Docker and the NVIDIA Container Toolkit
• Python 3.11
• Base utilities (git, curl, wget, etc.)

Run the script as root with the -E flag to preserve environment variables:

sudo -E ./bootstrap.sh

Note: If you encounter dpkg lock issues (common on platforms like TensorDock), wait ~15 minutes and re-run the script. The script will automatically reboot the machine if a new NVIDIA driver was installed.

Optional environment variables

Variable	Default	Description
NVIDIA_DRIVER_VERSION	535	NVIDIA driver version to install

Once the bootstrap completes (and any reboot finishes), proceed with the rest of this guide.

---

Install PM2 (Process Manager)

PM2 is used to manage and monitor the validator process. If you haven’t installed PM2 yet, follow these steps:

1. Install npm and PM2:

   sudo apt update
   sudo apt install npm -y
   sudo npm install pm2 -g
   pm2 update
   

2. For more details, refer to the PM2 Documentation.

---

Install Redis

1. Install 'redis'

   sudo apt update
   sudo apt install redis-server
   sudo systemctl start redis
   sudo systemctl enable redis-server
   sudo systemctl status redis
   

Install Project Dependencies

Prerequisites

• Python: Version 3.10 or higher
• pip: Python package manager
• virtualenv (optional): For dependency isolation

---

1. Clone the Repository

Clone the project repository to your local machine:

git clone https://github.com/vidaio-subnet/vidaio-subnet.git
cd vidaio-subnet

---

2. Set Up a Virtual Environment (Recommended)

Create and activate a virtual environment to isolate project dependencies:

python3 -m venv venv
source venv/bin/activate  

---

3. Install the Package and Dependencies

Install the project and its dependencies using pip:

pip install -e .

---

4. Configure Environment Variables

To configure environment variables, follow these steps:

1. Create a .env file in the project root directory by referencing the provided .env.template file:

   cp .env.template .env
   

2. Set up a bucket in cloud storage. The base miner code utilizes MinIO to connect with cloud storage services, so you'll need to prepare your bucket using a platform that supports MinIO integration, such as Backblaze. Alternatively, you can modify the code to suit your specific requirements. IMPORTANT: Note that currently the region of the storage is hardcoded, and must be adjusted in vidaio_subnet_core/utilities/storage_client.py for corresponding storage, such as AWS.

3. Add the required variables to the .env file. For example:

   BUCKET_NAME="S3 buckent name"
   BUCKET_COMPATIBLE_ENDPOINT="S3 bucket endpoint"
   BUTKET_COMPATIBLE_ACCESS_KEY="S3 bucket personal access key"
   BUCKET_COMPATIBLE_SECRET_KEY="S3 bucket personal secret key"
   PEXELS_API_KEY="Your Pexels account api key"
   WANDB_API_KEY="Your WANDB account api key"
   

4. Ensure that the bucket is configured with the appropriate permissions to allow file uploads and enable public access for downloads via presigned URLs.

5. Create your Pexels API key and replace it. (https://www.pexels.com/)

6. Once the .env file is properly configured, the application will use the specified credentials for S3 bucket, Pexels and Wandb.

---

Install FFMPEG

FFMPEG is required for processing video files. Install it using the following commands:

sudo apt update
sudo apt install ffmpeg -y

For more details, refer to the FFMPEG Documentation.

---

Install VMAF

To enable video quality validation, install VMAF by following the steps below to set up a clean virtual environment, install dependencies, and compile the tool.

---

Clone the VMAF repository into the working root directory of your vidaio-subnet package:

git clone https://github.com/vidAio-subnet/vmaf.git
cp vmaf_utils/Dockerfile vmaf/Dockerfile
cp vmaf_utils/Dockerfile.ffmpeg vmaf/Dockerfile.ffmpeg
cd vmaf
git stash && git reset --hard 332dde62838d91d8b5216e9822de58851f2fd64f && git stash apply
docker build -t vmaf .
docker build -t vmaf_ffmpeg:latest -f Dockerfile.ffmpeg .

---

Competition scheduler and Modal execution

Competition mode is independently disabled by default. With it disabled, the validator does not create competition tables, scan manifests, or change any synthetic/organic inference task.

For each new competition, complete validator_competition_checklist.md. The consolidated competition contract and timeout formulas are in competitions.md.

To prepare a competition scheduler, copy the example manifest from competitions/manifests/examples/ into competitions/manifests/, update its ID, timestamps, and Volume names, and provide the stock warmup fixture. Then set:

COMPETITION_MODE_ENABLED=true
COMPETITION_DATABASE_URL=sqlite:///video_subnet_validator.db
COMPETITION_ARTIFACT_ROOT=competition_artifacts
COMPETITION_MANIFEST_GLOB=competitions/manifests/*.json
COMPETITION_SCHEDULER_INTERVAL_SECONDS=30
COMPETITION_LEASE_TTL_SECONDS=120
COMPETITION_NETWORK_TIMEOUT_SECONDS=30
COMPETITION_MAX_CONCURRENT_REQUESTS=32
METAGRAPH_REFRESH_INTERVAL_SECONDS=1800
COMPETITION_EXECUTION_ENABLED=true
COMPETITION_BUILD_BACKEND=modal
COMPETITION_ACCEPT_MODAL_BUILD_WITHOUT_SIZE_ATTESTATION=true
COMPETITION_MODAL_ENVIRONMENT=main

The validator refreshes its in-memory metagraph every 1,800 seconds (30 minutes) by default. METAGRAPH_REFRESH_INTERVAL_SECONDS controls that cadence and refreshes all metagraph vectors, including the alpha-stake values used for competition enrollment. Submission finalisation uses the most recent snapshot recorded before the state transition when locking each submitted miner's alpha-stake eligibility; it does not trigger an additional refresh.

COMPETITION_DATABASE_URL must be visible to both PM2 validator processes. The competition-mode process writes scores and final rankings to that database; the inference-mode process opens the same database only as its competition ranking source when composing on-chain weights. Its inference performance data continues to use video_subnet_validator.db. If the variable is absent from the inference process, competition rewards are disabled and weights retain the 80% compression / 20% upscaling inference fallback. Restart both processes with updated environment variables after changing the URL.

The four execution settings above enable the validator-owned Modal build and Sandbox path in testnet or production. modal builds each pinned contender repository directly on Modal, records its immutable image ID as MODAL_ACCEPTED, and starts its validator-controlled offline Sandbox. Builds and Sandbox startup run concurrently, bounded by the manifest's max_parallel_contenders value.

The pre-evaluation submission archive contains every pinned GitHub repository, the manifest-configured boss repository (when configured), and an online, integrity-checked SQLite snapshot under database/<sqlite-filename>. The SQLite source path and filename come from COMPETITION_DATABASE_URL. Backup logs print the complete S3 object names for both the archive and its inventory.json. The logged database_archive_path is the SQLite member name inside the tarball, not a standalone S3 key and not a secret. Keep the archive and inventory private because both contain sensitive competition material.

The backup privacy gate checks bucket and object ACLs and rejects wildcard public-read statements when the provider exposes bucket policy. Native AWS S3 must enable all four Public Access Block controls. A custom S3-compatible endpoint such as Backblaze B2 may report those AWS-specific controls as absent or disabled; the validator warns but does not reject the bucket when its supported bucket/object privacy checks pass. Configure the B2 bucket as private so objects require the configured application key ID and application key. Competition-mode startup runs this bucket privacy preflight before enrollment or scheduler work begins and exits on a detected violation. The same check runs again at upload time so a policy change during enrollment still fails closed.

When competition_end_time moves a competition to COMPLETED, the validator also creates a final online, integrity-checked SQLite snapshot and uploads it privately to s3://<bucket>/<artifact-prefix>/<competition-id>/final/<manifest-digest>/<sqlite-filename>. The source path and filename come from COMPETITION_DATABASE_URL. The object size and SHA-256 are verified after upload, and a successful upload is recorded in the audit event stream. Failed uploads are logged and retried on later scheduler ticks.

For a manifest-configured boss, the pre-evaluation artifact archive contains the immutable boss export as contenders/<boss_hotkey>-boss and any submission from the same hotkey as contenders/<boss_hotkey>. Both are scored; only the higher-scoring row is ranked. The final SQLite snapshot preserves is_boss and the concrete contender ID, so it identifies which solution won even though competitions.winner_hotkey remains the real payout hotkey.

Before enrollment, validate the boss configuration and exact SDK export selected by the manifest:

python scripts/competition_preflight.py \
  competitions/manifests/compression-YYYY-wWW.json \
  --validate-boss

The command must report ACCEPTED. It fails non-zero when the boss is missing from the manifest, its path escapes the validator checkout, the export is incomplete, or the normal objective static source policy returns REVIEW_REQUIRED or REJECTED.

Modal does not currently provide final-image size attestation for this build path. Setting COMPETITION_ACCEPT_MODAL_BUILD_WITHOUT_SIZE_ATTESTATION=true is an explicit operator acknowledgement of that limitation; it is not a claim that the 25 GB limit was measured. Deployments that require attested size enforcement can still integrate the stricter trusted-builder interface.

Every direct Modal contender build uses the manifest's modal_build_timeout duration, defaulting to 10m when that field is omitted. Builds run in separate client processes and use contender-specific Modal Apps, so one stalled or malicious Dockerfile cannot block another contender's parallel build. When the deadline is exceeded, the validator kills the build client, asks Modal to stop that isolated App, records the contender as rejected with BUILD_TIMEOUT, and continues the BUILDING phase. Remote App cancellation is best-effort, so operators should investigate any App that Modal still reports as active after a BUILD_TIMEOUT event.

Modal authentication for competition execution

The scheduler and enrollment path above do not need Modal credentials. The validator-owned execution path does: it creates Modal Sandboxes, looks up the manifest's input Volume, and creates a separate output Volume for each contender. The Modal SDK is installed by pip install -e . because it is listed in requirements.txt.

Contender output Volumes are created automatically as Modal v2 Volumes. V2 is required because the validator explicitly commits each completed batch with sync before reading it; this Sandbox commit operation is unavailable for v1 Volumes. Do not pre-create generated output Volumes with Modal's default v1 setting.

Generated names retain a bounded namespace from output_volume_prefix, the actual competition_id, and recognizable leading/trailing characters from the miner hotkey plus a collision-resistant suffix. For example:

vidaio-compression-2026-w30-5FRUjvY1AxpK-bLqFmJLo-bad385

The database remains authoritative for the complete hotkey-to-Volume mapping. Contender code only performs the requested transformation; it is not trusted to validate or score its output. Every returned output is committed to the contender's output Volume and independently inspected by the validator. A competition result contains only its validator-assigned output_path (or null when no output was produced); it cannot supply success, failure reason, timing, evaluation identity, hotkey, or batch identity. Results are matched to request items by position and exact output path. A valid file is scored normally; an invalid file is FAILED with zero score while retaining any measurable size, compression, VMAF, validator-measured runtime, and cost metrics. Missing outputs remain ordinary failures with no stored file. As soon as one contender has terminal results for every evaluation item, the validator terminates that contender's Sandbox without waiting for slower miners. Later scheduler ticks exclude completed contenders instead of warming them again. This does not delete the input Volume, contender output Volumes, or any files stored in them. Competition Volumes persist until an operator manually deletes them.

If an empty v1 output Volume already exists under a generated contender name, stop the validator and any Modal Apps using it, then replace it explicitly:

modal volume delete --env main --yes "$OUTPUT_VOLUME"
modal volume create --env main --version 2 "$OUTPUT_VOLUME"

Never delete a non-empty output Volume as an automatic repair. Modal does not provide an in-place v1-to-v2 upgrade; migrate data that must be retained to a separately named v2 Volume first.

Authenticate the operating-system user that runs the validator:

modal setup

For a headless host or a validator managed by PM2, provide a Modal token in the validator process environment instead. Do not put this token in a miner submission or expose it to a contender Sandbox.

MODAL_TOKEN_ID=your-modal-token-id
MODAL_TOKEN_SECRET=your-modal-token-secret

Make sure the selected Modal environment exists and contains the read-only input Volume named by evaluation_input_volume_name in the competition manifest. The validator uses the environment selected by COMPETITION_MODAL_ENVIRONMENT (dev by default). Its launch policy passes secrets=[], disables OIDC identity, and blocks outbound networking, so the validator's Modal token remains in the trusted host process rather than inside contender code.

For example, create the manifest's input Volume before starting the validator:

INPUT_VOLUME=vidaio-competition-compression-2026-w30-inputs
modal volume create \
  --env main \
  "$INPUT_VOLUME"

INPUT_VOLUME must exactly match the manifest's evaluation_input_volume_name.

Creating the Volume does not upload the evaluation dataset. An empty Volume causes the validator to remain in EVALUATING while its Sandboxes continue to answer /health. Phase 4 dispatch starts only after the Volume contains a read-back-verified index and source files and that exact index digest is sealed in the competition database.

Prepare, validate, upload, and seal the Phase 4 dataset

Choose the manifest that the validator will load, a private directory containing the source MP4 files, a temporary local index path, and the validator's actual SQLite URL:

MANIFEST=/absolute/path/to/competitions/manifests/compression-2026-w30.json
SOURCE_DIR=/absolute/path/to/private-evaluation-videos
INDEX=/tmp/compression-2026-w30-index.json
DATABASE_URL=sqlite:////absolute/path/to/video_subnet_validator.db

Run all four operations, in this exact order, from the same deployed repository and virtual environment as the validator. The CLI enforces the sequence:

python scripts/competition_dataset.py prepare \
  --manifest "$MANIFEST" \
  --source-dir "$SOURCE_DIR" \
  --index "$INDEX"

python scripts/competition_dataset.py validate \
  --manifest "$MANIFEST" \
  --source-dir "$SOURCE_DIR" \
  --index "$INDEX"

python scripts/competition_dataset.py upload \
  --manifest "$MANIFEST" \
  --source-dir "$SOURCE_DIR" \
  --index "$INDEX" \
  --environment main

python scripts/competition_dataset.py seal \
  --manifest "$MANIFEST" \
  --index "$INDEX" \
  --environment main \
  --database-url "$DATABASE_URL"

prepare probes every MP4 and records immutable size, checksum, duration, dimensions, frame count, codec, pixel format, and aspect ratio metadata. Each source becomes exactly one compression evaluation row. Its CRF or VBR mode and VMAF target (85, 89, or 93) are selected by deterministic pseudorandom choice seeded from the manifest; VBR queries also receive a 5, 8, or 10 Mbps target. Rebuilding an unchanged index therefore produces the same query set. A full five-item batch always contains five distinct physical videos. prepare also writes <index>.pipeline.json, binding the manifest and index digests to the source directory and file identities. validate checks that receipt, the index contract, and that the prepared files remain unchanged; it does not repeat the full hashing and probing already performed by prepare. Keep the receipt beside the index through sealing. prepare places the canonical batch prefix in each indexed source path. upload requires the validated receipt and writes the trusted index and only the immutable canonical-batch source trees to the manifest's input Volume, then reads back every indexed source to verify its checksum. It does not create a duplicate root inputs/ tree. It refuses to replace a different index. Successful read-back advances the receipt to uploaded. seal requires that receipt and verifies the remote/local index digest before writing immutable evaluation rows to SQLite; it does not download and probe every verified video again. An upload verification failure requires a new competition ID and Volume; the uploaded index and batch trees are never narrowed or replaced. If the database does not exist yet, seal creates it, applies the competition migrations, and registers the manifest in SCHEDULED state. If the competition already exists, it requires the database manifest digest to match and therefore cannot silently replace the validator's configured revision.

Because the sealed index and contender API contract are immutable for a live competition, use a new competition ID for this one-query-per-video format and require miners to republish with the matching SDK (--refresh when upgrading an existing prepared repository).

This means the entire sequence can run while the validator is stopped. On its first boot the validator finds the pre-registered, pre-sealed competition and starts it automatically when competition_start_time is due. Keep the manifest file in COMPETITION_MANIFEST_GLOB and point COMPETITION_DATABASE_URL at the same database passed to seal.

Use an absolute SQLite URL as shown above, or prove that the CLI and PM2 use the same working directory. Sealing a different relative database file will leave the running validator waiting for a dataset even though the CLI reported success. Preloading is recommended, but not mandatory: the validator may also start with an empty Volume and wait in EVALUATING; completing the mandatory four-stage pipeline later unblocks it on the next execution cycle. After late sealing, restart or wait for that cycle:

PM2_APP=video-validator-testnet
pm2 restart "$PM2_APP" --update-env

Expected progress logs include Dispatching competition batch, Competition batch persisted, EVALUATING -> SCORING, SCORING -> AWAITING_END_TIME, and Competition Phase 4 complete. Each contender logs Contender Sandbox terminated after evaluation with trigger=contender_dataset_complete and volume_retained=true as soon as its own work is done. Dataset checksum mismatches and missing outputs remain fail-closed in EVALUATING with a reason-coded log. See competition_phase4_dataset_runbook.md for the focused operator procedure.

Competition execution and scoring deadlines are derived from each batch's sealed media metadata. Encoding is modeled as four parallel video lanes, with each video split into 10-minute chunks. A 10-minute 4K chunk takes two minutes; every started chunk receives that full allowance, including videos shorter than 10 minutes and final partial chunks. Every video also has an absolute two-minute processing floor before parallel scheduling, so resolution scaling cannot reduce a short video below that allowance. Work above the floor scales linearly with pixel count. VMAF scoring is modeled sequentially at 200 FPS for 4K and also scales with pixel count. Both processing deadlines include two minutes for Volume I/O and startup, and the database execution lease includes another two minutes for validator recovery and outcome persistence. The Sandbox row records the most recently applied invocation deadline, while each batch row records its attempt-specific execution lease and scoring deadline.

The manifest's evaluation_batched_run_timeout and scoring_batched_run_timeout are minimum deadlines, not fixed estimates. Dynamic workload calculations may increase them but never reduce them. The full minimum also applies to partial final or explicitly operator-requeued batches and is not prorated by item count. See competitions.md for the formulas, persistence semantics, and worked examples.

The validator creates every /output/evaluations/<batch-id> directory before calling the contender's /compress route. A Sandbox request failure is logged with its reason code and redacted detail; the persisted summary reports the actual post-attempt status and a per-reason count. If any current terminal item failed for a validator-infrastructure reason, evaluation stays fail-closed in EVALUATING instead of applying that failure to a contender's score. A vanished Sandbox is detected by polling its lifecycle independently from the request process, so control-plane delay does not inflate recorded runtime to the full invocation deadline. Sandbox creation, isolation, and readiness are a pre-dispatch gate: failure to warm any eligible contender pauses dispatch before claims are created, so a startup outage does not consume evaluation attempts. Startup and recovery details are also retained in the redacted SANDBOX_CLOSED audit event.

After fixing validator infrastructure, an operator can requeue those exhausted attempts without deleting their history. Stop the validator first so the repair does not race its scheduler, use the same absolute SQLite URL, then restart it:

python scripts/competition_repair.py requeue-infrastructure \
  --competition-id compression-2026-w30 \
  --database-url "$DATABASE_URL" \
  --reason-code SANDBOX_START_FAILED \
  --apply

pm2 restart "$PM2_APP" --update-env

For a Sandbox that exits during an active batch, use --reason-code SANDBOX_DISAPPEARED. Inspect the Modal lifecycle event and exit code first; the repair is for validator/platform loss, not a reproducible contender-controlled crash.

The repair accepts only allowlisted infrastructure reason codes, records an EVALUATION_INFRASTRUCTURE_REQUEUED audit event, retains old attempts as REQUEUED, and returns an AWAITING_END_TIME competition to EVALUATING. New attempts continue with increasing attempt numbers.

Before enabling competition execution, verify authentication and the offline Sandbox policy with the bounded live probe (this creates a short-lived Modal Sandbox and may incur a small charge):

python scripts/competition_modal_phase0_probe.py \
  --environment main \
  --skip-billing

Omit --skip-billing only when validating billing-report capability. Billing reports require a supported Modal Team or Enterprise workspace; they are not required for the network-isolation probe.

Current implementation status: the live validator now orchestrates submission finalisation, static-validation acceptance, image building, isolated Sandbox startup, durable evaluation dispatch, output validation, VMAF and cost scoring, and the transition to AWAITING_END_TIME. Batches are sequential per warm contender while different contenders run concurrently up to max_parallel_contenders. SQLite is authoritative for claims, lease expiry, terminal failure persistence, and exact-once result persistence; Redis is not required for recovery. Sandbox-forward, storage/scoring, and lease-expiry failures are not automatically retried. Existing DEVELOPMENT_ACCEPTED rows remain readable for migration.

Competition cost scoring locks Modal's public rates as of 2026-07-21: B300 $0.001972/s, B200 $0.001736/s, H200 $0.001261/s, H100 $0.001097/s, RTX PRO 6000 $0.000842/s, A100 80 GB $0.000694/s, A100 40 GB $0.000583/s, L40S $0.000542/s, A10 $0.000306/s, L4 $0.000222/s, and T4 $0.000164/s. Modal's separate Sandbox CPU rate is $0.00003942/physical-core/s. The validator probes the GPU model/count and CPU allocation inside every running Sandbox, persists them separately from the request, and estimates the full batch wall time from that observed allocation. Batch active_runtime_seconds is therefore equal to wall_runtime_seconds; failed validation, failed scoring, and other terminally failed items still consumed the Sandbox and retain their equal share of runtime and estimated cost. Automatic evaluation replay is disabled, preventing a contender from deliberately failing long videos and processing them later to alter the normal cost aggregate. Per-item compression ratio, VMAF, checksums, and media sizes are retained on failed rows whenever those measurements could be completed safely. A metric remains null only when the output could not be read, probed, or compared sufficiently to produce it. It does not attempt to reproduce the final Modal invoice: memory above the request, image builds, Volume storage, credits, reservations, taxes, CPU utilization reconciliation, and unrelated workspace usage are excluded. Some Modal automatic GPU upgrades retain the requested SKU's invoice rate; invoice-aligned data belongs in reconciled_cost_usd, while competition estimates consistently price the observed hardware.

Competition scoring version 3 keeps each item's media score absolute: it comes directly from services/scoring/scoring_function.py using its measured compression rate, measured VMAF, and sealed VMAF target. Cost efficiency is relative for each evaluation item. The cheapest valid contender receives 1.0 and every other valid contender receives minimum_valid_cost / own_cost. Failed and invalid outputs receive zero and cannot define the minimum. Because cost is population-dependent, aggregate scoring must use the complete finalized evaluated contender set.

The start time may fall on any day of the week. At startup the validator normalizes and hashes each manifest and persists it in competition-only SQLite tables. If a manifest with the same ID changes while its competition is non-terminal, the validator updates the database fields used by the scheduler, appends a MANIFEST_UPDATED audit event containing the old/new digests and field-level changes, archives the prior normalized manifest below competition_artifacts/<competition-id>/manifest.revisions/, and makes the new normalized manifest current. Completed, failed, and cancelled competitions stay immutable and require a new competition ID.

If SQLite and manifest.normalized.json contain different revisions after an interrupted update, SQLite remains authoritative. The validator preserves the divergent file as manifest.revisions/observed-<sha256>.json, appends a MANIFEST_ARTIFACT_DIVERGENCE audit event with the observed/database/requested digests, and atomically restores the requested manifest as current.

Startup fails closed if the configured warmup fixture is absent. The control scheduler advances persisted lifecycle state. If both the edited start and contender-finalisation times are already past, one scheduler tick advances the competition through ENROLLING to FINALIZING_SUBMISSIONS. No invitations are sent in that case because the collection window has already closed. Otherwise, on entry to ENROLLING, the validator snapshots serving miner axons, sends each miner a competition invitation, and immediately polls opt-ins for a submission. NOT_READY miners are polled again at contender_ping_interval until contender_finalisation_time; invitation and polling attempts survive validator restarts. A READY response is cloned and pinned immediately so the raw repository credential is never persisted. Trusted builds and evaluation remain separate fail-closed lifecycle gates.

Only COMPRESSION manifests are active today. The code reserves a future upscaling media contract with three distinct roles: (i) high-resolution ground truth held for trusted scoring, (ii) a downsampled reference mounted as the miner input, and (iii) the miner-processed output. The upscaling adapter remains an explicit NotImplementedError stub; do not configure or advertise an upscaling competition until its manifest, route, isolation policy, and scorer are implemented and tested.

Keep COMPETITION_MODE_ENABLED=false in production unless the outstanding trusted-builder Phase 0 gate is satisfied or the operator has explicitly accepted the unattested direct-Modal build limitation described above.

Running the Validator with PM2

To run the validator, use the following command:

pm2 start run.sh --name vidaio_v_autoupdater -- --wallet.name [Your_Wallet_Name] --wallet.hotkey [Your_Hotkey_Name] --subtensor.network finney --netuid 85 --axon.port [port] --logging.debug

Parameters:

• --wallet.name: Replace [Your_Wallet_Name] with your wallet name.
• --wallet.hotkey: Replace [Your_Hotkey_Name] with your hotkey name.
• --subtensor.network: Specify the target network (e.g., finney).
• --netuid: Specify the network UID (e.g., 85).
• --axon.port: Replace [port] with the desired port number.
• --logging.debug: Enables debug-level logging for detailed output.

---