A demonstration of SIG Network’s experimental Ethereum vault highlights a central dependency in Midnight’s proposed Nightmode privacy design: users cannot complete withdrawals without the network’s external signing and transaction-outcome services, even though the assets themselves remain on Ethereum.
According to CryptoSlate, the vault represents users’ claims on a pool of ERC20 tokens through shielded assets on Midnight. When a user requests a withdrawal, the corresponding shielded claim is burned before the Ethereum transfer is signed. The claim can be restored if the transfer is verified as failed, but the documented recovery process also depends on an attested response from the signing service.
How the experimental vault works
SIG describes the service as connecting a Midnight contract to a conventional Ethereum account. The vault’s underlying ERC20 tokens are held in that Ethereum account, while users receive shielded vault tokens on Midnight that represent their claims to the pooled assets.
That arrangement separates ownership records from the mechanism that moves the assets. Although the tokens remain recorded on Ethereum, a withdrawal still requires a threshold group of signers to produce an Ethereum transaction signature. SIG says the signers are independent and that no individual signer can act alone.
The withdrawal process begins when a user supplies a shielded vault coin matching the token and the exact amount requested, along with a destination address. The application rejects a zero address. A circuit called startWithdraw then burns the shielded coin and places the request in a queue.
A later queue operation assigns the vault account’s Ethereum transaction sequence number, or nonce. The system then records the requested ERC20 transfer and sends a notification to the multiparty-computation, or MPC, signing service.
The signing service does not broadcast the transaction itself. Instead, the dApp or a relayer combines the verified signature with the transaction and submits it to the Ethereum Virtual Machine chain.
Why a failed transfer does not automatically restore the claim
The MPC service has another role after signing: it provides an attestation describing what happened to the external transaction. The vault checks that response against its configured MPC response key before allowing the withdrawal to be settled.
The specification identifies three failure outcomes that can support restoration of the shielded claim:
- The Ethereum transaction is reverted.
- Another transaction consumes the relevant nonce, making the original transaction unviable.
- The ERC20 transfer executes but returns false.
After a verified result has been queued and processed, the user can complete the failure route and receive a newly minted shielded claim. This is a restoration of the Midnight-side claim, not a second transfer of the underlying tokens to the destination.
A transfer that executes successfully and returns true leaves the original burn in place and closes the withdrawal request. Crucially, an unanswered signing request or a missing outcome response does not qualify as a verified failure under the documented process. In other words, silence from the service is not, by itself, an exit route.
The vault includes an emergency procedure for a stuck transaction. The deployer can initiate a nonce-replacement request using a zero-value transfer from the vault account back to itself at the same nonce. Making the original transaction unviable can then allow an attested failure result to support claim restoration.
However, this mechanism remains connected to the same signing and attestation framework. Starting the recovery is restricted to the deployer, while submitting an already prepared request is permissionless. The code also warns that replacing an original request before the MPC has signed it could create a race, potentially leaving the request without an attestation while the user’s shielded claim remains burned.
Deployment remains at the testing stage
The available deployment information does not show a published mainnet vault address. The Oct. 21 repository update prepares vault package 0.5.0 for SIG Midnight 0.25.0, while the listed address registry contains a stagenet vault address and a blank mainnet entry identified as not yet deployed or published.
SIG’s separate full-stack demonstration uses Midnight stagenet and Ethereum Sepolia, both public test networks, together with a “fakenet” MPC responder. That setup demonstrates the application flow, but it does not establish that a production quorum of independent signers is operating the demo.
The roadmap ties mainnet support to ledger v9. It also targets a Tron integration for December 2026. On Oct. 21, Charles Hoskinson’s IOHK account welcomed Tron to Midnight. The published Ethereum integration, however, remains on stagenet.
The distinction matters because threshold signing explains how an authorization can be generated, but it does not by itself establish how a live deployment is governed or recovered. Relevant operational details include the number of signers required, who runs them, how the arrangement can change and what happens when the ordinary service is unavailable.
The supplied audit information also has a limited scope. Hacken’s final report, dated Feb. 21, 2025, covers Ethereum Solidity chain-signature contracts. It does not establish coverage of the newer Compact vault or the complete Nightmode system.
Moneyiar market picture
Moneyiar market data at 23:34 on Oct. 22, 2026, showed Ethereum at $2,380.8237081254, down 3.85% over 24 hours and 2.39% over seven days. Shiba Inu was priced at $0.0000049354, down 4.28% in 24 hours and 3.39% over seven days.
Uniswap stood at $6.9729497991, down 6.60% over 24 hours and 6.07% over seven days. Pepe was at $0.000004377, down 5.14% over 24 hours but up 7.32% over seven days. These figures are Moneyiar data at the stated time.
