A Midnight privacy-vault demo needs outside signers to release Ethereum tokens

SIG Network has released a new Ethereum vault that requires an external signing network to release tokens, illustrating a key dependency in its Nightmode privacy plan.

The experimental vault, built on SIG's Midnight protocol, allows users to hold shielded tokens on Ethereum while keeping the underlying assets on-chain.

Withdrawals require a threshold of independent signers to authorize the transfer, and the system includes a recovery mechanism for failed transactions.

SIG plans to integrate Tron by December 2026, but full mainnet support is still pending.

How the vault holds assets

SIG describes its service as giving a Midnight contract an ordinary Ethereum account. A threshold of signers produces the Ethereum signature when the contract requests it.

In this educational and experimental application, the underlying ERC20 tokens sit in the vault's EVM account. On Midnight, users hold shielded vault tokens representing their claims on that pool.

Native assets staying on Ethereum therefore answers where the assets are recorded; it does not, by itself, answer who can make them move.

The distinction also explains the burn. Starting a withdrawal destroys the shielded claim being redeemed, rather than destroying the underlying ERC20.

A successful external payment finishes the redemption. If the payment receives one of the documented failure outcomes, the application can restore the claim.

Withdrawal process and recovery

The withdrawal walkthrough treats the holder's coin spend as authorization. The holder supplies a shielded vault coin matching the token and exact withdrawal amount, then chooses a destination address.

The startWithdraw circuit burns that coin and queues the request. A later queue flush assigns the vault account's transaction sequence number, known as its nonce.

The send step then records a request for the exact ERC20 transfer and notifies the MPC, or multiparty computation, signing service.

The signing service does not broadcast the transaction. The dApp or relayer assembles it with the verified signature and sends it to the EVM chain.

The service has a second job after signing. It supplies an attestation of the external transaction's outcome, separate from the signature that authorized that transaction.

The vault checks the attestation against its configured MPC response key before allowing settlement.

After the attested result is queued and flushed, the withdrawer completes the request and receives a re-minted shielded amount.

A successful transfer returning true leaves the burn in place and closes the request. On the failure path, the restoration is a vault claim on Midnight, rather than a new payment of the native asset to the destination.

The documented refund route requires a verified, flushed attestation. An unanswered signing request or a missing outcome response does not itself meet that condition.

Emergency mechanism and deployment status

The example also has an emergency mechanism in the vault code. The deployer can start a nonce-replacement request for a stuck vault transaction, using a zero-value transfer from the vault account back to itself at the same nonce.

The purpose is to make the original transaction unviable, after which an attested outcome can support its failure settlement. Starting this recovery is restricted to the deployer, although sending an already-fixed request is permissionless.

It is another signed transaction, followed by attestation, rather than an exit that bypasses the MPC service.

The code also carries a specific warning: replacing an original request before the MPC has signed it can race that request, potentially leaving it without an attestation and its surrendered shielded claim burned.

The deployer also sets the initial account, chain and response-key configuration and can change the vault's gas settings. Already-started requests retain the gas values copied when they began.

Mainnet support remains tied to ledger v9 on SIG's roadmap. The Oct. 21 repository update prepares vault package 0.5.0 on SIG Midnight 0.25.0.

At that code version, the published address registry contains a stagenet vault address and a blank mainnet entry, which the file defines as not yet deployed or published.

SIG's separate full-stack demo uses Midnight stagenet and Ethereum Sepolia, both public testnets, with a 'fakenet' MPC responder. That demonstrates an application flow. It does not establish that a production quorum of independent signers is operating that demo.

SIG's threshold-signing description addresses how a signature is produced. Evaluating an actual deployment also requires knowing how many signers must cooperate, who operates them, how those arrangements can change and what recovery can complete when ordinary service is unavailable.

Audit scope needs the same precision. Hacken's final report dated Feb. 21, 2025 covers Ethereum Solidity chain-signature contracts. Its scope does not establish coverage of the newer Compact vault or the complete Nightmode system.

The next deployment evidence is therefore more consequential than another expansion announcement: the exact production code and addresses, its signing and attestation configuration, audit coverage for those components, and a recovery path matched to service failure.