ERC-5719 Signature Replacement: Stale Smart-Wallet Signatures After Owner or Policy Changes

The problem ERC-5719 is trying to solve

An externally owned account usually signs with a private key. If the message digest and signature remain unchanged, ordinary ECDSA verification is generally deterministic: the recovered signer does not change because the account later updated an application setting.

Smart-contract wallets work differently.

A contract wallet can implement isValidSignature under ERC-1271 and decide whether a signature is valid according to contract state, external calls, signer sets, thresholds, time conditions, modules, policy data, or signature format.

That flexibility is essential for multisigs and programmable accounts. It also means signature validity is not necessarily permanent.

A protocol can receive a valid signature at 09:00 and discover at 10:00 that the same bytes no longer pass ERC-1271 validation.

The user may not be online anymore. The wallet interface that originally created the signature may not be available. An off-chain order could be waiting for settlement. A marketplace intent could still be economically relevant. Requiring another interactive signature can therefore make some workflows fail unnecessarily.

ERC-5719 proposes a way for the smart wallet itself to advertise where a client can obtain a replacement signature for the same digest.

ERC-1271 is the foundation

ERC-5719 requires ERC-1271 because the client needs an authoritative way to ask a contract wallet whether a signature is valid.

ERC-1271 defines isValidSignature(bytes32 hash, bytes signature). A conforming contract returns a designated magic value when the signature is valid for the supplied hash.

The crucial feature is that the wallet contract controls the validation logic.

The wallet can verify one ECDSA owner.

It can verify several owners and a threshold.

It can verify a BLS or custom signature scheme.

It can consult another contract.

It can enforce time-based or role-based rules.

It can use current storage to decide whether the signer represented by an old signature is still authorized.

That makes ERC-1271 much more expressive than simple ECDSA recovery, but it also makes validation state-dependent.

EOA signatures and smart-wallet signatures have different persistence assumptions

What a stale smart-wallet signature actually means

A stale signature is not automatically malicious, revoked, expired, or malformed.

It means the signature bytes no longer satisfy the wallet's current ERC-1271 validation logic for the relevant digest.

That distinction matters.

The original signed intent may still be acceptable to the account under current policy, but the old representation is no longer enough to prove that authorization.

For example, a multisig signature can contain signer-specific proof material. If the signers are stored in a Merkle tree and the tree changes, the old Merkle path can become obsolete even though the signer remains authorized. The wallet can generate or expose a new proof path without asking the user to sign the underlying message again.

ERC-5719 is designed for this kind of non-interactive replacement.

Why smart-wallet signatures become stale

The ERC identifies several concrete causes.

A signer that contributed to the original signature is removed

A multisig wallet may originally have Alice, Bob, and Carol as authorized signers. An order is signed with Alice and Bob. Later Bob is removed. Current validation policy may no longer accept the old combination even though the off-chain order still exists.

A Merkle tree of signers changes

Some wallets compress signer membership into a Merkle root. Adding a signer changes the root and can invalidate old membership proofs embedded in or associated with signatures. The underlying signer can still be authorized while the old proof path is stale.

A Merkle tree of signatures changes

A wallet may aggregate or commit to signatures through a tree. Adding signatures can change proof data required to validate a specific signed digest.

The wallet makes signatures expirable

ERC-1271 permits context-dependent validation. A wallet can enforce a signature lifetime. Once that rule says the old signature is invalid, a client cannot treat earlier validity as current validity.

The wallet implementation changes

An upgrade can adopt a new signature schema or validation module. Old bytes that were valid under version 1 may not be valid under version 2. ERC-5719 allows the wallet to point to an updated representation where the same signed digest remains authorized.

The entire ERC-5719 wallet interface is intentionally small

The contract adds one view function:

function getAlternativeSignature(bytes32 _digest)
    external
    view
    returns (string);

The function accepts the digest associated with the stale signature and returns a string containing a URI.

That URI must point to a JSON object containing two fields:

