01
Contact
Share the project, target date, and the components you expect to include. The team performs an initial review and responds with questions, availability, and next steps.
OutputsInitial scope contextAvailability checkNext-step questions
02
Scope Definition
Kann Audits and the protocol team align on repositories, files, a fixed commit, architecture, assumptions, exclusions, and engagement requirements.
OutputsFixed review boundarySchedule and deliverablesTypically 2–4 assigned researchers
03
Audit Kickoff
A direct communication channel and private reporting workflow are established. Researchers receive the final code, documentation, tests, and technical contacts.
OutputsCommunication channelReporting workflowFinal review inputs
04
Security Review
Researchers independently inspect the code, compare behavior with protocol intent, explore attack paths, and collaborate on high-risk areas. Material findings can be shared as they are validated.
OutputsManual line-by-line reviewAdversarial analysisValidated candidate findings
05
Preliminary Report
The preliminary report records the scope and methodology, then explains each confirmed finding with severity, technical impact, evidence, and remediation guidance.
OutputsSeverity-rated findingsTechnical evidenceRemediation guidance
06
Fix Verification
After the protocol team submits remediations, researchers re-test the affected paths and assess whether the original issue is resolved without an obvious regression in the reviewed area.
OutputsRemediation reviewFinding status updatesRegression-focused checks
07
Final Delivery
The final report reflects the agreed scope, reviewed commits, findings, and verified remediation status. Publication and any follow-up support follow the engagement terms.
OutputsFinal PDF reportVerified statusesApproved publication package
Research method
A consistent review foundation
Public Kann Audits reports repeatedly document these areas of analysis.
- 01Architecture and trust-boundary analysis
- 02Independent manual review
- 03State-transition and invariant analysis
- 04Access-control and integration review
- 05Adversarial testing and attack-path analysis
- 06Fix verification and regression review
FAQ
Audit process FAQ
What should we prepare before contacting Kann Audits?
Share the repository or code-access plan, approximate scope, target release date, architecture documentation, supported chains and languages, and any known high-risk components. Do not submit secrets through the public form.
Does the code need to be frozen?
A fixed, stable commit is important for the formal review boundary. Active development can continue elsewhere, but changes to the reviewed scope need to be communicated and may affect the schedule.
How are findings communicated?
The existing process uses a direct team channel and a private reporting workflow so validated findings and technical questions can be discussed during the engagement.
What happens if we cannot fix a finding?
The protocol team can discuss alternatives or acknowledge the risk. The final report should accurately reflect the response and verification status rather than implying a resolution that did not occur.
Can a report be kept private?
Disclosure terms are agreed during scoping. The audit library contains only reports that Kann Audits has already published.
Does final delivery guarantee the deployed protocol is secure?
No. The report describes a bounded review of a specific scope and code revision. Deployment choices, later changes, and out-of-scope systems can introduce additional risk.
Start a conversation
Bring the right context into the room
Share your intended scope and release plan before code freeze so there is time for review, remediation, and verification.