perf(identity-registry): cache the registry address in a local instead of re-reading it per verification call

Author: rya-sge

CHANGELOG.md

@@ -73,6 +73,10 @@ Custom changelog tag: `Dependencies`, `Documentation`, `Testing`
   - **Screening of real participants is unchanged.** A mint to a sanctioned recipient is still rejected with code `31`, a burn from a sanctioned holder with code `30`, and the **minter is still screened as the `spender`** on the 4-argument mint path.
   - Side effect: a mint or burn now makes one oracle call instead of two — 2,478 gas versus 3,405 for a two-participant transfer, so roughly 900 gas saved per issuance and redemption.
 
+- **`RuleIdentityRegistry`: the registry address is read from storage once per check instead of up to five times** (`FEEDBACK_12.md` B-3), the same treatment as `RuleSanctionsList` above and safe for the same reason — both functions are `view`, so `isVerified` is reached by `STATICCALL` and cannot write `identityRegistry`. Behaviour unchanged. Measured: **113 gas** saved on a receiver-only transfer (the ERC-3643 default) and on a mint, **219** with `checkSender` enabled, **320** on a `transferFrom` with both flags on.
+  - The path where no registry is configured is **5 gas more expensive** — loading the slot into a typed local before comparing costs a couple of stack operations. Accepted: that is the path where the rule is switched off and does nothing, against 108–320 gas saved wherever it actually screens.
+  - The duplicated null-registry and burn guards between `_detectTransferRestrictionFrom` and `_detectTransferRestriction` were deliberately left in place, as with `RuleSanctionsList`: collapsing them needs a helper that takes the registry as a parameter, which would stop a subclass's override of the direct hook from applying to `transferFrom`.
+
 ### Testing
 
 - New `test/RuleSanctionsList/RuleSanctionsListMintBurnSentinel.t.sol` (8 tests) for the change above. The oracle in it deliberately sanctions `address(0)`; four of the tests fail against the previous implementation (mint blocked with code `30`, burn with `31`, and the write path reverting), while the four asserting unchanged behaviour pass either way — verified by reverting the guards and re-running.

src/rules/validation/abstract/base/RuleIdentityRegistryBase.sol