The minimalism is deliberate. The wallet does not need to store every signed digest and every possible signature mutation on-chain.

The contract only needs to tell the client where replacement material can be obtained.

The correct client replacement algorithm

ERC-5719 defines a strict validation sequence.

Signature replacement lifecycle

Before-and-after smart-wallet signature diff matrix

A stale signature is easiest to understand by comparing what can change around the unchanged digest.

The digest must remain the security anchor

ERC-5719 replaces signature bytes for a given digest.

It does not authorize a client to change the message and then ask for a signature that happens to validate.

This is the single most important boundary in the replacement process.

The digest identifies what the user or smart wallet originally authorized.

The alternative signature is only useful if it proves authorization for that same digest under the wallet's current validation logic.

A replacement service must not rewrite the order

If an order digest commits to selling one NFT for 2 ETH, a replacement mechanism cannot legitimately turn it into a digest selling the NFT for 0.2 ETH.

A replacement service must not change recipients

If the message binds a recipient, delegate, spender, or settlement contract, changing that field changes the digest and requires separate authorization.

A replacement service must not change nonce semantics

If the signed protocol uses a nonce for replay protection, ERC-5719 does not bypass that nonce. The underlying protocol still decides whether the digest remains executable.

What the blockHash field proves, and what it does not

The alternative-signature JSON includes a blockHash described as a block on which the signature should be valid.

This can help a client identify the blockchain state associated with the replacement.

It is not itself a cryptographic attestation that the signature is valid.

The client still needs ERC-1271 validation.

State-dependent signatures need state context

If signer membership changed several times, a replacement produced for one state snapshot might not remain valid after another configuration transaction.

Historical validation can be operationally difficult

A client attempting to validate against the state represented by an old block may need an RPC provider capable of historical eth_call at that block. Not every infrastructure setup retains arbitrary archival state.

Current settlement still needs current authorization semantics

A protocol should not assume that evidence of validity at an old block automatically means a transaction is safe to settle now. The underlying protocol and wallet policy determine which state should govern execution.

Why ERC-5719 points off-chain

The proposal intentionally returns a URI rather than returning replacement bytes directly from contract storage.

The rationale is economic and architectural.

A smart wallet may have signed many off-chain messages.

Storing every digest and every possible mutated signature on-chain would be expensive and often unnecessary.

A URI lets the wallet delegate replacement generation or storage to an external system.

A server can re-encode dynamically

If signer membership uses Merkle proofs, a server can compute the current proof path and return a newly encoded signature when requested.

Decentralized storage can publish precomputed replacements

An IPFS resource can contain replacement data without requiring one online centralized API.

The wallet contract remains the trust anchor

The URI's content is not trusted automatically. The smart wallet's ERC-1271 result determines whether the replacement is accepted.

Off-chain replacement introduces availability risk

Moving replacement data off-chain creates a new dependency.

A valid replacement may exist conceptually while the client cannot retrieve it.

Server outage

A centralized alternative-signature endpoint can become unavailable exactly when an order needs settlement.

DNS or hosting failure

The URI can resolve through infrastructure that is unavailable or misconfigured.

Rate limiting

A high-volume settlement engine can exceed API limits during market volatility.

Decentralized content unavailability

An IPFS identifier is useful only when the content remains pinned and retrievable.

Applications depending on ERC-5719 should therefore treat signature replacement as an external availability dependency even though final signature authority remains on-chain.

The off-chain service cannot be trusted by URL alone

A compromised replacement server can return arbitrary bytes.

That does not automatically allow it to forge valid wallet authorization because the client must validate the alternative with ERC-1271.

However, a malicious endpoint can still cause denial of service, excessive retries, tracking, or dangerous client behavior if the integration is weak.

Always validate returned signatures

Never interpret HTTP 200 or valid JSON as proof of wallet authorization.

Validate the response schema

Malformed signature bytes, missing fields, oversized payloads, and unexpected encoding should fail safely.

