How Is MPC Signing Different from Multiple Approvals?

An employee requests a transfer, and a team lead and a manager approve it in turn. If a server then signs the transaction with a single private key it holds, several people have approved the business action, but the cryptographic authority to produce a signature remains concentrated wherever that key is used.

An MPC wallet distributes this signing authority among several participants. The interesting question is how the computation works, rather than how many approval screens there are. How can two out of three people produce one valid signature without assembling the complete private key in one place?

Using a 2-of-3 wallet that sends 10 tokens, we will follow the process from secret sharing and distributed key generation to joint ECDSA signing. Small numbers illustrate the mathematics, and BXB's user-participation MPC flow connects those ideas to an implementation.

One transfer, two separate requirements

Suppose address A holds 100 units of token T on an EVM network, and address B holds none. The transaction sends 10 T from A to B. If it succeeds, A will have 90 T and B will have 10 T. Assume T has zero decimal places, with no minting, burning, token transfer fees, or concurrent transactions. A also has the native currency needed to pay the transaction fee.

A's signing authority is distributed among participants P1, P2, and P3. Any two of the three must cooperate to produce a signature. This condition is called 2-of-3. Address A and participant P1 are different concepts. A is one account as seen by the chain; P1 is a party that participates in computing signatures for that account.

The business application still needs an approval process that answers, "May this transfer proceed?" MPC adds another requirement: "Have enough participants actually taken part in the computation to produce a signature?" Recording two business approvals in a database does not, by itself, produce an MPC signature.

Design	Where signing authority resides	What the chain checks
Multiple approvals, then signing with one key	Wherever the final signing key is used	One signature
Contract multisig	Several independent keys and the contract's conditions	Multiple signatures and execution conditions
Threshold ECDSA	Participants' secret shares and their joint computation	One ECDSA signature

Here, multisig means the common design in which a contract checks signatures from multiple owners. With threshold ECDSA, the chain does not count signatures from individual participants. The key property is that the result of the joint computation is verified in the same way as an ordinary ECDSA signature.

MPC stands for Multi-Party Computation, a category of techniques that lets multiple parties compute together without revealing their private inputs. Its application to jointly computing signatures is called threshold signing, or TSS (Threshold Signature Scheme). The name MPC alone therefore does not specify a curve, participant count, number of communication rounds, or security conditions. NIST's explanation of threshold cryptography likewise discusses distributing both keys and operations.

Key shares are not password fragments

First, let us use small numbers to construct a rule under which two shares are enough and one is not. To keep the arithmetic simple, we work with remainders after division by 17, written as $\bmod 17$. This example does not reproduce the large numbers or security strength of a real wallet.

Set the secret to $x=5$ and construct a linear polynomial with a randomly chosen slope of 3.

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

The secret is the value at $u=0$. Each participant receives the value at a different point.

Participant	Input $u$	Received value $f(u)$
P1	1	8
P2	2	11
P3	3	14

Using P1's and P2's values, we can recover the secret as follows.

$$x=2\times 8-11=5\pmod{17}$$

The two points determine a line, and we find its value at $u=0$. Choosing P1 and P3, or P2 and P3, recovers the same secret. By contrast, the single point $(1,8)$ known to P1 does not determine both the slope and the intercept. With an appropriately random choice of slope, every candidate secret has a corresponding line through that point.

This is the starting point of Shamir secret sharing. To require $m$ participants to recover the secret, use a polynomial of degree $m-1$. A 2-of-3 scheme uses degree 1; a 3-of-5 scheme uses degree 2. Here, $m$ is the minimum number required, distinct from the total number $n$.

This example shows the mathematical relationship between the shares. It does not mean that MPC signing reconstructs the private key with this calculation and loads it onto a server. Enough shares can reconstruct the secret, but a threshold signing protocol is designed to perform the required operations while each participant keeps their own share. Being able to reconstruct a key and reconstructing it during signing are different things.

Generating a key without first assembling it

In the preceding example, someone knew the secret 5 and distributed values from the polynomial. If that party knows a real wallet's private key from the outset, authority can be concentrated at the generation stage. Distributed Key Generation, or DKG, changes this step so that the participants generate the key together.

