Perceptron Network

We express our gratitude to the Perceptron Network team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Perceptron Network is a decentralised data mesh on Solana that turns idle residential bandwidth and human-contributed data into infrastructure for AI data acquisition and agentic web access, rewarding pseudonymous node operators in the native $PERC token as a function of measurable per-epoch performance. The audit covered the PCN Program,a permissioned bandwidth-reward system on Solana that mints PCN reward tokens to network participants based on bandwidth measurements submitted by a trusted oracle. Emissions are bounded by a scarcity and support curve, by the remaining maximum token supply, and by the SOL support budget deposited for each epoch, and users redeem their allocations through per-epoch claim accounts.

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

The project provides a technical whitepaper that describes the network architecture, token economics, and the emission and reward-allocation formulas in detail. The whitepaper is the primary specification, and the onchain program implements a subset of it, namely the per-epoch emission curve and per-node reward settlement. Inline documentation in the program is sparse, and the relationship between the implemented arithmetic and the documented formulas is not recorded in the code. Deviations between the implemented emission and reward-weight formulas and the whitepaper specification were identified and reported.

Code quality

The codebase is organised along Anchor conventions with a clear separation between state definitions, instruction handlers, and reward mathematics, and value-determining accounting is performed in checked integer arithmetic. Account validation relies on Anchor constraints, program derived addresses, and explicit authority checks. Several code-quality and best-practice issues were identified and reported, including manual account space calculation and the use of floating point in value-determining curve arithmetic.

Test coverage

Code coverage of the project is unmeasurable. However, the program ships with unit tests for the reward mathematics and a LiteSVM integration suite exercising configuration authority, epoch validation, the rewards flow, and claim validation. Negative and boundary scenarios are represented, though coverage of the permissionless configuration path and of large-magnitude curve inputs is limited. Adding fuzz tests over the emission curve and reward-weight arithmetic, and explicit tests for unauthorized initialization, is recommended.

The PCN Program is a reward-distribution system that mints a native SPL token to participants in proportion to bandwidth contribution, as measured off chain and reported by a trusted oracle. The program is deployed on Solana under the Anchor framework and is structured around a single global configuration account and a per-epoch lifecycle that moves each epoch from open, to finalized, to swept.

Initialization creates the singleton configuration account through the initialize_config instruction. During initialization the program creates a nine-decimal SPL reward mint whose mint authority is a program derived address, a SOL reserve account, and a token reserve vault. The configuration account records the admin and oracle authorities, the reward mint, the reserve addresses and their bumps, the lifetime minted amount, the claim window duration in slots, and the curve parameters that drive emissions.

The epoch lifecycle begins with the open_epoch instruction, in which the oracle opens a new epoch and a funder deposits a SOL support budget into the epoch account. After the epoch window ends, the finalize_epoch instruction computes the reward pool from the reported total reward weight, the lifetime minted supply, the remaining maximum supply, and the available SOL support. The consumed portion of the support budget is moved into the SOL reserve, the unused portion is refunded, the reward pool is minted into the epoch token vault, and the lifetime minted amount is increased accordingly. The reward pool is the minimum of the scarcity cap, the support cap, and the remaining supply, which keeps issuance bounded on every axis.

Reward allocation is performed by the oracle through the create_claim instruction, which creates one claim account per user, deriving its address from the epoch identifier and the user key. Each claim records the user, bandwidth units, quality factor, reward weight, and reward amount, and the cumulative allocated amount is constrained to never exceed the epoch reward pool. Users redeem allocations through the claim_reward instruction, which transfers the recorded reward amount from the epoch token vault to a user-owned token account and marks the claim as redeemed so that it cannot be claimed twice. After the claim window expires, the sweep_epoch instruction transfers any unclaimed tokens from the epoch token vault into the token reserve vault and marks the epoch as swept.

The system holds value in three places: the per-epoch token vaults that back user claims, the SOL reserve that accumulates consumed support lamports, and the token reserve vault that accumulates swept and unclaimed tokens. All token movements are authorized by the program mint authority program derived address, and all epoch and claim accounts are isolated by seeds that include the epoch identifier, preventing cross-epoch interference.

Privileged Roles

• Admin (configuration account): The admin is a single address set at initialization. The admin can rotate the oracle authority, change the claim window length, and replace the entire emission curve parameter set through the configuration update instruction, subject only to basic validity checks and a constraint that the new maximum supply is not below the amount already minted. Changes take effect immediately with no timelock or multisig. Compromise of the admin key would allow redirecting the oracle authority and reshaping future emissions.

• Oracle (configuration account): The oracle is a single address and holds control over the entire reward flow. The oracle opens epochs, finalizes epochs and thereby determines the aggregate reward weight that drives emission and triggers minting, creates each node's claim with its bandwidth and quality inputs, and sweeps residual balances. The per-node performance score is computed entirely from the two scalars the oracle supplies, so the oracle effectively decides how much every node receives. Compromise or misbehaviour of the oracle key would allow inflating or suppressing emissions within the curve bounds and misallocating rewards among nodes.

• Mint authority (program derived address): The mint authority is a program derived address with no external key. It signs the reward token minting during finalization and the token transfers during claims and sweeps. Its powers are exercised only through the program instructions and cannot be invoked directly by any external signer.

• Configuration initializer (initialization instruction): The initialization instruction that creates the singleton configuration account is not access-controlled and can be called by any account, which sets the admin and oracle authorities and binds the reward mint. This is documented in the findings.

The scope of the project includes the following smart contracts from the provided repository:

Assets in Scope