Repository navigation
feat(accounts): point the Accounts demos at the t14-checkpoint devnet - #1047
Conversation
The t14-checkpoint devnet runs joshie/configurable-t14-devnet-checkpoint, which renames the configurable account hash domains and RPC fields. - Repoint the RPC proxy, tailnet URL and Node snippet from multisig-1113. - Pin viem's ox to the wevm/ox#519 preview for the new hash domains. - Rename multisigSimulation to configurableAccountSimulation in the proxy, so the node estimates a new account's first transaction correctly. Configuration updates still fail until viem ships the renamed precompile ABI. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
… domain The t14-checkpoint node emits ConfigurableAccountConfigUpdated and salts in-place upgrades with tempo:configurable-account:upgrade. viem still expects MultisigConfigUpdated, so updateConfigSync threw after a successful update. Send the update directly and parse the new event. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
viem>ox also replaced ox under transitive viem 2.54.6, which imports the MultisigConfig export the preview dropped, and broke the build. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| export const client = createClient({ | ||
| chain: tempoDevnet, | ||
| transport: http('https://rpc-multisig-1113.devnet.tempoxyz.dev', { | ||
| transport: http('https://rpc-t14-checkpoint.devnet.tempoxyz.dev', { |
There was a problem hiding this comment.
🔴 Readers who copy the Accounts docs samples now hit a devnet their code can't talk to. The samples break where they worked against multisig-1113 on base. This line points the shared client snippet at t14-checkpoint. The workarounds (pinned ox override, proxy field rename, local event ABI) only cover the site's own sandbox, not readers' released viem/ox. Fix: keep the published snippet on a devnet that released viem/ox supports until they ship the renames, or update every affected sample in the same change. That includes the tempo:multisig:upgrade salt at account-upgrade.mdx:81 and the updateConfigSync calls.
Why this was flagged
The client region of src/snippets/accounts-devnet.ts is included in about 17 docs pages (create.mdx, team-multisig.mdx, account-upgrade.mdx, configuration-updates.mdx, recover-an-account.mdx, and others). Readers run these with released viem and ox from npm. The PR description says released ox 0.14.56 still uses the tempo:multisig:* domains, so "the node rejects every derived address". It also says ox sends multisigSimulation, which this node ignores, so a new account's first transaction runs out of gas. Readers' traffic never passes through the renameSimulation proxy at src/pages/_api/api/devnet-rpc.ts:81. The docs also still call client.accounts.updateConfigSync (configuration-updates.mdx:68, team-multisig.mdx:131, recover-an-account.mdx:112), which the PR says throws because it expects MultisigConfigUpdated. account-upgrade.mdx:81 still builds the salt from toHex('tempo:multisig:upgrade'), so the account it derives no longer matches the node's commitment. On base, the same snippets targeted rpc-multisig-1113, where released viem/ox matched the node.
Verification: The trigger is a reader who copies a docs sample and runs it with released viem/ox from npm. src/snippets/accounts-devnet.ts:14 now has http('https://rpc-t14-checkpoint.devnet.tempoxyz.dev', ...). configuration-updates.mdx:68 still calls client.accounts.updateConfigSync(...), which lands onchain but then throws. On base, the snippet pointed at multisig-1113, which matched released viem/ox.
| /** The configuration salt Tempo assigns an account upgraded in place. */ | ||
| export function upgradeSalt(address: Address) { | ||
| return keccak256(concat([toHex('tempo:multisig:upgrade'), address])) | ||
| return keccak256(concat([toHex('tempo:configurable-account:upgrade'), address])) |
There was a problem hiding this comment.
🔴 Readers who follow the Accounts upgrade and watch-changes pages get a wrong upgraded config and an empty update list on the new devnet. The demos moved to tempo:configurable-account:upgrade and ConfigurableAccountConfigUpdated. The docs code samples still use the old names and point at the same t14-checkpoint client. Fix: update every docs sample and reference table that names the old salt domain or event to the new names, which covers the 2 code sites listed. Same pattern at 2 sites (accounts/account-configuration/account-upgrade.mdx:81, accounts/account-configuration.mdx:68). [also at: src/snippets/accounts-devnet.ts:14 - Readers copying the upgrade and watch-signers examples get a wrong salt and no events on the new devnet. The docs pages were not updated for the renames.]
Why this was flagged
src/pages/docs/accounts/account-configuration/account-upgrade.mdx:81 builds Account.fromConfig with salt keccak256(concat([toHex('tempo:multisig:upgrade'), original.address])). This PR changes upgradeSalt (account-sandbox-devnet.ts:268, UpgradeAccountDemo.tsx:44) to tempo:configurable-account:upgrade because the t14-checkpoint node uses that domain. A reader running the page's sample gets a local config whose salt does not match the onchain commitment, so later signatures or config updates from that account fail. src/pages/docs/accounts/account-configuration.mdx:68 queries eventName: 'MultisigConfigUpdated', but the PR says the node now emits ConfigurableAccountConfigUpdated (account-sandbox-devnet.ts:262-264), so the watch-signers sample returns no updates. On base, both samples matched the multisig-1113 devnet the client snippet targeted. Prose at development/single-key-accounts.mdx:86, configurable-accounts.mdx:119,193,195 and accounts/security.mdx:74 also names the old salt domain and event.
Verification: Trigger: a reader copies the account-upgrade or watch-changes sample after this merges. accounts/account-configuration/account-upgrade.mdx:81 still has tempo:multisig:upgrade, and account-configuration.mdx:66-68 still uses eventName: 'MultisigConfigUpdated', so updates comes back empty. On the base branch these samples matched multisig-1113, so this PR is what breaks them.
| // ox still sends the simulation hint as `multisigSimulation`, and the t14-checkpoint node reads | ||
| // `configurableAccountSimulation`. Without it, the node underestimates a new account's first | ||
| // transaction and it runs out of gas. Remove once ox sends the new name. | ||
| function renameSimulation(call: unknown) { | ||
| const [request] = (call as { params?: unknown[] }).params ?? [] | ||
| if (!request || typeof request !== 'object' || !('multisigSimulation' in request)) return false | ||
| const { multisigSimulation, ...rest } = request as Record<string, unknown> | ||
| ;(call as { params: unknown[] }).params[0] = { | ||
| ...rest, | ||
| configurableAccountSimulation: multisigSimulation, | ||
| } | ||
| return true | ||
| } |
There was a problem hiding this comment.
🔴 Node readers of the Accounts snippets send a new account's first transaction without the renamed simulation hint, so it can run out of gas on t14-checkpoint. Only the browser proxy renames multisigSimulation (devnet-rpc.ts:81). The shared snippet client in src/snippets/accounts-devnet.ts:14 calls the devnet directly, so its requests keep the old field name. Fix: apply the same rename on every path that reaches t14-checkpoint, for example a request hook on the snippet's http transport, or state the limit on the pages that include the snippet.
Why this was flagged
The PR moves the snippet client (src/snippets/accounts-devnet.ts:14) to https://rpc-t14-checkpoint.devnet.tempoxyz.dev. About 15 docs pages include it (create.mdx:112, team-multisig.mdx:68, fee-sponsorship.mdx:67, and others). The workaround comment at devnet-rpc.ts:78-80 says ox, including the pinned preview, still sends multisigSimulation, while this node reads configurableAccountSimulation. Without that field, "the node underestimates a new account's first transaction and it runs out of gas". renameSimulation runs only inside the same-origin proxy POST handler (devnet-rpc.ts:28). Node scripts built from the snippet, and the fee-payer relay server in fee-sponsorship.mdx, never go through that proxy. So the first transaction from a newly created configurable account reverts out of gas. On base, multisig-1113 read multisigSimulation itself, so the same scripts estimated gas correctly. The pinned ox override does not help here, because the comment says the preview build also sends the old name.
Verification: The rename covers only the browser proxy: renameSimulation (src/pages/_api/api/devnet-rpc.ts:81-90) runs only inside the same-origin proxy's POST handler. The snippet client skips the proxy: src/snippets/accounts-devnet.ts:14 points straight at t14-checkpoint with no rename. This is a regression. On the base branch the snippet pointed at multisig-1113, which reads multisigSimulation.
| overrides: | ||
| vocs: https://pkg.pr.new/vocs@1c023ba | ||
| # Configurable account hash domains matching the t14-checkpoint devnet (wevm/ox#519). | ||
| 'viem@2.57.5>ox': https://pkg.pr.new/ox@bf010ee |
There was a problem hiding this comment.
🔴 Production docs builds now install an ox preview tarball that the lockfile cannot integrity-check, and it ships in every page bundle that uses viem 2.57.5. The new lock entry at pnpm-lock.yaml:5092 records only resolution: {tarball: https://pkg.pr.new/ox@ bf010ee}, with no integrity. The vocs preview entry at pnpm-lock.yaml:6180 does carry one. Fix: regenerate the lock entry so it records an integrity hash for the ox tarball, or depend on an npm-published ox snapshot with an integrity hash.
Why this was flagged
The override 'viem@ 2.57.5>ox': https://pkg.pr.new/ox@ bf010ee (pnpm-workspace.yaml:35) applies to every viem@ 2.57.5 instance in the tree. That covers the site's own viem plus wagmi, accounts@ 0.19.1 and mppx (pnpm-lock.yaml:12674), not only the devnet demos. The new lock entry at pnpm-lock.yaml:5091-5093 has no integrity hash. Its version: 0.14.57-755f436.0 also names a different short sha than the bf010ee in the URL. So pnpm install --frozen-lockfile downloads whatever bytes pkg.pr.new serves for that URL and has nothing to compare them against. Other bytes reach the production browser bundle unnoticed, including wallet and signing code on mainnet and testnet pages. On base, ox@ 0.14.56 came from npm with integrity: sha512-…. The neighbouring vocs pkg.pr.new override shows the lockfile can record an integrity hash for these tarballs, so this missing hash is not inherent to pkg.pr.new.
Verification: The trigger is pkg.pr.new serving different bytes at https://pkg.pr.new/ox@ bf010ee than the ones the author tested. The lock entry at pnpm-lock.yaml:5091-5093 has no integrity field, while the vocs entry at pnpm-lock.yaml:6180 and the replaced ox@ 0.14.56 both had one. So pnpm install --frozen-lockfile installs and bundles whatever the URL serves.
Moves the Accounts demos from the `multisig-1113` devnet to `t14-checkpoint`. That devnet runs `joshie/configurable-t14-devnet-checkpoint` plus a recovery factory genesis flag (`liam/t14-checkpoint-recovery-factory`, image `sha-04e67d3`).
Changes
Tested against the devnet
These ran in the sandbox on `/docs/accounts/create`, from a production build (`pnpm build`, then `pnpm preview`):
`pnpm build` and `pnpm test` (1547 tests) pass.
Not covered
Follow-ups once viem and ox ship the renames
🤖 Generated with Claude Code