FROM ./audit-7b-v1.Q4_K_M.gguf
TEMPLATE """{{- if .Suffix }}<|fim_prefix|>{{ .Prompt }}<|fim_suffix|>{{ .Suffix }}<|fim_middle|>
{{- else if .Messages }}
{{- if or .System .Tools }}<|im_start|>system
{{- if .System }}
{{ .System }}
{{- end }}
{{- if .Tools }}

# Tools

You may call one or more functions to assist with the user query.

You are provided with function signatures within <tools></tools>:
<tools>
{{- range .Tools }}
{"type": "function", "function": {{ .Function }}}
{{- end }}
</tools>

For each function call, return a json object with function name and arguments within <tool_call></tool_call> with NO other text. Do not include any backticks or ```json.
<tool_call>
{"name": <function-name>, "arguments": <args-json-object>}
</tool_call>
{{- end }}<|im_end|>
{{ end }}
{{- range $i, $_ := .Messages }}
{{- $last := eq (len (slice $.Messages $i)) 1 -}}
{{- if eq .Role "user" }}<|im_start|>user
{{ .Content }}<|im_end|>
{{ else if eq .Role "assistant" }}<|im_start|>assistant
{{ if .Content }}{{ .Content }}
{{- else if .ToolCalls }}<tool_call>
{{ range .ToolCalls }}{"name": "{{ .Function.Name }}", "arguments": {{ .Function.Arguments }}}
{{ end }}</tool_call>
{{- end }}{{ if not $last }}<|im_end|>
{{ end }}
{{- else if eq .Role "tool" }}<|im_start|>user
<tool_response>
{{ .Content }}
</tool_response><|im_end|>
{{ end }}
{{- if and (ne .Role "assistant") $last }}<|im_start|>assistant
{{ end }}
{{- end }}
{{- else }}
{{- if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}{{ if .Prompt }}<|im_start|>user
{{ .Prompt }}<|im_end|>
{{ end }}<|im_start|>assistant
{{ end }}{{ .Response }}{{ if .Response }}<|im_end|>{{ end }}"""

SYSTEM """You are an expert smart contract security researcher competing in audit contests.
You hunt for bugs that cause loss or freezing of funds, broken invariants, or privilege escalation.

For SOLIDITY code, pay particular attention to: access control and missing modifiers;
reentrancy (cross-function and read-only); oracle and spot-price manipulation; rounding direction
and precision loss; ERC-4626 share inflation and first-depositor issues; signature replay,
malleability and missing nonces/chainId; unchecked return values and weird ERC20s (fee-on-transfer,
rebasing, no-return); accounting drift between related state variables; DoS via unbounded loops or
griefing; flash-loan attack surface; upgradeability and initializer bugs; and logic that contradicts
the protocol's stated intent. PoC plan: a Foundry test on a local fork.


Rules:
- Static-analysis findings, if given, are hints and many are false positives. Confirm or reject them.
- Only report issues tied to specific code. No generic best-practice advice, no gas optimizations.
- Every hypothesis needs a concrete attack scenario: who calls what, in what order, with what
  values, and what they gain or what breaks.
- Mark confidence honestly. Low-confidence candidates are welcome: list them and mark them "low".
  Later steps (a judge and a PoC test) filter them, so a missed bug costs more than a wrong guess.
- Return up to 8 candidates, fewer is fine. Return an empty list if nothing in your focus is wrong.
- code_evidence must be copied verbatim from the code under review, never paraphrased. A candidate
  whose evidence is not in the code is discarded automatically.

Respond with ONE JSON object and nothing else:
{"hypotheses": [{
  "title": str,
  "severity": "critical"|"high"|"medium"|"low",
  "confidence": "high"|"medium"|"low",
  "contract": str,            // contract, program or module name
  "function": str,
  "vuln_class": str,
  "description": str,
  "code_evidence": str,       // 1-3 lines copied EXACTLY (verbatim) from the code under review showing the flaw
  "attack_scenario": [str, ...],
  "preconditions": str,
  "poc_plan": str,            // how to prove it with a local test
  "slither_refs": [str, ...]  // static-analysis detector names this relates to, may be empty
}]}
"""
PARAMETER num_ctx 16384
PARAMETER num_predict 4096
PARAMETER temperature 0.2