OctaSpace Machines

Purpose

Containerized Presearch Vector workload deployment.

This page explains how to deploy a Docker container on OctaSpace to process workloads for Presearch Vector NFTs. The deployment is security-restricted and designed to run only on approved machines that meet Vector node requirements.

The container manages one or more Presearch Vector NFT tokens, runs workloads on available GPUs, tracks daily progress, and exits after the configured minimum threshold is reached. Multiple tokens can be processed by one deployment. Workload behavior and completion time can vary depending on the specific machine, including GPU and CPU performance, as well as the particular workload bucket being processed. The 2–8 hour estimate is therefore only a rough planning estimate.

Authorized machines

Approved node IDs.

Only these node IDs are allowed. These machines are hosted by different operators across the world and have been tested by GCNLab to confirm that they can successfully process Presearch Vector node workloads. You must select one of these authorized machines in OctaSpace Cube; deployments on other machines are expected to fail authorization and exit.

Loading

Reading gpu-auth.json…

Want to add your node? Requests to authorize additional machines can be sent to contact@gcnlab.fyi. Machines must meet Presearch Vector node requirements, provide stable performance, and demonstrate high reliability (above 99%).

Deployment configuration

Find an authorized machine, then configure the container.

Enter the image name and environment variable names exactly as shown. Paste your own values into the value column in OctaSpace Cube.

1

Find an authorized machine

In OctaSpace Cube, first look for an available machine whose node ID appears in the authorized list above. Do this before entering deployment details.

2

Enter the container image and disk size

Select a custom image, paste the image name exactly as shown, and set disk size.

Image name gcnlabfyi/gcnlab-pretext-2gpu:latest

Disk size 30 GB

Use 30 GB unless you have a specific reason to change it.

3

Add environment variables

Add these variable names exactly as shown.

Variable name TOKEN

One token ID, or multiple token IDs separated by commas.

Variable name REGISTRATION_BASE

Your registration ID without the machine and worker suffix. The container appends the authorized node ID and worker suffix automatically.

Variable name MIN_WORK

Minimum daily MTD target per token. Usually 20.

4

Optional: keep deployment active for the next round

By default, the container exits after the configured minimum MTD is completed and the OctaSpace deployment normally ends.

Variable name EXIT_WHEN_COMPLETE

Optional. Set to false to keep the container active after the minimum MTD is reached, so it can process again in the next UTC work round.

5

Deploy

After confirming the machine, image name, and environment variables, click Deploy in OctaSpace Cube.

Example configuration

Click image to enlarge

Example OctaSpace deployment configuration

After deployment

Use container logs to confirm authorization and progress.

Logs should confirm authorization, token progress, GPU assignment, and registration codes.

Example logs

Click image to enlarge

Operating rules

Daily work is tracked by UTC work rounds.

UTC work round

Daily progress is tracked using UTC day boundaries. A new work round begins with each new UTC day.

Multiple tokens

One deployment can process one token or multiple tokens. When multiple tokens are provided, the manager rotates between them according to current progress.

Minimum MTD reached

After all configured tokens reach the MTD threshold for the current UTC day, the manager stops launching new work.

Default completion

By default, EXIT_WHEN_COMPLETE=true. The container exits cleanly after all tokens reach the configured minimum MTD.

Keep-active behavior: set EXIT_WHEN_COMPLETE=false to keep the container alive after today’s minimum MTD is completed. It will restart processing after the next UTC day begins.

Legal notice

Limitation of responsibility

All GCNLab information, services, instructions, endpoints, deployments, validators, providers, and related materials are provided on an “as is,” “as available,” and “use at your own risk” basis. GCNLab makes no warranties or guarantees regarding availability, performance, rewards, profitability, accuracy, security, compatibility, or continued operation.

Users are solely responsible for their own configurations, accounts, keys, tokens, funds, deployments, delegations, staking decisions, costs, losses, missed rewards, downtime, third-party service issues, and any other consequences of using GCNLab materials or services.

GCNLab does not provide refunds, reimbursements, compensation, service-level commitments, or liability coverage. By using any GCNLab information or service, you agree that GCNLab is not liable for any direct, indirect, incidental, consequential, special, punitive, financial, operational, technical, or other damages.