chore: sync submodule state (parent ref update)

Made-with: Cursor

docs/operations/CHANNEL_INCIDENT_RUNBOOK.md

@@ -0,0 +1,37 @@
+# Channel Manager Incident Runbook
+
+Short runbook for PaymentChannelManager and GenericStateChannelManager: pause, unpause, and replace admin.
+
+## When to pause
+
+- Suspected bug or exploit in open/fund or state handling.
+- Upgrade or migration (pause new activity while in-flight channels settle).
+- Security incident: stop new channel opens and funds; existing channels can still close.
+
+## How to pause
+
+- **Who**: Current `admin` (or multisig that is admin).
+- **Call**: `pause()` on the contract (PaymentChannelManager or GenericStateChannelManager).
+- **Effect**: `openChannel` and `fundChannel` revert with "paused". `closeChannelCooperative`, `submitClose`, `challengeClose`, and `finalizeClose` remain callable so in-flight channels can settle.
+
+## How to unpause
+
+- **Who**: Current `admin`.
+- **Call**: `unpause()`.
+- **Effect**: New channels can be opened and funded again.
+
+## How to replace admin
+
+- **Who**: Current `admin`.
+- **Call**: `setAdmin(newAdmin)` with the new address (e.g. new multisig).
+- **Recommendation**: Use a multisig as `newAdmin`; avoid EOA for production.
+
+## Contracts and addresses
+
+- Document deployed addresses in [PAYMENT_CHANNELS_DEPLOYMENT.md](../deployment/PAYMENT_CHANNELS_DEPLOYMENT.md).
+- Ensure only the intended multisig/EOA has admin before and after replacement.
+
+## Monitoring
+
+- Monitor `Paused`, `Unpaused`, and `AdminChanged` events.
+- Alert on unexpected pause or admin change.

docs/operations/integrations/METAMASK_BRIDGE_SWAP.md

@@ -8,6 +8,27 @@ ChainID 138 is **not** currently supported in MetaMask's native Swaps and Bridge
 
 ## Swaps (In-Wallet Aggregator)
 
