Skip to content
Blockchain LabTHE VENTURE STUDIO

BLOCKCHAIN LAB BRIEFING · SECURITY

Retiring a Signer Shrinks a Window. It Does Not Change the Scheme.

If a public key could be recovered only after a delay, taking that address off a Safe’s owner list would shrink the useful window. The contract still treats the change as an ordinary transaction, and a module can ignore the owner list.

Blockchain Lab8 October 20264 min readAll briefings

A mitigation with a boundary

Fig. 01

Shorter authority is not a new signature scheme.
  • The mitigationRetire a disclosed key before a delayed recovery could use it.Rational only while recovery is slower than revocation.
  • The contractOwners and the threshold live in contract storage.Only a Safe transaction can change them.
  • The leftover pathAn enabled module does not check owner signatures.Replacing owners does not switch that path off.

The left column is a threat-model choice. The other two are what Safe’s own documents actually specify. None of them is a claim that ECDSA has been replaced.

Safe docs, Smart Account concepts; swapOwner.

01

What happened

Safe stores its owner list and its threshold in the smart-account contract. Adding, removing or replacing an owner, and changing the threshold, can be done only by a Safe transaction that the current owners approve. The reference is blunt about the call that swaps one address for another: it can only be done via a Safe transaction.

A separate operating idea is now in circulation among people who run treasuries. If an attacker could recover an ECDSA private key from a disclosed public key, but only after a delay, then removing that address from the owner list before the recovery finished would shrink the useful window. That is a mitigation under a stated threat model. It is not a change of signature scheme, and Safe’s documents do not describe owner replacement as a defence against a future break of ECDSA.

02

Why it matters

Changing the key inside a hardware device does not, by itself, retire authority. The old address remains an owner until a transaction updates the contract. Doing the rotation as a second transaction, after the payment the firm actually wanted, leaves an interval in which the old owners are still live. Where the account can do both inside one execution, the payment and the owner change share one confirmation. That is an architectural preference. It is not a switch in the product, and it still has to leave the account controllable at the intended threshold.

Collecting approvals away from the chain is also narrower than the word private. Safe’s signature format is assembled before execTransaction: each approval is encoded, sorted by signer address, and passed in with the call. Gathering them off the chain avoids a separate on-chain approval for every signer. It does not make the collection confidential. Whoever can see the coordination can see the public keys those signatures identify. An ECDSA signature is enough to recover the signer address.

03

The operating layer

For a treasury that wants the shorter window, the work is operational. List which keys are already disclosed and which contracts still authorise them. Confirm the replacement addresses, and the devices that can sign, before any owner is removed. After execution, read the owner list and the threshold back from the contract. A transaction that succeeded is not that reading.

Then look past owners. Safe executes along two paths. Owner-approved calls go through execTransaction, which checks that each signer is a current owner and that the number of valid approvals meets the threshold. An enabled module can call execTransactionFromModule and does not go through owner-signature verification. The concepts page marks modules as security-critical for that reason. Replacing owners is not a review of every path that can move the assets.

Before any funds move

Fig. 02

Read the owner list. Then look past it.
  1. 01Name the keysWhich public keys are already disclosed, and which accounts they still control.
  2. 02Prove the replacementsNew addresses and the devices that can sign, before anyone is removed.
  3. 03Read it backOwner list and threshold, from the contract, after execution.
  4. 04Review modulesAny enabled module can still execute without an owner signature.

A successful transaction hash is not a reading of the final policy. This sequence does not prove a deployment is free of other authorities.

Safe docs, concepts and the owner reference.

04

What is verified

The concepts document states that owners are Ethereum addresses stored on the account, that the threshold is the minimum number of owner approvals, and that adding or removing an owner requires a valid Safe transaction approved by the current owners. swapOwner, addOwnerWithThreshold and changeThreshold each carry the same warning: the action can only be done via a Safe transaction. The signature document states that approvals are sorted by signer address and concatenated for the execution call.

The same concepts document states the second path in plain language. Once a module has been enabled, it can execute through the Safe without owner-signature verification. The help centre treats owner changes like any other transaction: they sit in the queue for the existing policy to confirm. Nothing on these pages equates a new owner address with a new cryptographic assumption.

What the interface specifies

Fig. 03

Four facts that do not share a scale.
  • On-chainWhere the owner list is stored
  • One callswapOwner is itself a Safe transaction
  • Two pathsOwner approvals, and enabled modules
  • Same schemeA new ECDSA key is still ECDSA

These are properties of the interface, not a measurement of how fast a key can be recovered.

Safe docs: concepts, swapOwner, signatures.

05

What remains unclear

Whether a particular wallet interface will bundle an arbitrary payment and an owner swap into one Safe transaction without dropping the threshold or stranding the account. Whether a given deployment has modules, guards or a fallback handler that survive the swap. Safe documents the mechanism. The documents do not certify a firm’s workflow.

How fast an ECDSA key can be recovered from a public key is not settled by these pages. A delayed-recovery assumption can make a short authorisation window rational. If recovery is fast enough to finish while a transaction is still confirmable, rotating to a new key of the same scheme does not close the problem.

06

The catch

Short-lived authority for a disclosed key can matter under a delayed-recovery threat. It is not an instruction to rotate every signer after every movement of funds, and it is not a design that survives a break of the scheme itself. The failure mode closest to hand is the opposite of the cryptography: a rushed reconfiguration that removes an owner before the replacement can sign, or that leaves a module in place and calls the job finished.

Minimise disclosure. Then minimise the time a disclosed key remains authorised. Do not confuse either sentence with a guarantee.

WATCH

What builders should watch

  1. 01Whether the final owner list and threshold, read from the contract, match the policy that was intended.
  2. 02Whether modules and other execution paths were reviewed, not only the owner set.
  3. 03Whether replacement keys were proven on the devices that will actually sign, before the old owners were removed.

BOTTOM LINE

Retiring an exposed signer can shrink a window. It does not retire the scheme, and it does not retire a module.

Sources

The documents are below. A chart is a reading of those documents, not a recommendation to buy or sell anything.

Continue

All briefings