Complete reference for all NullGraph custom errors
The NullGraph program defines 6 custom errors to handle validation failures and prevent invalid state transitions. All errors are defined in the NullGraphError enum using Anchor’s #[error_code] macro.Location: lib.rs:579-593
#[error_code]pub enum NullGraphError { #[msg("Bounty is not in the expected status")] InvalidBountyStatus, #[msg("Submission is not in the expected status")] InvalidSubmissionStatus, #[msg("Matched submission mismatch")] SubmissionMismatch, #[msg("Bounty deadline has passed")] BountyExpired, #[msg("Reward amount must be > 0")] InvalidRewardAmount, #[msg("Fee calculation overflow")] FeeOverflow,}
Validation: require!(bounty.status == 0, NullGraphError::InvalidBountyStatus)Condition: Bounty must have status 0 (Open) to accept submissions.Example: Attempting to submit an NKA to a bounty that is already Matched (1), Fulfilled (2), or Closed (3).
Show approve_bounty_submission (line 157)
Validation: require!(bounty.status == 1, NullGraphError::InvalidBountyStatus)Condition: Bounty must have status 1 (Matched) to approve a submission.Example: Attempting to approve a bounty that is still Open (0) or already Fulfilled (2) or Closed (3).
Show close_bounty (lines 233-236)
Validation: require!(bounty.status == 0 || bounty.status == 1, NullGraphError::InvalidBountyStatus)Condition: Bounty must have status 0 (Open) or 1 (Matched) to be closed.Example: Attempting to close a bounty that is already Fulfilled (2) or Closed (3).
Validation: require!(submission.status == 0, NullGraphError::InvalidSubmissionStatus)Condition: BountySubmission must have status 0 (Pending) to be approved.Example: Attempting to approve a submission that has already been Approved (1) or Rejected (2).
Validation: require!(bounty.matched_submission == ctx.accounts.submission.key(), NullGraphError::SubmissionMismatch)Condition: The submission account’s public key must exactly match bounty.matched_submission.Example: Passing the wrong BountySubmission PDA when calling approve_bounty_submission.
This check prevents a malicious actor from substituting a different submission during approval. The bounty’s matched_submission field is set atomically in submit_to_bounty and cannot be changed except by approving or closing the bounty.
This error code exists for potential future enforcement of bounty deadlines. The NullBounty.deadline field is stored on-chain but not currently validated by the program.
Validation: require!(reward_amount > 0, NullGraphError::InvalidRewardAmount)Condition: The reward_amount parameter must be greater than 0.Example: Calling create_bounty with reward_amount: 0.
Validation: All fee/payout calculations use checked arithmetic:
let fee = total .checked_mul(fee_bps) .ok_or(NullGraphError::FeeOverflow)? .checked_div(10_000) .ok_or(NullGraphError::FeeOverflow)?;let payout = total.checked_sub(fee).ok_or(NullGraphError::FeeOverflow)?;
Condition: All intermediate calculations must fit within u64 bounds.Example: Theoretically possible with extremely large reward_amount values exceeding u64::MAX / fee_basis_points, but practically impossible with USDC’s 6-decimal precision and realistic bounty sizes.
Using checked arithmetic prevents integer overflow attacks. Even though the inputs make overflow practically impossible, defensive programming ensures the program fails safely rather than silently producing incorrect results.