In a simplified 2-of-3 model, each participant $P_j$ randomly chooses two values $a_j,b_j$ known only to that participant and constructs a polynomial. Below, $q$ is a large prime used in computations on secret values. In ECDSA, it is the order of the curve's base point: the number of times the point must be added to reach the identity element.

$$f_j(u)=a_j+b_j u\pmod q$$

P1 evaluates its polynomial and privately sends $f_1(2)$ to P2 and $f_1(3)$ to P3. P2 and P3 do the same. Each participant $P_i$ adds its locally computed $f_i(i)$ to the values $f_j(i)$ received from the others to obtain its final share $\sigma_i$.

$$\begin{aligned} \sigma_i&=\sum_{j=1}^{3}f_j(i)\pmod q\\ x&=\sum_{j=1}^{3}a_j\pmod q \end{aligned}$$

The second line mathematically defines the shared private key $x$ generated this way. There is no need for a server to receive and add $a_1,a_2,a_3$. Each participant ends up with its own share $\sigma_i$.

The public key can be constructed by adding values that can be made public. Let $G$ be the elliptic curve's base point. Each participant publishes $a_jG$, and these points are added to obtain the shared public key $Q$.

$$Q=\sum_{j=1}^{3}a_jG=xG$$

The value $a_jG$ is a point on the elliptic curve, not $a_j$ itself. With an appropriate curve and parameters, the discrete logarithm assumption says that recovering $a_j$ from this point is hard. Being able to add public keys does not mean the private key has been disclosed.

One problem remains: what if P1 sends inconsistent values to P2 and P3? Verifiable Secret Sharing, or VSS, lets recipients check whether the values they received match the committed polynomial. In a simple model using commitments to the coefficients, P1 publishes $C_{1,0}=a_1G$ and $C_{1,1}=b_1G$. P2 checks the following relationship using its received value.

$$f_1(2)G=C_{1,0}+2C_{1,1}$$

A commitment is information used to check later claims about a secret value without directly publishing that value. This check establishes consistency between the value P1 sent and the published coefficient commitments. A real DKG protocol needs additional procedures, including authenticated communication, proofs, and handling of misbehaving participants. The equation illustrates how consistency between secret shares is checked; it is not a complete specification for implementing DKG. Feldman's VSS paper provides foundations for these checks, while research on distributed key generation addresses the conditions needed when participants may act maliciously.

What must be computed together in ECDSA signing

Once the key is distributed, the participants need to sign a transaction. ECDSA is a digital signature scheme based on elliptic curves. Let the shared private key be $x$, the public key be $Q=xG$, and $z$ be the integer derived from the hash of the message to be signed. Choosing a secret value $k$ for this signature in the range $1\le k<q$ gives the following basic signing equations.

$$\begin{aligned} R&=kG\\ r&=\operatorname{xcoord}(R)\bmod q\\ s&=k^{-1}(z+rx)\bmod q \end{aligned}$$

Here, $\operatorname{xcoord}$ means the x-coordinate of a point on the curve. The modular inverse $k^{-1}$ is a value that gives a remainder of 1 when multiplied by $k$. The signature consists of two integers $(r,s)$, which must satisfy $1\le r,s<q$. The value $k$ is the secret nonce needed for each signature. It is different from the public transaction nonce that tracks an account's transaction sequence.

The verifier does not need to know the private key or $k$. It computes $w=s^{-1}\bmod q$ and then the following point.

$$V=(zw)G+(rw)Q$$

For a correct signature, $V=kG$, so its x-coordinate modulo $q$ matches $r$. Actual verification also checks the signature's range and the validity of the public key and points. These signing and verification relationships are described in FIPS 186-5, which specifies ECDSA.

Threshold ECDSA must ultimately produce $(r,s)$ that passes this same verification. The difference is that no single participant holds all the secret inputs to the signing equation. Participants use the distributed $x$ and, according to the protocol, also distribute the signing secret and intermediate computations.

Why not sign with each share and add the signatures?

Each of the two selected participants can multiply its share by a weight. In our small example, P1's weight was 2 and P2's was $-1$. Writing these interpolation weights as $\lambda_i$, the following relationship holds for the set $S$ of signing participants.

$$x=\sum_{i\in S}\lambda_i\sigma_i\pmod q$$

