The 2 of 3 multisig flow, step by step

This dossier walks through the 2 of 3 multisig flow on Nexus Market end to end, from the moment the buyer clicks to place an order to the moment the coin releases from escrow.

Key generation, order time

When the buyer places an order, the storefront generates three private keys for that specific order. One private key is held by the buyer through their storefront account. One is held by the vendor through theirs. One is held by the platform. The three public keys are combined into a multisig address, and the buyer sees this address on the checkout page as the deposit destination.

The keys are per-order, not per-account. This matters: even if a vendor's account is compromised in some future scenario, only the keys for currently open orders are exposed, not the vendor's historical order coin (which has already released).

Deposit

Buyer copies the multisig address, deposits the exact amount from their own wallet, waits for confirmations. Monero requires two confirmations minimum, Bitcoin ten, Litecoin around six. When the confirmations complete, the storefront marks the order as escrowed.

Vendor ships

Vendor sees the deposit confirmed on their orders page, ships the item, updates the storefront with any tracking or shipping metadata they choose to share. Message system available for coordination.

Buyer marks received

Package arrives, buyer checks the item against the listing, marks the order received in the storefront. This is the buyer's signature on the release. One of the three needed.

Vendor signs release

Vendor sees the marked-received flag, signs the release. This is the second of the three needed. The multisig transaction now has two signatures, which is enough. The transaction broadcasts to the coin's network. Coin moves from the multisig address to the vendor's wallet.

Platform key never moves in this path. This is the happy path, the vast majority of orders, and it settles without any moderator involvement.

Dispute path, buyer opens

Buyer opens a dispute instead of marking received. Storefront notifies the vendor. Vendor responds through the message system with their side. Moderator reads the entire message thread, checks vendor dispute history, checks any photographic evidence, judges. Moderator cosigns with whichever side they judged correct.

If moderator cosigns with buyer: multisig transaction constructed with buyer + platform signatures, sending coin to a refund address the buyer specifies. Vendor's signature not needed.

If moderator cosigns with vendor: multisig transaction constructed with vendor + platform signatures, sending coin to vendor's wallet. Buyer's signature not needed.

Dispute path, vendor opens

Symmetric case, rare. Vendor opens a dispute because the buyer has failed to mark received despite the vendor's evidence of delivery. Moderator reads both sides, cosigns with whichever they judge correct. Same signature-combination logic.

Timeout path, buyer inaction

Buyer neither marks received nor opens a dispute for an extended period after delivery has occurred. Some storefronts have automatic finalisation at this timeout. Nexus does not, as of the last observation. Coin sits in the multisig contract indefinitely until either the buyer signs, the vendor opens a dispute, or the buyer opens a dispute. Neither side loses the coin, but the vendor has to wait.

Key management on the storefront side

The storefront generates keys server-side. Buyer and vendor keys are held on the storefront database, encrypted with the account password. Platform key is held on the storefront infrastructure separately. When the account holder signs a release, the storefront uses the account password (submitted during the sign action) to decrypt the key and produce the signature.

This means an attacker with the account password can sign releases, which is why account passwords should be strong and not reused. The mnemonic seed issued at registration is the recovery path if the password is lost, and it should be treated as equivalent to the password for security purposes.

What could go wrong

Storefront compromise. If the entire storefront infrastructure is compromised, an attacker could construct signatures using the platform key and either buyer or vendor keys held in the database. This is why the platform key alone is not sufficient: even a full server seizure only gets the attacker one of three keys per contract, plus whatever account passwords they can crack. It does not give them the ability to unilaterally move any single order's escrow.

Multisig library bug. If the library the storefront uses to construct multisig transactions has a bug that lets an attacker forge a signature without knowing the private key, all deposits are at risk. This has never happened on a serious multisig library, but it is not zero probability.