Skip to content

Add a docs/AUDIT_PREP.md checklist for security audits #1916

Description

@Baskarayelu

Summary

What to hand the auditor, what to expect, what to fix pre-audit.

Background

We rely on this information internally but it is currently tribal knowledge. Writing it down lets reviewers verify behaviour against the documented intent, lets new contributors get productive without reading every commit, and lets the support team answer common questions without paging an engineer.

Acceptance criteria

  • The change matches the summary above.
  • The new document is linked from at least one existing top-level doc (README or docs/README).
  • Examples in the document compile / run if applicable.
  • Lint, type-check, and tests all pass locally.
  • PR description references this issue with Closes #<this-issue>.

Implementation hints

  • Audience: pick one (contributor / operator / downstream integrator) and write for them; do not try to address all three in the same doc.
  • Prefer concrete examples over abstract definitions. Show a real entrypoint, request, or output rather than foo() placeholders.
  • Cross-link from the README and from any related doc; orphaned docs rot fastest.
  • Where the project ships generated docs (rustdoc, JSDoc, OpenAPI), keep this new content discoverable from the same starting point.

Repo-specific notes

  • This is a Soroban contract crate. Run cargo build --target wasm32-unknown-unknown --release to verify the change still builds for WASM.
  • Run cargo test -p <package> for the affected crate, and cargo clippy --workspace --all-targets -- -D warnings before pushing.
  • Keep #![no_std] discipline: do not introduce std:: calls; use soroban_sdk primitives.

Out of scope

  • Unrelated refactors in adjacent files.
  • Stylistic-only changes (formatting, renaming) that are not required by the fix.
  • Anything beyond the acceptance criteria above; surface follow-ups as separate issues.

How to claim and submit

  1. Comment on this issue saying you'd like to take it on; wait for a maintainer to assign you (avoids duplicated effort).
  2. Open a PR that references this issue (Closes #<this-issue>).
  3. Make sure CI is green and request review from a CODEOWNERS maintainer.
  4. PRs that close this issue and pass review may qualify for a reward — see the MAYBE REWARDED label and the FWC26 campaign page.

Category: documentation  ·  Campaign: GrantFox OSS · Official Campaign | FWC26 · Maybe Rewarded

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions