Security & Audits

Purpose: Point developers to the published Octant security review materials and explain how to use them during integration work. Audience: Developers evaluating or integrating with Octant contracts. Level: Intermediate Source of truth: The audit reports themselves, plus the pinned Octant core code version referenced elsewhere in these docs. Use this page when: Finding the published reports and understanding the limits of what an audit does and does not tell you. Do not use this page for: A full risk assessment of your integration, exact report-to-commit mapping for every deployment, or a guarantee that your custom contracts are covered by Octant's audits.

Security reviews are an important input, but they are not a substitute for reading the code, validating assumptions, and testing your own integration. Use this page as a routing layer, not as a complete security assessment.

Published audit reports

Cantina competition audit

A competitive security review of the Octant core contracts.

📄 View Cantina competition audit report (PDF)

Spearbit audit

An additional external review of the Octant core contracts.

📄 View Spearbit audit report (PDF)

Cantina review-fixes audit

A follow-up review focused on fixes after the Cantina competition audit.

📄 View Cantina review-fixes audit report (PDF)

How to use these reports

When you read an audit report, check four things before you rely on it:

1. Scope: Which contracts, modules, and behaviors were reviewed.
2. Code version: Which repository state, commit, or snapshot the report applies to.
3. Findings status: Which issues were fixed, accepted, or left outside scope.
4. Assumptions: Which roles, operational controls, external dependencies, or trust assumptions the report expects.

If your deployment, custom strategy, wrapper, frontend workflow, or integration logic differs from the reviewed scope, do not assume the audit covers it.

What an Octant audit does and does not mean

An audit report is useful evidence that a specific codebase was reviewed at a specific point in time. It does not mean:

• every current deployment is automatically covered
• every helper repository or example integration is in scope
• your custom strategy or funding mechanism inherits audit coverage
• operational mistakes, misconfiguration, or integration bugs are eliminated

For that reason, treat audit reports as one part of your review process, alongside code review, fork testing, invariant testing where appropriate, and an assessment of your own trust model.

Integration guidance for builders

If you are building against Octant contracts, use the following baseline process:

1. Start from the pinned core version referenced in these docs.
2. Confirm that the contracts and interfaces you depend on match that version.
3. Read the relevant audit report sections for the specific modules you use.
4. Review all privileged roles, upgrade paths, pause or emergency controls, and external call surfaces.
5. Test your integration on a fork before interacting with live deployments.
6. Consider an independent review for any production system that adds new logic, custody assumptions, or user funds.

This is especially important if you are:

• writing a custom yield donating strategy
• writing a custom yield skimming strategy
• building a new allocation mechanism
• composing Octant contracts inside a broader treasury or governance system

Responsible disclosure

If you believe you have found a security issue affecting Octant contracts or documentation:

1. Do not disclose the issue publicly before the team has had a reasonable chance to review it.
2. Email the details to [email protected].
3. Include the affected component, impact, reproduction steps, assumptions, and any proposed remediation.
4. Wait for a response before sharing technical details more broadly.

When reporting an issue, include enough context for the team to reproduce it quickly, such as network, contract addresses, configuration, transaction traces, and the exact code path involved.