Limit response size

A client should not allow a replacement endpoint to return unlimited data into memory.

Use network timeouts

One broken URI should not stall a settlement worker indefinitely.

Backend fetchers must treat the URI as untrusted input

ERC-5719 does not prescribe a narrow URI scheme.

That flexibility supports centralized and decentralized storage, but a production client that fetches arbitrary URIs from a server environment should apply normal server-side request forgery defenses.

This is an integration-level risk rather than a special property of smart-wallet cryptography.

Block private network destinations

A malicious wallet contract should not be able to make a backend relayer request cloud metadata endpoints, localhost services, or private infrastructure merely by returning a crafted URI.

Control redirect behavior

A seemingly safe HTTPS endpoint can redirect toward a prohibited network location.

Allow supported URI schemes explicitly

Clients can define which schemes they understand rather than handing arbitrary strings to generic network libraries.

Separate fetch infrastructure

High-value settlement systems can isolate replacement retrieval from private internal networks.

Retry limits are a protocol requirement

The ERC explicitly requires clients to implement a retry limit when fetching alternative signatures.

The standard leaves the exact limit to the client.

This protects against both accidental and malicious loops.

Replacement A can point back to invalid state

The wallet can return an alternative that fails ERC-1271 because provider data is stale.

The endpoint can keep changing signatures

A broken service could return S2, S3, S4, and so on without ever reaching validity.

The same signature is a terminal condition

The ERC says that if the URI returns the same signature again after it has already failed, the signature must be considered invalid.

Retries consume real resources

Each cycle can involve an RPC call, external network request, JSON parsing, historical state lookup, and another ERC-1271 validation.

A finite retry budget prevents one signature from exhausting a relayer or order-processing queue.

ERC-5719 is not a signature revocation registry

The standard does not define a universal revokeSignature function.

It does not provide a global list of revoked digests.

It does not guarantee that every stale signature deserves a valid replacement.

Current ERC-1271 validation remains authoritative.

If the wallet deliberately decides that a digest should no longer be authorized, the proper outcome can simply be that no valid replacement exists.

Replacement is not guaranteed

When getAlternativeSignature fails, the URI is unusable, or every alternative fails validation, the client must treat the signature as invalid.

Invalidity can be intentional

An owner change may deliberately invalidate an old order because the new wallet policy should not honor it.

Applications still need their own cancellation semantics

Off-chain order books commonly use nonces, order cancellation, expiry, filled-state tracking, or other protocol rules. ERC-5719 does not replace those mechanisms.

ERC-5719 does not define a universal signature expiry

The ERC lists expirable wallet signatures as one possible reason a signature becomes stale.

It does not standardize how expiry is encoded.

A wallet can make its ERC-1271 validation time-dependent.

A signed message can also carry its own application-level deadline.

An exchange order can expire according to orderbook rules.

These are separate layers.

ERC-5719 does not remove replay protection requirements

Signature replacement preserves authorization for the same digest.

If that digest can be replayed repeatedly, replacement does not fix the underlying message design.

Orders need nonce or fill-state protection

An exchange should prevent one valid signed order from being filled beyond its intended quantity.

Permit-style messages need proper domains and nonces

A replacement signature should not become reusable across contracts or chains unless the original digest intentionally allows that.

Chain separation belongs in the digest or validation context

If the same contract-wallet address exists on several networks, applications should ensure the signed message and protocol semantics prevent unintended cross-chain replay.

Replacement must not reset consumed state

S2 is not a new order merely because it contains different bytes from S1. If the digest has already been executed or cancelled, a new signature representation should not resurrect it.

Owner changes are the clearest stale-signature example

A smart wallet's owner can change for legitimate security reasons.

A hardware key can be replaced.

A multisig signer can leave an organization.

A compromised signer can be removed.

An account-recovery process can install a new owner.

Every one of these changes can affect ERC-1271 validation.

Old signatures should not automatically remain valid

