home / skills / near / agent-skills / near-contract-audit

near-contract-audit skill

/skills/near-contract-audit

This skill conducts automated and manual NEAR contract audits to identify vulnerabilities and guide secure Rust smart contract fixes.

npx playbooks add skill near/agent-skills --skill near-contract-audit

Review the files below or copy the command above to add this skill to your agents.

Files (4)
SKILL.md
3.1 KB
---
name: near-contract-audit
description: Comprehensive security audit skill for NEAR Protocol smart contracts written in Rust. Use when auditing NEAR contracts, reviewing security vulnerabilities, or analyzing contract code for issues like reentrancy, unhandled promises, unsafe math, access control flaws, and callback security.
---

# NEAR Contract Audit

Security audit skill for NEAR smart contracts in Rust.

## Audit Workflow

### Phase 1: Automated Analysis

Run your preferred Rust static analysis and NEAR-focused security tools on the contract to:

- Scan for common vulnerability patterns (reentrancy, unsafe math, unhandled promises, access control issues, etc.)
- Highlight potentially risky patterns for deeper manual review

### Phase 2: Manual Review

After automated analysis, perform manual review for:

- Business logic vulnerabilities
- Access control patterns
- Economic attack vectors
- Cross-contract interaction safety

### Phase 3: Code-Specific Analysis

For each finding, verify:

1. Is it a true positive?
2. What is the exploitability?
3. What is the recommended fix?

### Phase 4: Report Generation

Document findings with severity, location, description, and remediation.

## Vulnerability Quick Reference

| Severity   | Detector ID                      | Description                                     |
| ---------- | -------------------------------- | ----------------------------------------------- |
| **High**   | `non-private-callback`           | Callback missing `#[private]` macro             |
| **High**   | `reentrancy`                     | State change after cross-contract call          |
| **High**   | `incorrect-argument-or-return-types` | Using native integer types in JSON interfaces |
| **High**   | `unsaved-changes`                | Collection modifications not persisted          |
| **High**   | `owner-check`                    | Missing caller/owner verification               |
| **High**   | `yocto-attach`                   | Missing `assert_one_yocto` on sensitive functions |
| **High**   | `storage-collision`              | Same storage prefix for different collections   |
| **High**   | `required-initialization-macro`  | Missing `#[init]` on initialization method      |
| **Medium** | `gas-griefing`                   | Unbounded loops causing DoS                     |
| **Medium** | `insecure-random`                | Predictable randomness from block data          |
| **Medium** | `prepaid-gas`                    | Insufficient gas reserved for callbacks         |
| **Low**    | `cover-storage-cost`             | Missing storage deposit verification            |
| **Low**    | `unsafe-math`                    | Arithmetic without overflow checks              |
| **Low**    | `float-math`                     | Using floating point types for financial math   |

## Reference Files

For detailed vulnerability documentation with code examples:

- [high-severity.md](references/high-severity.md) - Critical vulnerabilities (8 detectors)
- [medium-severity.md](references/medium-severity.md) - Medium vulnerabilities (4 detectors)
- [low-severity.md](references/low-severity.md) - Low severity findings (3 detectors)

Overview

This skill provides a comprehensive security audit workflow for NEAR Protocol smart contracts written in Rust. It combines automated scanning with focused manual review to find and prioritize vulnerabilities that affect correctness, safety, and funds. The goal is clear findings with exploitability assessment and actionable remediation for developers and auditors.

How this skill works

First, run Rust static analysis and NEAR-aware scanners to identify common patterns like reentrancy, unsafe math, unhandled promises, and access control gaps. Next, perform manual review of business logic, cross-contract interactions, and economic attack surfaces. Each finding is validated for true positive status, exploitability, and recommended fixes, then compiled into a structured report with severity and remediation.

When to use it

  • Before mainnet deployment of NEAR contracts written in Rust
  • During security reviews after major feature changes or refactors
  • When third-party integrations or callbacks are added
  • For pre-release audits requested by auditors or stakeholders
  • When handling funds, tokens, or privileged access in contract logic

Best practices

  • Run both automated NEAR-aware tools and manual code walkthroughs; tools find patterns, humans assess logic.
  • Treat cross-contract calls as untrusted boundaries: check callbacks, use #[private], and reserve gas for callbacks.
  • Use assert_one_yocto and explicit owner/caller checks on sensitive methods.
  • Avoid native integer types in JSON interfaces; use string-encoded amounts or safe wrappers.
  • Persist collection changes immediately and use distinct storage prefixes to prevent collisions.

Example use cases

  • Detecting and fixing reentrancy where state changes occur after external calls.
  • Verifying callbacks are marked private and protected with appropriate gas and deposit assertions.
  • Finding and remediating storage collisions between collections after a refactor.
  • Reviewing token transfer and staking logic for unsafe arithmetic or floating point use.
  • Assessing gas griefing risks in loops and ensuring prepaid gas for cross-contract flows.

FAQ

Which findings are considered highest priority?

High priority includes missing #[private] callbacks, reentrancy (state change after external call), native integer types in JSON interfaces, unsaved collection changes, missing owner checks, missing assert_one_yocto, storage prefix collisions, and missing #[init].

What tools should I run first?

Start with Rust static analyzers and NEAR-focused scanners that detect patterns like reentrancy, unhandled promises, and storage issues, then follow with manual review of business logic and cross-contract flows.

How do you validate a reported issue?

Validate by reproducing the pattern in code, reasoning about exploitability, checking call flow and state transitions, and proposing a minimal remediation with code examples when possible.