ethereum-optimism / ethereum-optimism/actions
CLI: 1-of-2 signer onboarding (add user as co-signer)
- Dominant language
- TypeScript
- Stars
- 32
- Forks
- 25
- Avg merge
- 10h 20m
- Merged PRs (30d)
- 16
Description
Let the agent create a smart wallet with both the agent's signer and the user's address as co-signers, so the user can co-sign or recover out-of-band.
Parent: #407
## Flow
1. Agent asks user for their Ethereum address.
2. Agent runs `actions wallet create --cosigner 0xuser` → calls `actions.wallet.createSmartWallet({ signer: agentSigner, signers: [agentSigner.address, userAddress], nonce: 0n })`.
3. Subsequent `getSmartWallet` calls must include both signers in `deploymentSigners` (address derivation is keyed on the full signer set).
## Commands to add
- `actions wallet create --cosigner
` → `createSmartWallet(...)` with two-signer signers array.- `actions wallet add-signer --chain ` → `smartWallet.addSigner(...)`.
- `actions wallet remove-signer --chain ` → `smartWallet.removeSigner(...)`.
## Open questions
- Where do we persist the cosigner address so subsequent `getSmartWallet` calls know to include it? Likely ties into the interactive config onboarding — store in user config file.
- How does the agent prove authorization to add/remove signers? For MVP assume `PRIVATE_KEY` is enough; revisit under session-key work.
Contributor guide
Research direction
Start with the CLI handlers for `actions wallet create`, `getSmartWallet`, and the interactive config onboarding mentioned in the issue. Trace how `deploymentSigners` and the user config file are handled, then verify the three commands and subsequent wallet lookups support the full signer set; authorization with `PRIVATE_KEY` remains an open MVP question.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- blockchain, cli
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100