Skip to main content

​
Manual Verification

Manual verification is the fallback path for protocols whose contracts are immutable or do not expose an admin interface (like owner()). In this flow, Phylax verifies off-chain evidence that the requesting team controls the protocol and then registers the selected protocol admin in the on-chain State Oracle registry.

​
Definitions

TermDefinition
Assertion GroupA smart contract that follows the Assertion Interface and is deployed as EVM bytecode. It is associated with a target smart contract (assertion adopter).
Protocol Admin (Manager)The smart contract or EOA that has permission to deploy, update, and remove assertions for one or more target contracts.
ProtocolA group of deployed smart contracts maintained by a company, DAO, or other entity.
State Oracle (Registry)The Credible Layer contract that is the source of truth for protocol admins, assertions, and the target contracts they are attached to.

​
How protocol admin authority is determined

There are two ways a protocol admin can be authorized:

​
1) Owner interfaces (automatic)

If the target contract exposes an owner() interface, the registry can verify the admin on-chain and authorize that address as the protocol admin.

​
2) Manual verification (fallback)

When on-chain verification is not possible, Phylax can authorize a protocol team to define a protocol admin address through manual verification. This requires trust in Phylax as a verifier, since Phylax updates the registry with the chosen admin address after reviewing evidence.

​
Manual verification eligibility

A protocol must satisfy all of the following criteria:
  • Control over protocol code
  • Sufficient evidence that the requesting party is authorized to act for the protocol, assessed in a good-faith, case-by-case review
  • Consent to sharing identity, if required
Manual verification is provided at Phylax’s discretion and may be declined for any reason. Approval is not guaranteed.

​
Verification methods

Control over protocol code
  • Must be able to merge PRs to the active, official repo
  • Must have permissions to manage collaborators in the GitHub org
  • Must be able to commit and merge a PR to a default branch
Proof of intent and alignment Phylax will look for strong public signals that the organization wants to use the Credible Layer and that the selected admin address reflects the org’s intent. Non-exhaustive examples:
  • Proof of control (e.g., signature) from an emergency council or admin multisig
  • Posting a GitHub commit hash on the official X account
  • Posting a GitHub commit hash in an official Discord
  • Consent to being recorded on a video call for posterity

​
Manual verification will not be offered if

  • The protocol is fully anonymous
  • The team refuses to provide public proofs
  • The Phylax team does not believe it is authorizing the rightful protocol maintainer/owner

​
After manual verification is approved

  • The selected protocol admin address is added to the State Oracle registry
  • The protocol admin is associated with a specific set of contract addresses and can deploy assertions for those contracts
  • A 5-day timelock begins before the admin can add assertions, giving the protocol time to react or cancel if needed

​
Opt-out / Blacklist

Protocols can request manual verification specifically to be blacklisted: we still verify control, but instead of adding them to the registry, we add their contracts to an opt-out registry that blocks additions from everyone except a provided escape-hatch address.
  • Any protocol that wants to opt out can add themselves to an opt-out registry after manual verification confirms control
  • This opt-out registry prevents Phylax from adding the specified contracts to the registry (no assertions can be attached to those contracts)
  • The only entity that can re-enable registration is an address provided by the dApp at the time of blacklisting. This escape hatch allows protocols to opt out of Phylax while preserving the option to opt back in later