Documentation · Model v1.1
How Qrypt assesses an asset
Every assessment reports three separate things: a security score, a quantum-readiness status and a confidence level. They answer different questions and are never merged into one figure.
Assessments are produced by deterministic rules applied to observable evidence. The same evidence always yields the same result. Where evidence is missing, the result is unknown — never an assumed pass.
Security score
A number from 0 to 100. Higher means fewer detected risks under this model — not that an asset is safe. Four dimensions contribute, with these weights:
| Dimension | Weight | Rules |
|---|---|---|
| Contract Security | 35% | 7 |
| Liquidity Security | 25% | 3 |
| Holder Distribution | 20% | 3 |
| Deployer Reputation | 20% | 3 |
Weights are initial product assumptions, not empirical constants. They are versioned: any change to weights, thresholds or rules produces a new model version, and every assessment records the version that produced it.
- Rule credit. A pass earns full credit, a caution half, a risk none. Rules have weights within their dimension.
- Unknowns are excluded. A rule without evidence contributes nothing — it neither raises nor lowers the dimension.
- N/A dimensions. A dimension with evidence for less than 50% of its rule weight is marked N/A and left out.
- Coverage. The share of total weight that remained applicable is published beside every score. Below 50% coverage no overall score is published.
- Bands. 75–100 low risk, 50–74 moderate, below 50 high. No score is reported as unknown. Any failed rule caps the band at moderate, whatever the number: a sound contract does not offset a market with almost no liquidity.
Rules
The complete rule set for model v1.1, generated from the engine itself.
Contract Security
- Source verificationweight 3
- Whether the deployed bytecode matches published source code. Without it, contract behaviour cannot be reviewed.Pass: verified. Fail: unverified.
- Mint permissionsweight 3
- Whether any account can create new supply after deployment.Pass: no mint function, or minting renounced. Warn: owner mint with hard cap. Fail: uncapped owner mint.
- Ownership privilegesweight 2
- Who controls privileged functions, and what constrains them.Pass: no owner role, renounced, or multisig behind a timelock. Warn: multisig without timelock. Fail: single externally owned account.
- Upgradeable proxyweight 2
- Whether contract logic can be replaced after deployment.Pass: not upgradeable. Warn: upgradeable behind a timelock. Fail: upgradeable by a single account.
- Blacklist functionalityweight 2
- Whether a privileged account can block specific addresses from transferring.Pass: absent. Warn: present.
- Transfer restrictionsweight 2
- Fees or limits applied to ordinary transfers.Pass: 0% fee. Warn: fee up to 5%. Fail: fee above 5%.
- Trading restrictionsweight 1
- Whether a privileged account can pause or disable trading.Pass: absent. Fail: present.
Liquidity Security
- Liquidity depthweight 3
- Total value available in detected pools. Thin liquidity amplifies price impact.Pass: ≥ $250,000. Warn: ≥ $25,000. Fail: below $25,000.
- Liquidity lockweight 3
- Share of liquidity-provider positions that are locked or burned and cannot be withdrawn.Pass: ≥ 80% locked or burned. Warn: ≥ 30%. Fail: below 30%.
- Liquidity concentrationweight 2
- Share of unlocked liquidity controlled by the largest single provider.Pass: ≤ 50%. Warn: ≤ 85%. Fail: above 85%.
Holder Distribution
- Top-10 holder concentrationweight 3
- Supply held by the ten largest holders, excluding pools and burn addresses.Pass: ≤ 25%. Warn: ≤ 50%. Fail: above 50%.
- Largest holderweight 2
- Supply held by the single largest holder, excluding pools and burn addresses.Pass: ≤ 5%. Warn: ≤ 15%. Fail: above 15%.
- Holder countweight 1
- Number of addresses with a non-zero balance.Pass: ≥ 1,000. Warn: ≥ 100. Fail: below 100.
Deployer Reputation
- Deployer activityweight 2
- How many other token contracts the deploying address has created.Pass: ≤ 3 prior tokens. Warn: ≤ 10. Fail: more than 10.
- Deployer prior findingsweight 3
- Prior deployments by the same address that carry high-severity findings.Pass: none. Warn: one. Fail: two or more.
- Deployer funding sourceweight 1
- Origin of the first funds received by the deploying address.Pass: exchange or canonical bridge. Warn: unfunded-history address. Fail: mixing service.
Quantum readiness
A status, deliberately not a score: there is no defensible way to rank assets numerically on quantum exposure today. Most standard tokens inherit their cryptographic security from the chain they live on, and the status says so plainly.
- Conventional Cryptography
- No asset-level post-quantum mechanism was detected. The asset relies on the signature scheme of its underlying chain, as most standard tokens do. This is the normal state today and is not a vulnerability finding.
- Post-Quantum Mechanism Detected
- Verified contract logic authorises actions with a post-quantum signature scheme. This describes a detected mechanism, not a guarantee: the asset still depends on the underlying chain.
- Hybrid Mechanism Detected
- Verified contract logic requires both a conventional and a post-quantum signature. The asset still depends on the underlying chain.
- Evidence Insufficient
- There is not enough verifiable evidence — typically because source code is unverified — to determine which cryptographic mechanisms the asset relies on.
- Not Applicable
- Quantum-readiness classification does not apply to this subject type.
Confidence
High, medium or low. Confidence describes the assessment, not the asset: a low score can be held with high confidence, and a high score with low. Four factors each contribute up to two points — scoring coverage, contract verification, freshness and the share of rules with evidence. Seven or more is high, four or more is medium. An unverified contract can never reach high.
Assessments older than 72 hours are flagged as stale and lose their freshness points.
Limitations
- An assessment is not an audit. Rules detect known patterns; they do not prove the absence of flaws.
- Qrypt never states that an asset is safe or quantum-safe.
- Evidence reflects chain state at the assessment timestamp and can change afterwards.
- Tokens are analysed once they are trading, ranked by volume across Uniswap V2, V3, V4 and Pons V2 curves on Robinhood Chain. For every token the index reads liquidity, holder distribution, ownership and proxy status. Mint, blacklist, fee and trading-switch findings are established only for tokens launched through Pons V2, whose token contract is identified by its bytecode; for other tokens they are unknown, coverage stays below 50% and no numeric score is published. Source verification and deployer history are not read yet for any token.
- Token names and symbols are reported by the contract itself and are not verified.