White Hat Hacker Web3: Reporting Routes, Safe Harbor and Payment Evidence

Finding the channel

An address labeled security is a route for a message. It is not permission to test a system, and it is not a promise of payment. That distinction should be established before a researcher spends time constructing a reproduction or assumes that a discovery qualifies for a bounty.

For the query white hat hacker Web3, the practical job is to connect a vulnerability observation with an authorized reporting process. Start at the project's official domain and follow its current disclosure policy or bounty listing. Verify the asset identifier and program scope rather than choosing a similarly named program from a search result.

The /.well-known/security.txt location is a standardized discovery mechanism. RFC 9116 defines fields such as Contact, Expires and Policy. It also expressly distinguishes a security contact file from implied permission to test. A file can help you find the policy that answers the authorization question, but the file itself does not answer it.

Our website survey found contact fields in only part of its selected records, including repeated domains. Some observed files lacked an expiry field or carried a past expiry. Those facts make a follow-up check necessary. They do not establish that the organization has no working disclosure channel.

Use the platform's specified channel when the program requires it. Immunefi's rules prohibit routing around the platform for negotiations and submitting through unauthorized channels. A technically detailed email can therefore be the wrong submission mechanism for a program hosted there. Record the route and current terms in the research notes before sending a report.

If a disclosure file has an expired Expires field, keep that fact separate from whether its Contact route still works. The published file may be stale while the organization maintains another official policy. Our measurement did not send a message to test delivery. It therefore supports a route-discovery observation only, with the recorded freshness limitation retained for the receiving organization.

Disclosure-route observations across 20 protocol records

Method

Source and selection

Top 20 protocol records by numeric TVL among HTTPS website entries in one DefiLlama API snapshot; ties by name. Fetch only standard well-known security.txt; no root fallback. HTML shells do not count.

Retrieved

2026-09-05

Observation

The sample is the 20 highest numeric-TVL records with HTTPS websites in the fetched DefiLlama response. It includes centralized services and repeated organizations.

Results

We observed a Contact field for Binance CEX, Lido, Robinhood, Binance staked ETH, Coinbase Bridge and Binance Bitcoin. These are six protocol records, not six independent disclosure organizations. The Binance entries repeat the same organization's route.

The observation deliberately stops short of calling these valid RFC 9116 files. Contact syntax and expiry still matter: the retained response includes contact values without a URI scheme and files with missing or expired expiry fields. The result supports a channel-discovery workflow with verification, not a claim that any listed endpoint authorizes research or guarantees a reply.

Limits

• The population contained 8,190 records; 3,965 had numeric TVL and an HTTPS website. Only the selected 20 routes were requested.
• Only the well-known route was tested. A policy elsewhere on the website or a root-level file could exist.
• Some requests failed or returned non-file content, so this route survey is partial. Missing observations do not mean no bounty or no disclosure process.

The reproducible record is kept in the repository: seo/research/articles-32-41-2026-09-05/surveys.py and seo/research/articles-32-41-2026-09-05/survey-37.json. These file paths are not public downloads.

Safe harbor conditions

Read the actual authorization language before testing. Scope, permitted techniques and disclosure conditions determine what the program permits. An ethical intention does not expand those terms. When a condition is unclear, request clarification through the authorized channel and keep the answer with the engagement record.

Ordinary vulnerability reporting and emergency asset rescue are different activities. The Security Alliance's Safe Harbor framework concerns defined action during an active exploit under an adopted agreement. It is not a general invitation to move funds whenever a researcher believes a contract is vulnerable.

The framework's public documentation describes protocol adoption, an agreement fact page and a registry process. Those artifacts establish the terms that a researcher must inspect. The documentation also identifies limits to legal protection. Do not replace that agreement-specific analysis with the assumption that the phrase whitehat makes an action lawful.

Immunefi's general rules prohibit testing against mainnet or public-testnet contracts and require express consent for whitehacking outside the applicable authorized arrangements. Treat a local fork as an isolated reproduction environment, not as a reason to send the same transaction to the live network. The production asset may be in scope for reporting while production testing remains prohibited.

If the affected system has no published safe-harbor policy, do not manufacture one from a contact address. Seek an explicit authorization decision before performing actions that could affect the system. The program-design article explains the corresponding responsibility on the protocol side: terms must say what is permitted rather than leave researchers to infer it.

Proof without exploitation

A useful report demonstrates a supported impact under the allowed testing conditions. It does not need to extract value from a live system to make the impact real. Provide enough evidence for the receiving team to reproduce the behavior in an isolated environment and identify the affected production configuration.

Begin with the asset and revision. Identify the in-scope contract, chain and relevant implementation, then explain the property that fails. A concise impact statement should name what an actor can do and the conditions required. Keep speculative extensions separate from the behavior the reproduction actually establishes.

A local reproduction should preserve its inputs and expected result. Record the chosen fork state or synthetic setup, tool versions and commands. If an assumption about a live dependency was modeled rather than observed, say so. The team needs to know which part of the claim depends on that assumption before assigning severity.

1. Identify a public behavior or code condition without affecting another party.
2. Confirm the asset, permitted activity and current reporting terms.
3. Demonstrate the impact in an isolated environment with recorded assumptions.
4. Use the authorized channel and retain the submission record.

