Notes / Findings

Finding (2026-09-18): should score_morpho_vault_generic treat a 1-of-1 Safe as EOA-equivalent? Evidence for the decision, not a fix

Findings2026-09-18Chain: not statedLinked: Morpho NetNet Credit vault

Source: data/finding_2026-09-18-morpho-generic-1of1-safe-treatment.md in the repository, rendered here without changes. Source file

Raised by an open follow-up: should the generic Morpho scorer treat a 1-of-1 Safe as an EOA? (NetNet Credit scores 22 on-chain against 8 by hand.) Pure investigation -- scripts/lib/scorers.py is unmodified by this finding. A change to this scorer's formula needs this project's own adversarial-review discipline before committing, per the project's review rules' "Before committing" section, not a unilateral edit from a research pass.

What the code does today, and why#

score_morpho_vault_generic (scripts/lib/scorers.py:392-452) already discloses this exact gap in its own docstring: "It does not special-case a 1-of-1 Safe as functionally EOA-equivalent... confirmed: NetNet Credit scores 22 here vs. 8 by hand." Tracing the actual branch (lines 431-434):

if owner_is_eoa:
    admin_key = 10
elif owner_safe:
    admin_key = 30 + owner_safe[1] * 6  # threshold=1 -> 36, no special case

For NetNet Credit (0x99347d5F70D3838763f6Bddcf80304C8aa953B57), owner and curator are the SAME confirmed 1-of-1 Safe: admin_key = 30 + 1*6 = 36, multisig = 1*8 + 1*8 = 16, timelock_score = 10 (all three authority selectors have delay 0). `_composite(36, 16,

  1. = 22`. **Re-verified live against Robinhood Chain mainnet today

(2026-09-18): unchanged, still 36/16/10 -> 22.** Not stale, still a live gap.

This project's own precedent is NOT one consistent rule#

Two different conventions coexist, and both are more conservative than this scorer's current 36/16:

Two OTHER ecosystems have an explicit, already-written rule that goes further, treating it as full literal identity:

So: Hyperliquid and Solana chose full identity (adminKey AND multisig both collapse to the bare-EOA value). Robinhood Chain's own two existing precedents (_safe_rooted_scores, and the hand-derived Ramses number) both instead keep adminKey matched to the EOA value but leave multisig small-and-nonzero -- reflecting that a Safe transaction still routes through a separate contract mechanism (a real, if minor, structural difference from an EOA signing directly), not a distinction this project invented for this finding.

data/scored_targets_2026-09-16-batch9.md:117-123 already flags this exact tension as an open, deliberately-unresolved question -- this finding is corroborating and quantifying that flag with live numbers, not raising a new one.

What this does NOT do#

Not an audit, not investment advice. All notes ยท Back to the dashboard.