If removed signers continue authorizing new actions indefinitely, signer rotation would not provide meaningful containment.

Replacement should represent current authorization

If the current owner set still wants to honor an old digest, an alternative signature can encode authorization under the new signer configuration.

Some digests should die with the old owner

A takeover recovery can deliberately invalidate all pre-compromise off-chain orders. In that situation a replacement service should not manufacture continuity merely because it is technically possible.

Multisig threshold changes can invalidate otherwise legitimate signatures

Imagine a wallet with five signers and a two-of-five threshold.

An off-chain intent is signed by Alice and Bob.

The organization later raises the threshold to three-of-five.

The old two-signature bundle may no longer pass ERC-1271.

The message digest has not changed.

The organization's policy has.

If the new policy still wants to honor that intent, ERC-5719 can provide a three-signer replacement without requiring the downstream protocol to understand the wallet's internal signature mutation scheme.

Merkle-based wallets are a strong use case for non-interactive mutation

Merkle structures allow large signer or signature sets to be represented compactly on-chain.

The root is stored in wallet state.

A signature can carry a proof path showing membership under that root.

When the tree changes, the proof path can become stale.

The signer does not necessarily need to create another cryptographic signature over the message.

A server that knows the updated tree can generate the current membership proof and re-encode the wallet signature.

This is exactly the kind of mutation ERC-5719's off-chain URI can support efficiently.

Implementation upgrades can change signature schemas

Upgradeable smart wallets introduce another source of signature drift.

Version 1 can parse a signature as a concatenation of ECDSA signatures.

Version 2 can use a modular validation envelope with signer identifiers and proof data.

Old messages do not need to become economically meaningless merely because the wallet improved its verifier.

ERC-5719 creates a compatibility bridge if the wallet can generate a replacement that current ERC-1271 logic accepts for the old digest.

Upgrade authority remains a major trust assumption

A malicious wallet upgrade could change isValidSignature to accept unauthorized signatures.

ERC-5719 cannot make a compromised validator safe.

Replacement should not hide dangerous semantic changes

If version 2 interprets a digest differently from version 1, blindly replacing signatures can create security ambiguity. Message-domain semantics must remain consistent.

Off-chain order settlement is the canonical application pattern

The ERC specifically highlights exchanges with off-chain order books.

A user signs an order while online.

The exchange stores it.

Hours later a matching order appears.

The user is offline.

Before settlement, the exchange validates the smart-wallet signature through ERC-1271.

If it remains valid, settlement proceeds normally.

If it fails because the wallet changed configuration, the exchange can request an alternative signature.

The exchange validates the alternative.

Only then does it consider executing the original order.

This avoids requiring the trader to wake up and re-sign merely because the wallet's proof encoding changed.

Signature validity is only one settlement condition

A valid ERC-5719 replacement does not prove that settlement is still economically or legally correct.

The order may have expired

Application-level expiration can make the digest unusable even if ERC-1271 accepts the replacement.

The order may have been cancelled

A nonce bitmap, cancellation registry, or account state can invalidate execution.

The order may already be filled

Replacement must not bypass fill tracking.

The account may lack assets

Signature validity does not guarantee sufficient token balance or approval at settlement time.

The destination contract may have changed state

Protocol pauses, upgrades, or risk limits can make execution unsafe or impossible.

Token allowances remain completely separate

ERC-5719 deals with smart-wallet message signatures.

It does not modify ERC-20 allowances.

If an off-chain order requires a settlement contract to transfer tokens, the wallet may also need an allowance or another transfer authorization.

A replacement signature can become valid while the allowance remains zero.

An allowance can remain unlimited while the signed order becomes invalid.

The two surfaces must be reviewed independently.

TokenToolHub's Crypto Approval Risks guide explains how spender authority can persist independently of message-signature validity.

For Permit2-specific authorization, the Permit2 and Allowances guide covers nonce, expiration, spender, and token-permission risks that ERC-5719 does not replace.

