# CreatorOVault + CreatorOVaultWrapper + CreatorShareOFT: accounting-system review

Date: 2026-09-29. Scope: source snapshot only. Nothing was deployed, no transactions were sent, and no production source was changed.

## 0. Answer in brief

- **Local accounting holds (verified by tests).** In the wrapper, `totalLocked == totalMinted*1000 + totalUserDustShares`. With the modelled bridge, hub supply plus remote supply equals `totalMinted`. Vault shares are conserved. The wrapper never keeps creator coin. Small, cooled synchronous exits stayed live. These held across 16,384 stateful calls by 4 users plus a seeder. The calls covered deposit/withdraw, direct wrap/unwrap, transfers, bridge out/in, async request/claim, recognised profit and a modelled idle loss.
- **No unprivileged theft of principal was found.** Coverage has limits; see §6.
- **Confirmed weaknesses (executable, real contracts):**
  - **F-1 (Low, needs a privileged role).** The H-06 mint-backing guard in ShareOFT counts only hub-local supply. Once holders bridge out, an additional minter can mint unbacked ShareOFT equal to the bridged amount. That supply drains other users' backing, and the last holder to exit is left short.
  - **F-2 (Low, griefing, unprivileged).** Anyone can deposit into the vault with `receiver = wrapper` for at least 1% of the wrapper's shares. That stamps the pooled wrapper's cooldown and blocks every user's wrapper exit for `withdrawDelayBlocks`.
  - **F-3 (Medium if misconfigured, depends on deployment).** If the wrapper is not registered with `setTrustedAdapter`, any user's deposit (even 1 token) blocks all other users' wrapper exits in that block.
- **Independent review was NOT achieved.** See §7. Every finding below comes from a single seat (this agent) and has not been independently confirmed.

## 1. Provenance and integrity (facts)

| Item | Value |
|---|---|
| Package source | `https://raw.githubusercontent.com/4626fun/4626/1596618d1793ff86cd73f81e6540826358899ae8/` (the task pin). IMD_CREATOR_JOB.json names `1d539958d0029596398f370d70d90abfa5f08c68`. I downloaded the archive, bootstrap and foundry.toml from both commits and they are **byte-identical**. |
| `IMD_CREATOR_VAULTS_ARCHIVE.b64` sha256 | `95af4e17342ec15324b7739db26255ce5dbcb4715e21d73c525317b4127e0ede` (569,205 B) |
| Decoded ZIP sha256 | `5fe22f0051ea176b88f0d36147efd60890e39b211ed9aab83783cdf476d8fa2e`, which **matches** the required hash |
| `IMD_CREATOR_BOOTSTRAP.sh` sha256 | `be8945f06b0a70c8e8bc0a2daa10d04bfbbcc2e578932d97e77aa88288c267e6`. I inspected it before running: hash check, zip extract, `npm ci --ignore-scripts`, forge-std checkout. |
| root `foundry.toml` sha256 | `f6f9aae0a734d0f77d00f54e04fa4050c39d06c0263e14eb82412220af393f2c` |
| `IMD_CREATOR_VAULTS_REVIEW.md` sha256 | `f57e629c81610c24292437fd7a266bfc8dd9b8a556951adac7c2f8244921d03a` |
| Upstream (per manifest, not independently fetched) | `wenakita/4626@2a9e1334d5b9a13a555c6672e0ec0e735da24bf4` |
| Manifest | `python3 verify_manifest.py` returned exit 0, "Verified 109 upstream files; no mismatches". I ran it after bootstrap, again after all testing, and again on the copy committed to the repo. |
| Toolchain | forge 1.7.1 (`4072e487…`, from pinned npm `@foundry-rs/forge-linux-amd64`), solc 0.8.30, via-IR, cancun, forge-std `7117c90c…`. Linux x86-64, Node v24.21.0. |

Primary source sha256 (identical before and after testing):

