# Five-view control-check pilot: agreement and disagreements

## Scope and comparison method

This report compares only the supplied independent views 1–5. It adds no contract checks. Contract labels below follow the assignment; the comparison does not independently establish that a label matches deployed code.

Views 1 and 3 report that explorer requests returned 403 and that they obtained no source, state, bytecode, or block. Their `unknown` answers are evidence of access failure, not evidence for either a positive or negative control finding. Views 2, 4, and 5 report substantive reads, with uneven coverage. In particular, Robinhood Chain source access was blocked for some checkers. The cited view evidence supports what that checker observed; this synthesis does not independently validate its chain claims.

For the agreement table, `yes 3; unknown 2` means three views gave yes and two unknown. Addresses are grouped only where the reported addresses match. For `owners`, a match means agreement on the principal address/role stated, not identical completeness or classification. For `block`, different snapshots/ranges are distinct; `unknown 2; 3 distinct` means two views had no block and the other three did not report one identical block. `evidence` is not a contract answer and cannot be counted as categorical agreement; its source trail is summarized below. Thus the overall agreement denominator is the 12 answer/state keys per contract (including `block`, excluding `evidence`): 8 × 12 = 96.

## 1. Agreement table

| Contract | proxy | implementation | admin | admin_owner | owners (principal/role) | mint | mint_cap | pause | fees | delay | source_verified | block |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 CLAUS, RH | yes 3; unknown 2 | same address 3; unknown 2 | same address 3; unknown 2 | same address 3; unknown 2 | controller chain agrees in 3; unknown 2 | unknown 3; yes 2 | unknown 3; no 2 | unknown 3; no 2 | unknown 3; no 2 | unknown 3; no 2 | unknown 3; yes 2 | unknown 2; 3 distinct |
| 2 CLAUS owner contract, RH | no 2; unknown 3 | n/a/no 2; unknown 3 | n/a/no 2; unknown 3 | n/a/no 2; unknown 3 | owner address in 3; operator in 2; unknown 2 | no 2; unknown 3 | no 2; unknown 3 | no 2; unknown 3 | no 2; unknown 3 | no 2; unknown 3 | yes 2; unknown 3 | unknown 2; 3 distinct |
| 3 Old CLAUS, ETH | yes 3; unknown 2 | same address 3; unknown 2 | same address 3; unknown 2 | renounced/zero in 3 (wording/value differs); unknown 2 | token owner/admin path agrees in 3; unknown 2 | no 3; unknown 2 | no 3; unknown 2 | no 3; unknown 2 | no 3; unknown 2 | no 3; unknown 2 | yes 3; unknown 2 | unknown 2; 3 distinct |
| 4 Claus NFT, ETH | no 3; unknown 2 | n/a/no 3; unknown 2 | n/a/no 3; unknown 2 | n/a/no 3; unknown 2 | owner address in 3; unknown 2 | yes 3; unknown 2 | yes 3; unknown 2 | no 3; unknown 2 | yes 2; no 1; unknown 2 | no 3; unknown 2 | yes 3; unknown 2 | unknown 2; 3 distinct |
| 5 IMD Intake, ETH | no 3; unknown 2 | n/a/no 3; unknown 2 | n/a/no 3; unknown 2 | n/a/no 3; unknown 2 | owner address in 3; unknown 2 | no 3; unknown 2 | no 3; unknown 2 | no 3; unknown 2 | yes 3; unknown 2 | no 3; unknown 2 | yes 3; unknown 2 | unknown 2; 3 distinct |
| 6 IMD Intake, RH | no 1; unknown 4 | n/a/no 1; unknown 4 | n/a/no 1; unknown 4 | n/a/no 1; unknown 4 | owner getter in 3; writer/signer getter values in 3 (role enforcement unclear); unknown 2 | no 1; unknown 4 | no 1; unknown 4 | no 1; unknown 4 | yes 1; unknown 4 | unknown 5 | unknown 5 | unknown 2; 3 distinct |
| 7 IMD token, ETH | no 3; unknown 2 | n/a/no 3; unknown 2 | n/a/no 3; unknown 2 | n/a/no 3; unknown 2 | owner address in 3; unknown 2 | yes 3; unknown 2 | no 3; unknown 2 | yes 2; unknown 3 | yes 2; unknown 3 | no 2; unknown 3 | yes 3; unknown 2 | unknown 2; 3 distinct |
| 8 IMD seat NFT, ETH | no 3; unknown 2 | n/a/no 3; unknown 2 | n/a/no 3; unknown 2 | n/a/no 3; unknown 2 | owner contract address in 3; unknown 2 | yes 3; unknown 2 | yes 3; unknown 2 | no 3; unknown 2 | no 3; unknown 2 | no 3; unknown 2 | yes 3; unknown 2 | unknown 2; 3 distinct |

