From 77090b28a852d00376032baf89b703f06db35bf3 Mon Sep 17 00:00:00 2001 From: Rayyan Alam Date: Tue, 9 Jun 2026 19:35:59 -0400 Subject: [PATCH] docs(IActivationRegistry): warn integrators not to use code presence as activation signal (BOP-322) The precompile writes a bytecode marker to its storage account on first activate and does not clear it on deactivation, so EXTCODESIZE/EXTCODEHASH at the registry address reflect initialisation state only. Add an explicit NatSpec integration note directing consumers to isActivated() instead. Generated with Claude Code Co-Authored-By: Claude --- src/interfaces/IActivationRegistry.sol | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/interfaces/IActivationRegistry.sol b/src/interfaces/IActivationRegistry.sol index 3e918f0..d4f4fc3 100644 --- a/src/interfaces/IActivationRegistry.sol +++ b/src/interfaces/IActivationRegistry.sol @@ -4,6 +4,12 @@ pragma solidity >=0.8.20 <0.9.0; /// @title IActivationRegistry /// @notice Singleton precompile that gates Base-native features behind an activation admin. Each feature /// is identified by an opaque `bytes32` id and is either active or inactive. +/// +/// @dev INTEGRATION NOTE — do not use code presence as a feature gate. The precompile writes a +/// bytecode marker to its own storage account on the first successful `activate` call and does +/// not clear it when features are subsequently deactivated. `EXTCODESIZE` and `EXTCODEHASH` at +/// this address therefore reflect initialisation state, not live activation state. Always use +/// `isActivated(feature)` as the authoritative signal. interface IActivationRegistry { /*////////////////////////////////////////////////////////////// ERRORS