Instale un Safe Guard. Sus propietarios, su umbral y su historial siguen exactamente igual, pero cada transferencia necesita además una aprobación poscuántica, verificada en la cadena.
Un propietario firma la transferencia en el Safe{Wallet} real. No se ejecuta. El Administrador Cuántico lee el pago en el dispositivo (token, importe, destinatario, ventana de validez, Safe y cadena) y lo aprueba con una firma poscuántica de un solo uso. Solo entonces se mueve el dinero.
Grabado de principio a fin en el entorno de demostración local: un Safe real, el Safe{Wallet} real y el Guard aplicando las reglas en la cadena. El dispositivo es el Ledger simulado, no hardware; consulte Estado para saber en qué punto está la app de Ledger.
Ver a tamaño completo · Ejecútelo usted mismo →
Todos los propietarios de un Safe firman con ECDSA. Un ordenador cuántico lo bastante grande rompe ECDSA, para todos sus firmantes a la vez. Los activos que se custodian durante diez años necesitan una firma que sobreviva a ese día.
Decide quién puede firmar. No sirve de nada cuando cae el propio esquema de firma.
No evitan una firma falsificada sobre la misma curva: la clave nunca tiene que salir del dispositivo.
Un motor de políticas que la cadena no consulta se puede eludir. La última palabra tiene que estar en la cadena.
FermionGuard es un Safe Guard, el mecanismo oficial de Safe que se ejecuta antes de cada transacción. Los propietarios siguen firmando como hoy. El Guard solo deja pasar la transacción si además lleva una aprobación poscuántica que coincida.
Los mismos propietarios, el mismo umbral, las mismas carteras de hardware. Protege frente a operadores desleales, dispositivos perdidos y fallos internos.
Un Administrador Cuántico designado aprueba cada transferencia en un Ledger con una clave XMSS. Protege frente a firmantes comprometidos, aprobaciones reutilizadas, vaciados de asignaciones y futuros ataques cuánticos.
Un operador pone una transferencia en cola en Safe{Wallet}. Los propietarios firman como siempre.
La Safe App de FermionGuard la marca con 🟡 autorización cuántica necesaria.
El Administrador revisa el contenido, decodificado a partir de dos fuentes independientes.
El Ledger muestra todos los campos que se aplican. Mantenga pulsado para aprobar.
La fila pasa a 🟢. Cualquiera puede ejecutarla; el Guard comprueba y consume la aprobación.
El Administrador ve exactamente lo que aprueba
Una aprobación indica el Safe, la cadena, el token, el destinatario, el importe y una ventana de validez. Si alguien modifica después la transacción en cola, la aprobación deja de coincidir y el Guard la rechaza.
Sin firmas a ciegas: el dispositivo muestra todos los campos que aplica el Guard
FermionGuard se distribuye como una Safe App dentro de Safe{Wallet} y como una app de Ledger para el Administrador. Los avisos de riesgo destacan destinatarios nuevos, importes inusuales y transacciones que el Guard rechazaría de todos modos, antes de que nadie firme.
¿Pago de nóminas? Un lote completo de hasta 100 transferencias necesita una sola aprobación.
Sin cartera nueva, sin cadena nueva, sin migrar activos. Cuatro pasos que realizan sus propietarios actuales mediante transacciones de Safe ordinarias.
Añada FermionGuard en Safe{Wallet}. Comprueba la versión y los módulos de su Safe antes de cambiar nada.
La clave del Administrador se genera dentro del Ledger. Los propietarios la confirman y firman conjuntamente su registro.
Los propietarios firman una transacción setGuard, como cualquier otra transacción de Safe.
Una transferencia de importe mínimo recorre todo el flujo. Cuando se confirma, su panel muestra Protegido ✓.
Añada un control criptográfico independiente y basado en estándares a la custodia de activos de clientes.
Mantenga su flujo de aprobación y haga que un firmante comprometido no baste para mover fondos.
Ponga un control público y con plazo de espera en los movimientos que más importan: los cambios de gobernanza.
El Guard es el último veto en la cadena, y está diseñado para que ni una clave perdida ni un error puedan congelar sus fondos.
¿Perdió el Ledger? Los propietarios por sí solos pueden retirar el Guard tras una cuenta atrás pública de 14 días. Un dispositivo inservible nunca bloquea el Safe.
Retirar el Guard o cambiar los propietarios exige una aprobación y una cuenta atrás pública de 48 horas de la que se avisa a todos los propietarios.
Un Guard no actualizable con una pausa rápida que lo bloquea todo ante incidentes. Sin puerta trasera de administración.
Los módulos de Safe se saltan los guards, así que la inscripción exige que no haya módulos activados, o un module guard emparejado en Safe 1.5+.
approve, permit y transferFrom se rechazan directamente, y los lotes se comprueban operación por operación en la cadena.
Los propietarios firman conjuntamente la raíz pública completa de la clave en sus propios dispositivos, de modo que un sitio web comprometido no puede sustituirla por otra.
Los cambios de gobernanza son lentos y visibles; cancelarlos es rápido
Un atacante con el Ledger del Administrador sigue sin poder mover fondos sin las firmas de sus propietarios, y no puede retirar el Guard sin una cuenta atrás pública de 48 horas que sus propietarios pueden cancelar.
XMSS se basa únicamente en funciones hash, así que la cadena lo comprueba directamente: sin oráculos ni servidores de confianza. El verificador es una implementación limpia de la RFC 8391, y decimos con exactitud hasta dónde llega su demostración: cada primitiva de la RFC y las comprobaciones que rechazan entradas mal formadas están verificadas por máquina para todas las entradas frente a una transcripción línea a línea de la RFC. Su composición en la comparación de la raíz que finalmente acepta o rechaza una firma bien formada se argumenta a mano, se comprueba simbólicamente con altura de árbol 2 y se fija con los vectores de la RFC para h = 4, 10 y 20.
XMSS tiene estado: reutilizar una hoja de un solo uso permitiría a un atacante falsificar firmas. El Ledger registra su contador antes de entregar una firma, y el contrato mantiene un mapa de hojas usadas que revierte ante cualquier reutilización.
Ver los contratos → · Especificación del Guard → · Demostración formal →
function _verifyAndConsumeXmss( bytes32 keyId, bytes32 digest, bytes calldata xmssSignature ) internal { XMSS.Signature memory sig = abi.decode(xmssSignature, (XMSS.Signature)); BitMaps.BitMap storage used = _usedLeaves[xmssRoot(keyId)]; // per KEY, not per registration if (used.get(sig.leafIdx)) revert LeafAlreadyUsed(keyId, sig.leafIdx); if (!XMSS.verify(digest, sig, publicKey(keyId), treeHeight(keyId))) revert InvalidXmssSignature(); // whole tx rolls back used.set(sig.leafIdx); // burn the one-time leaf emit LeafConsumed(keyId, sig.leafIdx, digest); }
El diseño y el verificador poscuántico ya son públicos. Los equipos con acceso anticipado ayudan a dar forma al resto.
Stan (Konstantin) Kladko: de la física que crea la amenaza cuántica a la criptografía que tiene que sobrevivir a ella.
Doctor por el Instituto Max Planck. Trabajó con el premio Nobel Robert B. Laughlin en sistemas cuánticos en Stanford. Director's Fellow en el Laboratorio Nacional de Los Álamos.
Dirigió un laboratorio acreditado por el NIST para pruebas de módulos criptográficos (CMVP), con certificaciones FIPS 140-2 y de seguridad frente a canales laterales.
Cofundador y CTO de SKALE, que llevó la criptografía de umbral BLS del papel a una mainnet alineada con Ethereum.
No. Instala un Guard en el Safe que ya tiene. Los propietarios, el umbral, el historial y las direcciones siguen exactamente igual.
Sus propietarios pueden retirar el Guard por sí solos, sin clave cuántica, tras una cuenta atrás pública de 14 días. Si la solicitud no es legítima, pueden cancelarla en cualquier momento de ese plazo con una transacción de Safe ordinaria. Un dispositivo perdido nunca puede bloquear su Safe de forma permanente.
Cada transferencia necesita una aprobación adicional del Administrador en un Ledger. Los lotes, como una nómina de hasta 100 transferencias, necesitan una sola aprobación para todo el lote.
Verificar la firma poscuántica cuesta unos 745.000 de gas, que se pagan una vez al crear la aprobación (745.003 de gas medidos con h = 20). La comprobación al ejecutar la transacción es una simple consulta.
Safe v1.3.0 y posteriores. El Safe no debe tener módulos activados, porque los módulos se saltan los guards, o bien debe estar en Safe 1.5+ con el module guard de FermionGuard instalado también. Tampoco debe tener fallback handler: los tokens ERC-20 y el ETH funcionan con normalidad, pero las funciones de mensajes firmados (Permit, órdenes de CowSwap, inicio de sesión) y la recepción de NFT mediante safeTransferFrom aún no son compatibles.
XMSS es una firma basada en hash aprobada por el NIST (SP 800-208), así que la EVM puede verificarla por aproximadamente 1M de gas. Los esquemas de retículos como ML-DSA y Falcon costarían hoy decenas de millones de gas para verificarse en la cadena.
Todavía no. El verificador poscuántico está verificado por máquina frente a la RFC 8391 en la medida descrita arriba, y los contratos del Guard están implementados y probados, pero nada está auditado aún; la app de Ledger y la Safe App están en desarrollo, y se necesita una auditoría externa antes de cualquier despliegue en mainnet. Solicite acceso anticipado para estar entre los primeros equipos incorporados.
Estamos incorporando un primer grupo de equipos con activos en Safe. Cuéntenos su configuración y nos pondremos en contacto cuando se abran los pilotos.
Abre un breve formulario público de GitHub; no incluya nada confidencial.