```
ac06c7dce93076a64dc54eb8bc7c6cf981c377d9715f806f60461506d1a41edf  contracts/creator/vault/CreatorOVault.sol
b892208d1ae3e069d558b70d1f194fa849669f43dff67a11c49b663f81ac3938  contracts/creator/vault/CreatorOVaultWrapper.sol
bbd30551a5963638b89661ce47a304dbd0552bc1f2fdc2180f91b732586b9f65  contracts/creator/vault/CreatorShareOFT.sol
14dda6885654d1bcd93e3180d2473cf0efa8792beeeb14cda33ec271e068f220  contracts/creator/vault/modules/CreatorOVaultCoreModule.sol
e6263d4d1457246afa9af852c82be8beb058ef10825e99109a31d666c500b4f1  contracts/shared/vault/modules/OVaultAdminModule.sol
2b5f99b0c016be34555e99aafebee336457f4ffc02155d67e89042c9ae22d9e9  contracts/shared/vault/modules/OVaultStrategiesModule.sol
2c5f9cefa2dec535105b47d989d7ed1145651dd9fea7ddb8d416ba80b8b38d99  contracts/shared/lottery/venue/ShareOFTSpokeModule.sol
```

I did not review the older root `contracts/` tree of the public repo. Only the extracted `imd-creator-vaults/` was used.

## 2. Commands and exit codes (facts)

All commands ran from `imd-creator-vaults/`, with `F=node_modules/@foundry-rs/forge-linux-amd64/bin/forge`.

| # | Command | Exit | Result |
|---|---|---|---|
| 1 | `bash IMD_CREATOR_BOOTSTRAP.sh` (repo root) | 0 | 109 files verified |
| 2 | `$F test --summary` (**baseline**, unmodified, rebalance suites included) | 0 | 538 `[PASS]`, 0 fail, 0 skip. Cold via-IR compile plus run took 10m38s. This matches the stated baseline of 538 executions. |
| 3 | `$F test --match-path 'test/imd/*' -vv` (config defaults: fuzz runs 64, seed `0x46264626`, invariant runs 32 / depth 32) | 0 | 14/14 regression, 8/8 invariants (1,024 calls each) |
| 4 | `FOUNDRY_INVARIANT_RUNS=256 FOUNDRY_INVARIANT_DEPTH=64 FOUNDRY_FUZZ_RUNS=1024 $F test --match-path 'test/imd/*' -vv` | 0 | 14/14 (fuzz 1,024 runs); 8/8 invariants (256 runs × 64 depth = 16,384 calls, 0 reverts) |
| 5 | `$F test --summary` (baseline **plus** new tests) | 0 | 560 `[PASS]` (538 + 22 new), 0 `[FAIL]` |
| 6 | `python3 verify_manifest.py` (after all testing) | 0 | no mismatches |

Earlier development runs failed and I repaired the tests; none of these failures came from production code:
- The real ShareOFT needs holder allowance for wrapper burns.
- `block.number` is cached under via-IR across `vm.roll`, so I switched to an explicit block cursor.
- Vault-share approval was missing for `wrap()`.
- A 1-wei `withdraw` reverts with `ZeroAmount` (see O-4).

I did not weaken any assertion to make it pass. The one bound change is withdraw ≥ 1e9 ShareOFT-wei. It is documented in the handler, and those tiny amounts are still exercised through `unwrap`.

## 3. Findings

`test_VULN_*` tests **pass when the weakness is present** because they assert the vulnerable behaviour. File: `imd-creator-vaults/test/imd/ImdCrossContract.t.sol`.

### F-1: ShareOFT H-06 mint-backing guard ignores remote supply (Low; needs a privileged role)
- **Code:** `CreatorShareOFT.sol:511-532`. `mint` → `_assertMintBacking` requires `totalSupply()*1000 <= vault.balanceOf(wrapper)`. `totalSupply()` is **hub-local**. The OFT `send` path burns on the hub (`_debit`), but the wrapper's backing (`totalLocked`) and `totalMinted` stay the same.
- **Prerequisites:** the owner grants `setMinter(x, true)` to some address other than the wrapper, or an existing minter is compromised, and holders have bridged ShareOFT off the hub. Unprivileged users cannot trigger this.
- **Reproduction:** `test_VULN_F1_localMintBackingGuardIgnoresRemoteSupply`.
  1. Alice deposits 10,000 coin and bridges her 10,000e18 ShareOFT out.
  2. The owner grants a rogue minter, which mints 10,000e18 on the hub. **Expected:** revert `UnbackedShareMint`. **Actual:** succeeds.
  3. The rogue calls `wrapper.withdraw` and receives about 10,000 coin.
  4. Alice bridges back and also exits, using other users' backing.
  5. The seeder, the last holder, can no longer exit in full. `requestAsyncExit(seederBal)` reverts, and `totalMinted == seederBal - 10,000e18`.
