Compute a response.
A supported model runs on the participant’s GPU host through the Pearl-compatible vLLM worker.
PERLA / VALIDATION RELEASEView release statusGPU mining.
GPU mining.
For AI compute.
Run AI inference through a Pearl-compatible worker. Perla checks native mining proofs, records accepted shares for your wallet, and prepares funded settlement on Robinhood.
↗Robinhood settlementGPU validation pending
PERLA / COMPUTECompute. Contribute. Verify.
GPU mining workerINITIAL VALIDATION PROFILEsm90
Proof checkingNative · offchain
Reward settlementRobinhood Testnet
Read the current validation scopeAI-oriented GPU workNative share verificationWallet-bound contributions↗Robinhood settlement
01 / THE PURPOSEAI needs matrix work.
AI needs matrix work.
That is where we begin.
Matrix multiplication sits inside the dense layers of an AI model. Perla’s first integration connects supported operations to a mining proof and a contribution record.
Produce a share.
Supported matrix operations can yield a candidate that satisfies the coordinator’s mining challenge.
Record its recipient.
Perla verifies the native proof and credits the worker’s registered wallet when the job is accepted.
An AI response and an accepted share are different outcomes. The proof checks admitted mining work; it does not certify the truth of a model’s answer.
Read the whitepaper02 / THE INITIAL PROFILEA specific workload.
A specific workload.
A stated validation scope.
Kernel support, model fit and measured GPU performance are separate questions. This release documents the reference configuration and the evidence actually available.
| Workload | What it produces | Current evidence |
|---|---|---|
| Dense matrix computationPearl NoisyGEMM · rank 128 · certificate v3 | Matrix work and a native mining proof | Integration implementedGPU execution remains a deployment-host check. |
| Reference text inferencepearl-ai/Llama-3.3-70B-Instruct-pearl · pinned vLLM plugin | An AI response, with shares possible during supported operations | GPU validation pendingThe reference command uses two GPUs. Actual VRAM needs depend on configuration. |
| Protocol test fixtureCPU-generated native PlainProof | Reproducible proof-to-ledger validation | Software testedThis exercises mathematics and accounting; it is not an AI service or GPU benchmark. |
No Perla throughput, energy saving or profitability benchmark is published for the GPU path. The reference model and supported kernel profile still need a complete run on the deployment hardware.
Check hardware and installation requirements03 / ACCEPTANCE RULESA submission goes through
A submission goes through
four clear checks.
The ledger credits an accepted job after verification. Reported speed and time online are not acceptance criteria.
Bound to one job
The submitted proof must belong to the authenticated worker’s unexpired challenge. The recipient is taken from the account.
Checked natively
The pinned Pearl verifier checks the supported certificate and matrix proof. Invalid or unavailable verification earns no points.
Committed once
Before recording a share, the coordinator checks expiry, revocation and epoch closure again. A unique job constraint blocks double credit.
Funded before a claim
The distribution contract must match the expected chain, token, root and budget before an allocation appears in the account.
Where operator trust remains
Read the trust modelThe verifier and contribution ledger run offchain. The operator publishes the allocation root; the reward contract cannot independently reconstruct every contribution.
04 / PARTICIPATIONBring hardware.
Bring hardware.
Keep your wallet in control.
Registration sets up an account and a worker credential. A participant also needs a reachable coordinator, supported hardware and active work admission.
- 01
Authorize a wallet
Sign a one-time message to manage your mining account. Your address becomes the recipient for that account’s contributions.
- 02
Register a worker
Give the installation a name. Save its revocable token once and download the worker configuration.
- 03
Receive a challenge
The coordinator creates a short-lived job bound to this site, network, epoch, worker and recipient.
- 04
Run inference
The supported Pearl vLLM integration produces mining proofs during dense matrix operations in an AI request.
- 05
Check the proof
An isolated native verifier checks the admitted work. An accepted job creates one persistent contribution record.
- 06
Publish a funded epoch
The operator snapshots points and funds a distribution root. The account shows a claim after onchain activation checks pass.
05 / CONTRIBUTIONS & SETTLEMENTA point records work.
A point records work.
A funded root enables a claim.
The initial profile awards one point per accepted job. UTC epochs group those records into a reviewable allocation.
ILLUSTRATIVE ALLOCATION · NOT LIVE REWARDS
- Total epoch points
- 100
- Your accepted points
- 25
- Example funded budget
- 1,000 test units
- Your example allocation
- 250 test units
25 ÷ 100 × 1,000 = 250. Actual integer allocations use token base units and deterministic rounding.
Before a wallet can claim
- The UTC day and its remaining jobs have closed.
- The operator has prepared the points snapshot.
- The exact allocation root is funded with test tokens.
- Perla has checked the chain, token, root and budget.
Points do not establish a mainnet balance, fixed yield or token allocation. A future Pons launch requires separate distribution decisions.
Read the complete reward lifecycle06 / SECURITY & LIMITATIONSKnow what is checked.
Know what is checked.
Know who operates it.
Account controls, native proof checks and contract rules cover different parts of the system. Their limits are part of the documentation.
Wallet authorization
Expiring, domain-bound challenges are consumed once. Account sessions use HttpOnly cookies.
Worker access
Each worker has a separate revocable token. The ledger stores a hash of the token, and account reads do not reveal it.
Proof processing
Request sizes, supported dimensions and verifier resources are bounded. Verification failures do not create contribution records.
Reward claims
The claim commits to the chain, contract, epoch, allocation index, wallet and amount. Repeating a claim cannot pay it twice.
Native verification: the accepted mathematical share is checked offchain. It does not attest physical hardware, customer demand or the quality of a complete AI response.
Review status: automated software tests have passed for the documented scope. An external audit, deployed GPU benchmark and live funded reward demonstration remain separate requirements.
07 / RELEASE PATHValidate the foundation.
Validate the foundation.
Then open participation.
Milestones follow working evidence rather than a launch-date promise. The status page separates software checks from deployment and contract activation.
Native mining integration
Wallet accounts, worker tokens, native proof checks, a durable ledger and funded reward tooling.
GPU validation pendingA complete testnet flow
Run supported GPU inference, accept a native share, validate a reachable service and demonstrate a funded test-token claim.
Operator validationA broader AI platform
Expand hardware and workload support, then assess managed capacity, AI services and a Pons token launch.
Later phase08 / COMMON QUESTIONSUnderstand your work.
Understand your work.
Understand the rules.
Hardware, costs, point accounting, claims and operator trust—explained before you install.
Open complete documentationWhat is Perla?
Perla connects AI-oriented GPU mining with wallet-bound contribution accounting and funded settlement on Robinhood. It adapts Pearl’s miner and native proof interface to an application coordinator.
What is the GPU actually doing?
A supported worker serves an AI model through the pinned Pearl vLLM plugin. NoisyGEMM adds mining work to supported dense matrix operations. When a candidate meets the share target, the worker can submit a proof to Perla.
Does an accepted share prove an AI answer is true?
It verifies the admitted mathematical mining work. It does not establish the truth, safety or quality of a complete AI answer, identify the physical GPU, or prove that a paying customer requested it.
Is mining open now?
Worker management and the protocol are implemented. Public admission is paused by default until a verifier and the supported GPU deployment are validated. The Status page reads the current deployment’s admission setting.
Which hardware can I use?
The current pinned kernel profile targets NVIDIA sm90 H100/H200 on Linux. Model memory requirements are separate from kernel compatibility. Consumer cards, Windows-native mining and additional GPU families are outside this release’s admission profile.
Can I mine in a browser or on my CPU?
The browser manages your account and displays server records. It does not run the CUDA miner. CPU proof fixtures are used for software tests and are not an advertised participant mining path.
Do I need to run a blockchain node?
No. The worker talks to the Perla coordinator through a local bridge. Reward contracts use Robinhood Chain Testnet, while proof checking and contribution accounting run offchain.
Can I use several workers?
Yes. Register each installation separately under your wallet. Each gets its own token and job history. Accepted shares from those workers contribute to the same account total.
What earns a point?
One accepted job adds one validation point in the current fixed-target profile. Uptime, an open browser, a model response or a worker-reported speed does not add points by itself. A job is credited at most once.
How do points become a claim?
After a UTC epoch closes and its final jobs expire, the operator prepares an allocation from accepted points. A claim is exposed only after the corresponding test-token root is funded and checked onchain.
What is the token supply?
The testnet contract source creates a fixed 1,000,000,000 tPERLA. The planned Pons mainnet supply is 1,000,000,000 PERLA. They are separate contracts; testnet balances do not automatically convert into mainnet tokens.
How is the mining budget released?
The testnet reference policy adapts Pearl’s declining curve to UTC days, using a 1B tPERLA pool and a 1,460-day constant. This is budget tooling, not an activated schedule. The operator must publish the start and fund each epoch. Mainnet reserve funding is still undecided.
Is there a mainnet allocation or guaranteed return?
No mainnet conversion, mining reserve percentage, yield or monetary return has been set. Equal testnet and mainnet supply does not create a 1:1 conversion. Contribution points are not a token balance.
Who pays for the hardware and gas?
Participants operate their own GPU or pay their chosen hosting provider for capacity, electricity and bandwidth. Signing the account message does not spend gas. Testnet contract deployment, funding and claims require test ETH; claims can also be relayed to the committed recipient.
Who do I trust?
The operator runs the native verifier, stores the contribution ledger and publishes the reward root. The contract enforces its funded allocation, but cannot determine whether the offchain ledger is complete. There is no EVM-native Pearl ZK verifier in this release.
What happens if a token is lost or exposed?
A worker token cannot be displayed again. Revoke it and register a replacement. Keep wallet recovery phrases and private keys out of the worker configuration; only the scoped worker token belongs there.
Has Perla been externally audited?
No independent external audit has been completed. The software validation record describes tests and their scope. Those checks do not replace a deployed GPU run, a security review or live contract verification.