# Pre-Deployment Recommendations and Suggestions

Use this checklist and recommendations before deploying PaymentChannelManager to Mainnet or Chain-138.

---

## 1. Security

| Recommendation | Details |
|----------------|--------|
| **Admin = multisig** | Set `CHANNEL_ADMIN` to a Gnosis Safe (or other multisig). Avoid EOA for production. |
| **Challenge window** | 24h (86400s) is a reasonable default. Shorter (e.g. 1h) increases griefing risk for honest offline users; longer increases exposure to stale-state attacks. Document the tradeoff for operators. |
| **Reentrancy** | Current design: state updates then external transfers. Consider adding a simple reentrancy guard (e.g. OpenZeppelin `ReentrancyGuard`) on `closeChannelCooperative`, `finalizeClose`, and any other entry that does `_transfer`. |
| **Signature replay** | State is bound to `(channelId, nonce, balanceA, balanceB)`. No cross-chain replay if each chain has its own contract. Same-chain replay is prevented by nonce and status (channel closed). |
| **ecrecover edge cases** | Contract uses `ecrecover` without checking for zero address or signature malleability. For maximum safety, consider EIP-2 malleability check (reject `s > secp256k1n/2`) or use a library (e.g. OpenZeppelin ECDSA). |

---

## 2. Operational

| Recommendation | Details |
|----------------|--------|
| **Deploy order** | Deploy to testnet (or Mainnet fork + Chain-138 testnet) first. Run full e2e tests (see test/e2e/PaymentChannelsE2E.t.sol). |
| **Verification** | Verify on block explorer after deploy (`--verify` in Forge script). Ensures users can read the contract. |
| **Frontend config** | After deploy, set `CONTRACT_ADDRESSES.mainnet.PAYMENT_CHANNEL_MANAGER` and/or `CONTRACT_ADDRESSES.chain138.PAYMENT_CHANNEL_MANAGER` in the dApp. |
| **Monitoring** | Monitor `ChannelOpened`, `ChannelClosed`, `ChallengeSubmitted`. Alert on unexpected pause or admin change. |
| **Watchtower** | If users may be offline during the challenge window, document or run a watchtower (see WATCHTOWER_AND_INDEXER.md). |

---

## 3. Testing

| Recommendation | Details |
|----------------|--------|
| **Unit tests** | Already in `test/channels/PaymentChannelManager.t.sol`. Run before every deploy: `forge test --match-path test/channels/`. |
| **E2E tests** | Run full e2e: `forge test --match-path test/e2e/PaymentChannelsE2E.t.sol`. Covers happy path, unilateral close, challenge, and edge cases. |
| **Fork / testnet** | Run e2e on a fork of the target chain (and Chain-138 testnet if available) to catch env-specific issues. |
| **Gas snapshot** | See [GAS_REPORT.md](GAS_REPORT.md). Run `forge test --gas-report --match-path test/channels/` and e2e paths to refresh. |

---

## 4. Contract behavior and limits

| Item | Current behavior | Suggestion |
|------|------------------|------------|
| **ETH only** | v1 holds only ETH. | If you need ERC20 later, add a separate PaymentChannelManagerERC20 or extend with a token parameter and safe transfer. |
| **No upgradeability** | Contract is not proxy-based. | If you expect to change logic, consider deploying behind a transparent proxy and an initial implementation; otherwise keep immutable for simplicity. |
| **Unbounded channel list** | `_channelIds.length` grows with channels. | `getChannelCount` and enumeration are O(1) and O(n) per read; acceptable for moderate channel counts. For very high volume, an indexer is recommended. |
| **Pause** | Pause blocks only `openChannel` and `fundChannel`; `closeChannelCooperative`, `submitClose`, `challengeClose`, and `finalizeClose` are allowed when paused. | In-flight channels can always settle; new channels are disabled when paused. |

---

## 5. Documentation and runbooks

| Recommendation | Details |
|----------------|--------|
| **Runbook** | Keep [PAYMENT_CHANNELS_DEPLOYMENT.md](../deployment/PAYMENT_CHANNELS_DEPLOYMENT.md) updated with actual deployed addresses and any chain-specific steps. |
| **Incident response** | Document: how to pause (admin), how to unpause, how to replace admin (multisig), and when to use each. |
| **User-facing docs** | Explain challenge window and liveness (must respond or run watchtower before deadline). Link Connext (or other) for cross-chain from the Channels UI. |

---

## 6. Optional improvements (post-MVP)

- **ReentrancyGuard** on close/finalize paths.
- **ECDSA** (or equivalent) for signatures to avoid malleability and zero-address edge cases.
- **Events** for admin changes and challenge-window updates (already present).
- **Indexer** for “my channels” and filtering by participant (see WATCHTOWER_AND_INDEXER.md).
- **Watchtower** service for users who may be offline during disputes.

---

## 7. Deployment checklist (summary)

- [ ] Unit tests pass: `forge test --match-path test/channels/`
- [ ] E2E tests pass: `forge test --match-path test/e2e/PaymentChannelsE2E.t.sol` and `test/e2e/GenericStateChannelsE2E.t.sol`
- [ ] Admin set to multisig address
- [ ] Challenge window chosen and documented
- [ ] Deploy to testnet (or fork) and re-run e2e
- [ ] Deploy to target chain (Mainnet / Chain-138)
- [ ] Verify contract on block explorer
- [ ] Update frontend config with manager address(es)
- [ ] Document addresses and any chain-specific notes in deployment doc