Can an MPC Wallet Stay the Same When Its Participants Change?

An employee who manages an institution's wallet moves to another department. Does bringing in a replacement also require a new wallet? If the institution must change the deposit address it has given customers and move the assets it already holds, a staffing change becomes an asset migration.

An MPC wallet can keep its shared key while redistributing the secret material held by the participants who use it. This is called key-share resharing. Our goal here is to keep the same public key while changing who participates in signing and what each participant stores.

We will replace P3 with P4 in a wallet that requires two out of three participants. The computation that avoids reconstructing the secret in one place and the process of putting the new shares into operational use are separate parts of the task.

1. Changing participants without moving tokens

Address A holds 90 units of token T, and address B holds 10 T. This is the state after A sends 10 T to B in part 1's explanation of MPC joint signing. If you are starting here, all you need to know is that P1, P2, and P3 share signing authority for A, and any two must cooperate to produce a signature. We write this as 2-of-3. The minimum required is $m=2$, and the total number of participants is $n=3$.

Suppose P1 and P2 can still use their existing material, and P4 will take P3's place. The new group of P1, P2, and P4 will still require two out of three participants. A participant label such as P1 and a blockchain address such as A are different kinds of identifiers. Changing the person responsible does not rename the account's address.

Item	Before replacement	Target after replacement
Participants	P1 · P2 · P3	P1 · P2 · P4
Minimum required	2	2
Wallet address	A	A
T balances	A90 / B10	A90 / B10

We retain the assumptions that T has zero decimal places and that there is no minting, burning, token transfer fee, or concurrent transaction. This operation submits no new token transfer. Resharing itself does not change on-chain balances, and this resharing incurs no on-chain transaction fee. The service's communication and computation costs are separate operating expenses.

2. Two old shares are the starting point for the new ones

Let us use small numbers to see how this works. All calculations use remainders after division by 17, written as $\bmod 17$. These values do not reproduce a real wallet's key or security strength. This is an illustrative example that even reveals the secret so we can see the relationships.

The existing secret is $x=5$, and the polynomial used to share it is:

$$f(u)=5+3u\pmod{17}$$

Here, $u$ is a coordinate assigned to a participant for the computation. Give P1, P2, and P3 coordinates 1, 2, and 3, respectively. Their shares are $f(1)=8$, $f(2)=11$, and $f(3)=14$. Each participant stores only their own share. The secret is the polynomial's constant term, $f(0)$.

For P1 and P2, the relationship to the original secret is:

$$\begin{aligned} x&=2f(1)-f(2)\\ &=2\times8-11\\ &=5\pmod{17} \end{aligned}$$

The coefficients 2 and $-1$ are interpolation weights that recover the constant term from these two coordinates. The key point is that we need not bring the right-hand side to a single server and add it there. P1 multiplies its own share by 2, and P2 multiplies its own share by $-1$.

$$\begin{aligned} c_1&=2\times8=16\pmod{17}\\ c_2&=-11=6\pmod{17} \end{aligned}$$

Each participant knows its own contribution, $c_1$ or $c_2$. The two values add up to 5, but we assign nobody the role of receiving and storing that sum. Instead, each participant shares its contribution among the new participants.

This starting point requires authority over the existing key. If only P1's share remains in this example, P4 coming online does not create the missing second share. Resharing lets participants cooperate using enough existing material; it does not recover every lost secret from an address.

3. Share each contribution again, then add at the receiving end

P1 creates a new linear polynomial with constant term 16, and P2 creates one with constant term 6. Each chooses a new random slope. For this calculation, suppose the slopes are 4 and 3.

$$\begin{aligned} g_1(v)&=16+4v\pmod{17}\\ g_2(v)&=6+3v\pmod{17} \end{aligned}$$

Here, $v$ is the coordinate of a participant receiving a new share. For the new group P1, P2, and P4, we use 1, 2, and 4, respectively. This mapping of coordinates to people is an illustrative choice; it does not represent the product's internal participant numbering or storage order.

P1 calculates $g_1(v)$ for each new participant and sends it privately to that participant. P2 does the same with $g_2(v)$. One person can have both a sending role and a receiving role: P1 calculates its own $g_1(1)$ locally and receives $g_2(1)$ from P2. P4 can receive the values intended for it from both participants without holding an old share.

First, consider P4's calculation.

$$\begin{aligned} g_1(4)&=16+4\times4=15\pmod{17}\\ g_2(4)&=6+3\times4=1\pmod{17}\\ \sigma'_4&=15+1=16\pmod{17} \end{aligned}$$

P4 does not receive P1's old share 8 or P2's old share 11. It receives two newly shared values for its own coordinate: 15 and 1. Adding them gives P4 its new share, 16. The prime in $\sigma'_4$ marks a share after resharing.