Counts for implementation/admin fields treat “none” and “not applicable” as the same substantive absence only when the view explicitly classified the target as non-proxy. For contract 3, `admin_owner` is not normalized to a literal address: view 2 wrote `no`, while views 4 and 5 gave the zero address. The shared interpretation is that the ProxyAdmin has no current owner.

The block entries have no five-way matching snapshot. Views 1 and 3 have no block. View 2 used Ethereum block 26398577 and Robinhood block 112493703. View 4 used ranges 26398572–26398581 and 112493273–112494208. View 5 reports Ethereum block 26398580 and Robinhood block 112494184. These are the views’ stated snapshot evidence; they show observations were not synchronized, not that answers at one common block conflict. The evidence arrays/text also differ in contents and format, so they are attributed individually below rather than treated as answer values.

**Overall:** all five agreed on 2 of 96 answer/state cells (2.1%): contract 6 `delay=unknown` and `source_verified=unknown`. At least four agreed on 10 of 96 (10.4%); the other eight are the contract 6 proxy, implementation, admin, admin_owner, mint, mint_cap, pause, and fees cells, each with four unknowns and view 4's contrary substantive answer. No other cell reached four matching answers. These are exact-choice counts, not a claim that the agreed unknowns answer the underlying control question.

## 2. Disagreements and what the evidence supports

Evidence references below point to the named checker view and its evidence IDs, read-call labels, or source functions. For views 1 and 3, the cited 403 results support only the reported inability to read the contracts. Views 2, 4, and 5 contain the affirmative/negative support described. “Supports” means supports that view's stated answer on the evidence as it reports it, not independent verification by this summary.

### Contract 1 — CLAUS token, Robinhood Chain

- **Proxy and addresses:** views 1 and 3 say unknown after 403s ([view 1, E1](view-1.md); [view 3, 1a–1b](view-3.md)). Views 2, 4, and 5 say yes and agree on implementation `0xd68727ddd50e8ba07e4be20d37a5ecf3dd814bff`, admin `0xcbc4bbd337e62c926c995e66a231e5e2b0a722a8`, and admin owner `0x979d5810d32292358639f25294472f01c95bdc46`. Their reported support is view 2 R1/R-A1 and S1, view 4 `cast storage` plus Sourcify full match, and view 5 R1–R4/R49–R50 plus runtime interpretation. The affirmative side is supported by storage/source observations; the 403s do not contradict it.
- **Mint, cap, pause, fees, delay, verification:** views 1 and 3 are unknown; view 5 is also unknown because its Robinhood implementation source was inaccessible (view 5 S1/S16/S17). Views 2 and 4 agree: mint yes, no cap, no transfer pause, no token fee setter, no delay, verified source yes. Supporting evidence: view 2 S1/I1/R-S1 and view 4 Sourcify full-match claim, runtime/owner calls, and MigrationToken source interpretation. The unknown answers reflect access limits and do not refute those code-based conclusions. A scope wrinkle is that view 4 treats the recorded pool fee field as a declaration, not a token fee; view 2 likewise says no token transfer fee.
- **Owners:** the three substantive views agree on the administrator contract and founder/controller address. View 2 additionally lists an operator and receipt signer; view 4 lists the operator; view 5's owners array omits those additional roles. The role lists therefore differ in completeness, not on the shared owner chain. See view 2 R2/R-X/R-W, view 4 live `owner()`/`operator()` calls and role table, and view 5 R6–R8/R53.

### Contract 2 — CLAUS owner contract, Robinhood Chain

