Cómo funciona la firma nativa de billetera en derivados DeFi

Qué significa realmente la firma nativa de billetera

En un exchange centralizado, tu cuenta es una fila en una base de datos. Te autenticas con co rreo y contraseña. El exchange guarda tus fondos en una billetera ómnibus. Al colocar una orden, envías una solicitud HTTP a su servidor confiando en que la respetarán, liquidarán correctamente y no conge larán tu retiro.

La firma nativa de billetera es estructuralmente distinta. Tu billetera Ethereum posee una clave privada. Esa clave firma un mensaje criptográfico que autoriza una acción específica . La firma prueba que aprobaste exactamente lo que se firmó, ni más ni menos. Nadie puede falsificarla sin tu clave.

En derivados DeFi, esto significa que tus órdenes son autorizadas por tu clave pr ivada antes de llegar a cualquier motor de emparejamiento. El protocolo recibe un mensaje firmado, verifica la firma y procesa la orden. No necesita confiar en tu identidad. La matemática se encarga de es o.

Esa es la distinción clave entre un inicio de sesión CEX y un flujo de trabajo nativo de billetera. Uno depende de la capa de autenticación del exchange. El otro depende de una prueba criptográfi ca.

EIP-712: el estándar detrás de las solicitudes de firma legibles

Las primeras billeteras Ethereum pedían a los usuarios firmar d atos hexadecimales crudos. Veías una cadena como 0x3d602d80600a3d3981f3... y debías aprobarla. Casi nadie podía verificar qué estaba autorizando realmente. Este era el problema de la firm a a ciegas.

EIP-712 se introdujo para solucionarlo. El estándar define un formato para la firma de datos estructurados tipados, permitiendo que l as billeteras muestren un desglose legible de lo que autoriza una firma.

Datos estructurados tipados

EIP-712 requiere que cada mensaje firmable cumpla con un esque ma definido. El esquema especifica nombres de campos, tipos y valores. Una orden puede definir campos como asset, isBuy, limitPx, sz, reduceOnly y nonce. Al firmar, tu billetera lee el esquema y muestra cada campo con su etiqueta y valor.

La solicitud de firma no es un bloque de hex. Es un formulari o estructurado que refleja lo que realmente aprobaste.

Separación de dominio

EIP-712 incluye un separador de dominio: un hash que codifica el nombre de la aplicación, la versión y el ID de la cadena. Esto evita que una firma creada para un protocolo sea reutilizada en otro. Una firma que generas para Hyperliquid en la red principal no puede ser enviada a otro lugar ni reutilizada en la red de prueba.

Sin la separación de dominio, un sitio malicioso podría capturar una firma válida y enviarla donde no pretendías. El separador de dominio cierra esa ventana.

Solicitudes legibles

Dado que el esquema está definido y el dominio es explícito, una billetera compatible como MetaMask o Rabby muestra la solicitud de firma como un de sglose legible. Ves el nombre del protocolo, cada campo y su valor. Puedes verificar el activo, la dirección, el precio y el tamaño antes de firmar.

Esto hace que la firma nativa de billetera sea au ditable en el punto de ejecución. No confías en una interfaz para describir lo que haces. Lees el payload real que tu clave autorizará.

Cómo usa Hyperliquid EIP-712 para firmar órdenes

El libro de órdenes de Hyperliquid corre en su propia L1, pero la capa de autorización usa EIP-712. Al colocar una orden, los parámetros se codifican como un payload de datos estructurados y se presentan a tu billetera para firmar. Tu billetera firma el payload. El mensaje firmado va al motor de emparejamiento de Hyperliquid, que verifica la firma antes de pr ocesar la orden.

Hyperliquid nunca necesita tu clave privada. Recibe un mensaje firmado y lo verifica contra tu dirección pública. Firma válida, nonce correcto: la orden es aceptada.

Nonces y prevención de ataques de repetición

