rename: OpStackManager -> OPContractsManager

ecosystem/op-deployer.md

@@ -62,7 +62,7 @@ directly. Instead, they'll define a _deployment intent_ which will describe the
 deploy. `op-deployer` will then diff the intent against the current state of the deployment, and run the pipeline to
 ensure that the real deployment matches the intent.
 
-An example deployment intent is below. Deployment intents are encoded as TOML to match what the OP Stack Manager
+An example deployment intent is below. Deployment intents are encoded as TOML to match what the OP Contracts Manager
 expects:
 
 ```toml
@@ -101,8 +101,8 @@ baseFeeVaultRecipient = "0xbc4a9110dad00b4d9fb61743598848ddda6eeb03"
 l1FeeVaultRecipient = "0x6b0c2542fa2cadced5c7f64ef6fb9ebbce7630ff"
 sequencerFeeVaultRecipient = "0xb4e5b724bbc54c95d292613d956871281120ead6"
 
-# Address of OPSM so that other addresses can be retrieved from on-chain data
-opStackManagerAddress = "0x79c6c6b1844e3db7c30107f189cfb095bd2c4b5d"
+# Address of OPCM so that other addresses can be retrieved from on-chain data
+opContractsManagerAddress = "0x79c6c6b1844e3db7c30107f189cfb095bd2c4b5d"
 
 # Genesis data
 genesis = "base64://abcd..."
@@ -142,7 +142,7 @@ To fix this, we will:
 - Remove booleans that are used to enable/disable features. This data belongs inside of the deployment intent, not
   the config - the config describes the chain, not the deployment process.
 
-Some of this is already started by the OP Stack Manager work. The `op-deployer` project will complete it.
+Some of this is already started by the OP Contracts Manager work. The `op-deployer` project will complete it.
 
 # Alternatives Considered
 

protocol/forge-scripts-deploy-in-go.md

@@ -41,7 +41,7 @@ in a way that is configurable but not error-prone.
 # Proposed Solution
 
 In [deployment-chains design doc 52](https://github.com/ethereum-optimism/design-docs/pull/52) and
-[OPStackManager design doc 60](https://github.com/ethereum-optimism/design-docs/pull/60) the importance
+[OPContractsManager design doc 60](https://github.com/ethereum-optimism/design-docs/pull/60) the importance
 of Modular configs and incremental deploy steps is outlined.
 
 To utilize those modular configs and deploy steps, we need a way to either 

protocol/op-stack-manager-arch.md → protocol/op-contracts-manager-arch.md

@@ -1,22 +1,22 @@
 # Purpose
 
-OP Stack Manager is a contract that will deploy the L1 contracts for standard OP Stack chains in a single transaction.
+OP Contracts Manager is a contract that will deploy the L1 contracts for standard OP Stack chains in a single transaction.
 However, we also have use cases for deploying non-standard chains, such as deploying devnet and testnet contracts while developing interop.
 This document will outline an architecture that:
 
-- Enables the OP Stack Manager to deploy these non-standard chains as an initial milestone.
+- Enables the OP Contracts Manager to deploy these non-standard chains as an initial milestone.
 - Gets us most of the way towards supporting standard chains deployments for the subsequent milestone.
 
 # Summary
 
-The original OP Stack Manager (OPSM) milestones were:
+The original OP Contracts Manager (OPCM) milestones were:
 
 - Milestone 1: Eliminating key handover complexity.
 - Milestone 2: Simplifying Superchain upgrades.
 - Milestone 3: Supporting interop upgrades.
 
-This design doc proposes the architecture for a Milestone 0.5 of "OPSM is used for all interop devnet & testnet L1 deployments".
-Adding this milestone will allow the interop team to build testing infrastructure that wraps OPSM, unifying our development, testnet, and production testing and deployment processes.
+This design doc proposes the architecture for a Milestone 0.5 of "OPCM is used for all interop devnet & testnet L1 deployments".
+Adding this milestone will allow the interop team to build testing infrastructure that wraps OPCM, unifying our development, testnet, and production testing and deployment processes.
 
 # Problem Statement + Context
 
@@ -34,10 +34,10 @@ This design doc focuses on the L1 contract configuration and deployment part of
 
 # Alternatives Considered
 
-The primary alternative is for the interop team to not use OPSM for devnet and testnet deployments.
+The primary alternative is for the interop team to not use OPCM for devnet and testnet deployments.
 This is not ideal for various reasons:
 
-- Duplication of effort: The interop team would need to develop and maintain their own deployment scripts, even though new ones will already be written for OPSM.
+- Duplication of effort: The interop team would need to develop and maintain their own deployment scripts, even though new ones will already be written for OPCM.
 - Divergence: With duplication, it's likely the interop team's deployment scripts diverge from the production deployment scripts, leading to inconsistencies and bugs.
 
 # Proposed Solution
@@ -290,7 +290,7 @@ blobBaseFeeScalar = 1
 
 The initial version of these input files will be minimal and only include the required inputs to deploy standard chains.
 Future versions will include more inputs to support more complex deployments, such as custom gas tokens or alt-DA (it is currently TBD whether this will be part of Milestone 0.5).
-The deploy scripts and OP Stack Manager code will be written in such a way to default to standard chains and only require additional inputs for non-standard chains.
+The deploy scripts and OP Contracts Manager code will be written in such a way to default to standard chains and only require additional inputs for non-standard chains.
 
 # Risks & Uncertainties