Your guide
to Perla mining.

Run a Pearl-compatible GPU worker, bind its work to your EVM wallet, and follow accepted contributions in Perla. Settlement is designed for Robinhood Chain.

The guide separates participant installation from operator deployment. The downloadable adapter contains the bridge, build scripts, native verifier, and upstream attribution.

Useful computation.
Verifiable shares.

1. Authorize your wallet.A short-lived, single-use signed message opens a browser account. It authorizes worker management, not transactions.
2. Register a worker.The dashboard issues a dedicated, revocable worker token. The server stores its hash; the token is shown once.
3. Receive a work challenge.Perla creates a random job bound to the worker, wallet, UTC contribution epoch, site, and Robinhood Testnet domain.
4. Run AI inference.The pinned Pearl vLLM plugin replaces supported dense linear operations with its NoisyGEMM CUDA kernels. Mining shares are produced during those operations.
5. Verify and account.The local bridge submits the native PlainProof. An isolated native verifier checks the work. Only an accepted proof creates a durable contribution record.
6. Settle a funded epoch.The operator publishes a deterministic allocation root and funds the reward contract. Eligible wallets can then claim with a Merkle proof.

Perla reuses Pearl’s miner/proof interface and native verifier. It supplies a separate coordinator and Robinhood settlement layer. Its work envelopes are not Pearl blocks, and no new blockchain is launched.

What the worker
is designed to do.

The initial path runs supported dense matrix operations during AI inference through the pinned Pearl vLLM integration. The native proof and the model response are separate outputs: one verifies admitted mining work, while the other is the model’s answer.

There is no published Perla GPU throughput, energy-saving, accuracy comparison or earnings benchmark for this path. CPU-generated test proofs validate the protocol and ledger; they do not demonstrate a deployed GPU model.

An accepted share does not attest the physical GPU, prove that a paying client requested the work, or establish the semantic correctness of a full model response. A public customer-job marketplace is outside the current release.

Built for
Robinhood Chain.

The validation release uses Robinhood Chain Testnet for reward contracts. GPU computation and native proof verification run offchain. Participants do not need to run a blockchain node.

Use a test wallet and test tokens for validation. Production token distribution requires a separate deployment; the operator CLI refuses other chains.

Start with
supported hardware.

Kernel architecture support does not guarantee that a model fits your GPU memory. The command below uses two visible GPUs for the reference checkpoint. Other GPU families, CPU mining, Windows-native mining, and MoE models are outside this validation profile.

nvidia-smi
docker buildx version
docker info

A browser tab cannot run these native kernels. Keep your seed phrase and private keys out of the miner configuration.

Bring a worker
online.

1. Create your worker configuration

Open the mining dashboard, choose Sign in with wallet, and sign the displayed authorization message. Choose Add worker, enter a name, then download worker.env. Also download the worker package above. The token is scoped to that worker and cannot spend wallet funds.

2. Extract and build

Put the downloaded archive and configuration in your working folder. Extract the package, move worker.env into its folder, and restrict its permissions. Inspect the build script before running it.

tar -xzf perla-worker.tar.gz
mv worker.env perla-worker/
cd perla-worker
chmod 600 worker.env
less setup-worker.sh
bash setup-worker.sh

The script checks the GPU architecture, fetches the exact upstream commit, preserves its licenses, initializes submodules, builds Pearl’s image, and adds the Perla bridge. It does not install a Pearl node or create a Pearl wallet. The build downloads large CUDA, PyTorch, vLLM, and model-related dependencies.

Download the checksum list alongside the archive and compare it before building:

sha256sum --ignore-missing -c SHA256SUMS

3. Start the worker

This reference command uses two GPUs and keeps the inference endpoint bound to your host’s loopback interface. Set tensor parallelism and memory limits for your actual hardware before starting.

docker run -d --name perla-worker --restart unless-stopped \
  --gpus all --env-file worker.env \
  -p 127.0.0.1:8000:8000 --shm-size 8g \
  -v "$PWD/hf-cache:/root/.cache/huggingface" \
  perla-worker:0.1 pearl-ai/Llama-3.3-70B-Instruct-pearl \
  --host 0.0.0.0 --port 8000 --tensor-parallel-size 2 \
  --max-model-len 2048 --gpu-memory-utilization 0.85 --enforce-eager

4. Check connectivity

docker logs --tail 100 -f perla-worker
curl --fail http://127.0.0.1:8000/v1/models

The bridge logs its local listener and accepted-share receipts. A worker appears online after a successful work request. A running vLLM process alone does not mean a share was accepted. If the coordinator is private, an external worker cannot reach it without an authorized deployment/access arrangement.

