@bananapus/omnichain-deployers-v6 0.0.19 → 0.0.21

package/README.md

@@ -1,134 +1,46 @@
 # Juicebox Omnichain Deployers
 
-Deploy Juicebox projects with cross-chain suckers and 721 tiers hooks in a single transaction. Every project gets a 721 hook (even with 0 initial tiers), so projects can add NFT tiers later without reconfiguring. Acts as a transparent data hook wrapper that gives suckers tax-free cash outs and on-demand mint permission -- without interfering with any custom data hook the project uses. Supports composing a 721 tiers hook alongside a custom data hook (e.g., a buyback hook) so both run on every payment.
+`@bananapus/omnichain-deployers-v6` launches Juicebox projects with cross-chain suckers and a 721 hook already wired in. It is the package you use when the default project shape should be omnichain from day one.
 
-[Docs](https://docs.juicebox.money) | [Discord](https://discord.gg/juicebox)
+Docs: <https://docs.juicebox.money>
+Architecture: [ARCHITECTURE.md](./ARCHITECTURE.md)
 
-## Conceptual Overview
+## Overview
 
-Launching a cross-chain Juicebox project normally takes several steps: deploy the project, configure rulesets, set up terminals, deploy suckers, and wire up a data hook that exempts suckers from cash out taxes. `JBOmnichainDeployer` collapses all of this into one transaction.
+The deployer wraps multiple launch concerns into one surface:
 
-It works by inserting itself as the data hook on every ruleset it touches, storing hooks in two separate mappings: the 721 tiers hook is stored per-ruleset in `_tiered721HookOf[projectId][rulesetId]` with its own `useDataHookForCashOut` flag, and an optional custom data hook (e.g., buyback hook) is stored per-ruleset in `_extraDataHookOf[projectId][rulesetId]` with `useDataHookForPay` and `useDataHookForCashOut` flags. When the protocol calls data hook functions during payments and cash outs, the deployer:
+- deploy or carry forward a tiered 721 hook
+- install itself as the project's data-hook wrapper
+- compose the 721 hook with an optional extra custom hook
+- grant tax-free and mint-safe behavior to project suckers
+- deploy suckers deterministically across chains
 
-- **Checks if the holder is a sucker** -- if so, returns 0% cash out tax and grants mint permission. This early return means suckers can always bridge tokens without interference, even if the project's hooks would revert.
-- **Composes the 721 hook and custom data hook** for payments -- the 721 hook is called first (via `tiered721HookOf`) to get its specs (including split fund amounts), then the custom hook from `_extraDataHookOf` (if `useDataHookForPay: true`) is called with a reduced amount context (payment minus split amount) so it only considers the available funds. The 721 hook's weight (already split-adjusted by `JB721TiersHookLib.calculateWeight`) is used directly, ensuring the terminal only mints tokens for the amount that actually enters the project treasury. If the 721 hook returns no specs (0 tiers), it is skipped in the merged output.
-- **Composes hooks for cash outs** -- the 721 hook is called first (if `useDataHookForCashOut: true`), updating the cash out parameters (tax rate, count, supply). Then the custom hook is called (if `useDataHookForCashOut: true`) with the already-updated values from the 721 hook. Both hooks' specifications are merged into a single array (721 specs first, then custom hook specs). If the 721 hook has `useDataHookForCashOut: true` and reverts (e.g., for fungible-only cashouts), that revert propagates. Set `useDataHookForCashOut: false` on the 721 config to skip it.
-- **Returns default values** if neither hook has the relevant flag set.
+The wrapper exists so suckers can bridge without being blocked by project-specific cash-out tax logic while the project still keeps its own data hooks.
 
-This wrapping is invisible to the project and its users. The project's hooks (buyback hook, 721 hook, etc.) work exactly as configured, and can be composed together.
+Use this repo when the default project shape is "Juicebox project plus 721 hook plus cross-chain bridge." Do not use it when a project is single-chain or does not need the wrapper semantics around suckers.
 
-### How It Works
+If the question is "how do suckers bridge?" start in `nana-suckers-v6`. If the question is "how does a 721 hook behave?" start in `nana-721-hook-v6`. This repo is where those components are packaged together and wrapped.
 
-```mermaid
-sequenceDiagram
-    participant Caller
-    participant Deployer as JBOmnichainDeployer
-    participant HookDeployer as IJB721TiersHookDeployer
-    participant Controller as JBController
-    participant Registry as JBSuckerRegistry
-    participant Owner
+## Key Contract
 
-    Caller->>Deployer: launchProjectFor(owner, rulesets, suckers, ...)
-    Deployer->>HookDeployer: deployHookFor(projectId, ...) — deploy 721 hook
-    Deployer->>Deployer: _setup721() — store hooks, insert self as data hook
-    Deployer->>Controller: launchProjectFor(owner=deployer, ...)
-    Controller-->>Deployer: projectId + project NFT
-    Deployer->>Deployer: transferOwnershipToProject(projectId) — 721 hook ownership
-    Deployer->>Registry: deploySuckersFor(projectId, salt)
-    Registry-->>Deployer: sucker addresses
-    Deployer->>Owner: transfer project NFT
-```
-
-During operation:
-
-```mermaid
-sequenceDiagram
-    participant Terminal
-    participant Deployer as JBOmnichainDeployer
-    participant Registry as JBSuckerRegistry
-    participant Hook721 as 721 Hook
-    participant HookExtra as Custom Hook
-
-    Terminal->>Deployer: beforeCashOutRecordedWith(context)
-    Deployer->>Registry: isSuckerOf(projectId, holder)?
-    alt Holder is a sucker
-        Deployer-->>Terminal: 0% tax (early return)
-    else Hooks configured
-        opt 721 hook with useDataHookForCashOut=true
-            Deployer->>Hook721: beforeCashOutRecordedWith(context)
-            Hook721-->>Deployer: updated taxRate, count, supply, specs
-        end
-        opt Custom hook with useDataHookForCashOut=true
-            Deployer->>HookExtra: beforeCashOutRecordedWith(updated context)
-            HookExtra-->>Deployer: further updated values + specs
-        end
-        Deployer-->>Terminal: merged specs from both hooks
-    else Neither hook has useDataHookForCashOut=true
-        Deployer-->>Terminal: original values (default)
-    end
-```
-
-### 721 Tiers Hook Integration
-
-Every project deployed through `JBOmnichainDeployer` gets a 721 tiers hook, even with 0 initial tiers. This lets projects add NFT tiers later without needing to reconfigure the data hook. The deployer:
-
-1. Deploys the 721 hook via `HOOK_DEPLOYER`
-2. Transfers hook ownership to the project via `JBOwnable.transferOwnershipToProject(projectId)` (after the project NFT exists)
-3. Stores the 721 hook per-ruleset in `_tiered721HookOf[projectId][rulesetId]` with its `useDataHookForCashOut` flag
-4. Sets itself as the data hook on each ruleset, enforcing `useDataHookForPay = true` and `useDataHookForCashOut = true`
-5. Stores the optional custom hook (e.g., buyback hook) separately in `_extraDataHookOf[projectId][rulesetId]` with its own per-hook flags
-
-For `queueRulesetsOf`, if no new tiers are provided, the 721 hook from the latest ruleset is carried forward instead of deploying a new one.
-
-This means a project can have both a 721 hook (for NFT minting on payments) and a custom data hook (for buyback, custom weight logic, etc.) running simultaneously. During both payments and cash outs, the hooks are called sequentially (721 hook first, then custom hook) and their specifications are merged.
-
-### Simplified Overloads
-
-Each of `launchProjectFor`, `launchRulesetsFor`, and `queueRulesetsOf` has a simplified overload that omits the `deploy721Config` parameter. These use `_default721Config(rulesetConfigurations)`, which creates an empty-tier 721 config with `currency` from the first ruleset's `baseCurrency`, `decimals = 18`, `useDataHookForCashOut = false`, and no salt. At least one ruleset configuration is required. For `queueRulesetsOf`, since the default config has 0 tiers, the existing 721 hook is always carried forward.
-
-### Deterministic Cross-Chain Addresses
-
-Sucker deployment salts are hashed with `_msgSender()` before use:
-
-```
-salt = keccak256(abi.encode(userSalt, _msgSender()))
-```
-
-This means:
-- **Same sender + same salt on each chain = same sucker addresses** (deterministic via CREATE2)
-- Different senders can't collide, even with the same salt
-- `salt = bytes32(0)` skips sucker deployment entirely
+| Contract | Role |
+| --- | --- |
+| `JBOmnichainDeployer` | Launches projects and rulesets, manages per-ruleset hook composition, and deploys suckers with deterministic salts. |
 
-### Supported Chains
+## Mental Model
 
-`JBOmnichainDeployer` supports the same chains as the sucker deployers it wraps. Currently supported:
+This repo owns orchestration plus runtime wrapping:
 
-- **Mainnets**: Ethereum, Optimism, Base, Arbitrum
-- **Testnets**: Ethereum Sepolia, Optimism Sepolia, Base Sepolia, Arbitrum Sepolia
+1. launch a project with a known omnichain-capable shape
+2. remember which hook composition belongs to which ruleset
+3. special-case sucker behavior so bridge flows are not broken by project-specific logic
 
-To deploy a cross-chain project, call `launchProjectFor` on each chain with the same salt. The sucker deployers use CREATE2 so that matching salts from the same sender produce deterministic addresses across chains.
+## Read These Files First
 
-### Ruleset ID Prediction
-
-The deployer stores hook configs keyed by predicted ruleset IDs (`block.timestamp + i`). This works because `JBRulesets` assigns IDs as `latestId >= block.timestamp ? latestId + 1 : block.timestamp`. For new projects, `latestId` starts at 0, so the first ID is always `block.timestamp`.
-
-The `queueRulesetsOf` function guards against prediction failures by reverting if `latestRulesetIdOf(projectId) >= block.timestamp` (i.e., rulesets were already queued in the same block).
-
-## Architecture
-
-| Contract | Description |
-|----------|-------------|
-| `JBOmnichainDeployer` | Deploys projects, rulesets, and suckers. Wraps the project's real data hook to intercept cash outs from suckers (tax-free) and grant suckers mint permission. Implements `IJBRulesetDataHook`, `IERC721Receiver`, `ERC2771Context`, `JBPermissioned`. |
-
-### Supporting Types
-
-| Type | Description |
-|------|-------------|
-| `JBOmnichain721Config` | 721 hook deployment config: `deployTiersHookConfig` (tier configuration), `useDataHookForCashOut` flag, and `salt` for deterministic deployment. Passed to all deploy/launch/queue functions. |
-| `JBDeployerHookConfig` | Per-hook config with `dataHook`, `useDataHookForPay`, and `useDataHookForCashOut` flags. Stored as a single value per `(projectId, rulesetId)` in `_extraDataHookOf` for the custom data hook. |
-| `JBTiered721HookConfig` | Per-ruleset 721 hook config with `hook` (the `IJB721TiersHook`) and `useDataHookForCashOut` flag. Stored per `(projectId, rulesetId)` in `_tiered721HookOf`. |
-| `JBSuckerDeploymentConfig` | Wraps an array of `JBSuckerDeployerConfig` with a `bytes32` salt for deterministic cross-chain addresses. |
-| `IJBOmnichainDeployer` | Interface for all deployer entry points and the `extraDataHookOf` view. |
+1. `src/JBOmnichainDeployer.sol`
+2. `nana-suckers-v6/src/JBSucker.sol`
+3. `nana-721-hook-v6/src/JB721TiersHook.sol`
+4. the extra hook repo, if the deployment composes one
 
 ## Install
 
@@ -136,96 +48,40 @@ The `queueRulesetsOf` function guards against prediction failures by reverting i
 npm install @bananapus/omnichain-deployers-v6
 ```
 
-If using Forge directly:
+## Development
 
 ```bash
-forge install Bananapus/nana-omnichain-deployers-v6
+npm install
+forge build
+forge test
 ```
 
-Add to `remappings.txt`:
-```
-@bananapus/omnichain-deployers-v6/=lib/nana-omnichain-deployers-v6/
-```
+Useful scripts:
 
-## Develop
+- `npm run deploy:mainnets`
+- `npm run deploy:testnets`
 
-| Command | Description |
-|---------|-------------|
-| `forge build` | Compile contracts |
-| `forge test` | Run unit, integration, and attack tests |
-| `forge test -vvv` | Run tests with full stack traces |
-| `npm run deploy:mainnets` | Propose mainnet deployment via Sphinx |
-| `npm run deploy:testnets` | Propose testnet deployment via Sphinx |
+## Deployment Notes
 
-### Settings
-
-```toml
-# foundry.toml
-[profile.default]
-solc = '0.8.26'
-evm_version = 'cancun'
-via_ir = true
-optimizer_runs = 200
-
-[fuzz]
-runs = 4096
-```
+This repo assumes the 721 hook, address registry, buyback hook, suckers, ownable, and core packages are already available. Matching salts from the same sender keep sucker addresses deterministic across chains.
 
 ## Repository Layout
 
-```
+```text
 src/
-  JBOmnichainDeployer.sol                       # Main contract (~817 lines)
+  JBOmnichainDeployer.sol
   interfaces/
-    IJBOmnichainDeployer.sol                    # Public interface
   structs/
-    JBDeployerHookConfig.sol                    # Custom hook config (dataHook + flags)
-    JBOmnichain721Config.sol                    # 721 hook deployment config
-    JBSuckerDeploymentConfig.sol                # Sucker deployment params
-    JBTiered721HookConfig.sol                   # Per-ruleset 721 hook config
 test/
-  JBOmnichainDeployer.t.sol                     # Unit tests
-  JBOmnichainDeployerGuard.t.sol                # Ruleset ID prediction tests
-  OmnichainDeployerAttacks.t.sol                # Adversarial security tests
-  OmnichainDeployerEdgeCases.t.sol              # Edge case tests (weight, cashout, mint)
-  OmnichainDeployerReentrancy.t.sol             # Reentrancy tests
-  TestAuditGaps.sol                             # Audit gap coverage tests
-  Tiered721HookComposition.t.sol                # 721 hook + custom hook composition tests
-  fork/
-    OmnichainForkTestBase.sol                   # Shared fork test base
-    TestOmnichain721QueueAndAdjust.t.sol        # Fork: queue and adjust 721 tiers
-    TestOmnichainCashOutFork.t.sol              # Fork: cash out flows
-    TestOmnichainStressFork.t.sol               # Fork: stress / load tests
-    TestOmnichainWeightFork.t.sol               # Fork: weight decay tests
-    TestSuckerDeploymentFork.t.sol              # Fork: sucker deployment
-  invariants/
-    OmnichainDeployerInvariant.t.sol            # Invariant tests
-    handlers/
-      OmnichainDeployerHandler.sol              # Invariant handler
-  regression/
-    HookOwnershipTransfer.t.sol                 # Hook ownership transfer regression
-    ValidateController.t.sol                    # Controller validation regression
+  unit, attack, invariant, fork, audit, and regression coverage
 script/
-  Deploy.s.sol                                  # Sphinx deployment script
+  Deploy.s.sol
   helpers/
-    DeployersDeploymentLib.sol                  # Deployment address helper
 ```
 
-## Permissions
-
-| Permission | ID | Required For |
-|------------|-----|-------------|
-| `DEPLOY_SUCKERS` | `JBPermissionIds.DEPLOY_SUCKERS` | `deploySuckersFor` |
-| `QUEUE_RULESETS` | `JBPermissionIds.QUEUE_RULESETS` | `launchRulesetsFor`, `queueRulesetsOf` |
-| `SET_TERMINALS` | `JBPermissionIds.SET_TERMINALS` | `launchRulesetsFor` |
-| `MAP_SUCKER_TOKEN` | `JBPermissionIds.MAP_SUCKER_TOKEN` | Granted to `SUCKER_REGISTRY` globally (projectId=0) at construction |
-
-Note: `launchProjectFor` requires no permissions -- anyone can launch a project to any owner.
-
-## Risks
+## Risks And Notes
 
-- **Ruleset ID mismatch**: If `_setup721()` predictions are wrong (e.g., due to same-block queuing from another source), the stored hook configs will be keyed to the wrong rulesets. The `queueRulesetsOf` guard prevents this, but `launchProjectFor` relies on `PROJECTS.count()` being accurate at call time.
-- **Reverting real hook**: If any stored hook reverts on `beforePayRecordedWith`, payments are blocked. If the 721 hook has `useDataHookForCashOut: true`, its revert for fungible cashouts propagates. Suckers are immune to this for cash outs (early return), but not for payments.
-- **Hook forwarding is view-only**: The deployer's data hook functions are `view`, so any real hook that requires state changes in `beforePayRecordedWith` or `beforeCashOutRecordedWith` will fail.
-- **Meta-transaction trust**: ERC2771 `_msgSender()` is used for salt hashing. A compromised trusted forwarder could impersonate senders and create suckers at unexpected addresses.
-- **Ownership transfer timing**: The 721 hook's ownership is transferred to the project after the project NFT is minted. In `launchProjectFor`, the hook is deployed before the project exists, and ownership is transferred after `controller.launchProjectFor` returns. If the controller call reverts, the hook exists but is owned by the deployer (the whole transaction reverts, so this is safe).
+- ruleset ID prediction is part of the implementation strategy and should be treated as a real assumption
+- hook composition order matters because the 721 hook runs before any extra custom hook
+- using the default empty-tier 721 config is convenient, but teams should still decide explicitly whether the hook participates in cash-out behavior
+- deterministic salts help with cross-chain address alignment, but only when the sender and configuration match exactly

package/RISKS.md

@@ -1,11 +1,28 @@
-# RISKS.md -- nana-omnichain-deployers-v6
+# Omnichain Deployers Risk Register
+
+This file focuses on the risks in the deployer layer that launches Juicebox projects across chains while composing 721 hooks, suckers, and optional custom data hooks.
+
+## How to use this file
+
+- Read `Priority risks` first; they capture the highest-blast-radius deployment and cash-out assumptions.
+- Use the detailed sections for access control, integration, and reentrancy analysis.
+- Treat `Invariants to Verify` as required checks for any new omnichain deployment flow.
+
+## Priority risks
+
+| Priority | Risk | Why it matters | Primary controls |
+|----------|------|----------------|------------------|
+| P0 | Registry-trusted sucker bypass | This deployer gives suckers privileged cash-out behavior based on registry answers. A bad registry entry can affect many projects. | Registry allowlists, deployment verification, and explicit registry scrutiny. |
+| P1 | Cross-chain deployment drift | Omnichain assumptions fail if chain-specific wiring, peers, or composed hooks do not match. | Deterministic deploy ordering, parity checks, and post-deploy peer verification. |
+| P1 | Data-hook composition mistakes | The deployer wraps or forwards custom data hooks; a bad composition can alter pay or cash-out semantics unexpectedly. | Integration tests for wrapped hooks and careful review of forwarding logic. |
+
 
 ## 1. Trust Assumptions
 
 - **Trusted forwarder.** ERC-2771 `_msgSender()` is trusted to append the real sender. A compromised forwarder can impersonate any address for `deploySuckersFor`, `launchProjectFor`, `queueRulesetsOf`, and `launchRulesetsFor`.
 - **Sucker registry.** `SUCKER_REGISTRY.isSuckerOf()` is the sole gatekeeper for 0% cashout tax and mint permission. A compromised or malicious registry lets any address bypass cashout taxes and mint tokens freely.
-- **Controller trust.** The deployer passes an arbitrary `IJBController controller` parameter. `_validateController` checks `controller.DIRECTORY().controllerOf(projectId)` (a reflexive lookup through the controller's own directory reference), but during `launchProjectFor` the project does not yet exist -- validation is skipped, relying on the controller returning the correct project ID.
-- **Extra data hooks.** Arbitrary `IJBRulesetDataHook` addresses from ruleset metadata are stored and delegated to with `staticcall`. A malicious hook can return arbitrary weight, cashout tax rate, or hook specifications.
+- **Controller trust.** The deployer passes an arbitrary `IJBController controller` parameter. `_validateController` checks `controller.DIRECTORY().controllerOf(projectId)` (a reflexive lookup through the controller's own directory reference), but during `launchProjectFor` the project does not yet exist, so no pre-launch controller validation is possible. The post-launch safeguard is the explicit project-ID match check on `controller.launchProjectFor(...)`.
+- **Extra data hooks.** Arbitrary `IJBRulesetDataHook` addresses from ruleset metadata are stored and called directly from the deployer's pay/cash-out wrapper paths. A malicious hook can return arbitrary weight, cashout tax rate, or hook specifications, and can also consume all available gas or revert.
 
 ## 2. Economic / Manipulation Risks
 
@@ -22,13 +39,13 @@
 ## 4. DoS Vectors
 
 - **Ruleset ID collision.** `_setup721` stores hook configs at `block.timestamp + i`. If `latestRulesetIdOf >= block.timestamp` (rulesets already queued this block), `queueRulesetsOf` reverts with `RulesetIdsUnpredictable`. An attacker who queues rulesets in the same block as the legitimate owner can front-run and block their queue attempt. Gas impact: `queueRulesetsOf` costs ~200-400k gas per ruleset queued. The collision only occurs when two transactions queue rulesets in the same block for the same project — race condition window is one block (~12 seconds on L1, 2 seconds on L2).
-- **External hook revert.** `beforePayRecordedWith` and `beforeCashOutRecordedWith` call external hooks without try-catch. A reverting hook blocks all payments or cashouts for that project/ruleset. For cash-outs, if the 721 hook reverts, the custom hook is never reached (the revert propagates before it). Gas impact: the `staticcall` to the extra data hook has no gas limit — a gas-griefing hook can consume the entire transaction gas. The 721 hook call is similarly unbounded.
+- **External hook revert.** `beforePayRecordedWith` and `beforeCashOutRecordedWith` call external hooks without try-catch. A reverting hook blocks all payments or cashouts for that project/ruleset. For cash-outs, if the 721 hook reverts, the custom hook is never reached (the revert propagates before it). Gas impact: the direct call into the extra data hook has no gas limit, so a gas-griefing hook can consume the entire transaction gas. The 721 hook call is similarly unbounded.
 - **721 hook deployment revert.** `HOOK_DEPLOYER.deployHookFor` is called without try-catch. A failing deployment blocks the entire project launch.
 
 ## 5. Reentrancy Surface
 
 - **`launchProjectFor` external call chain.** The function makes external calls to: (1) `_deploy721Hook()` via `HOOK_DEPLOYER.deployHookFor()` (deploys 721 hook clone), (2) `controller.launchProjectFor()` (creates project, deploys rulesets), (3) `JBOwnable(hook).transferOwnershipToProject()` (transfers hook ownership to the new project), (4) `SUCKER_REGISTRY.deploySuckersFor()` (deploys suckers if configured), (5) `PROJECTS.transferFrom()` (transfers the project NFT to the owner). None of these calls are try-catch wrapped — a revert in any of them fails the entire launch. Reentrancy from the controller callback during project creation could call back into `launchProjectFor`, but the new project would get a different ID (monotonically incrementing), so state corruption is not possible.
-- **`beforePayRecordedWith` delegates to external hooks.** Calls `IJBRulesetDataHook(tiered721Hook).beforePayRecordedWith(context)` (not try-caught) and optionally delegates to the extra data hook via `staticcall`. The 721 hook call can execute arbitrary code. At callback time, no deployer state has been modified (the deployer is stateless during payments — it only routes). Reentrancy through the pay path processes as an independent payment.
+- **`beforePayRecordedWith` delegates to external hooks.** Calls `IJBRulesetDataHook(tiered721Hook).beforePayRecordedWith(context)` (not try-caught) and optionally calls the extra data hook directly. The 721 hook and extra hook can execute arbitrary code. At callback time, no deployer state has been modified (the deployer is stateless during payments — it only routes). Reentrancy through the pay path processes as an independent payment.
 - **`beforeCashOutRecordedWith` delegates to external hooks.** Same pattern as pay: calls the 721 hook (not try-caught), then optionally the extra data hook. Sucker check via `SUCKER_REGISTRY.isSuckerOf` is a view call. No deployer state is modified during cashouts.
 - **No `ReentrancyGuard`.** Safe because the deployer is effectively stateless during pay/cashout operations — it reads `_tiered721HookOf` and `_extraDataHookOf` mappings but never writes them outside of deployment functions.
 
@@ -53,7 +70,7 @@
 
 ### 8.1 Controller validation skipped during `launchProjectFor` (by design)
 
-`_validateController` checks `controller.DIRECTORY().controllerOf(projectId)` to verify the provided controller matches the project's registered controller. During `launchProjectFor`, the project does not yet exist, so no directory entry exists. Validation is skipped, relying on `controller.launchProjectFor()` to return the correct project ID. This is accepted because: (1) the project is created atomically within the same transaction, (2) the caller provides the controller address, so they choose their own trust boundary, and (3) validating against a non-existent project would always fail, making the check useless.
+`_validateController` checks `controller.DIRECTORY().controllerOf(projectId)` to verify the provided controller matches the project's registered controller. During `launchProjectFor`, the project does not yet exist, so no directory entry exists and no pre-launch validation is possible. The accepted safeguard is the explicit `ProjectIdMismatch` check immediately after `controller.launchProjectFor()` returns. This is accepted because: (1) the project is created atomically within the same transaction, (2) the caller provides the controller address, so they choose their own trust boundary, and (3) validating against a non-existent project would always fail, making the check useless.
 
 ### 8.2 Suckers receive 0% cashout tax (shared with revnet-core)