Applying the same calculation to all three new participants gives the following results. Every number in the table is a remainder modulo 17.

Recipient	From P1	From P2	New share
P1	3	9	12
P2	7	12	2
P4	15	1	16

P4 is not the only participant to receive new material: P1's and P2's material also changes. Keeping a participant is different from keeping that participant's old share. In this example, P1's 8 becomes 12, P2's 11 becomes 2, and P4 holds the new share 16.

Desmedt and Jajodia's research describes redistribution in which old shares are shared again and recipients apply interpolation weights. Our example applies those weights before sending. Moving where the weights are applied preserves the linear relationship, but this simple calculation is not a complete protocol for dealing with malicious participants.

4. Why does the public key stay the same when the shares change?

The new participants' values lie on the polynomial obtained by adding the two linear polynomials. For illustration, write that combined polynomial as $F(v)$:

$$\begin{aligned} F(v)&=g_1(v)+g_2(v)\pmod{17}\\ &=5+7v\pmod{17} \end{aligned}$$

The old polynomial is $5+3u$, and the new one is $5+7v$. Their slopes and values at each participant's coordinate differ, but both have the value 5 at coordinate 0. Writing the combined polynomial here is also an explanation, not an instruction for a server to collect the two polynomials' secret coefficients.

Check the relationship using the shares of P2 and the newcomer P4. For coordinates 2 and 4, the weights that recover the constant term are again 2 and $-1$.

$$2\sigma'_2-\sigma'_4 =2\times2-16 =5\pmod{17}$$

The two new shares support a calculation corresponding to the same secret. Choosing P1 and P2, or P1 and P4, gives the same result. This interpolation checks the relationship between the shares; it does not mean that the next transaction reconstructs the private key 5 when signing. That signing operation runs the threshold signing protocol using the new shares.

In actual ECDSA, with secret scalar $x$ and curve base point $G$, the shared public key is $Q=xG$. If resharing preserves the same $x$, the public key $Q$ stays the same. On the same network, deriving the EVM address from that same public key also preserves A. The small number 17 only illustrates the relationship; secp256k1 computations use a much larger range of values.

However, writing a string that says "the same public key" in a result does not verify the computation. For example, if P1 sends values from different polynomials to different recipients, the new shares may not form a valid sharing of one secret. The process must address both whether the constant terms are correctly linked to the existing key and whether the values recipients receive agree with the committed polynomials. Research on verifiable redistribution explains the problem of checking these two connections.

Comparing public keys and addresses complements verification of the protocol's proofs. Our numerical example assumes that the participants follow the calculation honestly. A real implementation needs authenticated connections between participants, proofs that check consistency, and error handling. The addition table in this article does not replace all those security conditions.

5. Refreshing shares and resharing to new participants

A refresh gives the same participants new shares. A typical approach adds a random polynomial with constant term 0 to the existing polynomial. Call this additional polynomial $h(u)$. It satisfies:

$$\begin{aligned} h(0)&=0\\ f_{\mathrm{new}}(u)&=f(u)+h(u)\pmod q\\ f_{\mathrm{new}}(0)&=f(0) \end{aligned}$$

Here, $q$ is a prime used in computations on secret values. In practice, a refresh can combine random contributions from several participants. Adding the contribution at each coordinate to the corresponding old share changes the shares while preserving the secret. This is the basic approach explored in research on periodically refreshing secret shares.

But P4 does not hold the old share $f(4)$. Sending it only $h(4)$, a contribution from a polynomial with constant term 0, does not give it a complete new share. Creating a new participant group also requires a process that transfers valid material to that group from parties with enough authority over the existing key.

Our example therefore goes beyond the refresh formula that adds shares of zero to existing shares. It shows P1 and P2 resharing their weighted contributions to P1, P2, and P4. Both approaches can preserve the secret, but they require different inputs and transfers. They also differ from Distributed Key Generation, or DKG, which establishes a new secret in the first place. Here, preserving the existing key is a constraint.

6. BXB runs the old and new roles separately

The BXB path examined here involves user participation in recovering a key that needs recovery. It connects the steps that reshare material held by existing participants to a new participant group. The cryptographic module uses the secp256k1 resharing API in tss-lib v3.0.0. The linear-polynomial example above does not reproduce every operation and round in that library; it is a model that explains why the public key is preserved.

The existing group participating in recovery and the group receiving new shares are different. In our example, the old group P1 and P2 supplies the material, and the new group P1, P2, and P4 receives the result. The implementation distinguishes roles belonging only to the old group, only to the new group, or to both. Overlapping participants such as P1 and P2 take part in both the computation using old material and the computation receiving new material. P4 joins the receiving side without old material. Having the two old participants ready to provide material is not enough to complete the replacement. The browser extension selects the required number from the old group and starts the computation after every member of the new group is ready. P3 can therefore be absent in this example, but the replacement cannot finish with P4 absent from the new group as well.

