> 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/dualguard-lingo.md).

# DualGuard Lingo

## People and roles

**Protocol team:** The builders and operators of the system in scope. Typically includes engineering, security, and operations roles responsible for scoping, remediation, and deployment decisions.

**Security researcher:** An independent researcher who analyzes code and systems to find vulnerabilities and reports them through a review program under the published rules.

**Guard:** A security researcher participating in DualGuard programs. Guards submit findings in competitive security reviews and pre-launch bug bounties.

**Lead Guard (LG):** A senior guard selected from the relevant leaderboard to help lead a competitive security review.

**Contest Manager (CM):** The operator responsible for setting up the repo, fixing repo issues, evaluating review scope, supervising the contest channel, deleting messages that hint at a vulnerability or lead, and answering codebase-related questions.

**Lead Judge (LJ):** The judge responsible for evaluating submissions under the published rules. Lead Judges validate issues, assign severity, group duplicates, and determine final contest outcomes.

**Judging:** The end-to-end evaluation process for contest submissions: validation, impact and exploitability assessment, severity assignment, duplicate grouping, and final outcome determination based on contest rules.

***

#### Core concepts

**Finding (Issue):** A security-relevant problem identified in code, configuration, or system design. A finding typically includes an impact statement, an attack path (or failure mode), and remediation guidance.

**Severity:** A classification of a finding based on impact and exploitability. Severity reflects what can break (loss of funds, unauthorized control, insolvency, denial of service, invariant violation) and how realistically an attacker can reach that state given prerequisites and constraints.

**Impact:** What a finding enables if exploited: fund loss, permission escalation, governance/control takeover, bad debt, broken accounting, state corruption, or other defined adverse outcomes.

**Exploitability:** How feasible it is to turn a finding into a real attack path. Exploitability depends on prerequisites (roles/keys), reachable call paths, external dependencies (oracles, integrations), economic conditions, and timing/sequencing constraints.

**Proof of Concept (PoC) / Reproduction:** Evidence that a finding is real and reachable. This can be a test case, transaction sequence, minimal exploit script, or a clear set of steps that reproduces the behavior.

**Scope:** The exact system boundary covered by a program: repositories, commit hashes/tags, deployed addresses, specific contracts/programs, and explicitly included integrations. Scope defines what is reviewed and what results are expected to apply to.

**In scope / Out of scope:** In scope means the issue affects components and versions included in the defined boundary. Out of scope means the issue involves excluded components, unsupported versions, or threat models the program explicitly does not cover.

**Release candidate (Scope freeze):** A pinned version of the code intended for deployment (or already deployed) that the review applies to. This is usually a commit hash, tag, or set of deployed addresses. Changes after the freeze are not automatically covered unless explicitly re-reviewed.

**Fix verification (Retest):** A follow-up review that checks whether a remediation closes the reported failure mode and does not introduce regressions or new trust assumptions. Verification may include reviewing the patch and re-evaluating exploit paths against the updated code.

**Disclosure:** The process of reporting a vulnerability through an agreed channel so it can be validated and fixed before details are shared publicly. Disclosure expectations are defined by the rules of the program (contest or bounty) and any safe-harbor terms.

***

#### Review programs

**Double-Team Security Review:** A private review where 2 senior reviewers work in parallel on the same scope. The emphasis is depth, adversarial reasoning, and cross-checking.

**Redcoat:** DualGuard's elite Double-Team Security Review for the highest-stakes scopes.

**Competitive Security Review:** A structured public review program where many independent guards analyze a defined scope concurrently under clear incentives, rules, and timelines.

**Mitigation review:** A follow-up review that checks whether a remediation closes the reported failure mode and avoids regressions or new trust assumptions.

**Pre-Launch Bug Bounty:** A final review window before deployment, where external researchers can still report vulnerabilities before funds are at risk.

**Post-Launch Bug Bounty:** Not currently offered by DualGuard.

**Review report:** A written artifact that documents findings, severity, reproduction context, and remediation guidance for an agreed scope and version.

**Contest submission:** A report submitted by a guard during a competitive security review. Submissions are evaluated for validity, severity, and scope alignment.

**Duplicate:** A submission that describes the same underlying issue as another submission. Contest rules determine how duplicates are handled and how credit is assigned.

**Contest rules:** The published constraints and evaluation criteria for a contest, including scope definition, submission requirements, severity definitions, duplicate handling, and payout methodology.

**Contest results:** The finalized set of validated findings after judging, including severity assignments, duplicate groupings, and any final notes required by the rules.

***

#### Leaderboards and judging

**Leaderboard:** A ranked view of guards generated from chosen filters.

**Leaderboard filters:** The inputs used to generate a leaderboard for a contest. Current filters include time range, languages, protocol category, and fork origin when relevant.

**Top 5 rule:** Lead Guards are selected from the top 5 of the matching leaderboard. DualGuard then chooses the first 2 available guards with the highest rank.

**All-time range:** The current time-range setting used for Lead Guard selection.

**Dual judging:** A contest-judging model where 2 Lead Judges independently evaluate submissions and help finalize outcomes.

**AI Judge:** A planned judging system that DualGuard intends to train using dual-judging data.

**Fallback selection:** If no suitable Lead Guard exists for a protocol, DualGuard can hand-pick leads using strong track records from other platforms.