Hyperliquid usa nonces para prevenir ataques de repetición. Un nonce es un número que solo se puede usar una vez por di rección. Cada orden firmada incluye uno. Una vez que ese nonce es consumido por una presentación exitosa, el mismo mensaje firmado no puede ser enviado de nuevo.

Sin nonces, un atacante que capturar a una orden firmada válida podría reenviarla más tarde, ejecutando potencialmente una operación que ya completaste o cancelaste. Los nonces cierran esa ventana. La documentación de Hyperliquid cubre los detalles mecánicos de los nonces para quienes construyen sobre el protocolo.

Billeteras API y direc ciones de agente

Hyperliquid admite billeteras API, llamadas billeteras de agente: direcciones Ethereum separadas que autorizas para firmar órdenes en nombre de tu billetera principal. La autorizac ión es en sí misma un mensaje EIP-712 firmado desde tu billetera principal, otorgando permisos específicos a la dirección del agente.

Esto es importante para la automatización. En lugar de exponer l a clave privada de tu billetera principal a un bot, generas un par de claves separado, lo autorizas como agente y dejas que la automatización firme con esa clave. Tu clave principal permanece offline.

Las billeteras de agente tienen permisos limitados. Pueden colocar y cancelar órdenes, pero no pueden retirar fondos a direcciones arbitrarias. Esa separación entre la autoridad de firma y la de retiro es un límite de riesgo significativo.

Qué te muestra la solicitud de firma antes de ejecutar una operación

Cuando env ías una orden a través de una interfaz nativa de billetera construida en Hyperliquid, tu billetera muestra una solicitud de firma antes de ejecutar nada. La representación exacta depende de tu software de billetera, pero una implementación EIP-712 compatible mostrará algo estructurado como esto:

• Protocolo/dominio: el nombre de la aplicación y el contexto de la cadena
• Activo: el mercado que operas (ETH, BTC, etc.)
• Dirección: compra o venta
• Precio límite: el límite de precio para la orden
• T amaño: el tamaño de la posición en el activo base
• Reducir solo: si la orden solo puede reducir una posición existente
• Nonce: el número de secuenc ia para protección contra repetición

Revisas estos campos antes de firmar. Si el precio o tamaño no coinciden con lo que ingresaste en la interfaz, rechazas la firma. Nada se ejecuta hasta que apruebas.

Esa es la propiedad de seguridad central. El paso de aprobación es explícito y legible. No hay llamadas en segundo plano enviando órdenes sin tu conocimiento. La solicitud de firma es la puerta.

Firma delegada: qué es y cuándo usarla

Requerir una aprobación manual para cada orden es práctico para el trading discrecional. P ara estrategias automatizadas, es un cuello de botella. Una estrategia que necesita responder a condiciones de mercado en milisegundos no puede esperar una ventana emergente de MetaMask.

La firma de legada resuelve esto. Generas un par de claves separado, autorizas esa dirección como agente en Hyperliquid firmando un mensaje de delegación desde tu billetera principal, y dejas que tu capa de automatiz ación firme órdenes con la clave de agente. La clave de agente puede vivir en memoria o en un enclave seguro, accesible a tu automatización sin exponer tu clave principal.

La delegación en sí es un mensaje EIP-712 firmado una sola vez desde tu billetera principal. Especifica qué dirección autorizas y qué puede hacer. El motor de emparejamiento de Hyperliquid reconoce entonces esa dirección de agente como autorizada para actuar en tu nombre.

Algunas cosas a entender sobre las billeteras de agente:

• El agente puede colocar y cancelar órdenes. No puede iniciar retiros a direcciones exte rnas.
• Si la clave de agente es comprometida, un atacante puede operar tu cuenta pero no puede drenar tu colateral a una billetera arbitraria sin tu clave principal.
• Puedes revocar la autor ización del agente en cualquier momento con otro mensaje firmado desde tu billetera principal.

