La custodia colaborativa intenta repartir responsabilidades sin entregar necesariamente el control completo a un tercero. Para evaluarla bien necesitas saber quién posee cada clave, qué puede hacer cada parte y si puedes recuperar sin el proveedor.
Entre la custodia completamente delegada y la autocustodia independiente existe una familia de modelos intermedios.
Uno de ellos suele llamarse custodia colaborativa.
La expresión puede sonar tranquilizadora: tú conservas parte del control y una empresa o servicio te ayuda con otra parte.
Pero ese nombre, por sí solo, no explica casi nada.
Dos servicios pueden llamarse “colaborativos” y tener propiedades de seguridad, privacidad y recuperación muy diferentes.
Por eso la pregunta útil no es:
¿Es custodia colaborativa?
Sino:
¿Qué controla exactamente cada parte y qué ocurre si una de ellas desaparece?
Primero: custodia y colaboración no son lo mismo
En una custodia totalmente delegada, un tercero controla normalmente las claves necesarias para mover los fondos.
El usuario puede tener una cuenta, una contraseña y mecanismos de autenticación, pero la capacidad criptográfica efectiva está en manos del proveedor.
En una autocustodia independiente, el usuario controla las claves necesarias y no necesita la autorización de un proveedor para gastar.
La custodia colaborativa puede situarse entre ambos extremos.
Un ejemplo conceptual sería una política 2-de-3 en la que:
- tú controlas una clave;
- otra clave está bajo tu control pero se guarda en una ubicación de recuperación;
- el proveedor controla una tercera clave y puede ayudarte en determinados procesos.
Pero esa es solo una posibilidad. Hay muchas otras.
Por eso hay que estudiar la política concreta.
“Custodia colaborativa”, “multisig asistido”, “recovery service”…
Quién firma, quién puede bloquear, qué necesitas para recuperar y cómo abandonas el servicio.
La primera pregunta: ¿quién puede gastar por sí solo?
Esta es una de las comprobaciones más importantes.
En cualquier arquitectura con varias claves, pregunta:
- ¿cuántas firmas hacen falta?;
- ¿quién controla cada una?;
- ¿puede el proveedor alcanzar por sí solo el umbral de gasto?;
- ¿puedes tú alcanzar ese umbral sin el proveedor?;
- ¿necesitas una combinación distinta para recuperación?
Si el proveedor puede mover los fondos unilateralmente, la colaboración se parece mucho más a una custodia delegada de lo que podría sugerir el nombre.
Si tú puedes moverlos sin él, la arquitectura tiene una propiedad diferente: el proveedor puede prestar servicios sin convertirse necesariamente en una autoridad imprescindible para el gasto.
La segunda pregunta: ¿puede el proveedor impedirte gastar?
No poder robar unilateralmente los fondos no significa necesariamente no poder interferir.
Dependiendo de la política, el proveedor puede ser una firma necesaria para determinados movimientos.
En ese caso podría:
- dejar de responder;
- aplicar controles adicionales;
- sufrir una interrupción;
- estar sujeto a restricciones legales;
- cambiar sus condiciones;
- desaparecer.
La arquitectura debe dejar claro qué ocurre entonces.
La tercera pregunta: ¿puedes salir sin el proveedor?
Una buena forma de estudiar cualquier servicio colaborativo es imaginar que mañana deja de existir.
No porque tenga que ocurrir, sino porque obliga a descubrir tus dependencias reales.
Pregúntate:
- ¿conservo suficientes claves para reconstruir y gastar?;
- ¿conservo la política completa de la wallet?;
- ¿dispongo de descriptores o información equivalente cuando sea necesaria?;
- ¿conozco las rutas de derivación y datos relevantes para reconstruir?;
- ¿puedo utilizar otro coordinador o software compatible?;
- ¿hay documentación pública del procedimiento de recuperación?;
- ¿he probado ese procedimiento?
Si la respuesta depende de que el proveedor siga prestando el servicio, entonces esa dependencia forma parte de tu modelo de custodia.
En multisig, la clave del proveedor no es toda la historia
En una arquitectura multisig, es fácil concentrarse únicamente en quién guarda las seeds.
Pero recuperar correctamente puede exigir información adicional sobre la wallet compartida.
Por ejemplo:
- qué claves públicas participan;
- qué umbral de firmas se requiere;
- qué derivaciones utiliza cada firmante;
- qué descriptor representa la política;
- qué software puede reconstruirla de forma compatible.
Una persona puede conservar dos semillas y, aun así, encontrarse con dificultades si no sabe qué política conjunta debe reconstruir.
Por eso una arquitectura colaborativa robusta debe explicar qué exportar y conservar fuera del servicio.
Separa los roles antes de evaluar la confianza
Un mismo proveedor puede desempeñar varios papeles. Conviene analizarlos por separado.
Un coordinador no es necesariamente un custodio
En algunos sistemas, una aplicación o servidor coordina las transacciones sin poseer suficientes claves para gastar.
Puede preparar una PSBT, recopilar firmas y transmitir la transacción.
Ese papel es distinto del firmante.
La distinción importa porque permite preguntar con precisión:
- ¿puedo sustituir el coordinador?;
- ¿puedo exportar la configuración de la wallet?;
- ¿mis firmantes funcionan con otro software?;
- ¿el proveedor conoce mis direcciones o saldos aunque no pueda gastar?
Una arquitectura puede minimizar el riesgo de custodia y seguir manteniendo una dependencia de privacidad o disponibilidad.
¿Qué puede aportar un colaborador?
Un tercero puede aportar valor sin custodiar completamente los fondos.
Por ejemplo, puede ayudar con:
- una firma adicional para reducir el riesgo de una única clave;
- recuperación si pierdes una de tus piezas;
- coordinación de multisig;
- notificaciones y monitorización;
- procedimientos de herencia;
- documentación y soporte;
- controles organizativos cuando varias personas participan.
La cuestión no es negar que esos servicios puedan ser útiles.
La cuestión es comprender qué nueva dependencia introduces a cambio de esa utilidad.
Una colaboración puede reducir un riesgo y crear otro
Supongamos que partes de una single-sig.
Una única clave perdida o comprometida puede ser crítica.
Introducir una política multisig con una clave de un proveedor puede reducir ese punto único de fallo.
Pero ahora aparecen nuevas obligaciones:
- conservar la configuración multisig;
- mantener varias claves;
- comprender cómo sustituir al proveedor;
- revisar la compatibilidad del software;
- entender qué metadatos recibe el colaborador;
- mantener el sistema durante años.
La evaluación correcta no es «multisig es más seguro».
Es:
¿qué riesgo concreto reduce y qué nuevas formas de fallo introduce?
Privacidad: el proveedor puede saber más de lo que imaginas
Un tercero no necesita tener capacidad de gasto para aprender información sensible.
Dependiendo del diseño, puede conocer:
- direcciones de la wallet;
- saldos;
- historial de transacciones;
- momentos en los que intentas gastar;
- datos de red o de cuenta;
- relaciones entre varias operaciones.
Si el servicio necesita una clave pública extendida, un descriptor o información similar para coordinar la wallet, la capacidad de observación puede ser significativa.
Por eso privacidad y custodia deben analizarse por separado.
Un proveedor puede no tener tus bitcoin y seguir teniendo una visión muy detallada de tu actividad.
Recuperación: estudia tres escenarios diferentes
Una arquitectura colaborativa debería poder explicar claramente qué ocurre al menos en estos escenarios.
1. Pierdes una de tus claves
¿El resto de claves permite recuperar? ¿Interviene el proveedor? ¿Qué autenticación exige? ¿Hay un procedimiento documentado?
2. Desaparece el proveedor
¿Puedes seguir gastando? ¿Necesitas esperar una condición temporal? ¿Puedes importar la política en otro software?
3. Desaparece la aplicación original
¿Tus backups son interoperables? ¿Conservas todo lo necesario para reconstruir la wallet con herramientas distintas?
Estas preguntas deberían tener respuestas antes de mover fondos importantes.
¿Y si el proveedor controla una clave de recuperación?
Ese diseño puede ser útil, pero conviene saber qué significa exactamente.
La clave del proveedor puede formar parte de un camino de recuperación que no se utiliza en el día a día.
En ese caso interesa conocer:
- en qué condiciones puede firmar;
- si hay demoras temporales;
- qué identidad o documentación exige;
- qué ocurre si rechaza la operación;
- qué alternativa existe si deja de prestar el servicio.
Una clave de recuperación no debería convertirse en una dependencia invisible.
Custodia colaborativa no equivale a “sin confianza”
Bitcoin permite reducir ciertas formas de confianza, pero no todas las relaciones entre personas y servicios desaparecen.
En una arquitectura colaborativa quizá no necesites confiar en que el proveedor no robe unilateralmente tus fondos.
Pero podrías seguir confiando en que:
- mantenga el servicio disponible;
- proteja correctamente su clave;
- respete un procedimiento de recuperación;
- no filtre información privada;
- mantenga la compatibilidad durante años;
- documente adecuadamente una migración.
La ventaja no es eliminar mágicamente toda confianza.
Es poder identificarla y, cuando sea posible, reducir su alcance.
Qué deberías poder obtener del proveedor
Antes de considerar una arquitectura colaborativa, merece la pena comprobar si puedes conservar de forma independiente información suficiente para entender y reconstruir el sistema.
Según la arquitectura, eso puede incluir:
- descripción clara del esquema de firmas;
- identificación de quién controla cada clave;
- información exportable de la wallet;
- descriptor o formato equivalente cuando corresponda;
- instrucciones de recuperación sin el software original;
- lista de herramientas compatibles;
- procedimiento de salida o migración;
- documentación sobre privacidad y datos almacenados.
Si todo eso solo existe dentro de una cuenta web, conviene considerar qué ocurriría si esa cuenta dejara de estar disponible.
Una lista breve para comparar servicios
Sin entrar todavía en marcas concretas, estas preguntas permiten comparar arquitecturas:
- ¿Quién puede gastar por sí solo?
- ¿Quién puede impedir temporal o permanentemente un gasto?
- ¿Cuántas claves necesito para salir del servicio?
- ¿Puedo recuperar sin el proveedor?
- ¿Puedo recuperar sin la aplicación original?
- ¿Qué información conoce el proveedor?
- ¿Qué datos debo guardar además de las seeds?
- ¿Puedo cambiar de coordinador o software?
- ¿Qué ocurre con la herencia?
- ¿He probado la recuperación?
Cuándo puede merecer la pena estudiarla
La custodia colaborativa puede ser interesante cuando existe un problema concreto que una tercera parte ayuda a resolver.
Por ejemplo:
- quieres reducir la dependencia de una única clave;
- necesitas apoyo de recuperación;
- quieres repartir responsabilidad entre varias personas;
- necesitas continuidad para una organización;
- quieres preparar una herencia con ayuda operativa.
Pero si el sistema introduce más complejidad de la que puedes mantener, la colaboración puede convertirse en otra fuente de riesgo.
El objetivo no debería ser utilizar la arquitectura más sofisticada.
Debería ser utilizar una arquitectura cuyo funcionamiento, recuperación y mantenimiento puedas explicar y comprobar.
Qué debes llevarte de este artículo
- “Custodia colaborativa” no define por sí sola las propiedades de seguridad.
- Necesitas saber quién controla cada clave y cuántas firmas hacen falta.
- Un proveedor puede no poder gastar y aun así ser capaz de bloquear o retrasar una operación.
- La salida sin proveedor es una de las pruebas más importantes de la arquitectura.
- En multisig debes conservar también la información necesaria para reconstruir la política de la wallet.
- Coordinador y firmante son roles diferentes.
- Un colaborador puede aportar recuperación y soporte sin convertirse necesariamente en custodio completo.
- El proveedor puede conocer información privada aunque no controle los fondos.
- La recuperación debe probarse, no suponerse.
Compara la arquitectura antes de elegir el servicio
Primero identifica el riesgo que quieres reducir. Después comprueba qué función cumple cada firmante, qué dependencia conserva el proveedor y cómo sería la recuperación en escenarios reales de pérdida, indisponibilidad o migración.