[🧠 Smart Account] EIP-7702 upgrade/downgrade service#1906
[🧠 Smart Account] EIP-7702 upgrade/downgrade service#1906jungcome7 merged 6 commits intoroy/evm-smart-accountfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 11371a73c1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| undefined, | ||
| chainId | ||
| ); | ||
| return parseDelegation(code ?? "0x", ALLOWED_DELEGATORS); |
There was a problem hiding this comment.
Return unsupported status on chains without EIP-7702
getDelegationStatus always parses eth_getCode without checking the chain feature flag, so on non-7702 chains EOAs will be reported as "ready" (because code is 0x). That makes callers think upgrade is available, but upgradeToSmartAccount immediately fails later with "This chain does not support EIP-7702.", creating a broken flow for any UI that relies on this status endpoint. Add the same eip-7702 feature guard used in getAtomicCapability before returning delegation status.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
반영했습니다. getAtomicCapability와 동일하게 getChainFeatures guard를 추가했습니다.
| typeof auth.chainId === "string" | ||
| ? parseInt(auth.chainId, auth.chainId.startsWith("0x") ? 16 : 10) | ||
| : Number(auth.chainId); | ||
| if (numericChainId === 0 || !Number.isFinite(numericChainId)) { |
There was a problem hiding this comment.
Reject malformed authorization chain IDs
validateAuthorizationList uses parseInt and only rejects 0/non-finite values, so malformed values like "1abc" or negative IDs like "-1" pass validation. In internal signing flows this means invalid authorization entries are accepted and signed instead of being rejected at validation time, leading to hard-to-debug signing/broadcast failures and weakening the intended guardrail around authorization metadata. Enforce a strict positive-integer check (full-string validation) for chainId.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
validateAuthorizationList에 도달하는 chainId는 항상 evmInfo.chainId(number, 양의 정수)에서 옵니다. string chainId가 들어오는 외부 dApp 경로는 signEthereum과 prepareAndSignTransaction에서 이미 차단되므로 현재로서는 발생하지 않습니다.
11371a7 to
266dc30
Compare
266dc30 to
0a9ca56
Compare
…pe in tx-executor Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
0a9ca56 to
fcd94ff
Compare
참고#1910에서 이 PR의 |
#1905에서 만든 Type 4 직렬화와 authorization 서명을 활용하여, Smart Account 업/다운그레이드를 실제 수행하는 서비스를 구현합니다. UI는 후속 PR에서 구현합니다.
변경사항
approveExternal: false로 외부 dApp 호출 차단)sendEip7702Tx9단계 플로우 구현 (dummy auth →fillUnsignedEVMTx로 gas/fee/nonce batch 조회 → nonce+1로 진짜 auth 서명 → 브로드캐스트 →retry()폴링)signEthereum에서env.isInternalMsg를 확인하여 외부 메시지면 거부prepareAndSignTransaction에서 authorizationList가 있으면 무조건 거부validateAuthorizationList에서 허용된 delegator 주소인지, chainId=0이 아닌지 검증fillUnsignedEVMTx를 그대로 재사용eth_estimateGas파라미터에 dummy authorizationList를 포함하면 RPC 노드가 authorization intrinsic gas(PER_EMPTY_ACCOUNT_COST = 25,000)를 자동으로 계산하므로, 수동 overhead 추가가 불필요커밋
applyTxType()으로 통합sendEip7702Tx 흐름
Test plan
🤖 Generated with Claude Code
후속 PR — UI + ObservableQuery 마이그레이션
#1910에서 이 PR의 백엔드 서비스를 사용하는 UI 페이지를 구현합니다. 동시에
GetSmartAccountDelegationStatusMsg(메시지 기반 상태 조회)를 MobXObservableQuery로 마이그레이션하여, 자동 캐시와 관찰 시 자동 fetch를 지원합니다. 이에 따라 해당 메시지/핸들러/init 등록은 #1910에서 삭제됩니다.