The cryptographic module rejects a configuration if the old participant count is below the old threshold + 1. Here, the library's threshold is one less than the minimum number of participants. For 2-of-3, threshold=1, so two old participants are required. The service's recovery path involving user participation preserves the total participant count and minimum participation requirement, as in this example. The library accepting a wider range of parameters does not establish that arbitrary changes to participant count or quorum are supported by the product.

When the protocol finishes, participants receiving new shares get material to store along with the shared public key and address. This stored material is more than the single integer in our table: it includes the secret share, auxiliary material needed for later signing, and information tied to the participants. P1 and P2, who remain in the group, must store their new results too. Leaving the old files in place and changing P3's name to P4 on a list cannot replace this process.

The code includes tests for 2-of-3 and 3-of-5 that compare EVM addresses before and after resharing and run a signing session with the new material. These tests provide a basis for checking address preservation and the connection to subsequent signing. They do not mean that this article's P3-to-P4 example was executed with a real wallet or that its result came from sending a transaction to a chain.

7. New shares need updated storage records

Even a successful resharing computation leaves a problem if the next signing session selects material from different generations. Suppose P1 reads its new share 12, while P2 reads its old share 11. They are points on different polynomials. Treating them as two shares from the same generation gives $2\times12-11=13\pmod{17}$ in our example, rather than the intended 5.

A key-share version is therefore more than a label on a screen. It is operational information identifying which wallet's material, created for which participant group, should be used now. The new share, participant list, the participant's own position, and shared public key and address must remain consistently linked. Continuing to use the same address A does not make shares from different periods interchangeable.

BXB's browser extension stores the new material with the resulting address, new participant list, and version. In this recovery storage path, it encrypts the material with a password and updates the local record under the same wallet identifier before reporting completion to the server. Once every new member has reported completion, the server activates the new version and marks the old version's members as unavailable for operational use. Subsequent signing must use material corresponding to the new participant list.

Completion handling also includes a path that compares a submitted shared public key with the existing public key. Comparing public keys is different from the server receiving and independently verifying every participant's secret share. A server state transition should not be read as a substitute for protocol verification or for checking what each device has stored. An operational judgment that "the participant replacement is complete" also requires checking who received the new material, which version was activated, and whether joint computation with the new participants is possible.

We cannot assume that storage on individual devices and progress recorded by the server complete at the same moment. If a new participant disconnects before receiving its result or fails to store it, one success message must not be treated as completion of the entire transition. Each participant's result and current stored state need to be checked, along with any necessary restart or recovery procedure. This explanation does not promise an atomic storage update across every device and the server.

Checking that the new shares can sign is also separate from transferring tokens. A protocol test or a separate verification message can check signing, but its result is not an execution receipt for an actual transfer. This article submits no new transaction, so the balances remain A90/B10.

8. Old material can retain old authority

It is tempting to assume that removing P3 from the new participant list automatically makes every piece of secret material P3 stored useless. But this resharing has not changed the secret itself. If someone retains the old shares 8 and 11 from P1 and P2 together, the old relationship $2\times8-11=5\pmod{17}$ still holds.

If enough material for a quorum from one old generation remains, a new version number does not cryptographically invalidate it. The system refusing requests from an old version is different from eliminating the ability to use the key with old secret material. A chain that accepts valid signatures under the same public key does not distinguish signatures merely because an institution changed its internal staff list.

This does not mean P3's one old share can bypass the 2-of-3 requirement. What matters is how much material remains from each period and whether an old quorum's material could be brought together or used in collusion. Participant replacement therefore also involves retention and disposal policies for old devices and backups, revoking account access, and handling signing sessions already in progress. This is why security discussions of refresh and resharing state assumptions about deleting old material separately. Desmedt and Jajodia's redistribution research also treats those deletion conditions explicitly.

The convenience of keeping an address and the goal of revoking authority under an already exposed key do not always have the same solution. Suspecting that an old quorum's secret material remains outside the institution calls for a different completion criterion from an ordinary staff handover. In that situation, even the decision to keep the same key needs to be reconsidered.

The result of our normal case is not a transfer of assets to a new wallet. P1, P2, and P4 share signing authority for the same A using new material, and the token balances remain A90/B10. What makes this possible is the resharing computation linked to the existing key, not a change of name tags. Putting that computation into operational use requires consistent new stored material, readiness for the next joint signature, and handling of the old material. For the new participants to actually begin the next signing session, they also need communication that keeps their messages within the same session.