One of the most practical techniques in crypto asset management is multi-signature in the Bitcoin network: transfers are confirmed by several participants, and decisions are no longer dependent on a single device or person. For exchange services, this translates into clear rules: who generates the payment, who checks the risk, and who gives the final confirmation.

BoxExchanger describes its software as a universal platform for launching and managing an online exchange with a ready-made website and admin panel. The company states that it was founded in 2017 and is trusted by 250+ services.

What is this mechanism in simple terms?

The key concept here is multi-signature. The crypto wallet sets an M-of-N rule: M confirmations from N participants are required to send funds. The formula provides distributed control: one participant prepares the transfer, the second checks the details, and the third completes the signature.

If you need a short answer to the question of what multi-signatures are in cryptocurrency, it is a threshold cryptographic method that links the spending of funds to several independent signature data. As a result, compromising one signature element no longer means losing control, and the management rules are described by the M-of-N formula. This approach enhances security and makes the distribution of roles transparent.

The English term multisig is often used in professional circles. It is used as a short name for a scheme where funds are managed through a threshold and several signatories.

How joint confirmation works at the network level

In Bitcoin, the mechanism is most often implemented through scripts that are verified when UTXO is spent. Historically, P2SH, standardised in BIP16 and activated by network rules since 1 April 2012, has become a popular method.

In P2SH logic, the script hash is entered into the blockchain, and the script itself is only revealed when spent. For classic Bitcoin multi-signature in 2-of-3 format, the script contains three public signature parameters, and two signatures are applied at the time of spending. P2SH addresses usually start with "3", which helps to quickly distinguish the format.

With the growth of segwit addresses, part of the data is transferred to the witness area, which reduces the virtual size. Bitcoin Optech shows an estimate of the templates: for P2SH 2-of-3, the scriptSig size in the calculator is taken as 254 vbytes, and for P2WSH 2-of-3, the main signature load goes to the witness (63.5 vbytes in the calculator estimate).

What the signing process looks like step by step

From a practical point of view, the operation looks like "draft → signatures → publication". The initiator forms a draft, the verifier checks the amount and destination address, then the signatories add signatures until the M threshold is reached. After that, the transfer is sent to the network as a regular transaction, only with a large amount of signature data.

This model is convenient for dividing responsibilities: one employee sees the request and prepares the payment, another confirms it after risk control, and a third joins as a backup during peak loads or when colleagues are on holiday.

In conjunction with the exchanger, it is convenient to link signatures to request statuses and limits. For example, payments up to a set threshold follow the standard procedure, while large amounts require two independent confirmations and manual verification of details. BoxExchanger provides tools for managing applications, including order statuses, internal comments, and administrator activity logs, as described in the admin panel functionality on the project's official website.

Why do exchangers and businesses need this approach?

The main motive is to reduce the single point of failure. According to Chainalysis, in 2022, the volume of stolen funds reached $3.7 billion, and in 2023, the figure decreased to approximately $1.7 billion, while the number of incidents increased from 219 to 231. These figures reflect the systemic risk of compromised subscription data and operational errors.

The second motive is manageable processes within the team. As the service grows, the roles of operator, risk control, and final confirmation emerge. For an exchange, it is convenient to link this to the request system: one employee generates the payment, and the second confirms it after checking the details and risk.

The description of BoxExchanger's functionality mentions the assignment of a manager to an order, status changes with an action log, comments on requests, validation of details with regular expressions, and AML checks of transactions through integrated modules. All of this supports the "check first, then sign" model.

Limitations and practical compromises

A multi-signature scheme adds data to the transfer, which means it increases the network commission. The difference is especially noticeable in legacy formats: in the Bitcoin Optech calculator for P2SH, 2-of-3 scriptSig is estimated at 254 vbytes because the signatures and script are included in the main body of the transaction.

The example of "1 input + 2 outputs" illustrates the effect on the virtual size. If we take the field sizes from Bitcoin Optech (P2SH input: 36 + 1 + 254 + 4 = 295 vbytes; P2WPKH output: 31 vbytes), the benchmark is about 367 vbytes for the entire transfer: 10 bytes of overhead + 295 input + 62 for two outputs. For P2WSH 2-of-3, the benchmark is significantly lower due to the witness discount: about 177 vbytes (10.5 overhead with segwit marker + 104.75 for input + 62 for two outputs).