- **Proxy:** views 2 and 4 say no (view 2 R2/S2; view 4 zero EIP-1967 slots and direct-source/Sourcify findings). Views 1, 3, and 5 say unknown (views 1–3 access failures; view 5 R6/R9–R11 with source S2 inaccessible). Thus the positive evidence side is views 2/4; view 5 explicitly cautions that zero standard slots alone do not exclude other proxy schemes.
- **Owners:** all three data-bearing views return owner `0xbb145ca83272c3806d4ddc75ca1d5514789cf1c5`; views 2 and 4 also identify operator `0x8aca8890d34086d7a30b9c06fae25e0c3cda4cfa`, omitted from view 5's array. View 2 R7/R8 and source S2, view 4 `owner()`, `operator()` and codesize calls, and view 5 R6–R8 support the shared owner address. Only views 2 and 4 support the operator role; view 5 could not establish role completeness.
- **Mint, cap, pause, fees, delay, source:** views 2 and 4 say no for direct/local powers and yes for verified source; view 5, like views 1 and 3, leaves these unknown because its source read failed. View 2 S2/R2/R-S2, view 4 Sourcify full match and `execute()` interpretation, and view 5 S2 (403) support their respective positions. Interpretive scope matters: view 2 says downstream managed-target capabilities belong to contract 1, while view 4 notes this controller can execute calls that mint, pause, or upgrade managed targets. The bare form does not say whether to count powers exercised indirectly over another target.

### Contract 3 — Old CLAUS token, Ethereum

- **Proxy, implementation, admin, and source:** views 2, 4, and 5 agree yes and report the same implementation `0x55d555bd85fed6ecf30fda9b4c76019b844218a7`, admin `0xfb4b9d2ba3ef17787bfe3fd90c3ea7b319807a57`, and verified source. Views 1 and 3 are unknown due 403s. View 2 S3/R3; view 4 EIP-1967 storage plus Blockscout source pages; view 5 S3/S9/S10 and R12/R15/R16/R48 support the affirmative findings.
- **Admin owner:** view 2 answers `no` (no owner), views 4 and 5 report the actual zero address. These agree in meaning, not encoding: view 4's `owner()` read and view 5 R15/L1 support zero; view 2 R-A3 and S10 describe the renounced ProxyAdmin.
- **Token owner/type and other powers:** the three substantive views identify token owner `0xbb145ca83272c3806d4ddc75ca1d5514789cf1c5` and characterize it as an EIP-7702 delegated EOA/wallet; their description of delegation detail varies. Views 2 and 5 reference the delegation designator/delegate source (R-W/D3, A2/S11/R51/R66–R67); view 4 reads the designator but says it did not inspect the delegate. The three data-bearing views agree no mint, cap, transfer pause, fee setter, or delay, and yes verified source; view 2 I3/A3, view 4 ProtectedToken source interpretation and ProxyAdmin zero-owner call, and view 5 S9/S10/R15/R48 support those conclusions. Views 1 and 3 remain unknown, not opposing findings.

### Contract 4 — Claus NFT collection, Ethereum

- **Core fields:** views 2, 4, and 5 agree no proxy, yes mint, yes cap, no transfer pause, no delay, and verified source. They report owner address `0xbb145ca83272c3806d4ddc75ca1d5514789cf1c5`; view 4 calls it a wallet, while views 2/5 identify its EIP-7702 delegation. Source S4 and calls R17–R20/R71–R72 in view 5, view 2 S4/R4/R-S4, and view 4 `owner()`/`totalSupply()` plus ClausNFT source interpretation support the common findings. Views 1 and 3 are unknown due access failure.
- **Fees:** views 2 and 5 say yes because they include the external Chainlink/VRF oracle charge and its configurable wrapper/Safe authority (view 2 S13–S15/R21/R65/R68–R70; view 5 S13–S15 and R64–R84). View 4 says no owner setter on the NFT and treats the VRF charge as external (its ClausNFT section). The evidence supports both descriptions of different scopes: there is no collection-owner fee setter, while an external wrapper owner can change oracle pricing configuration. The form's unqualified “fees” field does not decide whether that external dependency counts.
- **Owner role detail:** the collection owner address is shared; views 2 and 5 trace the delegated wallet and the external fee controller, while view 4 reports the collection owner only. The fee-controller chain is not the NFT's owner chain, a distinction the original form does not request explicitly.

