Arquitectura de liquidación directa: cómo funcionan las carteras HD y la derivación de xPub

El mayor riesgo de seguridad en cualquier sistema de pagos con criptomonedas es la exposición de las claves privadas. Si el servidor que vigila los pagos entrantes también puede gastar esos fondos, una sola brecha significa perderlo todo. La arquitectura de liquidación directa puede reducir ese riesgo de custodia, y el mecanismo que la hace posible, la derivación de claves en carteras HD, es lo bastante útil como para merecer una explicación.

El problema de los hot wallets en un servidor

Un «hot wallet» es una cartera cuya clave privada vive en una máquina conectada a internet. La mayoría de las implementaciones ingenuas de pagos cripto funcionan así: se crea una cartera, se guarda la clave privada en un archivo de configuración o en la base de datos y se usa para generar direcciones de depósito y firmar las transacciones de pago.

Visto en retrospectiva, el problema salta a la vista: cualquier atacante que comprometa el servidor —mediante una vulnerabilidad sin parchear, un ataque a la cadena de suministro, unas credenciales filtradas o un cortafuegos mal configurado— obtiene la clave privada y puede vaciar todas las carteras asociadas a ella. La historia de los hackeos a exchanges de criptomonedas es, en buena medida, la historia de los hot wallets comprometidos.

La solución consiste en separar la capacidad de observar los pagos de la capacidad de gastar los fondos.

Carteras HD y la clave pública extendida

BIP-32 (carteras jerárquicas deterministas, o HD wallets) define una forma de derivar un árbol infinito de pares de claves a partir de una única semilla maestra. Su propiedad decisiva es la derivación de claves públicas: a partir de la clave pública extendida (xPub) de un nodo padre se pueden derivar todas las claves públicas hijas —y, por tanto, todas las direcciones de Bitcoin hijas— sin ver jamás la clave privada.

Esto es matemáticamente posible gracias a la aritmética de curva elíptica: las claves públicas son puntos sobre una curva, y basta con sumar un ajuste determinista para derivar claves públicas hijas a partir de la clave pública del padre.

En la práctica, esto significa que:

1. Generas la semilla maestra sin conexión: en un equipo air-gapped, una cartera de hardware o un dispositivo de firma.
2. Exportas la xPub (solo la clave pública, sin material privado) y se la entregas a tu servidor de pagos.
3. El servidor deriva la dirección n.º 1 para la factura n.º 1, la dirección n.º 2 para la factura n.º 2, y así sucesivamente: cada una única y vinculada al material de clave pública del comercio en una configuración aprobada de liquidación directa, sin llegar a conocer nunca la clave privada.

Cómo funciona la derivación de direcciones en la práctica

Para una xPub de BIP-32 en la ruta de derivación m/44'/0'/0' (el estándar BIP-44 de Bitcoin), el servidor deriva direcciones en m/44'/0'/0'/0/N, donde N es el índice de la factura. Cada N produce una dirección única. Las direcciones son deterministas —la misma xPub con el mismo N da siempre la misma dirección—, de modo que cualquier dirección se puede volver a derivar para verificarla.

En las cadenas UTXO (Bitcoin, Litecoin, Dogecoin, Bitcoin Cash) este es el enfoque estándar. Otras redes emplean mecanismos distintos pero equivalentes:

• TON y Tron: cada factura recibe un par de claves recién generado; en el servidor solo se almacena la clave pública (y, con ella, la dirección). La clave privada se descarta (para uso watch-only) o se guarda en un pool sin conexión.
• Solana: un pool offline de claves públicas pregeneradas (derivadas de una semilla offline) se consume a razón de una por factura.
• Cadenas EVM (ETH, BSC, Polygon, etc.): derivación desde la xPub mediante BIP-44, igual que en Bitcoin.
• XRP y XLM: modelo de dirección compartida con un destination tag o un memo único por factura.

El flujo completo de un pago no custodial

1. Se crea la factura: tu sitio llama a la API de la pasarela. La pasarela deriva una dirección de depósito nueva (o asigna un tag único) usando únicamente material público.
2. El cliente paga: los fondos se envían a esa dirección. La pasarela detecta la transacción a través de la API de un explorador de bloques.
3. Confirmación: alcanzado el número de confirmaciones requerido, la pasarela actualiza el estado de la factura y dispara un webhook firmado hacia tu servidor.
4. Los fondos llegan: directamente a tus propias carteras. La pasarela nunca los custodió, no puede moverlos y no tiene ninguna clave privada para hacerlo.
5. Retiro: cuando quieras barrer los fondos o procesar un pago, firmas la transacción sin conexión —en una máquina air-gapped, una cartera de hardware o cualquier dispositivo de firma— y difundes la transacción ya firmada. El servidor registra el hash de la transacción, pero no puede iniciar el gasto.

Qué significa esto para la seguridad

Con este modelo, comprometer por completo el servidor de pagos equivale, en el peor de los casos, a una filtración de datos: el atacante verá el historial de pedidos y las facturas en curso, pero no podrá mover ni un satoshi. Los fondos están en carteras controladas por claves que nunca tocaron el servidor.

Por eso las pasarelas no custodiales exigen exportar una xPub (o usar una herramienta de generación de claves sin conexión) antes de procesar pagos. El pequeño sobrecoste de configuración compra un perfil de riesgo radicalmente distinto: servidor comprometido ≠ pérdida de fondos.

Para cualquier operador con un volumen relevante, esta arquitectura es un modelo útil de entender. Por defecto, Payora acredita los pagos al saldo de Payora; los comercios verificados pueden solicitar liquidación directa con material de clave pública del comercio donde esté disponible. Descubre cómo funcionan los modos de liquidación de Payora.