+### Known error: "No XChain Swaps native asset found for chainId: eip155:138"
+
+If you see this error in MetaMask while connected to Chain 138, it can appear when clicking **Send** or **Swap** (depending on MetaMask version; the Send flow sometimes uses the same LavaPack/XChain code):
+
+```
+Error: No XChain Swaps native asset found for chainId: eip155:138
+  at LavaPack.loadBundle.s.getNativeAssetForChainId (...)
+```
+
+**Cause:** MetaMask’s LavaPack/XChain logic only supports a fixed list of chains. Chain 138 is not in that list. In some versions, the **Send** UI triggers this path (e.g. for gas or asset lookup), so the error appears on Send as well as Swap. This is not about using eth_sendTransaction vs eth_sendRawTransaction (the error happens in the UI before any RPC), and it is not caused by the Chain 138 Snap or its allowlisting—the extension uses its own LavaPack list and does not ask Snaps for native asset.
+
+**If it happens on Send:**
+
+- **Recommended — Chain 138 Send page:** Use the **Chain 138 Snap companion site Send page** (e.g. `/send` on the deployed Snap site). This page uses `eth_sendTransaction` from the dApp context, bypassing MetaMask's broken Send UI—connect MetaMask, open the Send page, ensure Chain 138, enter recipient and amount, then click Send.
+- **Alternative — Different entry point:** Try sending from the account/balance view (e.g. click the balance or “Send” from the asset list) instead of the home “Send” button, in case your MetaMask version uses a different code path.
+- **Alternative — Another wallet:** Use a wallet that supports custom EVM networks (e.g. add Chain 138 via Chainlist) and does not rely on this backend for Send.
+
+**If it happens on Swap:** Do **not** use the in-wallet Swaps button for Chain 138. Use a DEX that supports Chain 138 (see [Workaround: Use DEX UI](#workaround-use-dex-ui) below).
+
+Receiving and using dApps on Chain 138 work normally; the failure is in MetaMask’s own Send/Swap UI for unsupported chains.
+
 ### Current Limitation
 
 MetaMask Swaps supports a fixed set of networks:
@@ -79,9 +100,16 @@ For bridges to work with ChainID 138:
 
 ## Buy/Sell (Fiat On/Off-Ramp)
 
+### Priority flows (mainnet liquidity + ramps)
+
+**Recommended user flows** (operator must fund mainnet liquidity first):
+
+- **On-ramp:** Buy on Ethereum Mainnet via ramp → bridge to Chain 138. See [MAINNET_RAMP_USER_FLOWS.md](../../../../docs/04-configuration/MAINNET_RAMP_USER_FLOWS.md).
+- **Off-ramp:** Bridge Chain 138 → Mainnet → sell on mainnet via ramp. See [MAINNET_LIQUIDITY_AND_RAMPS_PRIORITY.md](../../../../docs/00-meta/MAINNET_LIQUIDITY_AND_RAMPS_PRIORITY.md) and [MAINNET_RAMP_USER_FLOWS.md](../../../../docs/04-configuration/MAINNET_RAMP_USER_FLOWS.md).
+
 ### Current Limitation
 
-MetaMask's on-/off-ramp partners only support certain chains/tokens. ChainID 138 assets are not currently supported.
+MetaMask's on-/off-ramp partners only support certain chains/tokens. ChainID 138 assets are not currently supported natively.
 
 ### Workaround: Bridge from Supported Chains
 

docs/operations/status-reports/ALL_TASKS_COMPLETE.md

@@ -93,5 +93,5 @@ All development tasks are complete. Remaining items are operational procedures:
 4. Load testing validation
 5. Disaster recovery testing
 
-See [TODO List](TODO.md) for complete task breakdown.
+See [TODO List](../tasks/TODO.md) for complete task breakdown.
 

docs/operations/status-reports/CANCUN_FORK_STATUS.md

@@ -0,0 +1,81 @@
+# Cancun Fork Status – ChainID 138
+
+## Summary
+
+**Adding Cancun is already done** in your production genesis. No extra work is required for the chain config.
+
+---
+
+## Current State
+
+### Production genesis (`genesis-138.json`)
+
+The phase1 genesis used for deployment already enables Shanghai and Cancun from block 0:
+
+```json
+"shanghaiTime": 0,
+"cancunTime": 0,
+```
+
+- **Source**: `smom-dbis-138/terraform/phases/phase1/config/genesis-138.json`
+- **Deployed to**: Besu nodes via phase1 scripts (e.g. `/genesis/genesis.json` or `/opt/besu/config/genesis.json`)
+
+So the chain is **already configured for Cancun** at genesis.
+
+### Genesis template
+
+`config/genesis-template.json` has been updated to include `shanghaiTime: 0` and `cancunTime: 0`, so any new genesis generated from this template will also have Cancun from block 0.
+
+---
+
+## EIP-7702 (delegation) on top of Cancun
+
+EIP-7702 requires:
+
+1. **Cancun fork** – ✅ Already in genesis (`cancunTime: 0`).
+2. **Besu 24.1.0+** – Must be checked on each node.
+
+To confirm Besu version on all nodes:
+
+```bash
+# Full list (validators, sentries, RPC)
+PROXMOX_HOST=192.168.11.10 ./scripts/check-besu-version-all-nodes.sh
+
+# Quick check on running RPC VMIDs only
+BESU_VMIDS="2101 2400 2401 2402" ./scripts/check-besu-version-all-nodes.sh
+```
+
+**Last run (sample):** VMIDs 2400 and 2402 reported Besu **23.10.0** (below 24.1.0). Use the project upgrade script to bring all nodes to latest:
+
+```bash
+# From repo root (proxmox)
+./scripts/upgrade-besu-all-nodes.sh              # upgrade to 25.12.0
+./scripts/upgrade-besu-all-nodes.sh --dry-run    # show what would be done
+BESU_VERSION=25.11.0 ./scripts/upgrade-besu-all-nodes.sh
+```
+
+- Ensure every Besu node runs **Besu 24.1.0 or later**.
+- Ensure the **deployed** genesis on each node is the one that contains `cancunTime: 0` (i.e. your current `genesis-138.json` or equivalent).
+- Use `scripts/enable-eip-7702-besu.sh` to verify genesis and remind about the Besu version requirement.
+
+---
+
+## If you were adding Cancun from scratch
+
+Difficulty: **low**.
+
+1. **Genesis**: In the genesis `config` object add (time-based) or block-based equivalents:
+   - `"shanghaiTime": 0` (or a Unix timestamp)
+   - `"cancunTime": 0` (or a Unix timestamp)
+2. **Besu**: No extra Besu options; fork activation is driven by the genesis file.
+3. **Deploy**: Replace genesis on all nodes with the updated file and restart Besu (or roll out in a coordinated way if scheduling a future fork time/block).
+
+For a **new** chain (genesis block 0), using `0` activates Shanghai and Cancun from the first block.
+
+---
+
+## References
+
+- Besu genesis reference: [Genesis file items](https://besu.hyperledger.org/stable/public-networks/reference/genesis-items)
+- EIP-7702 script: `scripts/enable-eip-7702-besu.sh`
+- Fork analysis: `smom-dbis-138/docs/operations/status-reports/FORK_ANALYSIS.md`

docs/operations/status-reports/COMPLETION_SUMMARY_METAMASK.md

@@ -249,6 +249,6 @@ The MetaMask integration is **code-complete** and **documentation-complete**. It
 - [MetaMask Integration Guide](METAMASK_INTEGRATION.md)
 - [MetaMask Developer Guide](METAMASK_DEVELOPER_GUIDE.md)
 - [MetaMask Gaps Analysis](METAMASK_GAPS_ANALYSIS.md)
-- [TODO List](../TODO.md)
+- [TODO List](../tasks/TODO.md)
 - [Project Review](PROJECT_REVIEW.md)
 

docs/operations/status-reports/FINAL_COMPLETION_STATUS.md

@@ -70,5 +70,5 @@ These are operational procedures, not development tasks:
 - **Status**: ✅ Complete
 - **Production Ready**: ✅ Yes
 
-See [TODO List](TODO.md) for complete task breakdown.
+See [TODO List](../tasks/TODO.md) for complete task breakdown.