update upgrade section

specs/experimental/inbox-contract.md

@@ -18,6 +18,9 @@
     - [How `op-node` knows the canonical batch inbox](#how-op-node-knows-the-canonical-batch-inbox)
     - [How `op-batcher` knows canonical batch inbox](#how-op-batcher-knows-canonical-batch-inbox)
   - [Upgrade](#upgrade)
+    - [L1Block Deployment](#l1block-deployment)
+    - [L1Block Proxy Update](#l1block-proxy-update)
+    - [SystemConfig Upgrade](#systemconfig-upgrade)
   - [Security Considerations](#security-considerations)
     - [Inbox Sender](#inbox-sender)
   - [Reference Implementation](#reference-implementation)
@@ -243,9 +246,52 @@ Immediately before submitting a new batch, `op-batcher` fetches the current inbo
 
 ## Upgrade
 
-To use this feature, existing OP Stack instances must complete two steps:
-1. Upgrade the `SystemConfig` and set an inbox contract on L1.
-2. Upgrade the `L1Block` on L2.
+The custom gas token upgrade is not yet defined to be part of a particular network upgrade, but it will be scheduled as part of a future hardfork. On the network upgrade block, a set of deposit transaction based upgrade transactions are deterministically generated by the derivation pipeline in the following order:
+
+- L1 Attributes Transaction calling `setL1BlockValuesEcotone`
+- User deposits from L1
+- Network Upgrade Transactions
+  - L1Block deployment
+  - Update L1Block Proxy ERC-1967 Implementation Slot
+
+The deployment transactions MUST have a `from` value that has no code and has no known
+private key. This is to guarantee it cannot be frontran and have its nonce modified.
+If this was possible, then an attacker would be able to modify the address that the
+implementation is deployed to because it is based on `CREATE` and not `CREATE2`.
+This would then cause the proxy implementation set transactions to set an incorrect
+implementation address, resulting in a bricked contract. The calldata is not generated
+dynamically to enable deterministic upgrade transactions across all networks.
+
+The proxy upgrade transactions are from `address(0)` because the `Proxy` implementation
+considers `address(0)` to be an admin. Going straight to the `Proxy` guarantees that
+the upgrade will work because there is no guarantee that the `Proxy` is owned by the
+`ProxyAdmin` and going through the `ProxyAdmin` would require stealing the identity
+of its owner, which may be different on every chain. That would require adding L2
+RPC access to the derivation pipeline and make the upgrade transactions non deterministic.
+
+### L1Block Deployment
+
+- `from`: `0x4210000000000000000000000000000000000002`
+- `to`: `null`
+- `mint`: `0`
+- `value`: `0`
+- `gasLimit`: TODO
+- `data`: TODO
+- `sourceHash`: TODO
+
+### L1Block Proxy Update
+
+- `from`: `0x0000000000000000000000000000000000000000`
+- `to`: `0x4200000000000000000000000000000000000015`
+- `mint`: `0`
+- `value`: `0`
+- `gasLimit`: `50,000`
+- `data`: TODO
+- `sourceHash`: TODO
+
+### SystemConfig Upgrade
+
+Finally, upgrade the `SystemConfig` and set an inbox contract on L1.
 
 Note that according to the [Optimism Style Guide](https://github.com/ethereum-optimism/optimism/blob/9d31040ecf8590423adf267ad24b03bc1bf7273b/packages/contracts-bedrock/STYLE_GUIDE.md), The process for upgrading the implementation is as follows:
 1. Upgrade the implementation to the `StorageSetter` contract.