Notes / Audits and snapshots

Tempo -- Morpho Vault V2 target type (rule R8), 3 targets scored, 2026-09-18

Audits and snapshots2026-09-18Chain: TempoLinked: Sentora pathUSD (Morpho Vault V2), Unnamed pathUSD Vault V2 feeding Sentora, Tempo Earn (Morpho Vault V2, Gauntlet-curated)

Source: chains/tempo/data/scored_targets_2026-09-18-vault-v2.md in the repository, rendered here without changes. Source file

Closes chains/tempo/data/scouted_targets_2026-09-17-run2.md section 8's open point 4 for Morpho Vault V2 ("Morpho Vault V2 and market oracles need a written target type"). Unlike the same day's other R2 extension (4 controller shapes, data/scored_targets_2026-09-18-controller-types.md), this is a genuinely NEW target type (rule R8, METHODOLOGY.md section 4.1) -- Vault V2's owner/curator were already resolvable by the existing classify()/weakest() (rules R2/R3) without any change, since both are plain addresses (a Safe or an EOA on every live target found so far). What did not exist before this pass was: (a) the decision that the root-control set for a vault is {owner, curator}, not just one of them, and not the allocator/sentinel roles either; and (b) a delay dimension based on Vault V2's own per-selector timelock(bytes4)/abdicated(bytes4) mappings rather than a single getMinDelay().

Reference implementation: score_vault_v2() / _vault_v2_timelock() / VAULT_V2_TARGETS / VAULT_V2_FUND_DESTINATION_SELECTORS, all in chains/tempo/scripts/methodology_test.py; wired into score_all() in chains/tempo/scorers.py.

Rule (METHODOLOGY.md section 4.1, R8)#

Targets scored#

#TargetAddressOwnerCuratorWeakest keyFund-destination delay
T1Sentora pathUSD (Morpho Vault V2)0x9a044AE05E5e6290DcF56afd69548565e957a626Safe 1-of-1 0xe8C9C99E...8008 (signer 0x295Df6B7...7E9)Safe 1-of-1 0x9e396dE3...ac0 (signer 0x992592e0...ABE)(1,1)259,200 s (3 d)
T2Unnamed pathUSD Vault V2 feeding Sentora0x83a1491f3e7f8dAAB8F787a631334b9ca7a87023plain EOA 0x445F7a27...8Dc9same EOA (owner = curator)(1,1)0 s
T3Tempo Earn (Morpho Vault V2, Gauntlet-curated)0xC609656Ed9ef219c98C8e549bF729144F211f06ESafe 4-of-7 0x5a4E1984...D0Safe 3-of-7 0x9E33faAE...585 (same 7 signers as owner)(3,7), via curator259,200 s (3 d)

All addresses, thresholds, owner sets and per-selector timelock/abdicated reads above were read live against https://rpc.tempo.xyz on 2026-09-18 (both via cast call and via this project's own call2() dual-endpoint cross-check inside score_vault_v2()), and match scouted_targets_2026-09-17-run2.md section 3/5's own live tables exactly (same owner/curator addresses and thresholds, same per-selector delay/abdicated values for every one of the 5 selectors on all 3 vaults).

Per-selector reads (live, both endpoints agree)#

SelectorT1T2T3
addAdapter259200, not abdicatedabdicated604800, not abdicated
removeAdapter604800, not abdicatedabdicated604800, not abdicated
setAdapterRegistryabdicated0, not abdicatedabdicated
increaseAbsoluteCap259200, not abdicated0, not abdicated259200, not abdicated
increaseRelativeCap259200, not abdicated0, not abdicated259200, not abdicated
Minimum over non-abdicated2592000259200

Scores#

TargetadminKeyScoremultisigScoretimelockScoreoracleAuthorityScorecompositeScore
T1 Sentora pathUSD10156010027
T2 unnamed feeder vault101501009
T3 Tempo Earn65566010061

Cross-check, not a coincidence: T1 and T3 independently reproduce scouted_targets_2026-09-17-run2.md section 4's own "resolved reading (proposal)" column EXACTLY -- "T1 curator 1-of-1 + 3 days = 10 / 15 / 60 / 27" and "T3 curator 3-of-7 + 3 days = 65 / 56 / 60 / 61" -- even though that column's numbers were hand-derived by a DIFFERENT research pass and this pass's score_vault_v2() re-derives them independently from a live classify() call, not by copying the target row. T2 has no example in that column to compare against (the proposal table only worked through T1 and T3); its 10/15/0/9 is this pass's own first reading, disclosed as such rather than presented as a reproduction.

crossExposureScore for these 3 targets is computed the same way as every other Tempo target once they run inside the same score_all() batch as the chain baseline and the 9 TIP-20s (rule R6, shared-root-signer count across the WHOLE tracked set) -- not reproduced here as a standalone number, since it depends on the other 10 targets' signer sets too.

Not yet promoted / disclosed limitations#

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