The next compromise is related to speed and coordination. Participants need an agreed order of actions: who creates the draft, who confirms the destination address, who stores the backups. In practice, 2-of-3 or 3-of-5 thresholds are popular: they provide a margin for participant readiness and maintain control with multiple signatures.

More about limits and regulations

The limit on public signature parameters for OP_CHECKMULTISIG in the Bitcoin Core implementation is set as MAX_PUBKEYS_PER_MULTISIG = 20, so 10-of-20 options appear to be the upper limit in terms of the number of signatories, and smaller N values are more often chosen for operational routines.

The complexity of recovery also increases. Businesses need documented regulations: where backups are stored, who has the right to initiate an emergency procedure, how decisions are recorded. Such a document reduces the risk of an "eternal pause" when funds remain in the wallet due to the lack of an agreed process.

Where joint control is used

Scenarios are divided into retail and corporate. In retail, joint confirmation is used by families and small teams: one signatory on a hardware device, a second signatory on a phone, and a third signatory in reserve with a trusted person. This arrangement helps to distribute responsibility and maintain control if one device is lost.

In a corporate setting, this approach is suitable for cash registers, reserves, OTC transactions, and escrow. For exchangers, a practical scenario is a "hot wallet" for small automatic payments and a separate safe wallet for large amounts, where the transfer goes through several roles.

In summary, multi-signature in cryptocurrencies often becomes a company's "internal safe": management rules are built through thresholds, and transaction control becomes more transparent thanks to logs and regulations.

How to create a scheme with multiple signatories

The process can be conveniently broken down into steps that are suitable for both private users and exchange service teams. For clarity, let's take 2-of-3.

1. Define the participants and roles: initiator, controller, backup signatory. Specify which amounts are "operational" and which are "reserves".
2. Create pairs for signing on different devices. Hardware wallets, separate workstations, or isolated profiles are suitable for signatures. At this stage, it is useful to agree on the address format and backup storage standard.
3. Collect the public signature parameters into a common script and obtain the address. In Bitcoin Core, there is an RPC method for this called createmultisig, which creates an address and redeemScript based on the number of signatures required and the list of public parameters.
4. Conduct a test transfer for a small amount and check the entire cycle: draft creation, transfer for signature, final confirmation, and recording the result in the log.
5. Integrate the procedure into the exchange's operations. In the admin panel, it is useful to link the payment to the request: the status "verified" is assigned after checking the details and risk, the status "sent" is recorded after signing and publishing to the network. This approach works well with the status and log system described by BoxExchanger.

Security and process recommendations

Separate signing devices physically and organisationally. Separating devices and roles increases resilience in the event of a compromise of the working environment and reduces the risk of impulsive decisions by a single participant.

Build your process around strong authentication and action auditing. 2FA and modern login methods are valuable in admin panels. BoxExchanger's news mentions support for WebAuthn for logging into the admin panel, which strengthens control over administrator accounts.

Add risk control before signing. For exchange services, this usually means AML checks, verification of details, and filters based on customer data. The BoxExchanger description mentions wallet format validation using regular expressions, blacklists based on IP and entered data, and transaction verification using AML modules.

For large payments, a "white list" of addresses helps: the team agrees in advance on the addresses of corporate wallets and counterparties, and when the changes, re-confirmation by two roles is required. This control works well with validation of details and logging of actions in the admin panel.

Plan a "rotation day": once a quarter, the team checks the readiness of signatories, the relevance of backups, and disaster recovery scenarios. Such a test reduces the likelihood of funds being blocked due to device loss or procedural errors.

Conclusion

Joint confirmation increases the manageability and stability of crypto asset storage, especially in business processes involving payments and reserves. The M-of-N formula creates clear roles, and the signing rules reduce the risk of losing control due to a single compromised signature element. For practical implementation, it is important to choose a threshold, distribute signature devices across devices, and maintain a transparent activity log.

The information presented in this article is for informational purposes only and does not constitute a guide to action, financial advice or investment advice. Cryptocurrency investments involve a high level of risk, and each investor should conduct their own analysis, assess their financial capabilities and consult with professional financial advisors before making investment decisions.