ILatticeFactory

The deployer (msg.sender) is folded into the CREATE2 salt, so a given counterfactual address can only ever be realized by the sender it was derived from. Two entry points share one pipeline:

• deployStrict reverts LatticeFactory__AlreadyDeployed when the address is occupied and refuses latest entries (version 0). It is the entry point for user interfaces and any caller that must know its recipe was applied.
• deploy is idempotent: re-running it for an already-deployed (sender, salt) returns the existing diamond instead of reverting, and ignores the call's entries/cuts/init entirely. The address commits to (sender, salt) ONLY, never to the recipe, so a distinct recipe needs a distinct salt; DiamondDeployed carries a hash of the applied recipe so indexers can tell recipes apart. Because the salt is bound to msg.sender, every user behind one shared forwarder (Multicall3, a relayer) shares one salt namespace: call the factory directly from the deploying account, or use deployStrict so a second user's call reverts instead of returning the first user's diamond. All registry drift/lookup failures (ILatticeRegistry reverts) bubble unchanged — the factory adds no drift handling of its own.

Recipe entries resolve through ILatticeRegistry.getCut, which live-re-verifies the code and selector pins and returns an Add cut; a version of 0 first resolves the curator's latest(nameHash) pointer, and each entry's exclude selectors are then dropped from its cut. Custom cuts are appended AFTER the registry cuts, order preserved — a deliberate custom Replace may therefore re-point a selector a registry cut just added. Argument validation (LatticeFactory__EmptyRecipe, LatticeFactory__InitCalldataWithoutInit, LatticeFactory__ExportSelectorForbidden) runs on every call, including idempotent re-calls; registry resolution, exclusion, LOUPE-COVERAGE validation (LatticeFactory__MissingLoupeCoverage — every fresh deploy must route the four EIP-2535 loupe selectors; the registered lattice.DiamondLoupeFacet entry is the one-line way) and initialization run only when the diamond is actually deployed. INIT AUTHORITY: Lattice.initialize is called by THIS FACTORY, so inside init msg.sender is the factory, not the deployer. An init that grants msg.sender a role or ownership grants it to the factory, which has no way to use it: pass the admin explicitly in initCalldata (every shipped Init does).

Every successful call deploys a fresh diamond from exactly this recipe and emits DiamondDeployed, so a double-submitted or replayed transaction fails loudly instead of "succeeding" with another recipe. Same validation, resolution, exclusion and init-authority rules as deploy.

Lets an off-chain client check which proxy build a factory deploys before it predicts addresses: address = keccak256(0xff ++ factory ++ keccak256(abi.encode(deployer, salt)) ++ hash)[12:].

recipeHash is keccak256(abi.encode(cuts, init, initCalldata)) over the MATERIALIZED FacetCut[] cuts handed to Lattice.initialize: the registry-resolved cuts in entry order (with each entry's exclude applied), then the custom cuts. It records what was applied, including the version a latest entry resolved to; it is not part of the address. An init that self-destructs the diamond leaves the address empty when the transaction ends (EIP-6780), so the same (sender, salt) can deploy again and emit a second event for the same address: indexers treat the LATEST event for an address as authoritative.

An un-introspectable diamond is unusable by EIP-2535 tooling (explorers, upgrade dashboards, the loupe-driven test harnesses), so the factory requires a routing ENTRY for each loupe selector at assembly time — paired with LatticeFactory__LoupeSelectorNotReplaceable, which forbids undoing that routing within the same deploy. The check is COVERAGE-based, never facet-identity-based: any facet may provide the selectors (the stock DiamondLoupeFacet, a registry-resolved release of it, or a combined facet of the deployer's own). It validates the selector SURFACE, not the implementation behind it: registry cuts pin codehash + self-reported export blob, custom cuts are unverified — a facet claiming selectors it does not implement is the recipe author's responsibility (see IFacet's security note). The CUT facet remains optional — immutable-by-design diamonds are legal; blind ones are not. Reported selector = the FIRST missing one in the order listed above. Like registry resolution, this check is skipped on idempotent re-calls to an occupied (sender, salt) (the address never commits to the recipe; see deploy).

Fresh-deploy recipes may only ADD loupe routing; re-pointing or removing it is a post-deploy upgrade decision made through the diamond's own cut facet, never smuggled into assembly.