Add cross-chain asset consolidation proposal and draft documents

Author: hanzel98

documents/CrossChainAssetConsolidationProposal.md

@@ -0,0 +1,74 @@
+# Cross-Chain Asset Consolidation via Delegated Automation
+
+## Problem Statement
+
+Automate periodic transfers of assets (e.g., USDC) from multisig smart accounts on multiple EVM chains to Ethereum mainnet using the existing bridge infrastructure ([va-mmcx-bridge-contracts](https://github.com/consensys-vertical-apps/va-mmcx-bridge-contracts)).
+
+## Solution Architecture
+
+Leverage our existing delegation framework ([internal multisig/delegation repo]) to enable secure, automated cross-chain bridging with on-chain policy enforcement and off-chain execution orchestration.
+
+### On-Chain Components
+
+**Multisig Deployment**: Deploy MultiSigDeleGator smart accounts on each source chain using deterministic deployment to achieve identical addresses across chains with consistent signer sets and thresholds.
+
+**Delegation Creation**: Multisig creates off-chain delegations (EIP-712 signed) granting limited execution authority to an automation service. **Critically, a single delegation signature can be reused indefinitely**—the automation service redeems the same signed delegation object for every bridging operation without requiring multisig signers to regenerate signatures. Delegations are validated on-chain by DelegationManager at each redemption time. Each delegation combines caveat enforcers:
+
+- **AllowedTargetsEnforcer**: Only bridge contract addresses
+- **AllowedMethodsEnforcer**: Only bridge entrypoints (deposit/lock/mint)
+- **AllowedCalldataEnforcer**: Fixed mainnet treasury destination address
+- **ERC20TransferAmountEnforcer**: Per-delegation spending limits
+- **ERC20PeriodTransferEnforcer**: Time-windowed cumulative limits
+- **TimestampEnforcer**: Validity windows
+- **RedeemerEnforcer**: Optional automation wallet restriction
+
+Delegations can be disabled on-chain via `disableDelegation()` for immediate revocation.
+
+**Execution Flow**: When the automation service redeems a delegation via `DelegationManager.redeemDelegations()`, the framework validates all caveats, then the multisig executes the bridge call (approve tokens if needed, call bridge deposit function, emit events). Funds arrive at the mainnet treasury multisig with complete on-chain audit trail.
+
+### Off-Chain Components
+
+**Automation Service**: Node.js/TypeScript service (or OpenZeppelin Defender) monitors multisig balances via RPC, evaluates thresholds and limits, constructs delegation redemption transactions with encoded bridge calls, and submits signed transactions using the automation wallet.
+
+**Key Management**: Private key never stored in plaintext. The automation service retrieves the key at runtime from a secrets manager (HashiCorp Vault, AWS KMS, GCP KMS, Azure Key Vault, or HSM). The service authenticates to the secrets manager using IAM roles, service accounts, or certificates. Network access controls restrict which machines/IPs can access the secrets manager API, and the automation service runs in an isolated network segment (VPC/subnet) with egress-only access to blockchain RPC endpoints. The key material is only decrypted in memory during transaction signing and never persisted to disk. Even if the automation service is compromised, delegation caveats limit blast radius (strict allowlists, per-tx/per-period caps).
+
+**Delegation Issuance**: Multisig signers compose delegations with caveat configuration and sign via EIP-712. DelegationManager validates signatures at redemption. Signer set changes invalidate existing delegations (expected behavior; re-issue as part of signer-change playbook).
+
+## Operational Flow
+
+1. Off-chain service queries multisig balances on source chains
+2. Service evaluates thresholds, time windows, and cumulative limits
+3. If conditions met, service builds `redeemDelegations()` call with signed delegation and encoded bridge execution
+4. DelegationManager validates signatures, caveats, and delegation status
+5. Multisig approves tokens (if needed) and calls bridge contract
+6. Funds bridge to mainnet; events emitted for audit
+
+**Key Separation**: Policy enforcement is on-chain (delegations + caveats); decision logic and scheduling are off-chain (automation script).
+
+## Advantages
+
+**Security**: Multisig control, narrowly scoped permissions, immediate revocation, limited blast radius even if automation key compromised.
+
+**Efficiency**: No multisig sign-off required per bridging operation; enables frequent automated transfers. **A single delegation signature is reusable indefinitely**, eliminating the need to coordinate multisig signers for each transfer—sign once, use forever (subject to caveat limits and validity windows).
+
+**Scalability**: Easy extension across chains using same delegation pattern and deterministic addresses.
+
+**Auditability**: Complete on-chain event records plus off-chain automation logs.
+
+**Reuse**: Builds on existing MultiSigDeleGator and DelegationManager infrastructure.
+
+## Risks and Mitigations
+
+**Bridge Risk**: Exploit or downtime affects funds in transit. _Mitigation_: Immediate revocation via `disableDelegation()`, chain-specific configs, bridge event monitoring.
+
+**Key Compromise**: Attacker could redeem delegations. _Mitigation_: Strict limits, secure key storage, revocation capability. Caveats prevent exceeding limits or calling unauthorized contracts.
+
+**Config Errors**: Misconfigured thresholds cause unintended behavior. _Mitigation_: Code review, staged rollouts, on-chain verifiability of delegation parameters.
+
+**Signer Changes**: Invalidates existing delegation signatures. _Mitigation_: Re-issue delegations as part of signer-change playbook.
+
+## References
+
+- Delegation Framework: [internal multisig/delegation repo]
+- Bridge Contracts: https://github.com/consensys-vertical-apps/va-mmcx-bridge-contracts
+- Bridge API: https://github.com/consensys-vertical-apps/va-mmcx-bridge-api

documents/CrosschainDraft.md

@@ -0,0 +1,51 @@
+Cross-Chain Asset Consolidation via Delegated Automation
+
+Problem: Automate periodic transfers of assets (e.g., USDC) from multisig smart accounts on multiple EVM chains to Ethereum mainnet using a bridge.
+
+Solution Architecture: The system leverages our existing Delegation Framework to enable automated cross-chain bridging with strict on-chain policy enforcement. The multisig smart accounts are DeleGator Multisig smart accounts—smart account implementations that integrate with the Delegation Framework, enabling them to create delegations and honor delegation redemptions through the DelegationManager. Here's the high-level flow: DeleGator Multisig smart accounts hold assets on each source chain. During initial setup, multisig signers create a single delegation (signed once via EIP-712) that grants an automation service permission to bridge funds, but only under strict constraints enforced on-chain by caveat enforcers. The automation service monitors balances and, when conditions are met, redeems the delegation to execute bridge transactions. Each redemption is validated on-chain by the DelegationManager, which checks all caveat enforcers before allowing execution. Critically, the delegation framework's caveat enforcers ensure the automation can ONLY call approved bridge contracts, use approved methods, send to the fixed mainnet treasury address, and respect spending/time limits—even if the automation key is compromised. This means multisig keys are only needed once for setup, then can be stored in cold storage, while the automation key runs continuously but cannot perform unauthorized actions. Policy enforcement happens on-chain (via delegations and caveats), while decision logic and scheduling happen off-chain (automation script). The system uses the existing MetaMask bridge infrastructure for cross-chain transfers.
+
+On-Chain Components
+
+Multisig Deployment: Deploy MultiSigDeleGator Smart Accounts on each source chain.
+Delegation Creation: Multisig creates off-chain delegations (EIP-712 signed) granting limited execution authority to an automation service. Single delegation signature reusable indefinitely. Each delegation combines caveat enforcers:
+
+- AllowedTargetsEnforcer: Only bridge contract addresses
+- AllowedMethodsEnforcer: Only bridge entrypoints (deposit/lock/mint)
+- AllowedCalldataEnforcer: Fixed mainnet treasury destination address
+- ERC20TransferAmountEnforcer: Per-delegation spending limits
+- ERC20PeriodTransferEnforcer: Time-windowed cumulative limits
+- TimestampEnforcer: Validity windows
+
+Delegations can be disabled on-chain via disableDelegation() for immediate revocation.
+
+Execution Flow: Automation service redeems delegation via DelegationManager.redeemDelegations(). Framework validates caveats, then multisig executes bridge call. Funds arrive at mainnet treasury with on-chain audit trail.
+
+Off-Chain Components
+
+Automation Service: Node.js/TypeScript service (or OpenZeppelin Defender) monitors balances via RPC, evaluates thresholds/limits, constructs delegation redemption transactions using Smart Accounts Kit, and submits signed transactions.
+
+Key Management and Security Model: Multisig signers sign delegation ONCE during setup, then keys stored in cold storage. Automation service uses separate private key that only signs transactions—it never directly controls multisig funds. When the automation key signs a transaction, it must redeem the delegation through DelegationManager, which validates all caveat enforcers on-chain before allowing the multisig to execute. Even if the automation key is leaked, caveat enforcers restrict actions to approved bridge contracts/methods, fixed treasury address, and spending/time limits. Worst case: attacker triggers bridging early (funds still go to correct destination) or spends gas tokens (mitigated via ERC-4337 paymaster). The automation key cannot access multisig funds directly, send to unauthorized addresses, or bypass on-chain constraints. Standard security practices (secrets manager, network controls) suffice since compromise has minimal impact.
+
+Delegation Issuance: Multisig signers compose delegations with caveat configuration and sign via EIP-712. Signer set changes invalidate existing delegations (re-issue as part of signer-change playbook).
+
+Operational Flow: (1) Service queries multisig balances, (2) evaluates thresholds/limits, (3) builds redeemDelegations() call if conditions met, (4) DelegationManager validates, (5) multisig executes bridge call, (6) funds bridge to mainnet with audit trail.
+
+Advantages
+
+Security: Multisig keys only needed once (see Solution Architecture). Automation key strictly limited by on-chain caveats. Immediate revocation via disableDelegation().
+Efficiency: No multisig sign-off per operation; enables frequent automated transfers. Single delegation signature reusable indefinitely.
+Scalability: Easy extension across chains using same delegation pattern and deterministic addresses.
+Auditability: Complete on-chain event records plus off-chain automation logs.
+Reuse: Builds on existing MultiSigDeleGator and DelegationManager infrastructure.
+
+Risks and Mitigations
+
+Bridge: If bridge risks are detected, stop automation script and disable delegations.
+Key Compromise: Automation key leak has minimal impact (see Key Management). Multisig keys remain in cold storage.
+Config Errors: Misconfigured thresholds cause unintended behavior. Mitigation: Code review, staged rollouts, on-chain verifiability of delegation parameters.
+Signer Changes: Invalidates existing delegation signatures. Mitigation: Re-issue delegations as part of signer-change playbook.
+
+References
+What is the Delegation Toolkit and what can you build with it?
+Delegation Framework Contracts
+MetaMask Bridge Contracts and Bridge API