Methodology v0.2

Introduction

Celebtir reads who controls each protocol straight from the chain: who can upgrade its programs, how fast, who holds its admin keys and where its prices come from. Every rating links to the account and slot it was read from. Published versions: v0.1, v0.2. Thresholds on this page are read from methodology/v0.2.toml, the same file the scorer uses.

Principles

• Evidence, not claims. Every rating links to the on-chain account and slot it was read from. Docs and announcements never change a rating.
• Weakest link. A protocol is rated by its weakest core program: one single-key program caps the whole protocol.
• Effective controller. Control is followed to its end. If a multisig's config authority is one key, that key is the real controller, with no delay.
• Unknown upgrade control makes a protocol Unrated. Other Unknown factors cap the Stage at 0. A failed read is never guessed; an observed but unrecognized controller is distinct from an unavailable read.
• Independent factors. The six ratings are never added up: each answers its own question.

Assessment scope

Six risk factors

Rating criteria

Every factor side by side. Thresholds are read from methodology/v0.2.toml.

Token factors · methodology v0.2

Tokens have four independent factors and no Stage. The recorded scorer output supplies the reason, improvement criterion and evidence for each finding. Token issuer powers do not automatically determine the rating of an accepting protocol.

freeze and seize

Recorded example (JLP): balances can be frozen by unrecognized controller AVzP…QK49 owned by program PERP…qQJu

Improvement criterion: remove any permanent delegate and hold freeze or pause powers in a multisig → MEDIUM

Inspect source observations

provenance

Recorded example (JLP): native to Solana

Improvement criterion: none: LOW is the lowest risk level

Inspect source observations

supply control

Recorded example (JLP): new supply can be minted by unrecognized controller AVzP…QK49 owned by program PERP…qQJu

Improvement criterion: hold the mint authority in a multisig → MEDIUM

Inspect source observations

transfer restrictions

Recorded example (JLP): no transfer restrictions

Improvement criterion: none: LOW is the lowest risk level

Inspect source observations

Stages

Stages describe who can change the protocol and how fast. They don't measure code security. A Stage is not a safety score and is never combined with the six factors.

1. Stage 0Rated, with requirements for Stage 1 still missing.
2. Stage 1Changes need many signers and give users time to react.
3. Stage 2Meets the published Stage 2 control requirements.

Unrated means the protocol cannot be assessed: its core programs are not identified, or a core program's controller could not be read. Stages follow Celebtir's versioned control requirements below. They do not guarantee protection from exploits or all team actions.

Evidence collection

Facts are read from Solana RPC each day and recorded with the account, field and slot they came from. Build verification comes from OtterSec, and TVL, fees and volume from DefiLlama.

How missing data is shown

Unknown

Celebtir could not read this on-chain data. Unknown is neutral, but it caps the Stage at 0.

Unrated

This protocol cannot be assessed yet: a core program's controller could not be read, or its source is not public.

Not applicable

This does not apply to the protocol (for example, it uses no price feeds).

Data unavailable

The external source (DefiLlama or OtterSec) did not answer. Ratings are unaffected.

Hyperliquid

HyperEVM sources

• Upgrade control: the EIP-1967 admin slot of each proxy, followed through its ProxyAdmin owner to a key, a Safe multisig or a timelock. UUPS proxies are followed through the owner of the implementation.
• Upgrade delay: a timelock's minimum delay. A timelock whose admin role is held by an outside address counts as no delay, because that admin can change the delay at once.
• Admin powers: the owner, or the role holders the registry names, of each contract, confirmed on chain.
• Code transparency: verified source on Sourcify, then on HyperEVMScan when a key is configured; for a proxy, the implementation is checked.
• Dependencies: the contracts the registry declares. They are not traced from transactions yet, and each reason says so.

HIP-3 anchor block

The Hyperliquid info API returns no block height. Every HIP-3 fact is anchored to the HyperEVM block read just before the request, and the site shows that block, never a guessed time.

Why HIP-3 DEXs are not rated yet

A HIP-3 market can never be immutable: its deployer must keep pushing prices, can halt and settle markets, and sets the caps. The six factors would rate every deployer the same way, so this version lists the facts (deployer, oracle updater, delegated actions, caps and stake) without ratings or a Stage. Rules for HIP-3 arrive with a later methodology version, after public feedback.

Limitations

• Value by control type is a simplification: free sources do not report TVL per program, so all of a protocol's value is placed under its weakest link.
• Recomputable, within limits. Anyone can re-score any published day's facts with the CLI and get the same ratings. Solana RPC cannot return an account's past state, so nobody can re-fetch yesterday's raw data: live checks can only confirm today's.
• Ratings describe on-chain configuration only. They do not audit code, and they may contain errors: report one from the About page.

Version history

Changelog

v0.2 verifies declared program-derived authority addresses and rates them by the program's upgrade control. Lending and perpetuals without registered feeds are Unknown. Delayed value control requires at least the Medium upgrade-delay threshold. Historical v0.1 scores retain their original rules.

The file

# Celebtir methodology v0.2: every threshold the scorer uses (SCO-2).
# The rules themselves are in the PRD's "Risk methodology" section. Changing a
# number here changes ratings without a code change, and needs a changelog entry.

version = "0.2"

# Who can replace the code?
# Low: immutable, or a multisig with >= low_min_voters voters at >= low_min_threshold_pct.
# Medium: a multisig with >= medium_min_voters voters at >= medium_min_threshold_pct.
# High: a single key, a smaller multisig, or a multisig whose config authority is one key.
# Ratios use voters (members with the Vote permission), not total members.
[upgrade_control]
low_min_voters = 5
low_min_threshold_pct = 60
medium_min_voters = 3
medium_min_threshold_pct = 50

# How long between approval and a new version going live?
# Low: >= low_min_secs, or immutable. Medium: >= medium_min_secs. High: less, or none.
[upgrade_delay]
low_min_secs = 432000    # 5 days
medium_min_secs = 86400  # 24 hours

# Can a key change parameters, pause or move funds outside an upgrade?
# Low: no admin key, or parameters-only power held behind a time lock of at least
# low_min_time_lock_secs (ADR 003). Medium: parameters or pause held by a multisig
# meeting the medium multisig bar above. High: anything else.
[admin_powers]
low_min_time_lock_secs = 86400  # 24 hours

# Where do prices come from? Oracle owner programs are classified by registry/oracles.yaml.
# Low: an established network with a fallback. Medium: a single established network.
# High: a protocol-run or single-signer feed, or an unclassified owner.
[oracle_dependency]
required_for_categories = ["lending", "perps"]
established_networks = ["pyth", "switchboard", "chainlink"]

# Stage 1, "Guarded" (mirrors L2Beat's Stage 1).
[stage1]
min_upgrade_delay_secs = 432000   # 5 days
emergency_min_voters = 8
emergency_min_threshold_pct = 75

# Stage 2, "User-protected".
[stage2]
governance_min_delay_secs = 2592000  # 30 days