OceanAltOceanAlt

Rating methodology v0.4

Method before conclusions. This page spells out exactly how a score is produced — indicators, weights, bands, evidence levels, review and appeals. You can apply it to any provider yourself. If your result differs from ours, then either our method or our judgement is wrong, and we want to hear about it.

01

Indicators & weights

The seven pillars come from our published RAP framework v1.0. The weights aren't arbitrary: attribution and enforcement are what decide whether money leaves at all, so they carry the most weight. Privacy and interoperability matter, but they don't determine whether a payment clears, so they weigh less.

PillarThe question it answersWeight
AttributionCan we establish who is paying and which entity is accountable25
Mandate & limitsAre spending boundaries enforced by a system outside the agent20
FirewallAre non-compliant payments actually stopped before settlement20
AML screeningIs the counterparty screened against sanctions and risk signals15
AuditabilityCan what happened be reconstructed after the fact10
PrivacyIs compliance achieved without over-collecting data5
InteroperabilityDoes it work across protocols and rails rather than locking in5
Total (enforced = 100: a model whose weights do not sum to 100 cannot be saved, published or recomputed)100

Front end, back office, computation, API and this page read one and the same weight configuration. Rating model v0.4; all profiles were last recomputed under these weights on 2026-09-06.

02

How each pillar is scored

Each pillar scores 0–3. The bands are defined so a third party can reproduce them; otherwise a score is just an impression. Note the gap between 2 and 3: 'it exists' and 'we actually tested it' are not the same claim.

Capability score and evidence strength are two different things and are recorded separately: the score says which band the subject actually reaches; evidence strength (sufficient / partial / insufficient) says whether the public material supporting that judgement is adequate and traceable. 'Sufficient evidence' means the current score is well supported and high-confidence, not that the pillar deserves a higher score; evidence strength only affects confidence, pending-verification status and publishability, never the score itself.

  • 0

    Absent

    The capability doesn't exist, or the stated positioning bypasses it

  • 1

    Stated

    Publicly claimed, but no verifiable evidence of implementation

  • 2

    Implemented

    Verifiable implementation exists — docs, code, API or a working demo

  • 3

    Verified

    We or a credible third party actually tested it and can reproduce the result

03

How the grade is set

The grade follows the weighted score directly: ≥85 L3 / ≥65 L2 / ≥40 L1 / otherwise L0. A human may deviate from the mapping, but must state the reason publicly — for instance when one fatal gap should not be averaged away by high scores elsewhere. Protocols and settlement rails themselves are not graded.

  • L3TrustworthyKey pillars independently verified; safe as a default counterparty
  • L2UsableCore controls implemented; some parts await third-party verification
  • L1LimitedIdentity or compliance is claimed, but enforcement is weak
  • L0Non-compliantStructurally fails attribution; a paying agent should assess the risk before integrating
  • NRNot ratedNot yet rated, or public information is insufficient. Neither an endorsement nor a warning

We keep the L0–L3 scale published in RAP v1.0 rather than renaming it to match other documents: renaming would invalidate the published standard and any existing citations.

04

Evidence levels

Every piece of supporting evidence is labelled by level. Secondary reporting alone can't support a score — it can point us at something worth checking, but it never becomes a score by itself.

  • E1 · TestedWe ran it ourselves and can reproduce it
  • E2 · Primary sourceOfficial docs, code repos, on-chain data, regulatory filings
  • E3 · Self-attestedThe subject's own claims, not independently verified
  • E4 · Secondary reportingPress coverage; insufficient on its own to support a score

05

Review cycle, re-review and appeals

  • Cycle: routine re-review every 180 days, plus an immediate re-review whenever the subject materially changes — a new release, a licence, or a security incident.
  • Change log: every grade change is recorded on the subject's profile page with the before, the after and the reason. Past ratings are never erased.
  • Notice before publication: for a named rating we notify the subject before publication where possible and offer a response window. Their reply is published verbatim on the profile page; if they decline or don't respond, we say so.
  • Appeals: a subject may dispute a factual finding by submitting evidence; we respond within two weeks and publish the outcome. Facts can be disputed; conclusions cannot be requested.

Submit a re-review or appeal →

06

Conflict-of-interest policy

OceanAlt accepts commercial partnerships and commissioned assessments, but commercial relationships do not influence our rating conclusions; all such relationships are disclosed on the relevant rating pages.

  • Any commercial, investment or personnel relationship with a subject is disclosed at the top of its profile. If a relationship can't be disclosed, we don't rate that subject.
  • Our own products are always marked self-attested, are never ranked alongside third-party ratings, and get no benefit of the doubt: the current self-rating is L2 precisely because we have not had a third-party security audit.
  • As of this page's last update, OceanAlt has no outside investors and no commercial agreement with any rated subject. This sentence will be updated as that changes.

This methodology may itself be wrong. How the weights are set and where the line between a 2 and a 3 falls are judgements, not facts. If you think we've got it wrong, tell us — revisions to the method are versioned and logged too.

Rating methodology v0.4, published ahead of any rating conclusions. For the ratings themselves, see Ratings.