Yes, if the contract can hold, move, mint, or lock user funds. Excluding unverified logic from bounty scope creates a coverage gap exactly where attackers may concentrate effort. A bounty programme is only meaningful when it follows the deployed control point, not the organisation’s preferred architecture diagram.
Why unverified contracts should not be excluded from bounty scope
Bug bounty scope should follow the deployed system, not the verification status of the code repository. If an unverified contract can custody value or trigger transfers, it is part of the attack surface and should be in scope for reporting. Treating it as out of scope simply creates a blind spot where the highest-impact defects can hide.
That distinction matters because attackers do not need source verification to find callable functions, privileged roles, or unsafe state transitions. They need only a live contract address, a reachable execution path, and an economic reason to probe it. The bounty programme should therefore reward findings against the deployed control point that actually moves risk.
What changes when the contract is unverified
Unverified does not mean inaccessible or low risk, it means reviewers have less visibility into intended logic. That reduces auditability, slows triage, and can make root-cause analysis harder, but it does not make the deployed contract less exploitable. In practice, the lack of verified source often increases the value of external testing because it removes one layer of defender assurance.
For bounty design, the key question is whether the contract can materially affect user assets, protocol state, or trusted execution flows. If it can mint, lock, transfer, or authorize value-bearing actions, then the absence of verification is a governance problem, not an exclusion criterion. Scope should be based on exploitability and impact, not on whether the team has published source verification.
Verified source still helps defenders and hunters by improving reproducibility and reducing false positives. But its presence is a convenience for review, not a prerequisite for responsible disclosure coverage. The deployed contract remains the authoritative object of assessment, especially when on-chain behaviour is already observable.
How to define scope without creating a coverage gap
A practical scope rule is to include every deployed contract that can directly or indirectly affect funds, permissions, or protocol integrity, whether or not it is verified. If the contract is a proxy, upgrade point, router, bridge component, vault, token contract, or other value-bearing control plane, it belongs in bounty scope even when source access is incomplete. Scope language should make that explicit so hunters do not self-filter the most important targets.
Use the verification status as triage context, not as a binary gate. If a finding depends on inferred logic rather than source review, testers should provide stronger proof of exploitability, but they should still be eligible for reward when the impact is real. That keeps the programme aligned to deployed risk while preserving a fair standard of evidence.
Where a team wants narrower scope, it should exclude specific behaviours or addresses, not entire classes of live value-bearing contracts by default. A blanket exclusion for unverified code encourages security debt to accumulate in the exact places where external scrutiny is most useful. The Tesla Kubernetes cryptojacking case is a reminder that exposure often begins at the deployed control point, not at the architectural diagram.
Risk and Threat Considerations
Excluding unverified contracts from bounty scope can leave a high-value blind spot in the precise places where attackers expect weaker review and weaker monitoring. That is especially dangerous when the contract can lock funds, route approvals, or change balances, because a single logic flaw can become a direct loss event.
Failure mechanism: The programme treats verification status as a proxy for safety, so testers avoid the live contract even though it still executes production logic and controls assets. Attackers then concentrate on the unreviewed surface, where bugs are less likely to have been found and published already.
Impact: Funds can be drained, frozen, or misrouted, and the organisation may only discover the issue after on-chain exploitation or user complaints. The result is a preventable gap between what is deployed and what is covered by incentive-driven testing.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Unverified deployed contracts create a production exposure gap analogous to insecure live configuration. |
| Recommendation — Include deployed value-bearing components in scope and test the live control point, not the published source status. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Bug bounty scope is a software-security boundary decision for deployed logic and attack surface. |
| Recommendation — Define scope around production software that can affect assets, not around repository verification state. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Verification status does not change whether deployed logic must be assessed for unsafe architecture or state handling. |
| Recommendation — Assess the deployed architecture and control flows that can move funds or change state. | ||
| NIST SP 800-53 Rev 5 | CA-2 — Control Assessments | Bounty scoping is a control-assessment boundary for the deployed system under review. |
| Recommendation — Assess the live contract behavior that creates risk, even when source verification is missing. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Publicly reachable contracts are exposed attack surfaces that adversaries probe for exploit paths. |
| Recommendation — Hunt the reachable contract surface for exploitable logic regardless of source publication status. | ||
Practitioner Guidance
What to prioritise: Put value-bearing deployed contracts in scope first, then decide whether to add review notes, test constraints, or evidence requirements for unverified code. If the contract can move or lock funds, bounty eligibility should not depend on source verification.
What to verify: Scope text should explicitly cover proxies, upgrade paths, vaults, routers, and other contracts that influence asset control. Hunters should be able to show an on-chain impact path even when source is unavailable.
Common mistake: Teams often confuse “harder to analyse” with “safe enough to exclude.” That shortcut usually undercuts the bounty programme, because the contracts that are hardest to inspect are often the ones that most need external scrutiny.
Practitioner takeaway: Scope should track production authority over user funds and protocol state, because that is where exploit impact lives, regardless of whether the code has been publicly verified.
Related resources from NHI Mgmt Group
- What should organisations do first when they want to include production assets in bug bounty scope?
- How should security teams handle leaked credentials reported outside bug bounty scope?
- Why do broad scope and responsive triage matter in bug bounty programmes?
- Why does bug bounty scope quality matter so much?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org