1. Name the in-scope asset and the exact condition required for the issue to occur.
2. State the intended property and the observed violation, with a minimal local reproduction where required.
3. Attach the relevant source location and execution evidence, then identify assumptions the reproduction does not verify.
4. Explain the consequence in the program's impact terms without inflating severity or adding unproved losses.
5. Include a proposed remediation direction only when it follows from the mechanism; the receiving team still needs to review the complete fix.

Scanner output can be supporting evidence. It is rarely a complete report because the rule match may not establish reachable impact. Immunefi's rules address automated reports that lack the required impact information. The static-analysis triage guide explains how to turn a detector result into an investigated claim.

Protect the reproduction artifacts. Do not upload sensitive evidence to an unrelated public paste service merely because it is convenient. Use the platform's accepted attachment or inline mechanism and follow its rules for external dependencies. The report should be easy for the authorized recipient to inspect without exposing it to everyone else.

Package the observation for private review

A receiving engineer needs to distinguish a suspected issue from a demonstrated consequence. State the affected component and the conditions you observed, then separate them from assumptions that remain untested. If the evidence comes from source inspection, say so. Do not imply that the behavior was reproduced against a live deployment when it was only reasoned about locally.

For a permitted local proof, preserve the artifact versions and the test conditions needed to reproduce the result. Use synthetic accounts and assets where the authorized testing arrangement allows them. The report should explain why the observed behavior violates the intended property without including unrelated user data or unnecessary sensitive material.

Keep the scope boundary visible in the report itself. A researcher may have identified a shared component without verifying every downstream integration. List the observed target separately from potentially affected users of the component. The recipient can coordinate broader assessment without inheriting an unsupported claim that every adopter is exploitable.

When an initial report is incomplete, the next step can be a request for clarification through the approved channel. Explain what additional evidence would resolve the uncertainty and whether collecting it needs further authorization. Do not expand the activity merely to make the submission look more conclusive. An accurately bounded report remains useful even when the receiving team must complete part of the validation.

Retain the private submission record and any scope clarification. If the program later disputes the activity or the supported impact, those records help establish what was communicated and when. They do not guarantee a reward or legal protection; they preserve the evidence needed for the applicable process to evaluate the report.

Negotiating the payout

The advertised maximum is a ceiling under the program's terms. It is not the expected payment for every valid report. Eligibility, impact classification, duplication rules and required identity checks can change the result. Read those provisions before treating a bounty amount as money earned.

Build the payout discussion around the submitted evidence. If the project disputes impact, identify the condition on which the disagreement rests and provide the permitted reproduction evidence that resolves it. A technical disagreement is easier to mediate when both sides refer to the same asset, revision and state assumptions.

Keep communications inside the required process. Immunefi's rules consider negotiations outside its dashboard invalid. Use the platform's mediation path where applicable and preserve the relevant messages. Threatening exploitation or public disclosure to force a payment is incompatible with a responsible reporting process and can violate program rules.

Identity verification requirements deserve early attention. A program may require information for payout processing even when a researcher can initially submit a report. If a requirement cannot be met, resolve the issue through the authorized process rather than supplying inaccurate information or assuming it will be waived.

Separate a valid vulnerability from an eligible bounty claim. A genuine defect can be outside a program's scope or subject to another explicit exclusion. That outcome does not make the defect technically imaginary, but it can affect payment. A careful report records the technical conclusion and the program decision separately.

Payment does not necessarily grant immediate publication rights. Immunefi's responsible-publication policy defines categories and notes that some programs retain legacy conditions. Read the category attached to the actual program. Do not publish a reproduction while assuming that a paid status automatically lifts every restriction.

What happens when there is no policy

An unpublished policy leaves important questions unanswered. It does not create a universal reward obligation or authorize testing. Limit the initial contact to a concise description of the suspected issue and a request for a secure reporting route. Avoid sending sensitive proof broadly while trying to find someone who will respond.

Verify the recipient through official channels. A person replying from a social account may be helpful, but the account alone may not establish authority to approve testing or receive private evidence. Ask the organization to confirm the appropriate channel and retain that confirmation.

A security.txt file can help discover the route even when a bounty does not exist. Conversely, a missing file does not prove that the organization refuses reports. Look for a security policy linked from official documentation or a recognized platform program that the organization itself references. Keep these discovery steps separate from a decision to test.

If a shared library affects several projects, the maintainer may be a better coordination point than every downstream user at once. The researcher should still identify the scope of the observation and avoid assuming that every integration is vulnerable. A coordinated process can help assess the affected versions and disclosure timing.

Our Pharos Production member profile and member directory identify security providers; they do not grant permission to test clients or promise payment for unsolicited findings. Provider discovery is different from obtaining authorization from the system owner.

An unanswered report also needs a measured response. Retain the attempted contact and follow any published escalation process. Do not turn silence into permission to extract assets or reveal sensitive information. When the legal position or risk to users is unclear, obtain appropriate advice before expanding the activity.

The finished record should let another reviewer distinguish discovery, authorization, proof and the payout decision. A technically strong report can still fail at the authorization boundary. Establishing that boundary early protects the usefulness of the research and gives the receiving team a clear basis for action.