Title
The form asks for a title that conveys the essence of the vulnerability. Mechanism and consequence, one sentence.
Mechanism in function lets actor consequence
Summary
What the issue is, in two or three sentences. The first thing Cantina’s documentation asks of a good finding is that it states the issue before any code.
What is wrong and what it leads to. Name the function and the affected party.
Finding Description
Why it happens, and where. Highlight the exact lines on the audit branch with the code-highlighting feature, then explain which logic they connect to.
- Location:
path/File.sollines start-end onaudit branchat commitcommit - Root cause: the mistake, and why the surrounding checks do not stop it
{The smallest excerpt that shows the root cause}
Path:
- Actor calls
functionwith arguments. State after the call. - Actor calls
functionwith arguments. State after the call. - Final state, with the number.
Impact Explanation
Severity on Cantina is impact × likelihood. State the impact level and the fact that puts it there. Loss of user funds or broken core functionality is High. A temporary disruption or minor fund exposure is Medium. Dust lost to rounding is capped at Low.
Impact: High, Medium or Low. Affected party lose amount, or the core function that stops working and for how long.
Measured by the PoC: the number from the output below.
Likelihood Explanation
Who triggers it and what it takes. Any user at any time is High. Capital, planning or other users’ actions is Medium. Rare conditions or admin action is Low, and a finding that needs admin access is capped at Low.
Likelihood: High, Medium or Low. Who triggers it, what they need, and how each precondition is reached from the current state.
Severity claimed: High, Medium or Low, from the matrix on the competition or programme page you used.
Proof of Concept
In a competition, High and Medium need a coded PoC before the competition ends unless your reputation score is 80 or above. It has to compile and demonstrate the impact. Name the test file, confirm it runs on the audit branch, list anything else it needs, paste the output, and set the output against what was expected.
- Test file:
test/path/File.t.sol, added to the project's own suite - Branch and commit:
audit branchatcommit - Extra setup: none, or what the reviewer installs or sets
- Command:
forge test --match-test test_name -vvv
{The test}
Output:
{Pasted output}
Expected against actual: what a correct implementation prints, and what this prints
Recommendation
Cantina’s criteria recommend a mitigation with every finding. A fix that goes against the protocol’s design philosophy marks the finding as informational at most, so propose one the team would merge.
The change, in the file and function it belongs to.
- {vulnerable line}
+ {fixed line}
Limits and non-claims
A PoC that relies on unrealistic assumptions gets the finding downgraded or invalidated. List the assumptions yourself and show that each one holds.
- Not claimed: what this report does not say, for example no loss beyond the funds held at this address
- Mocked or assumed: each mock and assumption, or "nothing: every step runs the deployed code"
- Stops working when: the condition that breaks the path
Known issues checked
A finding acknowledged in a previous report is invalid, and so is one the team already knows about. The competition README is the reference for how the protocol is meant to behave.
- Competition README or programme page, known issues: the nearest item, why this differs
- Previous reports on this code: report and finding id, why the root cause differs
- Intended behaviour per the README: the sentence that shows this is not by design
Markdown sourcecantina.md
> Cantina report template from https://bountyoperator.com/templates/cantina. Platform rules checked 2 Oct 2026.
> Replace every {placeholder}. Delete this note before you submit.
# {Mechanism} in `{function}` lets {actor} {consequence}
## Summary
{What is wrong and what it leads to. Name the function and the affected party.}
## Finding Description
- Location: `{path/File.sol}` lines {start}-{end} on `{audit branch}` at commit `{commit}`
- Root cause: {the mistake, and why the surrounding checks do not stop it}
```solidity
{The smallest excerpt that shows the root cause}
```
Path:
1. {Actor} calls `{function}` with {arguments}. {State after the call.}
2. {Actor} calls `{function}` with {arguments}. {State after the call.}
3. {Final state, with the number.}
## Impact Explanation
Impact: {High, Medium or Low}. {Affected party} lose {amount}, or {the core function that stops working and for how long}.
Measured by the PoC: {the number from the output below}.
## Likelihood Explanation
Likelihood: {High, Medium or Low}. {Who triggers it, what they need, and how each precondition is reached from the current state.}
Severity claimed: {High, Medium or Low}, from the matrix on {the competition or programme page you used}.
## Proof of Concept
- Test file: `{test/path/File.t.sol}`, added to the project's own suite
- Branch and commit: `{audit branch}` at `{commit}`
- Extra setup: {none, or what the reviewer installs or sets}
- Command: `{forge test --match-test test_name -vvv}`
```solidity
{The test}
```
Output:
```text
{Pasted output}
```
Expected against actual: {what a correct implementation prints, and what this prints}
## Recommendation
{The change, in the file and function it belongs to.}
```diff
- {vulnerable line}
+ {fixed line}
```
## Limits and non-claims
- Not claimed: {what this report does not say, for example no loss beyond the funds held at this address}
- Mocked or assumed: {each mock and assumption, or "nothing: every step runs the deployed code"}
- Stops working when: {the condition that breaks the path}
## Known issues checked
- Competition README or programme page, known issues: {the nearest item, why this differs}
- Previous reports on this code: {report and finding id, why the root cause differs}
- Intended behaviour per the README: {the sentence that shows this is not by design}