A Midnight privacy-vault demo needs outside signers to release Ethereum tokens
SIG’s Ethereum example burns a shielded claim before payout, while restoring it after failure requires an attested outcome. Read the full story on CryptoSlateUnderstand the crypto stories that matter and what to watch next. Get The Catalyst in your inbox
Withdrawals from SIG Network’s experimental Ethereum vault require its signing network, even though the underlying assets stay on Ethereum. The example illustrates the withdrawal dependency in Midnight’s Nightmode privacy plan: users burn a shielded claim before the external transfer is signed, and failed-transfer recovery also needs an attested response.
Charles Hoskinson’s @IOHK_Charles account welcomed Tron to Midnight on Oct. 21. SIG’s roadmap targets Tron for December 2026, while its listed Ethereum integration is on the stagenet test network.
Related ReadingSIG 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. SIG says the signers are independent and that no single signer can act alone.
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:
| Step | What must happen | Withdrawal consequence |
|---|---|---|
| Authorize and queue | The holder spends the shielded claim; Midnight records the request. | The claim is burned before the external payout. |
| Sign | The MPC service returns a signature for the vault’s transfer. | The holder’s authorization alone cannot sign from the vault account. |
| Broadcast and execute | The client submits the signed transaction; Ethereum processes it. | A returned signature still needs an external transaction to execute. |
| Attest | The MPC service reports the transaction’s outcome. | Midnight settlement depends on an authenticated outcome. |
| Complete | The vault checks the settlement record and closes the request. | The result determines whether the shielded burn stands or the claim is re-minted. |
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.
Related ReadingThe 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.