Esta arquitectura permite separar las claves de firma "calientes" de las claves de custodia "fría s". Tu billetera principal, que controla los retiros, permanece offline. Tu billetera de agente, que controla el flujo de órdenes, corre en tu stack de automatización.

Cómo Stacked Markets presenta la mecánica de firma

Stacked Markets es una terminal de trading no custodial construida sobre el CLO B on-chain de Hyperliquid. No retiene nada de tu colateral, no agrupa nada y enruta tus órdenes a través del motor de emparejamiento de Hyperliquid. Cada orden requiere una aprobación explícita de la bill etera antes de ejecutarse.

La interfaz está construida alrededor del flujo de trabajo de firma. Al enviar una orden, aparece una solicitud de firma en lenguaje sencillo antes de la ejecución. Esa so licitud refleja el payload EIP-712 real que tu billetera firmará: activo, dirección, precio, tamaño. Apruebas o rechazas. Nada se mueve sin tu firma.

Las órdenes se enrutan como órdenes límite con d eslizamiento limitado estilo IOC, no como órdenes de mercado falsas. El límite de precio en la solicitud de firma es el límite real en tu ejecución. No firmas una orden de mercado que puede llenarse a cua lquier precio. Firmas un límite con un piso o techo de precio explícito, y el CLOB de Hyperliquid maneja el emparejamiento.

La terminal también admite firma delegada para traders con flujos de traba jo automatizados. Vinculas una dirección de firmante a tu billetera principal, y la terminal firma órdenes en tu nombre sin requerir aprobación manual para cada operación. La delegación sigue el mismo pat rón EIP-712 descrito arriba. Tu billetera principal autoriza al firmante. El firmante maneja el flujo de órdenes. Los retiros permanecen bloqueados por tu clave principal.

Stacked Markets no retiene nada. Hyperliquid maneja el emparejamiento, margen y liquidación. Tu PnL y fondeo son verificables on-chain.

Las funciones de automatización y copy-trading están planeadas pero aún no están activas . La red de prueba está disponible en testnet.stackedmarkets.com para traders que quieran probar el flujo de firma antes de la red principal.

Riesgos honestos que debes entender

La firma nativa de billetera es más segura que entregar la custodia a un exchange. No está libre de riesgos.

Ries go de firma a ciegas. No todas las interfaces implementan EIP-712 correctamente. Algunas presentarán un hash crudo y te pedirán firmarlo. Si no puedes leer lo que firmas, confías totalmente en la interfaz. Antes de aprobar nada, confirma que tu billetera renderiza campos estructurados, no una cadena hex cruda. Si solo ves un hash, recházalo.

Pérdida de clave. Tu clave priva da es la única credencial que importa. Si la pierdes sin respaldo, tus fondos desaparecen. Ningún equipo de soporte puede recuperarlos. El almacenamiento de la frase semilla y la gestión de claves son tu responsabilidad total.

Phishing y suplantación de dominio. Un sitio malicioso puede imitar una interfaz legítima y presentar una solicitud de firma que parece correcta pero codifica parámetros diferentes. Verifica siempre el dominio en tu navegador antes de conectar tu billetera. Comprueba que el separador de dominio en la solicitud de firma coincida con el protocolo que pretendes u sar.

Compromiso de la clave de agente. Si usas firma delegada y tu clave de agente es expuesta, un atacante puede operar tu cuenta. No pueden retirar a una dirección arbitraria, per o pueden abrir y cerrar posiciones y generar pérdidas reales. Mantén las claves de agente en entornos seguros y rótalas si sospechas exposición.

Riesgo de contrato inteligente y protocolo. La L1 y el motor de emparejamiento de Hyperliquid tienen su propio perfil de riesgo. Errores de protocolo, fallas de oráculos y mecánicas de liquidación pueden afectar tus posiciones de formas no relacionadas con tu configuración de firma. La liquidación on-chain significa que tu PnL es verificable, pero también que las pérdidas son finales.

