> For the complete documentation index, see [llms.txt](https://dualguard.gitbook.io/dualguard/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dualguard.gitbook.io/dualguard/security-reviews/protocol-teams/security-review-contest-timeline.md).

# Security Review Contest Timeline

## Security Review Contest Timeline

DualGuard schedules security review contests around scope size, architecture complexity, and launch risk. The review flow can include an agentic contest, a traditional contest, and a mitigation review, depending on the engagement.

This page provides planning guidance for the main contest window based on codebase size. Final duration is set during scoping.

**Planning guidance by codebase size**

DualGuard estimates size using nSLOC (non-comment source lines of code), calculated using Solidity Metrics.

*Note: The sizing guidance below is based on Solidity nSLOC and is meant for EVM/Solidity scopes. For non-Solidity codebases, such as Solana programs in Rust, and for mixed-language systems, DualGuard scopes timeline and review length based on program structure, attack surface, and integration complexity rather than nSLOC.*

<table data-header-hidden><thead><tr><th width="229">Solidity Lines (nSLOC)</th><th width="145">Main contest window</th></tr></thead><tbody><tr><td>~500</td><td>~3 days</td></tr><tr><td>~1000</td><td>~6 days</td></tr><tr><td>~2000</td><td>~12 days</td></tr><tr><td>~3000</td><td>~18 days</td></tr><tr><td>~4000</td><td>~25 days</td></tr><tr><td>~5000</td><td>~32 days</td></tr><tr><td>~6000</td><td>~38 days</td></tr></tbody></table>

> Note: DualGuard uses [Solidity Metrics](https://github.com/ConsenSys/solidity-metrics) to calculate nSLOC.\
> \
> \*Very large codebases introduce disproportionate complexity. DualGuard may recommend splitting scope, sequencing reviews, or narrowing the release candidate when the surface area exceeds what a single contest window can cover well.

For very large codebases, duration is not purely linear. DualGuard confirms scope boundaries and expected throughput during scoping, and may recommend splitting scope or sequencing reviews if the surface area is too broad for a single contest window.

### How to plan around the full review flow

Contest length is only one part of the schedule.

Protocol teams should also budget time for:

* Agentic review, if included before the main contest
* Judging and deduplication after submissions are in
* Remediation for confirmed findings
* [Mitigation Review](/dualguard/security-reviews/security-reviews-for-protocol-teams/mitigation-review.md) before launch or upgrade

The exact sequence depends on the scope and the review package selected.

### After the contest: remediation and verification

After the contest ends, DualGuard finalizes the judged findings and your team begins remediation planning.

Teams should budget time for:

* Judging and deduplication
* Remediation of confirmed findings
* Fix verification through mitigation review

### Follow-up review windows

Sometimes the patch set is large enough that a short follow-up review is the safer move. This is common for major upgrades or when remediation touches core accounting, permissions, or integrations.

In these cases, DualGuard may recommend a shorter follow-up contest or targeted review window focused on the changes. The duration and cost are determined during scoping based on the change set and risk.

For a broader walkthrough of the process, see [How Security Review Contests Work](/dualguard/security-reviews/security-reviews-for-protocol-teams/how-security-review-contests-work.md).