Security Audit Report

The Groth16 verifier accepted proof elements in non-canonical form. The BN254 curve's scalar field has a specific order (r), and points can be represented with multiple valid byte encodings. Without enforcing canonical encoding, a valid proof (π_A, π_B, π_C) could be "randomized" post-generation to produce a distinct but equally valid byte sequence. An attacker who observed a provider's valid PoC submission could generate a malleated proof variant and submit it first—or replay it in a separate epoch—to claim rewards for work they did not perform.

// Verify Groth16 proof elements
pub fn verify_proof(proof: &ProofData, vk: &VerifyingKey) -> bool {
    let pi_a = G1Affine::from_compressed(&proof.pi_a);
    let pi_b = G2Affine::from_compressed(&proof.pi_b);
    let pi_c = G1Affine::from_compressed(&proof.pi_c);
    // No uniqueness / canonical check
    if pi_a.is_none() || pi_b.is_none() || pi_c.is_none() { return false; }
    groth16_verify(vk, &pi_a.unwrap(), &pi_b.unwrap(), &pi_c.unwrap())
}

pub fn verify_proof(proof: &ProofData, vk: &VerifyingKey) -> Result<()> {
    let pi_a = G1Affine::from_compressed_unchecked(&proof.pi_a)
        .filter(|p| p.is_on_curve() && p.is_torsion_free())
        .ok_or(ErrorCode::InvalidProofElement)?;
    let pi_b = G2Affine::from_compressed_unchecked(&proof.pi_b)
        .filter(|p| p.is_on_curve() && p.is_torsion_free())
        .ok_or(ErrorCode::InvalidProofElement)?;
    let pi_c = G1Affine::from_compressed_unchecked(&proof.pi_c)
        .filter(|p| p.is_on_curve() && p.is_torsion_free())
        .ok_or(ErrorCode::InvalidProofElement)?;
    // Canonical check: re-serialize and compare
    require!(pi_a.to_compressed() == proof.pi_a, ErrorCode::NonCanonicalProof);
    require!(pi_b.to_compressed() == proof.pi_b, ErrorCode::NonCanonicalProof);
    require!(pi_c.to_compressed() == proof.pi_c, ErrorCode::NonCanonicalProof);
    groth16_verify(vk, &pi_a, &pi_b, &pi_c)
}

Enforce canonical encoding for all curve points before verification. Serialize the deserialized point back and compare byte-for-byte with the input. Additionally, track submitted proof hashes in a Solana account to prevent epoch-level replay. Both fixes were applied and verified in the final commit.

The epoch reward calculation accumulated per-node GPU-hours using a u64 accumulator. With a large number of nodes each contributing a large work unit, the intermediate product total_gpu_hours * base_rate_per_hour could exceed u64::MAX (≈1.84 × 10¹⁹). In Rust, integer overflow in release builds silently wraps, producing an astronomically small reward total rather than panicking. This would result in either vastly inflated or deflated reward distributions depending on the wrap depth.

let total_reward = total_gpu_hours * BASE_RATE_PER_HOUR; // silent wrap possible
let per_node = total_reward / active_node_count;

let total_reward = total_gpu_hours
    .checked_mul(BASE_RATE_PER_HOUR)
    .ok_or(ErrorCode::RewardOverflow)?;
let per_node = total_reward
    .checked_div(active_node_count)
    .ok_or(ErrorCode::ZeroNodeCount)?;

Use Rust's checked_mul / checked_div throughout all arithmetic in reward and accounting paths. Consider enabling overflow-checks = true in the release profile during development and test runs to surface these issues earlier.

The governance-controlled slashing_threshold_bps parameter (basis points fraction of stake to slash on violation) accepted the full u16 range including 0 and 10000. A value of 0 would disable slashing entirely, removing the economic disincentive for misbehavior. A value of 10000 (100%) would slash an operator's entire stake on a single infraction, which could be weaponized through governance to mass-eject legitimate operators.

pub fn set_slash_params(ctx: Context<Admin>, threshold_bps: u16) -> Result<()> {
    ctx.accounts.config.slashing_threshold_bps = threshold_bps;
    Ok(())
}

const MIN_SLASH_BPS: u16 = 100;  // 1% minimum
const MAX_SLASH_BPS: u16 = 5000; // 50% maximum

pub fn set_slash_params(ctx: Context<Admin>, threshold_bps: u16) -> Result<()> {
    require!(
        threshold_bps >= MIN_SLASH_BPS && threshold_bps <= MAX_SLASH_BPS,
        ErrorCode::InvalidSlashThreshold
    );
    ctx.accounts.config.slashing_threshold_bps = threshold_bps;
    Ok(())
}

Enforce sensible bounds on all governance parameters that have security implications. Consider adding a time-lock delay to governance parameter changes so the community has time to respond before changes take effect.