> ## Documentation Index
> Fetch the complete documentation index at: https://docs.phylax.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# How to Request Manual Verification

> Request protocol admin authorization when contracts lack supported owner interfaces

This guide shows you how to prepare a manual verification request when your contracts are immutable or do not expose a supported admin interface such as `owner()`.

<Note>
  Manual verification is the fallback path. If your target contracts expose a supported owner interface, use the normal [Ownership Verification](/credible/ownership-verification) and [deployment](/credible/deploy-assertions-dapp) flow instead.
</Note>

## Prerequisites

* The target contracts do not pass automatic owner-based verification.
* You can identify the contract addresses that need a protocol admin.
* You have selected the smart contract or EOA that should manage assertions for those contracts.
* You can provide evidence that the requesting team controls the protocol.
* You can provide public proof that the organization wants to use the Credible Layer, if required.
* You are willing to share identity or authorization evidence when needed.

## Step 1: Confirm Automatic Verification Does Not Apply

Check whether the target contracts expose a supported ownership interface. The common automatic path expects an `owner()` function:

```solidity theme={null}
interface IOwnable {
    function owner() external view returns (address);
}
```

If your contracts expose this interface, use [Ownership Verification](/credible/ownership-verification). If they are immutable or use a different ownership architecture, continue with manual verification.

## Step 2: Choose the Protocol Admin Address

Choose the smart contract or EOA that should be allowed to deploy, update, and remove assertions for the target contracts.

<Note>
  Managing assertions is a sensitive role. We recommend using hardware wallets and multisig accounts for protocol admin addresses.
</Note>

## Step 3: Prepare Code-Control Evidence

Prepare evidence that the requesting party controls the active, official protocol codebase. Useful signals include:

* Ability to merge pull requests to the active, official repo
* Permission to manage collaborators in the GitHub organization
* Ability to commit and merge a pull request to a default branch

## Step 4: Prepare Proof of Protocol Intent

Prepare strong public signals that the organization wants to use the Credible Layer and that the selected protocol admin address reflects the organization's intent.

Non-exhaustive examples:

* A signature from an emergency council or admin multisig
* A GitHub commit hash posted from the official X account
* A GitHub commit hash posted in an official Discord
* Consent to being recorded on a video call for posterity

## Step 5: Submit the Request for Review

Share the target contracts, selected protocol admin address, code-control evidence, and proof of protocol intent with Phylax for review.

Phylax reviews manual verification requests in good faith on a case-by-case basis. Approval is not guaranteed, and Phylax may decline a request for any reason.

Manual verification will not be offered if:

* The protocol is fully anonymous.
* The team refuses to provide public proofs.
* The submitted evidence is insufficient to verify the rightful protocol maintainer or owner.

## Step 6: Verify the Result

If manual verification is approved:

* The selected protocol admin address is added to the State Oracle registry.
* The protocol admin is associated with the approved contract addresses.
* A 5-day timelock begins before the admin can add assertions, giving the protocol time to react or cancel if needed.

Before deploying assertions, confirm that the registered admin address and contract set match the approved request.

## Opt Out of Registry Additions

Protocols can also request manual verification to opt out of registry additions. Phylax still verifies control, but instead of adding the protocol admin to the registry, Phylax adds the contracts to an opt-out registry.

The opt-out registry blocks assertion additions for those contracts. The only entity that can re-enable registration is an address provided by the platform at the time of blacklisting. This escape hatch allows protocols to opt out while preserving the option to opt back in later.

## Related docs

* [Ownership Verification](/credible/ownership-verification)
* [Projects](/credible/dapp-projects)
* [Credible Layer Contracts](/credible/credible-layer-contracts)