diff --git a/erc/erc-8350.md b/erc/erc-8350.md
index fc22981..3c1ac41 100644
--- a/erc/erc-8350.md
+++ b/erc/erc-8350.md
@@ -160,6 +160,20 @@ accept a transition only if `sequence == currentSequence + 1` and
 `prevStateRoot == currentStateRoot`. It MUST then atomically store the Transition
 ID, next state root, and sequence.
 
+### Immutability of the enforcing logic
+
+The linearity guarantee above is a property of the deployed code, not of the
+recorded data. A registry whose implementation can be replaced can be made to
+accept a transition violating `sequence == currentSequence + 1`, while still
+reproducing every test vector in this document; passing the vectors and providing
+the guarantee are therefore distinct claims.
+
+A conforming registry MUST NOT be deployed behind an upgrade mechanism able to
+replace the logic enforcing sequence linearity, state root chaining, or signature
+validation, and MUST expose no upgrade authority over that logic. Extensions and
+off-chain tooling MAY be upgraded independently, provided they cannot alter the
+acceptance rules above.
+
 ### Signing domain
 
 All registration, authorization-update, and transition signatures MUST use the
@@ -182,6 +196,26 @@ The domain prevents a signature from being replayed on another chain or another
 registry. A `transitionId` remains a chain-independent content identifier; its
 signature does not.
 
+### Referencing a transition
+
+A `spaceId` is derived from the controller and salt only, so it is stable across
+chains. The same Memory Space identifier can therefore be used for histories on
+more than one chain. Two chains MAY hold different histories under the same
+`spaceId`, so `(spaceId, transitionId)` alone does not determine which history is
+meant.
+
+A conforming transition reference MUST identify the registry address and the
+chain on which that registry is deployed, in addition to `spaceId` and
+`transitionId`. The chain context MAY be implicit when the reference is emitted
+on the same chain as the registry.
+
+This is a verification requirement, not only a resolution convenience. The
+signing domain sets `verifyingContract` to the registry address, so the signed
+digest cannot be reconstructed — and the authorizer's signature therefore cannot
+be checked — without knowing which registry accepted the transition. An otherwise
+complete reference that omits the registry or chain context is not independently
+verifiable.
+
 ### Space registration
 
 Registration MUST bind the Space to non-zero `controller` and `authorizer`
@@ -501,10 +535,18 @@ deletion.
 
 ### Upgradeability
 
-An upgradeable registry can change hashing or authorization semantics after
-users sign transitions. Deployments using proxies are advised to make upgrade
-authority explicit, and to freeze or version any change affecting the normative
-v1 behavior.
+An upgradeable registry can change hashing or authorization semantics after users
+sign transitions. Because a replaced implementation can accept a transition that
+violates sequence linearity while still reproducing every published test vector,
+non-upgradeability of the enforcing logic is a precondition of the non-forgeability
+property rather than a deployment preference. It is stated normatively under
+"Immutability of the enforcing logic" in the Specification, and repeated here
+because a requirement stated only in this section is read as informative.
+
+Verifiers assessing a deployment SHOULD confirm that no upgrade authority exists
+over the registry — for example that the EIP-1967 implementation and admin slots
+are empty and that the deployed source exposes no owner, admin, initializer, or
+proxy — rather than inferring immutability from vector conformance alone.
 
 ## Copyright