- **Contrast:** `test_OK_F1_guardWorksWhenAllSupplyIsLocal` shows the same mint is rejected when there is no remote supply. The guard works only in the single-chain case.
- **Severity rationale:** the impact is full loss of the minted amount, pushed onto the last holders to exit. Likelihood needs an owner misconfiguration or key compromise, and the NatSpec at `CreatorShareOFT.sol:506-510` presents H-06 as the guard for exactly that case. So the defence is weaker than documented: Low.
- **Proposed fix (not applied):**
  - Bind the guard to global accounting: require `IWrapper(wrapper).totalMinted()` to have increased by `_amount` during the call, or allow only `wrapper` to mint on the hub.
  - Or track `netBridgedOut` in `_debit`/`_credit` overrides and check `(totalSupply()+netBridgedOut)*1000 <= held`.

### F-2: an unprivileged third party can freeze all wrapper exits by stamping the pooled wrapper's cooldown (Low; griefing)
- **Code:**
  - `CreatorOVaultCoreModule.sol:435-439` and `515-524`: third-party inflows stamp `lastDepositBlock[receiver]` when `shares*100 >= receiverSharesBefore`. Trusted adapters are exempt only for **self**-deposits.
  - `CreatorOVaultCoreModule.sol:551-552`: `WithdrawTooSoon` in redeem.
  - `CreatorOVault.sol:1914-1920`: `TransferTooSoon` on share transfers out of the wrapper.
- **Reproduction:** `test_VULN_F2_thirdPartyInflowStampsPooledWrapperCooldown`.
  1. Carol calls `vault.deposit(≈1% of wrapper value + 1e18, wrapper)`.
  2. In the same block, a cooled user's `wrapper.withdraw` and `wrapper.unwrap` both revert. **Expected:** cooled users can exit. **Actual:** everyone is blocked.
  3. Exits succeed again one block later.
- **Contrast:** `test_OK_F2_smallInflowDoesNotStamp`. A deposit below 1% does not stamp.
- **Impact and severity:** this is a liveness denial for all wrapper users for `withdrawDelayBlocks` (default 1, admin max 100 per `OVaultAdminModule.sol:779`). It can be repeated. The griefer donates ≥1% of the wrapper's value each time; that value becomes wrapper surplus that only the owner can recover through `emergencyWithdraw`. The cost is high and no funds are lost, so: Low.
- **Inference, not tested:** the same stamp probably also blocks fee-bearing `wrap` (the fee transfer out of the wrapper) and `requestAsyncExit`.
- **Proposed fix:** in `_shouldStampInflowCooldown`, return `false` when `isTrustedAdapter[receiver]`. Adapters enforce per-user cooldowns themselves, which is the stated rationale at lines 504-514.

### F-3: an unregistered wrapper lets any depositor block everyone's exits (Medium if misconfigured; depends on deployment)
- **Code:** same stamp logic. If `isTrustedAdapter[wrapper]` is false, every `wrapper.deposit` self-stamps the wrapper.
- **Reproduction:** `test_VULN_F3_untrustedWrapperDepositBlocksAllExits`. Bob deposits 1 coin and Alice's cooled `withdraw` reverts in the same block.
- **Rationale:** this denial of service is cheap and repeatable every block, but it exists only when `setTrustedAdapter(wrapper,true)` was skipped. The wrapper's `supportsShareOFTAsyncExit()` already reads that flag. I have no deployment inventory, so I cannot say whether production is affected.
- **Proposed fix:** add a deploy-time or `setShareOFT` check that the wrapper is a trusted adapter, or apply the F-2 fix together with an explicit registration check.