Frescura de datos de la UI. Firma r una solicitud que refleja datos obsoletos es un riesgo de ejecución real. Si el precio mostrado en la UI es viejo, el límite en tu orden firmada puede no reflejar las condiciones actuales del mercado. S tacked Markets muestra indicadores de frescura y estado de conexión para señalar esto, pero siempre debes verificar que los datos sobre los que actúas sean actuales antes de firmar.

Pregu ntas frecuentes

¿Qué es la firma nativa de billetera en derivados DeFi?Tu clave privada firma un mensaje criptográfico que autoriza cada operación. El protocolo verifica la firma a ntes de procesar cualquier orden. Nunca entregas la custodia de tus fondos al exchange, y nada se ejecuta sin una aprobación explícita de tu clave.

¿Qué es EIP-712 y por qué importa a los tr aders?EIP-712 es un estándar de Ethereum para la firma de datos estructurados tipados. Permite a las billeteras mostrar un desglose legible de lo que autoriza una firma (activo, dirección, precio , tamaño) en lugar de una cadena hex cruda. El paso de aprobación se vuelve algo que realmente puedes verificar antes de confirmar.

¿Cómo previene Hyperliquid ataques de repetición en órdene s firmadas?A través de nonces. Cada orden firmada incluye un nonce que solo puede consumirse una vez por dirección. Una vez que un mensaje firmado es procesado, el mismo mensaje no puede ser envi ado de nuevo. Un atacante que capture una orden firmada válida no puede repetirla.

¿Qué es un firmante delegado o billetera API y cuándo debo usarlo?Un firmante delegado es una dire cción Ethereum separada que autorizas para firmar órdenes en nombre de tu billetera principal. Es útil al ejecutar estrategias automatizadas que necesitan firmar órdenes sin aprobación manual. El agente p uede colocar y cancelar órdenes pero no iniciar retiros a direcciones externas. Tu clave principal, que controla los retiros, permanece offline.

¿Puede un sitio malicioso robar mis fondos si firmo una solicitud de phishing?Un sitio de phishing puede presentar una solicitud de firma que codifica parámetros diferentes a los que muestra. Si la firmas, autorizas lo que el payload realme nte dice. Verifica el dominio antes de conectar tu billetera, confirma que tu billetera renderiza campos EIP-712 estructurados en lugar de un hash crudo, y rechaza cualquier solicitud que no puedas leer c ompletamente.

¿Qué retiene Stacked Markets cuando opero a través de él?Nada. Stacked Markets es una terminal no custodial. Tu colateral permanece en tu billetera. Las órdenes se enr utan a través del CLOB on-chain de Hyperliquid, y Hyperliquid maneja el emparejamiento, margen y liquidación. Stacked Markets no tiene acceso a tus fondos en ningún momento.

¿Es la firma nat iva de billetera más lenta que la entrada de órdenes CEX?Para trading manual, el paso de firma añade unos segundos por orden. Con firma delegada, tu clave de agente firma órdenes programáticament e sin una ventana emergente de aprobación manual, lo que elimina esa latencia para flujos automatizados. Para trading discrecional, el paso añadido es el precio explícito que pagas por una autorización ve rificable.

Conclusión

La firma nativa de billetera no es una característica de UX. Es el mecanismo que devuelve la autorización a tus manos. EIP-712 hace que esa autorización sea legible. Los nonces la hacen no repetible. Las billeteras de agente la hacen compatible con la automatización sin exponer tu clave principal.

Entender cómo funciona la capa de firma significa q ue puedes auditar lo que apruebas, reconocer cuando algo parece incorrecto y estructurar tu configuración de claves para que coincida con tu tolerancia al riesgo real.

Si quieres probar esta mecánic a en un entorno en vivo antes de comprometer capital real, la red de prueba está en testnet.stackedmarkets.com.