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.
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 circuit rejects a zero destination.
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 rest is a sequence of distinct responsibilities:
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.
A failed transfer and a silent service are different
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 integration protocol describes binding that outcome to the request and its returned data.
The vault checks the attestation against its configured MPC response key before allowing settlement.
The withdrawal specification describes three ways the claim can be restored: a reverted transaction, a transaction made unviable because another consumed its nonce, or an executed ERC20 transfer that returned false. 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.
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.
The production test is the complete exit path
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.