Each participant can work with its own weighted value, so addition is relatively straightforward to distribute. But ECDSA's $s=k^{-1}(z+rx)$ includes an inverse and multiplication involving secret values. Having each participant produce a complete ECDSA signature with an independently chosen nonce and then adding those signatures does not produce a signature for the shared public key. They must construct a common $r$ and compute the intermediate values needed for multiplication and inversion without exposing $k$ or $x$.

The difficulty with multiplication becomes clear when we express each secret as two additive shares.

$$\begin{aligned} (a_1+a_2)(b_1+b_2) &=a_1b_1+a_2b_2\\ &\quad+a_1b_2+a_2b_1 \end{aligned}$$

If each participant computes only the product of its own shares, $a_1b_1$ or $a_2b_2$, the cross terms involving the other participant's shares are missing.

One technique used here is MtA, short for Multiplicative-to-Additive. For a secret $a$ held by one participant and a secret $b$ held by another, the two compute results $\alpha,\beta$ that they hold separately and that satisfy the following relationship.

$$\alpha+\beta=ab\pmod q$$

Rather than receiving the other participant's secret and multiplying it directly, they obtain the product as distributed additive shares. An encryption scheme such as Paillier, which supports addition and multiplication by a known constant on encrypted values, can be used in this process. The participants compute with encrypted values and random masks, leaving each with only a share of the result.

Implementing this short equation alone does not produce a secure MtA protocol. Paillier and elliptic curve computations operate over different domains, and a malicious participant might supply an out-of-range value or a malformed ciphertext. Real protocols therefore include additional mechanisms such as range proofs and zero-knowledge proofs. A zero-knowledge proof establishes that a specified relationship holds without revealing the secret.

Inversion can also be understood through a masked product. Suppose the participants prepare a distributed random secret $\gamma$ so that no one knows its complete value, and jointly compute $\delta=k\gamma\bmod q$. Both $k$ and $\gamma$ must be nonzero. With an appropriately generated random mask, they can reveal only $\delta$ and use the following relationship.

$$k^{-1}=\delta^{-1}\gamma\pmod q$$

Each participant can compute the inverse of the public value $\delta$. Multiplying each additive share of $\gamma$ by the public value $\delta^{-1}$ therefore produces additive shares of $k^{-1}$. This is an outline for understanding secret inversion; a secure protocol must supply the proofs required for mask generation, multiplication, and disclosure. Gennaro's explanation of threshold ECDSA presents this algebraic construction, and the related paper provides more detail on the joint computation.

Communication rounds in threshold ECDSA exchange these intermediate values, commitments, and proofs. Even when a final step combines signature shares, joint computation is needed beforehand. The number of rounds and the use of precomputation vary by protocol; the name MPC does not imply a fixed round count.

Why must a signing nonce be used only once?

Incorrectly reusing the signing secret $k$ can undermine the protection offered by distributing the key. Suppose two different hashes $z_1,z_2$ are signed with the same private key and the same $k$. The two signatures have the same $r$ and satisfy the following relationship.

$$s_1-s_2=k^{-1}(z_1-z_2)\pmod q$$

If the difference between the two hashes is not a multiple of $q$, so the required inverse exists, the two public signatures allow the following calculation.

$$\begin{aligned} k&=(z_1-z_2)(s_1-s_2)^{-1}\bmod q\\ x&=(s_1k-z_1)r^{-1}\bmod q \end{aligned}$$

The complete private key $x$ is exposed. Secure nonce generation and management of one-time material are therefore as important as storing key shares securely. An interrupted signing session does not mean its intermediate values can be reused arbitrarily for the next message. Different precomputed values serve different purposes, so the protocol's conditions determine which material can be reused.

The equations so far explain the computational relationships and security conditions that threshold signing must satisfy. They are a way to understand why an implementation needs substantial computation and communication beyond storing shares, rather than a procedure for implementing a cryptographic protocol from scratch.

Where does BXB perform this computation?

In BXB's user-participation flow, a browser extension drives each participant's MPC computation. The cryptographic module runs Go code as WebAssembly and uses the secp256k1 key generation and signing APIs of tss-lib v3.0.0. The curve secp256k1 is used to sign for this EVM account.

A 2-of-3 scheme requires at least 2 participants, but the threshold passed to the library is 1. This API requires threshold + 1 participants. The "required participant count" in business configuration and the cryptographic library parameter should not be assumed to be the same number.

