5.2 KiB
5.2 KiB
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. 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 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.solandtest/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