### Observations (Informational, tested)
- **O-1: dust is keyed to the wrapping address.** `test_OK_O1_dustStrandedButRecoverable`. After moving all ShareOFT away, a user cannot unwrap to claim dust (`unwrap(0)` → `ZeroAmount`). The dust is not lost: re-depositing folds it in, and another holder's unwrap does not receive it.
- **O-2: same-block "hot" dust transfer grief is bounded.** `test_OK_O2_hotDustTransferIsBoundedGrief`. A victim's full exit waits one block, but `balance - hot` exits immediately. This refutes a stronger denial-of-service claim.
- **O-3 (model only): wrapper cooldown is not carried through OFT burn/mint.** `test_MODEL_O3_cooldownNotCarriedAcrossBridge`. In the model, a same-block round trip to a fresh address clears it. Real LayerZero delivery takes multiple blocks, so with `wrapperWithdrawDelayBlocks = 1` I judge it not exploitable (inference).
- **O-4: sub-wei asset exits revert.** `wrapper.withdraw` of about 1 ShareOFT-wei reverts with vault `ZeroAmount` (found by the invariant campaign). `unwrap` still works. This is expected.
- **N-1: integration and test gap.** The real ShareOFT `burn` requires the holder's ERC-20 allowance to the wrapper (`CreatorShareOFT.sol:538-553`, H-3). Every wrapper exit path (`withdraw`, `unwrap`, `requestAsyncExit`) therefore needs a prior `share.approve(wrapper, …)`. The existing wrapper suites use mock ShareOFTs that skip this, so they do not cover the real burn authorization. Front-ends must request this approval.
- **TRUST: transport trust assumption, not an application bug.** `test_TRUST_authenticatedPeerCreditHasNoHubBackingCheck` shows an authenticated peer message mints on the hub with no backing check. Hub backing therefore depends entirely on peer and DVN configuration. `test_OK_lzReceive_rejectsUnauthenticatedOrigins` confirms that a wrong peer, an unknown EID and a non-endpoint caller all revert.

### Code-reading notes (not tested; inferences)
- `CreatorShareOFT._sendFeesToGauge` reverts with `HubGaugeControllerUnset` when `gaugeController == 0` on the hub. While fees are enabled and a `SwapOnly` venue is configured, every fee-bearing "buy" transfer would revert. This is a configuration liveness risk.
- `ShareOFTSpokeModule.handleLz` rejects winner-callback replay by GUID (`usedReportIds`). Remote-lottery forwards that fail are stored for retry by GUID. I did not test the retry path.

## 4. Refuted or negative results (facts, with evidence)

- **Wrapper backing equation (I1):** holds by algebra and under invariants. On wrap, Δrequired = `afterFee`. On unwrap, Δrequired = `-beforeFee`. Fees in both directions go to `feeRecipient` in vault shares (`test_OK_feesConserveShares`).
- **Global supply conservation (I3):** hub supply plus the modelled remote ledger equals `totalMinted` across 16,384 calls. A holder on another chain can bridge back and redeem 1:1 (`test_OK_globalBacking_bridgeRoundTripToDifferentUserThenExit`).
- **Dust:** held below 1 unit per user and summed correctly (I4). A fuzz test with 1,024 runs and non-trivial PPS showed every vault share accounted for through wrap and unwrap.
- **Async exits:** entries are isolated per `(adapter, owner)`. The receiver cannot claim or cancel. Claiming before unlock reverts. Double claims revert. Cancel returns raw vault shares, not ShareOFT (`test_OK_asyncExit_claimAndCancelConserveBacking`). Large synchronous withdrawals are forced into the queue.
- **Authorization:** non-vault minters need allowance to burn ShareOFT. `propagateCooldownOnTransfer` can only be called by the ShareOFT. The cooldown hook runs in try/catch, so it cannot freeze transfers (`CreatorShareOFT.sol:651-667`, code reading).

## 5. Tests added (`imd-creator-vaults/test/imd/`; also in `artifacts/imd-tests.zip`)

| File | sha256 | Content |
|---|---|---|
| `ImdSystemBase.sol` | `877bf875…3b41` | Real vault, all three modules, real wrapper and real ShareOFT. Stub LZ endpoint and remote-supply ledger (MODEL). |
| `ImdCrossContract.t.sol` | `d9a7b449…f505` | 14 tests: 3 VULN, 1 TRUST, 1 MODEL, 9 OK/negative controls |
| `ImdSystemInvariant.t.sol` | `d0f8b003…ed63` | Handler with 12 actions and 4 actors; invariants I1–I8 |

`artifacts/imd-tests.zip` sha256 is `5e8777a3fbb2f51c2e7aea0552ac49220d95ab864d94054dde8059a49d8cea6d`. It contains a README and SHA256SUMS.

