Skip to content
Github

Using New Signers

When a new signer is configured, it's written directly to a single chain. But what if the new signer wants to start sending transactions on another chain? You could sync from the master chain if the setConfig call was executed there, but if the new signer was just added, that master chain block won't settle on L1 for 3.5 days (and up to 10 days in the case of optimistic rollup disputes).

To get make new signers usable immediately, Keyspace supports replayable setConfig calls, which allow a setConfig call from one chain to be replayed on another chain with the same arguments. Since replica chains can be synced from the master chain, any conflicts between the configurations on a replica chain and the latest master chain configuration will be overwritten by the master chain's configuration.

Replay with the New Signer

When the existing signer is updating the configuration, the configuration is updated on a single chain. For the new signer to transact on a second chain, the setConfig call needs to be replayed on that chain. The new signer can be authorized to fund the setConfig call with the wallet's assets by processing the setConfig call during the validation phase of the user operation.

However, if the configuration on a replica chain has diverged from the master chain, it might require a sync before the replay can be performed. A new signer cannot be authorized to fund a sync because syncing violates ERC-4337's validation rules, so someone else needs to initiate the sync. (There are workarounds for ERC-4337 validation restrictions, but we don't expect them to be worthwhile for handling rare divergence scenarios.)

Set, Replay, and Sync via Wallet Vendor

The simplest scenario is when the wallet vendor takes care of setting the new configuration on a chain, replaying it on the desired chains, and syncing divergent replicas when necessary. The wallet vendor uses their own assets to pay for these actions.

A straightforward implementation of this method would have the wallet client send a request to the wallet vendor's backend to initiate the set, replay, and sync operations while the client's desired transaction waits for the wallet vendor's configuration calls to be confirmed in a block. To skip this wait, the wallet vendor can also act as the bundler for their users when a new signer is added. The set, replay, and sync calls would then be called right before the user's user operation within the same transaction.

Set, Replay, and Sync with an Existing Signer

The existing signer can take responsibility for setting the new configuration on the chain the new signer intends to transact on, but the complexity of this operation depends on where the wallet's funds are located.

  1. The simplest scenario is when the wallet has funds on the chain the new signer intends to transact on. In this case, the existing signer can simply call setConfig on that chain.
  2. If the wallet's funds are location on a different chain, the existing signer needs to perform a cross-chain transaction to set the new configuration on the desired chain.
  3. If the new signer wants to transact on a replica chain that has diverged from the canonical configuration history, the existing signer needs to execute a sync and one or more setConfig calls.
    1. If the master chain's configuration is too old to resolve the conflict, the existing signer can execute all the setConfig calls up to the desired configuration on the master chain, then sync the replica chain after the setConfig calls have been confirmed on the master chain.
    2. If the master chain's configuration is recent enough to resolve the conflict, the existing signer can execute a sync and one or more setConfig calls on the replica chain to reach the desired configuration.
    3. In the former case, if the wallet has no assets on the master chain, the existing signer can only set the new configuration via a cross-chain transaction from a replica chain with assets.