### Contract 5 — IMD Intake, Ethereum

- **Agreement on substantive answers:** views 2, 4, and 5 agree no proxy, no token/NFT mint or supply cap, no transfer pause, fees/price/payee can be changed, no timelock, and verified source. They identify owner `0x047f606fd5b2baa5f5c6c4ab8958e45cb6b054b7`. Support: view 2 S5 and R23–R27; view 4 slot/owner/payTo/writer/signer calls and Intake source; view 5 S5 and R22–R27. Views 1 and 3 say unknown solely because they could not access data.
- **Meaning of pause/mint:** view 2 makes explicit that it is a request/payment service rather than a token ledger; view 4 says setting a price to zero can stop sales but still answers no to pause. This is a scope distinction, not a disagreement on transfer pausing. View 2 also reports writer and signer roles, which views 4/5 do not include in their JSON owners lists; those roles are supported by view 2's getters/source and view 5's R24/R25 plus source, while view 4 did not check their code types.

### Contract 6 — IMD Intake, Robinhood Chain

- **Proxy and proxy fields:** views 1, 2, 3, and 5 say unknown; view 4 says no based on zero standard slots and code observations. View 4's slot reads support absence of the standard EIP-1967 pattern, but view 5 R9–R11 cautions that zero standard slots do not establish absence of every proxy scheme, and verified source was unavailable. Full proxy status is therefore unresolved from the evidence recorded here.
- **Mint/cap/pause/fees:** view 4 says no mint/cap/pause and yes fees, inferring shared behavior from similarly sized Ethereum/RH code and responsive getters. Views 1, 2, 3, and 5 leave these unknown. View 4 reports owner/getter calls and a codehash comparison, but explicitly says the code hashes differ and it did not byte-diff the code or verify the source; this is indirect support, not confirmation of the RH implementation's complete behavior. Views 2/5 have getters but state that getters alone do not establish role enforcement or setter logic. Therefore these disagreements remain unresolved for this chain. The fact that the same address is used on Ethereum does not settle it.
- **Owners:** views 2, 4, and 5 agree on owner `0x047f606fd5b2baa5f5c6c4ab8958e45cb6b054b7`; views 2 and 5 also return writer/signer getters. View 2 adds payee and labels all four as code-free wallets; view 5 lists owner/writer/signer but omits payee; view 4 reports the same getters but its owner classification is the strongest confirmed role. Their evidence (view 2 R29–R33/R-W, view 4 live getter and codesize calls, view 5 R29–R33/R55/R57/R59/R61) supports the returned values, not necessarily completeness or authorization.
- **Delay and source verification:** all five answer unknown. View 4 says delay unknown because RH source is not verified; view 5 likewise reports Sourcify `match:null` and a Blockscout 403 (S6); views 1–3 record access failures. No evidence in the views resolves either question.

### Contract 7 — IMD token, Ethereum

- **Proxy, owner, mint/cap, and source:** views 2, 4, and 5 agree no proxy, owner `0x047f606fd5b2baa5f5c6c4ab8958e45cb6b054b7`, mint yes, no explicit cap, and verified source; views 1 and 3 are unknown. View 2 S7/R38/R41, view 4 owner/endpoint/totalSupply calls and OFT source interpretation, and view 5 S7/R37–R43 support the common findings.
- **Pause, fees, delay:** views 2 and 5 say yes for bridge-level restrictions and configurable bridge options, and no timelock; view 4 leaves all three unknown because it did not inspect the imported LayerZero library line by line. View 2 identifies peer changes/message inspector and enforced options (S7/R42–R43); view 5 does likewise from S7 and R41–R43. View 4's unknown is a coverage limit, not contrary evidence. There is an important scope qualifier: views 2/5 distinguish bridge restrictions or costs from pausing or taxing ordinary local ERC20 transfers.

### Contract 8 — IMD seat NFT, Ethereum