The result of key generation is also more than a single integer. The implementation stores each participant's secret share and the auxiliary material required by the protocol, and separately creates the shared public key and address. The cryptographic module also has a path for constructing and validating precomputed material related to Paillier. To sign, a participant starts a new signing session with its own stored material and the list of participants selected for that session. The earlier $\sigma_i$ is a mathematical representation used to explain the secret-sharing relationship within this stored material.

The extension then forwards messages produced by the cryptographic module to the other participants and feeds received messages back into the module. This flow does not collect the other participants' complete key shares to sign in one place. Relaying and session coordination keep the communication for this joint computation moving. Authority to relay messages, authority to sign for the wallet, and authority to approve business actions must each be addressed separately in the design.

This description is based on the user-participation key generation and signing flow found in the source code. The DKG and MtA equations above explain the principles; they do not reproduce every round of the product's internal protocol.

From joint signing to one EVM transaction

Return to the transfer of 10 T. Suppose P1 and P2 take part in signing this transaction. The process can be separated into the following steps.

1. Define the business request. The business application determines whose asset is being sent, where it is going, and whether the transfer is permitted.
2. Prepare the transaction to sign. Construct an unsigned transaction containing the network, account nonce, recipient, call data, and fee parameters.
3. Align the inputs to the joint computation. The selected participants use the same signing hash of the prepared transaction as their input.
4. Run the MPC rounds. Each participant computes with its own stored material and exchanges protocol messages to obtain the final $r,s$.
5. Construct and submit the EVM transaction. Check that the expected address can be recovered from the signature, then serialize and submit the transaction including the signature.
6. Check the chain's result separately. Go beyond the submission response to check the execution receipt and the required level of confirmation.

For an ERC-20 transfer, the outer transaction's recipient is the token contract. The actual token recipient B and amount 10 are encoded in the contract call data. The connection between the human-readable instruction "10 tokens to B" and the bytes being signed therefore matters as well. Signing the same hash does not, by itself, prove that each participant correctly understood the transaction's business meaning.

BXB's cryptographic module computes a signature for the supplied hash and returns $r,s$. The extension uses those values and candidate recovery parities to recover an address, then constructs the signed EVM transaction using the result that matches the expected wallet address. The chain receives one account signature, rather than two separate signatures from P1 and P2.

Here, the signing hash and the hash of the submitted transaction are different. The former identifies the content to be signed; the latter identifies the transaction including its signature. Obtaining either hash alone is not enough to conclude that the token transfer succeeded. Execution and confirmation must be checked before we can close the example with balances of 90 T for A and 10 T for B. A separately pays the native currency fee consumed by the transaction. MPC distributes signing authority; gas sponsorship is a separate design choice.

The process of selecting a wallet for a customer account and authorizing key use is explained in BXB's connection between customer accounts and signatures. Applying MPC adds joint computation by multiple participants at the signing stage of that connection.

What changes when one participant goes offline?

Even if P3 cannot connect, P1 and P2 can form a new signing session that satisfies the 2-of-3 condition if both are available. But if a session selects P1 and P2 and P2 stops participating, P1 cannot finish the signature alone. The fact that P3 is still available does not mean it can simply be inserted into the ongoing computation. The participant set and session material must be handled again according to the protocol.

If the process stops before producing a signature and no transaction is submitted, that attempt incurs no on-chain fee, and the balances remain 100 T for A and 0 T for B. If the transaction was already submitted but its response was lost, the situation is different: first check whether it may have executed on-chain. Completion of the business request, completion of joint signing, and completion of on-chain execution are distinct states.

A 2-of-3 condition also does not mean a transfer can be prevented if two participants collude. The setting means that two participants with the required secret material can cooperate to sign. If one operator controls all three participants' devices and backups, the intended separation of authority is weakened. Participant authentication, independent storage, business policies, and audit records need to be designed together.

MPC changes the cooperation required to produce a valid signature. In our example, P1 and P2 produce one ECDSA signature without collecting the complete private key in one place. The business application decides whether the transfer is permitted, and the chain verifies the signature and transaction before changing state. Connecting these three roles makes it possible to distribute the authority that actually moves assets, beyond merely recording that two people approved a request.