Run an
AI request.

Mining happens during supported matrix operations. An idle model server does not manufacture contribution points. Send an actual inference request to the worker:

curl --fail http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"pearl-ai/Llama-3.3-70B-Instruct-pearl","messages":[{"role":"user","content":"Explain matrix multiplication in one paragraph."}],"max_tokens":128}'

Read the model response, inspect the worker logs, then refresh the Contributions tab. A response and a share are separate outcomes; not every request necessarily yields a share. The initial integration does not include a public inference marketplace, billing, or automatic customer traffic.

A worker you
can manage.

docker logs --tail 100 perla-worker
docker stats --no-stream perla-worker
docker stop perla-worker
docker start perla-worker

Stopping the container stops the miner and bridge. Accepted contribution records remain on the server. To retire an installation, revoke its token in the dashboard and stop the container. Revocation rejects new jobs and re-checks in-flight submissions before crediting work.

Update and uninstall

This release pins upstream code rather than automatically pulling a moving branch. For an approved update, download the new package, read its release notes, stop the container, build the new revision, and recreate the container with the existing configuration. Do not delete the model cache unless you intend to download it again.

docker stop perla-worker
docker rm perla-worker
# Revoke the worker token in your dashboard.
# Remove worker.env and the extracted package when no longer needed.

Worker configuration is independent from wallet keys. A lost token cannot be displayed again; revoke it and create a replacement.

Proof first.
Accounting second.

The verifier uses the pinned pearl_mining native implementation of certificate-version-3 PlainProof validation, including its matrix/Merkle/noise and proof-of-work checks. Initial admission is limited to dense GEMM with rank 128 and bounded dimensions and payload sizes.

Jobs expire after five minutes. Their native challenge binds the site, chain, epoch, worker, recipient wallet, and random job ID. A proof cannot be moved to another job or wallet. One job can be credited once; a database uniqueness constraint prevents concurrent duplicate credits. Worker-supplied speed, uptime, and reward amounts are never used as proof.

A dedicated operator runs the native verifier. Proof parsing runs in a CPU/time/memory-bounded subprocess and fails closed. Perla does not currently verify Pearl ZK certificates inside an EVM contract. Reward-root publication therefore trusts the operator’s offchain accounting.

A valid mathematical share does not attest to a particular physical GPU or prove that a paying customer requested an AI response. The CPU fixture utility exists only to test protocol correctness; it is not an AI workload, hardware benchmark, or profitability demonstration.

One billion tokens.
Two separate networks.

The testnet deployment source creates 1,000,000,000 tPERLA with 18 decimals and no additional mint function. The planned mainnet supply is also 1,000,000,000 PERLA. These are separate contracts and balances; equal supply does not create a bridge or a conversion right.

Pearl issues native block rewards. Perla instead distributes existing ERC-20 tokens from funded epochs on Robinhood. Mainnet mining requires a funded reserve from the planned Pons launch or later treasury acquisition. Its size and custody have not been set. Launching a 1B token does not itself make those tokens available for mining.

Clear contributions.
Explicit allocations.

For the validation profile, each accepted share adds one contribution point. The share target is fixed by the coordinator. An epoch is a UTC day; jobs that cross its boundary retain their original epoch until they expire.

The operator closes an epoch after its final jobs expire, snapshots accepted points, and prepares a deterministic Merkle tree. Integer rounding uses largest remainders with address-based tie-breaking, so allocations sum exactly to the budget.

The immutable reward root must be funded with actual ERC-20 test tokens. The dashboard only exposes allocations after the coordinator reads the expected token, root, budget, and chain from the contract. Claims bind the chain, distributor contract, epoch, index, recipient, and amount. Anyone may relay a valid claim, but the tokens always go to its committed recipient.

Publishing reward roots is an operator responsibility. The contract cannot independently determine whether all offchain contributions were included. Claiming requires test ETH for gas and an active funded epoch.

What you operate.
What you pay for.

Perla does not offer a paid managed-GPU plan in this release. There is no published earnings-per-hour estimate or guarantee that contribution points offset hardware costs.

Keep credentials scoped.
Understand the operator.

The browser uses an HttpOnly account session to manage workers. A worker receives its own bearer token; the database stores that token’s hash. Account reads expose worker records and accepted contribution history, not the original token.

The coordinator receives native proof payloads and forwards them to the verifier. Persistent contribution records include the job, worker, recipient, epoch, time, points and proof hash. Reward manifests commit wallet addresses and allocation amounts.