Clear signing still matters before the original signature exists

ERC-5719 can preserve a smart-wallet signature after technical staleness.

It cannot repair bad intent.

If the user originally signed a malicious order, dangerous Permit message, misleading governance action, or phishing payload, generating a technically valid replacement only preserves that mistake.

The original signing experience therefore remains the first security checkpoint.

TokenToolHub's Clear Signing in Crypto guide explains why wallets should display the actual action, domain, target, value, expiry, and consequences of a signature rather than asking users to approve opaque bytes.

Hardware signing protects the original credential, not the replacement service

Hardware wallets remain useful for protecting root signing keys used by multisigs and smart accounts.

A device such as Ledger can keep a primary private key isolated from the browser or settlement software while the smart account handles ERC-1271 validation.

An air-gapped workflow such as Keystone can similarly reduce direct key exposure for signers participating in smart-wallet authorization.

Neither device secures an ERC-5719 replacement endpoint automatically.

The replacement system can fail, leak signatures, or return invalid data even though the original signer key was never compromised.

The client still needs ERC-1271 verification.

ERC-5719 can be incompatible with signatures treated as secrets

The official security considerations highlight one specific risk: some applications use signatures as secrets.

ERC-5719 exposes alternative signatures through a URI.

If possession of a signature itself grants hidden access and the signature was expected to remain confidential, publishing it through a retrievable endpoint can leak that secret.

Most blockchain authorization assumes signatures are observable

Transaction signatures and many off-chain orders eventually become public or are shared with relayers.

Some application designs use signed bytes as bearer secrets

A private invitation, one-time authentication artifact, download credential, or hidden authorization token can rely on secrecy rather than only cryptographic validity.

Do not adopt replacement blindly

If confidentiality is part of the security model, designers need an authenticated retrieval mechanism or a different replacement architecture rather than publishing bearer credentials openly.

Caching alternative signatures requires careful invalidation

A replacement signature that is valid at noon can become stale again at 12:05.

That means caching is a performance optimization, not a permanent validity certificate.

Cache by digest and wallet context

Mixing replacements between accounts or digests is an obvious critical failure.

Associate state context

The returned blockHash can help identify when the replacement was expected to be valid.

Revalidate before use

A settlement engine should call ERC-1271 near actual execution rather than trusting an old cache entry indefinitely.

Invalidate after wallet configuration changes

Owner, module, implementation, or policy changes can make cached alternatives stale immediately.

Why returning the same invalid signature must terminate replacement

The ERC explicitly calls out one loop condition.

If the replacement URI returns the same signature that already failed validation, the client must consider it invalid.

There is no reason to keep validating identical bytes against unchanged state and expecting a different result.

This rule also prevents a naive client from entering a replacement loop where getAlternativeSignature always points back to the original stale signature.

Chain context is not a top-level ERC-5719 argument

getAlternativeSignature receives only a digest.

The smart wallet contract itself exists on a specific chain, so calling the interface is already chain-contextual.

Applications still need careful domain separation.

The same wallet address can exist on multiple chains

Deterministic deployments and account abstraction make repeated addresses increasingly common.

The same digest can theoretically exist on several networks

If the signed message does not include chain-specific domain data, cross-chain replay can become possible.

ERC-5719 does not add missing domain separation

The original signed protocol must decide which chain, verifying contract, nonce, and context are bound into the digest.

Use transaction decoding when signature replacement leads to on-chain execution

ERC-5719 itself is primarily about obtaining valid signature bytes.

The economically important step often happens afterward when a relayer or protocol submits a transaction using that signature.

TokenToolHub's Transaction Decoder can help inspect the resulting EVM transaction, including contract target, nested calls, token transfers, approval changes, execution trace, fees, and revert behavior.

This separation is useful because a replacement can be cryptographically valid while the final transaction still does something unexpected due to contract state, routing, calldata, or protocol behavior.

Independent ERC-5719 verification workflow

