En esta aplicación educativa y experimental, los tokens ERC20 subyacentes están en la cuenta EVM de la bóveda. En Midnight, los usuarios tienen tokens blindados de la bóveda que representan sus derechos sobre ese fondo común. Que los activos nativos permanezcan en Ethereum responde a dónde están registrados los activos; por sí solo, no responde quién puede hacer que se muevan.

La distinción también explica la quema. Iniciar un retiro destruye el derecho blindado que se canjea, no el ERC20 subyacente. Un pago externo exitoso completa el canje. Si el pago recibe uno de los resultados de fallo documentados, la aplicación puede restaurar el derecho.

El paso a paso del retiro trata el gasto de la moneda del titular como autorización. El titular proporciona una moneda blindada de la bóveda que coincide con el token y el monto exacto del retiro, y luego elige una dirección de destino. El circuito rechaza una dirección de destino con valor cero.

El circuito startWithdraw quema esa moneda y pone la solicitud en cola. Un vaciado posterior de la cola asigna el número de secuencia de transacción de la cuenta de la bóveda, conocido como nonce. Luego, el paso de envío registra una solicitud para la transferencia exacta de ERC20 y notifica al servicio de firma MPC, o computación multipartita.

El resto consiste en una secuencia de responsabilidades distintas:

El servicio de firma no transmite la transacción. La dApp o el relayer la ensambla con la firma verificada y la envía a la cadena EVM.

Una transferencia fallida y un servicio que no responde son cosas distintas

El servicio tiene una segunda función después de firmar. Proporciona una atestación del resultado de la transacción externa, aparte de la firma que autorizó esa transacción. El protocolo de integración describe cómo vincular ese resultado con la solicitud y los datos que esta devuelve.

La bóveda verifica la atestación con la clave de respuesta MPC configurada antes de permitir la liquidación.

La especificación de retiros describe tres formas de restaurar el derecho: una transacción revertida, una transacción que se vuelve inviable porque otra consume su nonce, o una transferencia ERC20 ejecutada que devuelve false. Una vez que el resultado atestado se pone en cola y se vacía, quien realiza el retiro completa la solicitud y recibe una cantidad blindada reacuñada.

Una transferencia exitosa que devuelve true mantiene la quema y cierra la solicitud. En caso de fallo, lo que se restaura es un derecho de la bóveda en Midnight, no un nuevo pago del activo nativo al destino.

La ruta de reembolso documentada requiere una atestación verificada y procesada mediante el vaciado de la cola. Una solicitud de firma sin respuesta o la falta de una respuesta con el resultado no cumplen por sí solas esa condición.

El ejemplo también incluye un mecanismo de emergencia en el código de la bóveda. El implementador puede iniciar una solicitud de reemplazo de nonce para una transacción atascada de la bóveda, usando una transferencia de valor cero desde la cuenta de la bóveda a sí misma con el mismo nonce.

El objetivo es hacer inviable la transacción original, tras lo cual un resultado atestado puede respaldar su liquidación por fallo. Iniciar esta recuperación está restringido al implementador, aunque enviar una solicitud ya definida no requiere permisos. Es otra transacción firmada, seguida de una atestación, no una salida que evite el servicio MPC.

El código también incluye una advertencia específica: reemplazar una solicitud original antes de que MPC la haya firmado puede crear una condición de carrera con esa solicitud y posiblemente dejarla sin atestación, con el derecho blindado entregado ya quemado.

El implementador también establece la configuración inicial de la cuenta, la cadena y la clave de respuesta, y puede cambiar la configuración de gas de la bóveda. Las solicitudes ya iniciadas conservan los valores de gas copiados cuando comenzaron.

La prueba de producción es la ruta de salida completa

El soporte de mainnet sigue vinculado a ledger v9 en la hoja de ruta de SIG. La actualización del repositorio del 21 de octubre prepara la versión 0.5.0 del paquete de la bóveda en SIG Midnight 0.25.0. En esa versión del código, el registro de direcciones publicado contiene una dirección de la bóveda en stagenet y una entrada vacía para mainnet, que el archivo define como aún no desplegada ni publicada.

La demostración full-stack independiente de SIG utiliza Midnight stagenet y Ethereum Sepolia, ambas redes de prueba públicas, con un respondedor MPC «fakenet». Eso demuestra un flujo de aplicación. No demuestra que un quórum de producción de firmantes independientes esté operando esa demostración.

La descripción de la firma de umbral de SIG aborda cómo se produce una firma. Para evaluar un despliegue real también hace falta saber cuántos firmantes deben cooperar, quién los opera, cómo pueden cambiar esos acuerdos y qué puede completar la recuperación cuando el servicio habitual no está disponible.

El alcance de la auditoría requiere la misma precisión. El informe final de Hacken, fechado el 21 de febrero de 2025, cubre los contratos Solidity de firmas de cadena de Ethereum. Su alcance no establece que se hayan cubierto la bóveda Compact más reciente ni todo el sistema Nightmode.

Por lo tanto, la próxima evidencia de despliegue tendrá más peso que otro anuncio de expansión: el código y las direcciones exactos de producción, su configuración de firma y atestación, la cobertura de auditoría de esos componentes y una ruta de recuperación acorde con los fallos del servicio.