**Real versus mock (evidence classes):**
- **Real contracts:** CreatorOVault plus CreatorOVaultCoreModule, OVaultStrategiesModule and OVaultAdminModule through the real delegatecall; CreatorOVaultWrapper; CreatorShareOFT, including its OFT `_debit`/`_credit`, `lzReceive` peer checks and the real spoke module.
- **Mock or model:**
  - The LZ endpoint is etched code with `send` mocked.
  - Remote chains are a ledger.
  - The registry is minimal.
  - The coin is a plain ERC20.
  - "Loss" means removing idle coin plus `syncBalances()`. No strategy is attached in the new tests.
  - **There is no fork, no real LayerZero delivery and no real strategy evidence.**

**Handler coverage (deep campaign, forge table; all handler calls return, and inner reverts are caught and classified):** bridgeIn 1371, bridgeOut 1336, claimAsync 1382, deposit 1363, directDepositThenWrap 1399, loss 1322, profit 1393, requestAsync 1318, roll 1344, transferShare 1387, unwrap 1403, withdraw 1366. Reverts: 0.

Ghost success/skip counts for the final run (depth 64):

| Action | Success | Skip |
|---|---|---|
| deposit | 5 | 0 |
| withdraw | 3 | 1 |
| wrap | 9 | 0 |
| unwrap | 5 | 0 |
| transfer | 6 | 1 |
| bridgeOut | 6 | 1 |
| bridgeIn | 4 | 2 |
| requestAsync | 5 | 0 |
| claimAsync | 2 | 4 |
| profit | 2 | 0 |
| loss | 3 | 0 |
| roll | 5 | 0 |

Skips are no-balance or no-queue preconditions. Unexpected exit reverts are asserted to be 0 (I7).

**Limitation:** forge reports ghost counts only for the last run, so per-campaign success totals are not reported. An earlier attempt at a non-vacuity assertion in `afterInvariant` broke forge's shrinking replay, so I removed it.

## 6. Coverage gaps and unanswered questions

- **Strategies:** the new tests attach no strategies. Rebalance, valuation-revert, maxLoss and hostile-strategy behaviour rests on the **retained baseline suites** (all passing), not on new evidence.
- **Impairment and recovery:** ERC-1155 claims, epoch snapshots, `OVaultRecoveryEscrow` and the wrapper's `claimImpairmentRecovery` were **not newly tested**; only the baseline suites cover them. Open question: shares queued in the vault's own balance during an async exit (`_sharesUpdate(adapter, address(this))`) could be mis-attributed in impairment snapshots. I did not verify this.
- **OVaultHubComposer, the lottery queue and fee flush/sweep paths:** not tested.
- **Delegatecall storage layout and reentrancy across facade, modules and hooks:** not independently diffed or fuzzed. I relied on the baseline `ModuleIdentity` and `MigrateStrategyReentrancy` tests.
- **Management and performance fees, profit unlocking, report timing:** not newly tested.
- **Real LayerZero behaviour:** DVN configuration, ordered delivery, `lzReceive` retry and clear, in-flight supply and enforced options are not modelled. Replay protection is assumed to come from the endpoint nonce.
- **Deployment facts:** no deployment inventory or bytecode equivalence was available. F-3 and the gauge-unset note depend on deployment.

## 7. Independent review record

- **Test writer and analyst:** Claude (Opus 5.5) acting as a single IMD agent seat in this session.
- **Independent reviewer: NOT AVAILABLE and NOT ACHIEVED.** This session had no separate reviewer seat or subagent facility, and no second human or model reviewed the code, the tests or the findings. Self-review does not satisfy the requirement. Treat F-1 to F-3 as **single-seat, unconfirmed** until a different reviewer reproduces them with the commands in §2.

## 8. Remediation priorities

1. **F-2 and F-3:** exempt trusted adapters as inflow receivers from cooldown stamping, and assert wrapper registration at deploy time. This is a small change with a large liveness benefit.
2. **F-1:** make the ShareOFT mint guard use global or wrapper accounting, or restrict hub minting to the wrapper only.
3. **N-1:** add wrapper tests against the real ShareOFT, including allowance-based burns, and document the approval UX.
4. Close the §6 gaps, especially impairment snapshots versus queued shares, and a real-endpoint or fork test of hub/spoke supply.