Client and protocol integrator checklist

Smart-wallet builder checklist

User checklist for smart-wallet signatures that may outlive a signer configuration

Incident response when a signer or wallet policy changes unexpectedly

A stale signature can be a normal consequence of account maintenance.

It can also be evidence of compromise.

Worked ERC-5719 security scenarios

Scenario 1: removed multisig signer

A two-of-three wallet signs an off-chain trade with Alice and Bob. Bob later leaves the company and is removed. The trade remains open. When the exchange validates the old signature, ERC-1271 rejects it. The wallet's replacement service returns a new signature bundle from Alice and Carol for the same digest. ERC-1271 accepts the replacement, so settlement can proceed without changing the order terms.

Scenario 2: owner rotation should cancel old orders

A user's root signer is compromised. The smart account recovers to a new owner. The user does not want any pre-compromise orders to remain executable. In this case the safe behavior is for old digests to remain invalid. ERC-5719 must not be treated as a requirement to generate alternatives for every stale signature.

Scenario 3: Merkle proof mutation

A signer remains authorized, but the wallet adds another signer to its Merkle tree. The root changes and the old membership proof embedded in the signature is stale. A replacement server computes the new proof path and returns an updated signature representation. No new human signature over the underlying digest is required.

Scenario 4: upgrade changes signature schema

A smart wallet upgrades from a legacy multisig encoding to a modular validator format. An old marketplace listing still represents a valid intended sale. getAlternativeSignature returns a signature encoded for the new validator. The marketplace accepts it only after current ERC-1271 validation succeeds.

Scenario 5: malicious replacement server

The wallet's replacement API is compromised and returns attacker-created bytes. The client's ERC-1271 validation rejects them. Settlement stops. The server can cause denial of service, but it cannot forge current wallet authorization merely by controlling the URI response if the client verifies correctly.

Scenario 6: client trusts JSON without ERC-1271

A marketplace fetches the alternative-signature JSON and treats the returned signature as authoritative. The replacement server is compromised. The marketplace now accepts a forged signature because it skipped the only authoritative validation step. This is an integrator failure, not a limitation of the cryptographic idea.

Scenario 7: infinite replacement loop

A broken endpoint alternates between two invalid signatures. A naive client repeatedly fetches, validates, and retries without a limit. Settlement workers become exhausted. A compliant implementation defines a finite retry count and fails the signature after that budget is consumed.

Scenario 8: same stale signature returned

The endpoint returns S1, exactly the signature that already failed. The ERC instructs the client to consider the signature invalid instead of retrying identical bytes forever.

Scenario 9: valid replacement but cancelled order

The alternative signature passes ERC-1271, but the order nonce was cancelled on-chain yesterday. The exchange still rejects settlement because signature validity does not override protocol cancellation state.

Scenario 10: valid replacement but expired order

The smart wallet accepts S2 for the digest, but the order includes a deadline that passed ten minutes ago. Replacement preserves signature validity, not economic executability.

Scenario 11: valid replacement, insufficient allowance

A DEX order has a valid ERC-5719 replacement, but the user's token allowance to the settlement contract was revoked. The settlement transaction fails or is rejected before submission. Signature and allowance are independent requirements.

Scenario 12: old blockHash misunderstood

An endpoint says the alternative is valid at a particular historical block. A client assumes this means it remains valid forever. The wallet's signer policy changes again. Current ERC-1271 rejects the signature. The block hash was contextual information, not a permanent guarantee.

Scenario 13: cross-chain digest reuse

The same smart-account address exists on two networks and an application signs a digest without adequate chain-domain separation. ERC-5719 does not repair the message design. Replacement signatures can still participate in the same cross-chain replay risk as the original digest.

Scenario 14: confidential signature leak

An application incorrectly treats a signed message as a secret bearer credential. The wallet publishes a replacement through a publicly retrievable URI. Anyone able to discover the URI can obtain the credential. The official ERC security section specifically warns that signature replacement can leak secrets in designs that depend on signature confidentiality.