@@ -195,7 +195,10 @@ abstract contract RuleIdentityRegistryBase is RuleNFTAdapter, RuleIdentityRegist
         override
         returns (uint8)
     {
-        if (address(identityRegistry) == address(0)) {
+        // Read the registry address once. Safe to cache across the calls below: this function is
+        // `view`, so those are STATICCALLs and cannot write `identityRegistry`.
+        IIdentityRegistryVerified registry = identityRegistry;
+        if (address(registry) == address(0)) {
             return uint8(IERC1404Extend.REJECTED_CODE_BASE.TRANSFER_OK);
         }
         // ERC-3643: "The `burn` function bypasses all checks on eligibility."
@@ -204,13 +207,13 @@ abstract contract RuleIdentityRegistryBase is RuleNFTAdapter, RuleIdentityRegist
         }
 
         // OPT-IN, stricter than ERC-3643. Mints carry no sender, so they are exempt.
-        if (checkSender && from != address(0) && !identityRegistry.isVerified(from)) {
+        if (checkSender && from != address(0) && !registry.isVerified(from)) {
             return CODE_ADDRESS_FROM_NOT_VERIFIED;
         }
 
         // MANDATED by ERC-3643: the receiver must be verified. This is the only required check,
         // and it applies identically to `transfer`, `transferFrom` and `mint`.
-        if (!identityRegistry.isVerified(to)) {
+        if (!registry.isVerified(to)) {
             return CODE_ADDRESS_TO_NOT_VERIFIED;
         }
         return uint8(IERC1404Extend.REJECTED_CODE_BASE.TRANSFER_OK);
@@ -231,7 +234,8 @@ abstract contract RuleIdentityRegistryBase is RuleNFTAdapter, RuleIdentityRegist
         override
         returns (uint8)
     {
-        if (address(identityRegistry) == address(0)) {
+        IIdentityRegistryVerified registry = identityRegistry;
+        if (address(registry) == address(0)) {
             return uint8(IERC1404Extend.REJECTED_CODE_BASE.TRANSFER_OK);
         }
         // ERC-3643: burn bypasses all eligibility checks.
@@ -245,7 +249,7 @@ abstract contract RuleIdentityRegistryBase is RuleNFTAdapter, RuleIdentityRegist
         // able to mint to a verified recipient, exactly as the specification requires.
         if (
             checkSpender && spender != address(0) && from != address(0) && to != address(0)
-                && !identityRegistry.isVerified(spender)
+                && !registry.isVerified(spender)
         ) {
             return CODE_ADDRESS_SPENDER_NOT_VERIFIED;
         }

test/RuleSanctionsList/RuleSanctionsListMintBurnSentinel.t.sol

@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: MPL-2.0
+pragma solidity ^0.8.20;
+
+import {Test} from "forge-std/Test.sol";
+import {HelperContract} from "../HelperContract.sol";
+import {SanctionListOracle} from "src/mocks/SanctionListOracle.sol";
+import {RuleSanctionsList, ISanctionsList} from "src/rules/validation/deployment/RuleSanctionsList.sol";
+
+/**
+ * @title RuleSanctionsListMintBurnSentinel
+ * @notice The zero address is the ERC-20 mint/burn sentinel and must never be sent to the oracle
+ *         (`FEEDBACK_12.md` F-1).
+ * @dev The oracle here sanctions `address(0)` itself -- a degenerate input a real oracle has never
+ *      been asked about, and one it is free to answer either way. Before the fix the rule forwarded
+ *      the sentinel to the oracle, so a `true` answer blocked EVERY mint and EVERY burn on every
+ *      token using this rule, trapping holders behind a third party's handling of a non-wallet.
+ *      These assertions fail without the `from != address(0)` / `to != address(0)` guards.
+ */
+contract RuleSanctionsListMintBurnSentinel is Test, HelperContract {
+    SanctionListOracle private oracle;
+    RuleSanctionsList private rule;
+
+    function setUp() public {
+        oracle = new SanctionListOracle();
+        // A real sanctioned wallet, and the sentinel.
+        oracle.addToSanctionsList(ATTACKER);
+        oracle.addToSanctionsList(ZERO_ADDRESS);
+        rule = new RuleSanctionsList(SANCTIONLIST_OPERATOR_ADDRESS, ZERO_ADDRESS, ISanctionsList(address(oracle)));
+    }
+
+    function testOracleReallyDoesSanctionTheSentinel() public view {
+        // Guards the premise of every assertion below.
+        assertTrue(oracle.isSanctioned(ZERO_ADDRESS));
+    }
+
+    function testMintIsNotBlockedWhenTheOracleSanctionsTheZeroAddress() public view {
+        assertEq(rule.detectTransferRestriction(ZERO_ADDRESS, ADDRESS2, 10), TRANSFER_OK);
+        assertTrue(rule.canTransfer(ZERO_ADDRESS, ADDRESS2, 10));
+    }
+
+    function testBurnIsNotBlockedWhenTheOracleSanctionsTheZeroAddress() public view {
+        assertEq(rule.detectTransferRestriction(ADDRESS1, ZERO_ADDRESS, 10), TRANSFER_OK);
+        assertTrue(rule.canTransfer(ADDRESS1, ZERO_ADDRESS, 10));
+    }
+
+    function testMintAndBurnDoNotRevertOnTheWritePath() public view {
+        // `transferred` reverts on a non-zero code, so this is the enforcement-side equivalent.
+        rule.transferred(ZERO_ADDRESS, ADDRESS2, 10);
+        rule.transferred(ADDRESS1, ZERO_ADDRESS, 10);
+    }
+
+    function testMintToASanctionedRecipientIsStillBlocked() public view {
+        // The sentinel guard must not weaken screening of the REAL participant.
+        assertEq(rule.detectTransferRestriction(ZERO_ADDRESS, ATTACKER, 10), CODE_ADDRESS_TO_IS_SANCTIONED);
+    }
+
+    function testBurnFromASanctionedHolderIsStillBlocked() public view {
+        assertEq(rule.detectTransferRestriction(ATTACKER, ZERO_ADDRESS, 10), CODE_ADDRESS_FROM_IS_SANCTIONED);
+    }
+
+    function testOrdinaryTransfersAreUnaffected() public view {
+        assertEq(rule.detectTransferRestriction(ADDRESS1, ADDRESS2, 10), TRANSFER_OK);
+        assertEq(rule.detectTransferRestriction(ATTACKER, ADDRESS2, 10), CODE_ADDRESS_FROM_IS_SANCTIONED);
+        assertEq(rule.detectTransferRestriction(ADDRESS1, ATTACKER, 10), CODE_ADDRESS_TO_IS_SANCTIONED);
+    }
+
+    /**
+     * @notice The spender leg is deliberately NOT guarded; the minter must still be screened.
+     * @dev `CLAUDE.md` records that the deny-lists screen the minter, which arrives as `spender` on
+     *      the 4-arg mint path. Guarding `from`/`to` must not silently disable that.
+     */
+    function testTheMinterIsStillScreenedAsSpender() public view {
+        assertEq(
+            rule.detectTransferRestrictionFrom(ATTACKER, ZERO_ADDRESS, ADDRESS2, 10), CODE_ADDRESS_SPENDER_IS_SANCTIONED
+        );
+    }
+}