- **Core answers:** views 2, 4, and 5 agree no proxy, owner address `0x4e59b44847b379578588920ca78fbf26c0b4956c`, mint yes, cap yes, no transfer pause, no fee setter, no delay, and verified source; views 1 and 3 are unknown. View 2 S8/R44–R46/R62–R63; view 4 owner/totalSupply reads and IdentityMD source; view 5 S8/R44–R46 support these answers. View 2 and view 5 identify partial verification; view 4 reports both a Blockscout verification result and a Sourcify match. The headline yes agrees, but “verified” is not consistently distinguished from full verification.
- **Owner's controller:** view 2 says upstream owner unknown because the 69-byte owner contract has no verified source and its `owner()` call fails. View 5 gives the same unresolved upstream result (S12/R62–R63). View 4 infers that the address is a keyless CREATE2 deployer that cannot exercise `onlyOwner`; it cites codesize and a code-pattern identification but says it did not disassemble the code in its method limits. That inference is plausible from its cited runtime observation but is not established by the owner getter, and conflicts with the other views' deliberately limited trace. The upstream controller remains unresolved in this comparison; no human owner is established.

## 3. Keys most often unknown

The strongest concentrations are **`delay` and `source_verified`**, each unknown in all five views for contract 6 (RH Intake). Across the eight contracts, each is unknown in 21 of 40 responses: views 1 and 3 contribute 16 unknowns apiece across every key, and restricted RH source access adds three more unknowns for source status and several more for action delay. `block` is unknown in views 1 and 3 for all eight contracts (16 of 40); the other three views report different block snapshots/ranges, so the problem there is snapshot comparability rather than missing data from those three. Mint, cap, pause, and fees are also frequently unknown for contract 6 because only view 4 offers a substantive behavior inference and the RH source was unavailable.

This is an access and evidence-coverage result, not a finding that these contracts lack powers. The rate-limiting/403 and Sourcify-unmatched reports are documented in views 1, 3, and 5; view 4 substituted some RPC/Sourcify checks but retained source-dependent unknowns.

## 4. Overall agreement

On the 96 answer/state cells (12 keys × 8 contracts, excluding the non-categorical `evidence` field), all five gave the same answer in **2/96 (2.1%)**; at least four agreed in **10/96 (10.4%)**. The only unanimous cells are the two explicit unknowns for contract 6: delay and source verification. The ten four-or-more cells consist of those two plus eight contract 6 fields where four views said unknown and view 4 inferred an answer. Thus the agreement percentage should not be read as validation or confidence: much of it counts shared inability to establish facts.

## 5. Wording issues and a more repeatable form

The views themselves identify several sources of variation:

- **What does “mint” apply to?** Views 2 and 4 use `no`/not applicable for Intake and the administrator, while the prompt says “new units.” The RH Intake dispute also shows that same-address contracts on separate chains cannot be presumed identical.
- **What does “pause” cover?** The form groups pausing, blocking, and restricting. Intake can stop sales by setting a price to zero; the OFT token can restrict bridge transfers while ordinary ERC20 transfers remain available; the Claus NFT can stop new oracle requests without freezing NFT transfers.
- **What counts as “fees”?** Collection 4 exposed the distinction between a fee setter on the target and an external oracle's configurable charge. Intake's price/payee controls are service pricing, while the token bridge's enforced options alter quoted messaging costs. Views answered different scopes consistently with those readings.
- **Which “owner” and which depth?** The form combines token owner, proxy admin, admin owner, operational roles, indirect executors, and dependency controllers. Contract 1 has owner and operator paths; contract 4's fee controller is external; contract 8's owner is itself a contract with unresolved upstream control. A single `admin_owner` field cannot hold all that. EIP-7702 delegated EOAs also do not fit a simple contract/wallet binary.
- **What is a cap?** Views 2/5 explain that an outstanding-identity limit with recycled IDs differs from a lifetime issuance cap. The form does not define whether a cap may be reusable, current-capacity-limited, per-wallet, or only a total supply ceiling.
- **What does “delay” mean?** Ownership acceptance, oracle confirmations, epochs, cross-chain delivery, and an enforced timelock are different. Views 2/5 explicitly exclude operational latency from a timelock answer; the original wording does not.
- **What does “source verified” mean?** Views distinguish explorer `is_verified` from full verification, partial verification, Sourcify matches, and simply being unable to read the explorer. A yes/no-only field also conflicts with the instruction to answer unknown when not established.
- **Which time point?** Views 2 and 5 pin different chain snapshots; view 4 reports ranges/latest reads; views 1 and 3 have no block. Mutable state cannot be compared as if simultaneous. `evidence` also mixes source pages, read calls, and access errors, so an opaque string/list is hard to compare.