Scenario 15: backend SSRF through malicious wallet URI

A settlement service accepts signatures from arbitrary contract wallets. One malicious wallet returns a URI pointing to an internal cloud metadata address. The backend fetcher follows it. A hardened client restricts network destinations and URI schemes so signature replacement cannot become an internal-network request primitive.

ERC-5719 risk matrix

How ERC-5719 fits broader wallet safety

Signature replacement is one piece of a larger smart-account security system.

Users still need secure root credentials.

They still need safe signer rotation.

They still need clear signing.

They still need approval hygiene.

They still need protocol-specific cancellation.

They still need transaction verification.

TokenToolHub's Wallet Safety 101 provides the broader operational framework for separating routine DApp activity, high-value signing, recovery, approval review, and incident response.

ERC-5719 should be understood as a compatibility tool inside that larger framework, not as a security system that makes all old signatures safe automatically.

Common ERC-5719 misconceptions

ERC-5719 keeps every old smart-wallet signature valid forever

No. It provides a way to look for an alternative signature. The replacement still has to pass ERC-1271, and no valid replacement is guaranteed to exist.

ERC-5719 replaces ERC-1271

No. ERC-5719 requires ERC-1271. ERC-1271 remains the authoritative validation mechanism.

A replacement signature changes the message

No. The replacement is requested by digest. It is intended to provide different signature bytes for the same signed digest.

The URI response proves the signature is valid

No. The client must validate the alternative signature through ERC-1271.

blockHash makes the replacement permanently valid

No. It indicates a block context on which the signature should be valid. Wallet state can change again.

Signature replacement is token approval replacement

No. ERC-20 allowances and Permit2 permissions are separate authorization systems.

Owner rotation automatically cancels every off-chain order

Not necessarily. Current ERC-1271 behavior and protocol cancellation rules determine whether an order remains usable or can receive a valid replacement.

A valid replacement means settlement must succeed

No. Balance, allowance, nonce, fill state, expiry, protocol pause state, and transaction execution can still prevent settlement.

The replacement service must be decentralized

No. The ERC deliberately uses a URI so both centralized servers and decentralized content systems can be used.

A centralized replacement server can forge wallet signatures by itself

Not if clients correctly validate every replacement through a secure ERC-1271 implementation. The server can still cause availability and data-quality problems.

Retrying forever is safer because a valid replacement might eventually appear

No. The ERC explicitly requires a client retry limit.

Returning the same invalid signature is acceptable

No. The standard says the signature must be considered invalid when the URI returns the same signature after it already failed.

ERC-5719 defines signature expiry

No. Expiry is only one example of why a wallet signature may become stale. The standard does not define a universal expiration field.

ERC-5719 provides a revokeSignature method

No. It does not define a general signature revocation registry or method.

ERC-5719 makes replay-safe message design unnecessary

No. Nonces, domains, deadlines, cancellation, fill tracking, and chain separation still belong to the signed protocol.

A practical way to reason about signature replacement

The replacement problem can be reduced to six questions.

The first question protects signed intent.

The second prevents unnecessary replacement.

The third identifies the wallet's advertised replacement path.

The fourth protects client infrastructure.

The fifth establishes current smart-wallet authorization.

The sixth prevents a cryptographically valid replacement from bypassing cancellation, expiry, fill state, balance, allowance, or other protocol conditions.

Conclusion: ERC-5719 separates signed intent from the signature bytes needed to prove it today

ERC-5719 signature replacement exists because smart-contract wallets can change while their old off-chain messages remain economically relevant.

That is a subtle but important difference from the way many developers first learn to think about signatures.

For a normal EOA, a signature is closely tied to one fixed public key and a deterministic cryptographic verification rule.

For a smart wallet, the contract decides what counts as valid.

The signer set can change.

The threshold can change.

The wallet can expire signatures.

A Merkle root can change.

