Withdrawals from SIG Network’s experimental Ethereum vault require its signing network, even though the underlying assets remain securely situated on the Ethereum blockchain. This technical design illustrates the intricate withdrawal dependencies built into Midnight’s Nightmode privacy plan, where users must burn a shielded claim before an external transfer can be officially signed, and any failed-transfer recovery mechanism must also rely on an attested response from a decentralized signing infrastructure.
The broader roadmap for the network has continued to expand in parallel with these technical developments. Charles Hoskinson’s account publicly welcomed Tron to the Midnight ecosystem on Oct. 21. According to SIG’s official roadmap, integration support for Tron is currently targeted for December 2026, whereas its listed Ethereum integration currently operates on the stagenet test network environment.
How the Ethereum vault holds assets
SIG describes its specialized service as a mechanism that provides a Midnight contract with an ordinary, functional Ethereum account. Under this architecture, a threshold of independent signers produces the necessary Ethereum signature whenever the underlying contract explicitly requests it. SIG emphasizes that these signers operate independently and that no single signer can act alone to authorize movements from the pool.
In this educational and experimental application, the underlying ERC20 tokens sit directly within the vault’s EVM account. On the Midnight side of the ledger, users hold shielded vault tokens that represent their individual claims on that shared pool. The fact that native assets stay on Ethereum successfully answers where the assets are physically recorded, but it does not, by itself, answer who holds the authority to make them move.
This architectural distinction also explains the necessity of the token burn. Starting a withdrawal destroys the specific shielded claim being redeemed rather than destroying the underlying ERC20 tokens directly. A successful external payment finishes the redemption process. However, if the payment encounters one of the documented failure outcomes, the application is designed to restore the user’s claim.
The withdrawal walkthrough treats the holder’s coin spend as the primary authorization. The holder supplies a shielded vault coin that matches the exact token type and withdrawal amount, and then chooses a destination address. The underlying circuit strictly rejects any zero-destination inputs.
The startWithdraw circuit burns that specific coin and queues the request. A subsequent queue flush assigns the vault account’s transaction sequence number, widely known as its nonce. The send step then records a request for the exact ERC20 transfer and notifies the multiparty computation, or MPC, signing service.
The entire process relies on a sequence of distinct responsibilities. First, during the authorization and queue phase, the holder spends the shielded claim, and Midnight records the request, resulting in the claim being burned before any external payout occurs. Second, during the signing phase, the MPC service returns a signature for the vault’s transfer, reflecting the rule that a holder’s authorization alone cannot sign directly from the vault account. Third, during the broadcast and execution phase, the client submits the signed transaction so that Ethereum can process it, demonstrating that a returned signature still requires an external transaction to execute. Fourth, during the attestation phase, the MPC service reports the outcome of the transaction, ensuring that Midnight settlement depends securely on an authenticated outcome. Finally, during completion, the vault checks the settlement record and closes the request, where the result determines whether the shielded burn stands permanently or the claim is re-minted to the user.
The signing service itself does not broadcast the transaction. Instead, the decentralized application or relayer assembles it with the verified signature and submits it directly to the EVM chain.
A failed transfer and a silent service are different
The signing service carries out a secondary, crucial job after the signature has been generated. It supplies a formal attestation of the external transaction’s outcome, which is kept separate from the signature that initially authorized that transaction. The integration protocol details how this outcome must be bound directly to the request and its returned data.
The vault carefully checks the attestation against its configured MPC response key before it will allow any final settlement to occur.
The withdrawal specification outlines three distinct scenarios in which a burned claim can be restored: a reverted transaction, a transaction rendered unviable because another transaction consumed its required nonce, or an executed ERC20 transfer that explicitly returned a false value. After the attested result has been queued and flushed, the withdrawer completes the request and receives a newly re-minted shielded amount.
A successful transfer that returns a true value leaves the initial burn permanently in place and closes the request. On the failure path, however, the restoration takes the form of a vault claim on Midnight, rather than a brand-new payment of the native asset to the destination address.
The documented refund route strictly requires a verified and flushed attestation. An unanswered signing request or a missing outcome response does not meet that necessary condition on its own.
The experimental setup also features an emergency mechanism embedded directly within the vault code. The deployer possesses the ability to initiate a nonce-replacement request for a stuck vault transaction by executing a zero-value transfer from the vault account back to itself using the exact same nonce.
The primary purpose of this feature is to render the original transaction unviable, after which an attested outcome can adequately support its failure settlement. Initiating this recovery procedure is restricted exclusively to the deployer, although broadcasting an already-fixed request remains permissionless. It is another signed transaction followed by an attestation, rather than an emergency exit that bypasses the MPC service entirely.
The underlying code also carries a specific warning: replacing an original request before the MPC service has signed it can cause a race condition against that request, potentially leaving the transaction without an attestation while the user’s surrendered shielded claim remains permanently burned.
Furthermore, the deployer sets the initial account, chain, and response-key configuration, and retains the ability to modify the vault’s gas settings. Requests that have already been started retain the specific gas values that were copied at the moment they began.
The production test is the complete exit path
Mainnet support remains closely tied to ledger version 9 on SIG’s current roadmap. An Oct. 21 repository update prepared vault package 0.5.0 to run on SIG Midnight 0.25.0. At this specific code version, the published address registry contains a designated stagenet vault address alongside a blank mainnet entry, which the file defines as not yet deployed or published to production.
Meanwhile, SIG’s separate full-stack demo utilizes the Midnight stagenet and Ethereum Sepolia, both of which are public testnets, alongside a fakenet MPC responder. This setup effectively demonstrates an application flow, but it does not establish that a production quorum of independent signers is actively operating that specific demo.
SIG’s description of threshold signing addresses the technical mechanics of how a signature is produced. However, evaluating an actual, secure deployment also requires knowing how many signers must cooperate, who operates those signers, how those operational arrangements can change over time, and what recovery paths can successfully complete when ordinary service is unavailable.
Audit scope requires a similar level of precision. A final security report from Hacken dated Feb. 21, 2025, covers Ethereum Solidity chain-signature contracts. However, the scope of that audit does not establish coverage for the newer Compact vault or the broader Nightmode system.
As a result, subsequent deployment evidence will carry far more weight than standard expansion announcements. Observers will be looking closely at the exact production code and addresses, the signing and attestation configurations, comprehensive audit coverage for those specific components, and a validated recovery path matched precisely to potential service failures.
