Repository navigation
feat(tempo): sync configurable accounts with Tempo T14 - #5408
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 877ea39 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e0e921c036
ℹ️ 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".
| if (keyInfo.expiry <= BigInt(Math.floor(Date.now() / 1000))) | ||
| return false |
There was a problem hiding this comment.
Check delegate grant expiry against the selected block
When verifying a configurable access-key signature with a historical blockNumber or blockHash, the grant and owner quorum are read at that block, but expiry is checked against the current wall clock. Consequently, a signature whose grant was active at the requested block returns false once that grant expires today. This also makes the configurable-key path inconsistent with the primitive V2 path, which delegates verification to a precompile at the selected block. Compare the expiry against the selected block's timestamp instead.
Useful? React with 👍 / 👎.
|
Published pnpm add viem@pr-5408
pnpm add viem@0.0.0-pr-5408-89fe7e9 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 42fe58e074
ℹ️ 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".
| if (version === 'v2') | ||
| return await ( | ||
| readContract(client, { | ||
| ...block, | ||
| ...verifyAccessKey.call({ |
There was a problem hiding this comment.
Preserve access-key verification on Tempo Zones
For clients using a chain created by Zone.from, verifying any primitive V2 access-key signature with mode: 'allowAccessKey' now unconditionally calls the signature-verifier precompile. Zones lack that precompile, as documented in src/tempo/internal/relay/feePayer.ts, while src/tempo/Zone.ts installs this same chainConfig. Consequently, previously valid signatures can no longer be verified on Zones: the call fails instead of using the previous keychain-metadata lookup and local signature verification. Preserve a verification path for Zones rather than requiring the precompile on every Tempo chain.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ebe04046f8
ℹ️ 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".
| if (decoded.functionName !== 'upgradeAccount') return undefined | ||
| const [threshold, owners] = decoded.args | ||
| return AccountConfig.fromUpgrade(from, { owners, threshold }) |
There was a problem hiding this comment.
Cache config updates that follow a batched upgrade
When a root-signed batch contains upgradeAccount followed by updateConfig, this scan caches only the upgrade's initial config and ignores the configuration installed by the subsequent update. The root-signed submission path never calls cacheNextConfigs, so without a custom resolveConfig, account_getConfig returns null for the final onchain commitment and subsequent address-only coordinated transactions cannot be prepared. Process the calls following the upgrade through the config-update caching logic as well.
Useful? React with 👍 / 👎.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Brings viem's Tempo configurable accounts in line with tempoxyz/tempo
main(T14) and the TIP-1107/1111/1113/1137 specs.Fixes
UpgradeMustBeOnlyCallwas renamed upstream toUpgradeMustBeDirectCall(feat(evm): allow upgradeAccount anywhere in a batch tempoxyz/tempo#8778), and viem now uses the new name in the ABIs and inExecutionError, so the revert decodes again.updateConfigSyncreturned the version-0 registration config on an account's first transaction. Since feat(evm): emit ConfigurableAccountConfigUpdated on registration tempoxyz/tempo#8758 that transaction emits two events, andextractEventnow takes the last one.Upgrades (TIP-1113)
accounts.upgrade/upgradeSyncacceptkeyAuthorization(feat(evm): allow key_authorization in the migrating transaction tempoxyz/tempo#8868). An authorization list is still rejected.upgrade.callcan be batched anywhere incalls(feat(evm): allow upgradeAccount anywhere in a batch tempoxyz/tempo#8778), and the accounts relay caches configs from batched upgrades.Access keys
configurableAccount), through a newaccessoption onAccount.fromConfig(Account.fromConfig(config, { access: parent })) and keychain V2 envelopes. Simulation covers the delegate, and the relay fee payer accepts these envelopes.keyAuthorizationSimulationis typed, and it is filled in when a configurable parent's key authorization has no quorum yet.verifyHashkeychain path follows T14: it rejects retired root keys and key-type mismatches.adminoption on key authorizations,accessKey.isAdmin,accessKey.watchAdminAuthorized, and their docs. Access keys no longer sign key authorizations (the root key or a configurable account does).verifyHashkeepsadmin, which now means "root key only".Chain config
prepareTransactionRequestdrops a dead account check and two async IIFEs, anduseExpiringNonceis a module function called only when the request is not coordinated, so coordinated requests (configurable accounts and their access keys) skipConcurrent.detect.ABIs and docs
Abis.configurableAccountShim(isValidSignature,onERC721Received).0xefcode and support ERC-1271, and that the address is derived by keccak, not CREATE2.Tests
tempo-accountsCI image moves fromsha-179347b(the closed checkpoint chore: checkpoint configurable accounts for devnet audit tempoxyz/tempo#8595) tosha-96bdeb7(Tempomain).tempo-accountsproject passes 179/179. Before these changes it failed 2 of 159 tests, both from theupdateConfigSyncbug.tempounit tests: 318 passed, 6 skipped.pnpm check:typesand Biome pass.Relay coordination for configurable access keys
Relay.accountsnow collects owner approvals for a configurable account acting as an access key (TIP-1111). It unwraps the keychain V2 envelope, stores the operation with its parent asuserAddress, and broadcasts the keychain envelope at quorum. Pending results andeth_getTransactionByHashreport the parent asfrom.withRelayroutes keychain envelopes with a configurable inner signature to the relay, and approving a stored operation byhashworks with the access key account.internal/relay/accounts.test.tsrun throughwithRelaywithRelay.accountsandRelay.feePayer, with owners on separate clients. They cover sponsored quorum, a same-transaction grant and its later reuse, spending limits, revocation, expiry, rotation of the delegate's owners withupdateConfig, and a non-owner approval. With these,tempo-accountspasses 186/186 (185/185 after the admin key tests were removed).AccountOperationuserAddressfrom feat(tempo): add userAddress to AccountOperation transaction operations ox#575, released in ox 0.14.63 (ported to ox v1 in feat(tempo): add userAddress to AccountOperation transaction operations ox#576).Notes
Abis.tswas edited in its generated format rather than regenerated.pnpm gen:tempo-abisalso rebuilds the Earn and propAMM ABIs from their latest commits, and the Earn build failed in this environment. Rerunning the generator should produce the same configurable-account entries.`viem/tempo`:.Pyramid thread: https://pyramid.tehq.net/threads/4b936132-b820-48bb-9572-3b71be133a78