A module can be replaced.

The entire wallet implementation can upgrade.

Those changes can make old signature bytes fail even when the wallet's current owners still intend to honor the underlying digest.

ERC-5719's answer is deliberately narrow.

Validate the original through ERC-1271.

If it works, stop.

If it fails, ask the smart wallet for an alternative-signature URI associated with the same digest.

Fetch the replacement data.

Validate the replacement through ERC-1271.

If it works, the alternative can stand in for the stale bytes.

If it fails, retry only within a finite budget.

If the wallet returns the same invalid signature, stop.

If no replacement exists, treat the authorization as invalid.

The digest is the boundary that keeps this process honest.

Replacement should repair representation, not rewrite intent.

An exchange cannot change price.

A marketplace cannot change recipient.

A relayer cannot change quantity.

A protocol cannot reset a consumed nonce.

Any change that modifies the signed message creates a new digest and therefore a different authorization problem.

The off-chain URI is also an important design choice.

It lets wallets avoid storing every signed digest and proof mutation on-chain.

Servers can dynamically re-encode Merkle proofs.

Decentralized storage can serve precomputed replacements.

But off-chain retrieval creates availability and infrastructure risk.

Endpoints can disappear.

Responses can become stale.

Attackers can return malformed data.

Backend fetchers can be exposed to malicious URIs.

Broken services can create endless replacement loops.

The standard's mandatory retry limit is therefore not a minor implementation detail.

It is part of safe failure behavior.

ERC-1271 remains the security anchor.

No replacement endpoint should be trusted merely because it returns JSON with a field called signature.

The smart wallet must accept the alternative for the digest.

Even then, protocols need another layer of checks.

A valid smart-wallet signature does not prove an order remains unexpired.

It does not prove the order was not cancelled.

It does not prove sufficient balance.

It does not prove a token allowance remains available.

It does not prove the order was not already filled.

It does not prove the eventual transaction will execute successfully.

Signature validity is one predicate inside a larger settlement policy.

This is also why token approvals must stay conceptually separate.

The Crypto Approval Risks guide covers persistent spender relationships that can remain unchanged while wallet-signature validity changes.

The Permit2 and Allowances guide covers another reusable authorization layer with its own nonce and expiry rules.

The original message also needs to be understandable when the user signs it. TokenToolHub's Clear Signing in Crypto guide explains that security checkpoint.

And when a replacement signature eventually results in an on-chain settlement transaction, the Transaction Decoder can help verify what actually happened rather than assuming signature validity describes every downstream call.

From a user perspective, the key lesson is equally important.

Changing the owner of a smart wallet does not automatically answer what should happen to every message signed before the change.

Some intents should survive.

Some should be cancelled.

Some are merely technically stale and can be re-encoded.

Some were created during compromise and should never receive replacements.

The account and application need explicit policy around those cases.

ERC-5719 is best understood as a compatibility mechanism, not a blanket continuity promise.

Its safest mental model is:

When clients preserve the digest, validate every alternative through ERC-1271, enforce bounded retries, harden URI retrieval, and separately check the underlying protocol state, signature replacement can keep long-lived smart-wallet workflows usable without weakening the account's ability to rotate signers and upgrade security policy.

FAQs

References and further reading

These official Ethereum resources provide the primary technical basis for smart-contract signature validation, signature replacement, and the broader security direction of programmable accounts.

• ERC-5719: Signature Replacement Interface
• ERC-1271: Standard Signature Validation Method for Contracts
• Ethereum Improvement Proposals and ERC Standards
• Ethereum.org: A More Secure Ethereum

ERC-5719 is currently marked Stagnant and is not universally implemented by smart wallets or signature-consuming applications. ERC-1271 remains the authoritative contract-signature validation mechanism. Signature replacement also does not supersede protocol-specific nonce, expiry, cancellation, allowance, settlement, or transaction-validation rules. This guide is educational security research and is not financial, legal, or software-audit advice.