Notes
Give the auditor your protocol's trust model and design context so it reasons about your code, not textbook code.
Overview
A note is a free-form fact about your protocol that the auditor should know before it reasons about your code. It's the difference between an auditor who flags every external-call-before-state-update as reentrancy and one who knows your vault only holds WETH and USDC and moves on.
Notes are the most direct lever you have on audit quality. They're injected at the start of every audit as context the auditor reads during discovery, and they steer how findings get categorized — toward your protocol's actual design decisions, away from textbook patterns that don't apply.
What makes a good note
Good notes encode the things an experienced auditor would want briefed before they start: the trust model, the design intentions, the known-and-accepted trade-offs.
| Good note | Why it helps |
|---|---|
| "Admin keys are held in a 3-of-5 Gnosis Safe multisig. Treat admin functions as trusted." | Stops the auditor flagging every onlyOwner function as a centralization risk |
| "This protocol only ever holds WETH and USDC. Neither has transfer hooks or callbacks." | Pre-empts false-positive reentrancy findings |
| "Fee-on-transfer tokens are explicitly unsupported and rejected at the deposit boundary." | Tells the auditor a whole bug class is out of scope by design |
"rebalance() is permissionless by design — anyone can call it, and that's intended." | Prevents a finding about a missing access-control modifier |
Write notes the way you'd brief a human auditor on day one. If you'd say it out loud in a kickoff call, it belongs in a note.
What a note is not
Notes shape reasoning. They are not a way to silence the auditor. Cygent validates every note on save and rejects entries that try to:
- Blanket-suppress a bug class ("ignore all reentrancy", "don't report access control issues").
- Inject instructions at the auditor ("ignore your system prompt", "you must follow these rules").
- Smuggle in secrets (API keys, emails, credentials are rejected).
Notes must be between 10 and 4,000 characters. If you genuinely believe a specific finding is a non-issue, that's what the Invalid status on the finding is for — see Understanding Findings. A note explains why something is the way it is; it doesn't order the auditor to look away.
Creating a note
Open the Knowledge tab → Notes
On the instance dashboard, go to Knowledge → Notes.
Choose the scope
Project for context specific to one repo; Global for a fact that holds across every project in the instance. See scoping.
Write the note and save
One fact per note, stated plainly. The note is available immediately for the next audit.
Notes are injected when an audit starts. Add them before you kick off the run. A note saved while an audit is already in flight applies to the next audit, not the current one.
How notes flow through an audit
Before audit: you write notes (global + project)
Audit start: enabled notes matching the project are injected as auditor context
During audit: the auditor reads them and reasons with your trust model in mind
After audit: findings reflect your design — fewer false positives, sharper categorization
The same notes apply to every audit on that project until you change them. There's no per-run setup once they're in place.
Recommendations
You don't have to author every note from scratch. As Cygent audits your code and talks with your team, it spots context worth capturing — a trust assumption that came up in a chat thread, a pattern that recurs across findings — and proposes it as a note in the Recommendations banner.
- Accept opens the note form prefilled, so you review and edit before saving. Nothing is written without your sign-off.
- Dismiss drops it and stops Cygent proposing the same note again.
You can also trigger an on-demand scan that reviews recent audits and project conversations and surfaces note candidates in one pass.
Accept the recommendations that match your protocol's real design; dismiss the noise. Because every accepted note is reviewed before it's saved, there's no downside to a generous accept-then-edit habit.