Connect mining work to an application ledger.
Perla’s initial integration uses the pinned Pearl vLLM miner and NoisyGEMM kernels for supported dense matrix operations. A local bridge connects the miner’s JSON-RPC interface to the Perla coordinator.
When a candidate meets the coordinator’s challenge, the worker submits a native PlainProof. The verifier checks the admitted mathematical work and the coordinator records one accepted contribution for the account’s recipient wallet.
Perla is an application on Robinhood, with offchain work admission and accounting. It does not run a new consensus chain. The native 76-byte work envelope is used to bind a challenge to Perla’s domain; it is not a Pearl block.
These notes describe implementation behavior. They are not a new mathematical security proof, a performance benchmark or a declaration that all AI output has been independently verified.
Five parts with different duties.
| Participant wallet | Authorizes browser worker management and is the recipient committed by that account. |
|---|---|
| GPU worker and bridge | Run supported inference, request mining challenges and submit native proofs using a scoped token. |
| Coordinator and ledger | Issue jobs, enforce account ownership and admission rules, record accepted shares and prepare reward manifests. |
| Native verifier | Parse and check PlainProof in a resource-limited process using the pinned upstream mathematical verifier. |
| Reward distributor | Hold an explicitly funded ERC-20 epoch and enforce wallet allocations through Merkle proofs on Robinhood Testnet. |
AI inference traffic is supplied to the worker by its operator. An automatic public job marketplace, client billing and managed GPU rental are later product phases.
A challenge has one recipient and one credit.
- 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.
A work request requires a valid worker token, enabled admission and a native verifier reporting the expected protocol and source revision. The challenge commits to the site origin, Robinhood domain, UTC epoch, worker, wallet and random job identifier.
The bridge preserves the pinned miner’s getMiningInfo and submitPlainProof wire interfaces. Only its outbound coordinator traffic carries the Perla worker token. No Pearl node or private wallet key is required.
Mathematical verification and ledger checks.
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.
The native verifier admits certificate v3, dense GEMM and noise rank 128. Its parser checks the envelope, payload limit, configured target and supported dimensions before calling the pinned proof verifier. Request parsing runs with CPU, memory and wall-time bounds.
The coordinator also binds the verifier’s response to the submitted proof and challenge hashes. Before inserting a record, it rechecks expiry, worker revocation and whether the epoch has already been prepared. A unique job constraint prevents concurrent double credit.
These checks establish a valid share under the admission profile. They do not attest a physical GPU, prove customer demand, or evaluate the semantic accuracy of a model response.
Fixed rules for the validation profile.
Each accepted job adds one point. A UTC day defines an epoch; a job’s epoch is fixed at issuance. A proof may arrive after midnight while the job is still valid and remain credited to its original epoch.
Epoch preparation waits until the UTC day and the final five-minute job lifetime have ended. The operator aggregates accepted points by recipient and commits an immutable snapshot for that epoch. The prepared snapshot closes the epoch against later credits.
Allocations use integer base units. The algorithm floors proportional shares, then assigns remaining units by largest remainder with deterministic address tie-breaking. The distributed amounts sum exactly to the stated budget.
This is validation accounting, not a market pricing formula. It does not promise a return per hour, GPU, inference request or electricity unit.
Adapt the curve to a funded application.
Pearl’s official node defines a 2.1B native-coin supply limit and a block subsidy proportional to S × C / ((h + C)(h − 1 + C)). The constant C represents approximately four years of blocks. This is chain-native issuance to block producers, not a daily ERC-20 pool allocation.
Perla keeps settlement on Robinhood. Its testnet reference policy uses a 1B tPERLA pool and a daily version of the cumulative curve. This is a Perla adaptation, not Pearl consensus. Proportional points describe distribution within a Perla epoch; they are not a claim that Pearl uses this same payout service.
Fixed supply in the deployment source. A new deployment is required to use it.
Separate Pons launch. Its mining reserve still needs to be allocated and funded.
A declining budget. A proportional allocation.
The reference schedule adapts Pearl’s cumulative curve to UTC days: C(d) = S × d / (d + 1460). Each daily budget is the difference between two rounded cumulative amounts. At day 1,460, the cumulative scheduled budget is 50% of the testnet pool.
This calculates a budget; the current distributor does not enforce the schedule. The operator still publishes and funds each epoch. Days with no accepted work create no allocation and have no automatic rollover.
1% of a 684,462.696 tPERLA daily budget. Cumulative scheduled budget: 684,462.696 tPERLA.
Illustration only, displayed to three decimal places. Actual claims use integer base units and deterministic rounding. Testnet balances do not establish a mainnet allocation or a 1:1 conversion.
Read the emission model and funding limitsThe test token is minted once to its deployer on Robinhood Testnet. It does not mint as a side effect of proof submission. The mainnet plan also targets 1B PERLA through Pons, with a separate mining reserve still to be allocated. Until that reserve is funded, mainnet mining rewards cannot be activated.
The operator must publish a UTC start day and epoch budgets before using the reference schedule. The CLI emission command previews the budget without sending a transaction. Existing manual epoch tooling and the distributor do not enforce this schedule onchain.
Pearl emission source · reviewed 23 Oct 2026Commit the allocation and back it with tokens.
The operator prepares a Merkle manifest and funds its root in the distributor. The distributor has an immutable owner and reward token; an epoch root cannot be replaced after publication. Funding requires an actual token transfer for the stated budget.
A claim leaf binds chain ID, distributor address, epoch, allocation index, recipient and amount. The claim bitmap prevents a second payment for an already claimed allocation. A relayer may submit a valid claim, but the contract pays only the committed recipient.
The coordinator activates an epoch only after reading the expected chain, token, root and budget from the contract. Account responses expose that wallet’s allocation and proof for active epochs.
The operator CLI rejects chain operations outside Robinhood Testnet. A Pons token launch does not automatically deploy this distributor, fund it, or establish mainnet conversion rules.
What remains under operator control.
The native verifier is an offchain service. Participants trust its deployment to run the specified implementation. They also trust the coordinator to retain accepted records and the operator to publish an allocation that includes the complete eligible ledger.
The contract can enforce inclusion in the root it was funded with. It cannot reconstruct the offchain work history, add an omitted participant, or correct an incorrectly prepared allocation on its own.
The current system does not provide EVM-native Pearl ZK verification, decentralized verifier consensus, workload confidentiality, hardware attestation, slashing, customer escrow or automatic dispute adjudication.
Workers and their operators can access the AI inputs and outputs they handle. The coordinator receives native proofs and stores wallet/worker records, contribution receipts and reward manifests. There is no end-to-end private inference claim.
Automated tests cover their stated scenarios. They do not establish the absence of all attacks, independent audit completion, CUDA deployment validity or economic demand.
A bounded initial release.
| Protocol | perla-pearl-plain-v3 |
|---|---|
| Settlement chain | Robinhood Testnet · 46630 |
| Certificate | 3 |
| Work envelope | 76 bytes · application challenge |
| Job lifetime | 300 seconds |
| Share target | Fixed compact target 0x207fffff |
| Point rule | 1 point per accepted job |
| Epoch | UTC day |
| Maximum native proof | 5 MiB |
| Dense admission | Noise rank 128 · K 2,048–32,768 · no MoE |
| GPU kernel profile | NVIDIA sm90 · H100/H200 |
| Reward allocation limit | 5,000 recipients per epoch in this release |
| Upstream source | 82e6eee7076aafe10123e08db78f100d270c0582 |
These values describe the current implementation, not a benchmark or permanent economic schedule. Future admission and token policies require an explicit release and documentation update.
Know which part comes from where.
The CUDA integration, miner proof interface and native mathematical verifier come from the pinned Pearl source. Perla supplies the adapter, coordinator, account controls, contribution ledger and Robinhood reward tooling.
Upstream licenses and attribution are documented in the downloadable packages. Perla is a separate integration; this documentation does not assert endorsement by Pearl, Vearl or Robinhood.