AI prompts, outputs, checkpoints and model caches are handled on the worker host. Native proofs can disclose parts of the mathematical workload. This release does not provide confidential inference or a zero-knowledge privacy guarantee; a host operator can access the workloads it handles.

The reward contract enforces its funded root. Participants still trust the operator to run the native verifier correctly, retain accepted records, and include the complete eligible ledger in the allocation. An external audit has not been completed.

Never put recovery words or private wallet keys in worker.env. Revoke an exposed worker token and create a replacement. The operator’s verifier and epoch-management secrets belong only in server configuration.

Deploy the
verification service.

The website stores accounts, jobs, contributions, and reward manifests in its persistent SQLite database. Run the native verifier on a separate Linux host behind HTTPS. It requires CPU resources, not a GPU. The GPU worker is a separate process.

The operator package includes the verifier, contracts, and CLI. Use Node.js 22.13 or newer and a Linux host with Docker. Extract it and install the pinned CLI dependencies:

tar -xzf perla-operator.tar.gz
cd perla-operator
npm install
cd services/pearl-adapter

Create verifier.env locally with a random verifier-only secret:

python3 -c 'import secrets; print("PERLA_VERIFIER_TOKEN=" + secrets.token_hex(32))' > verifier.env
chmod 600 verifier.env

docker build -f Dockerfile.verifier -t perla-verifier:0.1 .
# Create a random PERLA_VERIFIER_TOKEN in verifier.env and chmod 600 it.
docker run -d --name perla-verifier --restart unless-stopped \
  --memory 5g --cpus 4 --env-file verifier.env \
  -p 127.0.0.1:8766:8766 perla-verifier:0.1

Terminate TLS at a reverse proxy and forward only to the loopback verifier. Keep its bearer token private. Configure the website with PERLA_VERIFIER_URL, matching PERLA_VERIFIER_TOKEN, and a separate PERLA_OPERATOR_TOKEN. Set PERLA_MINING_ENABLED=true only after the health check and real GPU inference-to-share flow pass.

Return to the package root with cd ../.. for the reward CLI. Configure PERLA_ENDPOINT and the same PERLA_OPERATOR_TOKEN as the website. Set PERLA_REWARD_TOKEN after deploying the test token, then PERLA_DISTRIBUTOR_ADDRESS after deploying the distributor. Keep PERLA_PRIVATE_KEY in your local environment and use a dedicated test wallet.

The source includes contracts/PerlaRewards.sol, a test token, and the scripts/perla-rewards.mjs operator CLI. All CLI chain operations reject networks other than Robinhood Testnet. Keys are read from environment variables and never requested by the website.

node scripts/perla-rewards.mjs compile
# Configure PERLA_RPC_URL, PERLA_PRIVATE_KEY and test-token addresses locally.
node scripts/perla-rewards.mjs emission 1
# Preview only. Then deploy the fixed 1B tPERLA token.
node scripts/perla-rewards.mjs deploy-test-token
node scripts/perla-rewards.mjs deploy
# Configure the returned distributor and token in the website runtime.
node scripts/perla-rewards.mjs prepare EPOCH BUDGET_BASE_UNITS
node scripts/perla-rewards.mjs fund epoch-EPOCH.json
node scripts/perla-rewards.mjs activate EPOCH

EPOCH is the integer UTC day: Math.floor(unixSeconds / 86400). Only fully closed epochs can be prepared. BUDGET_BASE_UNITS is an integer amount in the token’s smallest unit. Replace these placeholders before running commands.

Review the generated allocation manifest before funding. The native-verifier container and GPU installation must be validated on their deployment hosts; a successful web build does not validate a CUDA runtime.

Find the
right signal.

The words
used in this guide.

Worker

One registered miner installation with its own access token.

Coordinator

The service that authorizes workers, issues challenges and records accepted contributions.

Job

A five-minute mining challenge for a specific worker and recipient; it is separate from an AI request.

Share

A native proof accepted for that job under the current admission rules.

PlainProof

The native Pearl proof format checked by the pinned mathematical verifier.

NoisyGEMM

The upstream matrix-computation integration used by the supported mining profile.

Epoch

One UTC day of contribution accounting. Jobs retain the epoch in which they were issued.

Contribution point

One unit of validation accounting awarded per accepted job in this profile.

Reward root

A Merkle commitment to the wallets and amounts in a funded epoch allocation.

Claim

A contract call that proves inclusion in the funded allocation and pays its committed recipient.

Before your
first installation.

Built to verify.
Released in stages.

The initial goal is a reproducible GPU inference request, accepted native proof, persistent contribution, and funded test-token claim. Mainnet rewards require a separate launch and validation decision.