Repository navigation
Conversation
…g update Arweave items come newest first, but the reader kept the last (oldest) signature of each signer. After the guard key rotation the key machine republishes guard wallet signatures for stored config updates; the old ones no longer validate. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With a validationProvider, ArweaveReader uses the newest signature of each signer (config updates) or the newest migration that validates on that chain, and the newest one otherwise. After a guard key rotation rollback the older guard signatures become valid again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The previous default owner has no Sequence-Sessions items on Arweave; every item since 2024-10 is published by 0xA27b3EDE035dE132DA35f115bB5614D421f3201f (key machine /status arweave.signer). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- validationProviders(chainId) replaces validationProvider: each signature is checked on the chain it was made for; no-chain-id signatures on the chain the caller returns for chain id 0. - Migrations are checked with the transactions digest; the wallet applies its own domain in isValidSignature. - A signature that can't be checked (no provider, signer without code, RPC error) is preferred over one that was checked and is invalid; if every one is invalid, the newest is used and a warning is logged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Leave the default owner as it was; this change only covers signature selection. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ture Wallets revert on invalid signatures instead of returning false. Only a missing contract or a failed RPC call means the signature could not be checked. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
RemoteConfigTracker can be given smart-wallet signers (e.g. guard wallets) and a provider per chain. For the chain a status is computed for, it reads each signer's externalImageHash() and passes it as signerConfigs to ConfigUpdates and Migrations. Account.status passes its chain to the tracker. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Agusx1211
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Use signatures that are valid on the chain where they will be used.
Ask the key machine for the right signature. Some signers are wallets whose signing key can change. After such a change, the key machine keeps a new signature next to the old one for each saved update, and a chain accepts one or the other depending on whether that signer wallet has changed its key there yet. The key machine client can now read, for the target chain, which configuration each such signer wallet uses (its
externalImageHash()), and send it along. The key machine then returns the signature that works on that chain.Accountpasses its chain when it loads saved updates. Apps opt in by listing the signer wallets and giving a provider per chain; without that, nothing changes.Pick a valid signature from Arweave. Saved updates and migrations are also mirrored on Arweave, where a signer can have several signatures for the same payload. The Arweave reader kept the oldest one. It can now check each signature on the chain it belongs to and use the newest one that is valid. Migrations are checked against their transactions digest. A signature that can't be checked (no provider, no contract code yet, network error) is preferred over one that was checked and is invalid. Without providers, the reader uses the newest signature.
Details
RemoteConfigTrackeroptions:signerWallets,providerFor(chainId). Key machine reads gain an optionalsignerConfigsfield.ArweaveReaderoption:validationProviders(chainId). Signatures that work on every chain use the provider returned for chain id 0.ConfigTracker.loadPresignedConfigurationtakes an optionalchainId; wrapper trackers pass it through.Tests