Fase 5: Bitcoin, taproot 2 de 2 y un alcance honesto

20 de abril de 2026: Bitcoin es la cadena en la que tenemos que ser honestos. La superficie de scripts de la L1 no tiene la expresividad de EVM o Solana, así que el patrón de «contrato de enlace de pago que reparte de forma atómica» no se traslada. Lo que sí podemos hacer es reducir la custodia, de «OrcaRail guarda la xpub» a «multisig de dos firmantes con un firmante del comercio y un reembolso prefirmado», y dejar los pagos recurrentes para un futuro camino con Lightning.

En resumen

• Cada enlace de pago en BTC pasa a ser una multisig taproot 2 de 2: un firmante del comercio y un firmante de la plataforma. La plataforma no puede mover fondos de forma unilateral.
• Cada depósito recibe una PSBT de reembolso prefirmada guardada off-chain, para que el pagador pueda recuperar los fondos si el comercio desaparece.
• Las xpub maestras salen del servidor de la API y pasan a un servicio HSM o MPC (por ejemplo, Lit o Turnkey). Ningún mnemónico en disco.
• Los pagos recurrentes en BTC quedan fuera del alcance hasta que Lightning BOLT12 esté listo para producción. Hoy, Cobro automático ya indica que BTC no se admite para el cobro automático, y eso sigue siendo así.

Qué cambia en esta fase

Hoy, BitcoinHotWalletService en api/src/withdrawals/services/bitcoin-hot-wallet.service.ts deriva una dirección p2wpkh unilateral a partir de un mnemónico guardado en el servidor y la barre mediante bitcoin-withdrawal-transfer.service.ts. Es una única clave que controlamos.

Tras la Fase 5:

Ninguna parte puede gastar sola. Ningún servidor guarda una semilla unilateral.

Qué vamos a publicar

1. Taproot 2 de 2 por enlace

• Wallet de descriptores por enlace: wsh(multi(2, merchant_pubkey, platform_pubkey)) o un equivalente taproot (tr(NUMS, {pk(m), pk(p)}) con MuSig2 para una salida que parece de firma única, bueno para la privacidad y las comisiones).
• La clave del comercio vive en el navegador o en la extensión móvil del comercio. El flujo de alta del comercio pide una xpub; las claves por enlace se derivan de ella.
• La clave de la plataforma vive detrás de un servicio HSM o MPC. El servidor de la API nunca ve el material privado.

2. PSBT de reembolso prefirmada

Cuando se detecta un depósito:

1. La API monta una PSBT que devuelve el depósito, menos el gas, a la dirección del pagador (capturada al crear el enlace de pago cuando se conoce la wallet del pagador; si no, se aplica la política sendback).
2. Ambos firmantes firman la PSBT de reembolso de inmediato y se guarda (cifrada) en la base de datos.
3. El comercio puede emitir el reembolso en cualquier momento con un clic; no hace falta firmar nada más.

Es el equivalente en BTC de una función refund() on-chain.

3. Rotación de claves MPC

• Las xpub maestras de las claves de la plataforma rotan anualmente.
• Todas las claves por enlace derivadas siguen las rotaciones; los enlaces antiguos siguen funcionando porque su multisig ya está on-chain con la pubkey concreta.
• La rotación se registra en el mismo historial de auditoría que los despliegues de la multisig de la Fase 0.

Qué no vamos a publicar

• Suscripciones / cobro automático en BTC. Hoy no hay un diseño creíble en la L1. La documentación de cobro automático actual ya excluye BTC, y eso sigue siendo correcto.
• Repartos atómicos on-chain para BTC. Los repartos ocurren en la PSBT de liquidación que firma el comercio. El reparto sigue siendo determinista y visible en la transacción emitida, pero no lo impone el script.
• Fedimint o statechains. Investigación interesante; no entra en esta fase.

Lightning como camino futuro

Los pagos recurrentes en BTC tienen una opción realista: ofertas BOLT12 de Lightning + la extensión recurrence. Eso nos daría una solución de suscripciones en BTC comparable al approve + pull de ERC-20. Lo seguimos como una fase futura:

• Depende de implementaciones maduras de la recurrencia BOLT12 en LND y CLN.
• Depende del soporte de las wallets Lightning (Phoenix, Zeus, Blink) para la recurrencia BOLT12.
• Requiere una flota de nodos LN con liquidez suficiente; probablemente mediante un socio (Voltage, Greenlight).

Publicaremos un documento de diseño dedicado cuando las herramientas de base estén listas. Hasta entonces, BTC sigue siendo de pago único.

Obsolescencias

• BitcoinHotWalletService: mantiene su interfaz, pero el proveedor de claves pasa a HSM/MPC. Deja de generarse la dirección de depósito p2wpkh unilateral para los enlaces nuevos.
• Las direcciones de depósito BTC heredadas se pueden seguir liquidando hasta su caducidad mediante el antiguo camino de barrido.

Plan de migración

• Enlaces de pago BTC nuevos: direcciones multisig 2 de 2. La interfaz no cambia; el formato de dirección pasa a taproot.
• Enlaces BTC abiertos existentes: las direcciones unilaterales heredadas siguen activas hasta su caducidad; no forzamos la migración.
• Comercios sin un firmante BTC configurado: por ahora usan una multisig solo de la plataforma, con un paso de alta obligatorio para añadir una clave del comercio en un plazo de 30 días. Así se conserva el camino de reembolso y no se bloquea el volumen BTC existente.

Riesgos y mitigaciones

• El comercio pierde su clave. Mitigación: el alta del comercio pide dos xpub (principal + respaldo); la de respaldo es opcional, pero muy recomendada.
• Caída del HSM de la plataforma. Mitigación: el HSM es redundante entre regiones; recuperación de claves de emergencia mediante una ceremonia multisig documentada en el runbook.
• Compromiso del almacenamiento de PSBT de reembolso. Mitigación: las PSBT de reembolso están cifradas en reposo con una clave KMS distinta; además, son inútiles sin que la firma del comercio se vuelva a hacer para otro destino (el destino está fijado en la PSBT prefirmada).
• Madurez de MuSig2. Mitigación: la v1 sale con un 2 de 2 explícito wsh(multi(...)); MuSig2 llegará más adelante, cuando las herramientas estén ampliamente auditadas.
• Picos en el mercado de comisiones. Mitigación: las PSBT de liquidación incluyen un gancho CPFP que el comercio puede subir; el keeper monitoriza la mempool y avisa a los comercios cuando el gas de liquidación supera un umbral.

Lista de estado

• Plantilla de descriptor taproot finalizada
• Proveedor HSM / MPC seleccionado (Lit frente a Turnkey frente a HSM propio)
• Flujo de alta de la xpub del comercio en el panel
• Derivación y almacenamiento de descriptores por enlace
• Generación de PSBT de reembolso prefirmadas + almacenamiento cifrado
• Interfaz de cofirma de liquidaciones (firma del comercio en un clic)
• Runbook para el failover del HSM y la pérdida de claves del comercio
• Grupo canario de comercios en BTC 2 de 2

Qué sigue

Descentralización opcional del keeper mediante EigenLayer: Fase 6.

---

Documentación de referencia: Estado de la Fase 5 · Consideraciones sobre Bitcoin · Modelo de seguridad