### Rewritten per-contract form

For each target, first record chain ID, checksummed/lowercase address, UTC read time, and one exact block number/hash for every state read. Keep source retrieval time separate. If a field is unknown, state the failed or missing observation; do not encode “not applicable” as `no`.

1. **Proxy:** Is the target delegated/proxied at the recorded block? `yes/no/unknown`. State detection method and proxy kind. If yes, give implementation, proxy admin/beacon, and each controller address separately; if no, state which proxy patterns were checked.
2. **Control roles:** List every directly observed owner/admin/operator/writer/signer/role address, role name, and exact getter/source evidence. For each address give chain-specific classification: code-free account, deployed contract, EIP-7702 delegated EOA, or unknown. Trace controllers for at most three edges, marking each edge and any unresolved end; do not infer a human/key holder.
3. **Issuance:** Does this target create its own token units/NFTs or equivalent units? `yes/no/unknown/not applicable`. Name the callable path and authorized caller(s). Separately state cap type (lifetime total, outstanding/recyclable IDs, per-account, or none), numeric bound, and current remaining capacity. For service contracts, answer not applicable and separately identify whether they control issuance on another target.
4. **Restrictions:** Can an authorized actor block or restrict (a) ordinary local transfers, (b) minting/new requests, or (c) bridge/cross-chain transfers? Answer each independently with actor and mechanism. Distinguish service availability from transfer restrictions.
5. **Prices and charges:** Can an actor change (a) target transfer tax, (b) mint/sale price or payee, (c) external oracle/bridge quote inputs? List actor, setter/configuration path, and whether it belongs to the target or a dependency. Say no only for the specified category after inspecting its relevant code.
6. **Timelock:** Is a mandatory elapsed-time delay enforced in code before each identified privileged action? `yes/no/unknown`; name the action and minimum delay. Exclude transaction inclusion, quote expiry, confirmation counts, epochs, and ownership acceptance unless code makes them an owner-action delay.
7. **Source status:** Report separately: explorer status (`verified`, `partially verified`, `unverified`, or `unreadable`), full-match/reproducibility status if available, and the explorer page/API response. Do not equate unreadable with unverified.
8. **Evidence and scope:** For every answer give exact page or read call, result, block for state, source read time, and fact/inference/unknown label. List source/dependency limitations and whether the answer covers only the target or indirect dependency powers.

This version makes scope and “not applicable” explicit, separates an external dependency from target-level control, and asks every checker to compare state at a common block where possible.

## 6. Time per contract

Only view 4 reports an estimate: about 35 minutes for all eight contracts, roughly four minutes per contract, with proxies taking longer and the two Intakes faster. That is a rough allocation, not a separately timed per-contract measurement. Views 1, 3, and 5 explicitly say no careful successful single-contract duration was measured. View 2 reports a batched interval and expressly rejects dividing it by eight. Therefore there is **no comparable measured time for one careful contract check**; the only available estimate is view 4's approximate four minutes.

## Evidence attribution index

- [View 1](view-1.md): all targets returned 403; E1–E8 record explorer attempts and times; timing section says no successful check.
- [View 2](view-2.md): fixed blocks and exact-call catalogue R1–R8, supplementary role/dependency reads and source catalogue S1–S17; detailed contract tables cite the relevant IDs.
- [View 3](view-3.md): all targets returned 403; sections 1–8 list exact requests/times and unknown answers.
- [View 4](view-4.md): public RPC storage/getter/code calls and Sourcify/Blockscout observations, described by contract; timing estimate in Method and read points.
- [View 5](view-5.md): comparable JSON plus source/read catalogues S1–S17, R1–R86, A1–A3 and L1; its tables label facts, interpretations, and unresolved points.

Facts in this report are statements about what each view recorded. The agreement counts are calculations over those recorded answers. Judgments about whether differing answers are truly contradictory or reflect scope are explicitly identified as synthesis; unresolved evidence gaps remain open.