Es source routing multinivel: el emisor crea una trampoline onion interna con destino, importe y presupuestos de comisión y CLTV, la lleva dentro de una onion normal al primer trampoline node y este calcula la ruta intermedia concreta hasta el siguiente trampoline hop o el receptor; cada nodo delegado conoce solo su parte de la tarea.
El source routing normal de Lightning supone que el emisor conoce un grafo de red utilizable y elige cada hop. Para un teléfono que suele estar desconectado, eso exige descargar y depurar channel gossip y calcular una ruta antes de pagar; Trampoline Routing traslada ese trabajo a varios nodos con una visión más reciente de la red, no la custodia de claves o canales. [6]
El emisor elige el primer trampoline node, fija el importe, el destino final y los presupuestos de comisión y CLTV, y crea una trampoline onion. Una payment onion normal lleva esa onion menor al nodo; este descubre solo la instrucción del siguiente trampoline hop, busca una ruta concreta mediante nodos normales y vuelve a envolver la onion restante para el siguiente tramo. [1]
Entre dos trampoline nodes puede haber nodos Lightning normales que no admitan la propuesta: procesan una onion y un HTLC estándar conforme a BOLT #4. El trampoline node completa el hueco de la ruta, pero no puede alterar el importe, las condiciones temporales o el secreto final sin que falle una comprobación posterior. [2]
Delegar no es ceder la custodia. El trampoline node no recibe seed, clave privada ni derecho unilateral a gastar del canal; sí puede rechazar o retrasar el pago, elegir una ruta mala o cara y observar metadatos de su tramo. La cartera debe imponer los presupuestos de comisión y CLTV, el payment secret y el tratamiento correcto de errores cifrados y reintentos. [1]
A comienzos de octubre de 2026, la propuesta pública BOLTs #836 sigue abierta, mientras Eclair y lightning-kmp ya remiten a la implementación del formato propuesto más reciente y a la transición desde el protocolo experimental anterior. Eso demuestra un despliegue real, no interoperabilidad completa de toda la red; la configuración actual de Eclair también separa la habilitación general de pagos de un feature flag de prototipo. [5]
BOLT #4 protege el contenido de las capas y solo revela a un hop su predecesor y sucesor, pero no oculta automáticamente todos los metadatos. Un único proveedor trampoline puede conocer al cliente emisor y, al pasar a un receptor sin soporte, también el destino; varios trampoline hops y una blinded path pueden repartir ese conocimiento, aunque tiempo, importe y reutilización siguen correlacionando. [2]
Route blinding se combina con trampoline colocando outgoing_node_id en vez de outgoing_channel_id en los datos cifrados. El trampoline node descifra solo el siguiente nodo y calcula una ruta hasta él; el receptor puede ocultar su tramo y permitir nuevos intentos de búsqueda durante una falta temporal de liquidez. [4]
Verificar una cartera exige comprobar si realmente limita el gossip, cómo elige trampoline nodes, qué feature bits y onion TLV usa, si el formato es antiguo o propuesto, cómo impone los presupuestos de comisión y CLTV, trata errores y MPP, y si un destino sin soporte revela al trampoline node más de lo que espera el usuario. [3]
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, Lightning Routing, Lightning Service Provider, HTLC, Payment Channel, Privacidad en Bitcoin.
01¿Puede un trampoline node robar un pago Lightning?+
Delegar la búsqueda de ruta no le da claves privadas ni una forma de eludir las condiciones del pago. Aun así puede rechazar o retrasar, probar rutas caras o reunir metadatos. La cartera debe limitar comisión y CLTV, validar la onion y el payment secret, y poder elegir otro nodo o intento.
02¿Es Trampoline Routing lo mismo que un LSP?+
No. Un LSP es un rol operativo que puede proporcionar conectividad, canal y liquidez; un trampoline node calcula un tramo delegado. Un operador puede cumplir ambos roles, pero son distintos y concentrarlos en un servicio aumenta la dependencia de disponibilidad y privacidad.