El problema: la confianza no escala
Un desistimiento es un acto jurídicamente vinculante. Quien afirma haber desistido necesita una prueba. Quien afirma haber recibido un desistimiento, también. En la configuración clásica guardas las entradas en tu base de datos, además de un archivo de registro, y esperas que nadie afirme que cambiaste algo.
El problema: el operador de la base de datos, es decir, nosotros, podría en teoría editarlo todo a posteriori. Un abogado que cuestione tu prueba lo tiene fácil. “¿Cómo sabemos que este registro de la base de datos data realmente del momento de la recepción?”
La solución en una frase
Cada desistimiento recibe una huella. Al final del día reunimos todas las huellas en un árbol. Publicamos la raíz de ese árbol. Cualquiera puede comprobar más tarde si su desistimiento estaba realmente en el árbol, sin obtener acceso a los demás desistimientos.
Quien no lea el resto de este artículo ya ha captado lo esencial.
La huella: SHA-256
SHA-256 es una función hash criptográfica. Introduces cualquier cantidad de texto y obtienes 64 caracteres. Estos 64 caracteres son únicos para ese texto. Cambia una sola coma y la huella entera cambia. Es prácticamente imposible encontrar dos textos distintos que produzcan la misma huella.
En nuestro sistema, cada desistimiento se serializa al recibirse en un bloque de texto definido: nombre, contacto, referencia del pedido, texto libre, marca de tiempo al milisegundo, ID de la tienda. Este bloque pasa por SHA-256. Resultado: una huella de 64 caracteres.
La huella es como la prueba de un sobre sellado. Si más tarde mostramos el contenido y alguien recalcula la huella, debe coincidir exactamente de nuevo. Si un solo carácter difiere, por ejemplo porque acortamos el nombre a posteriori, la huella ya no coincide. La manipulación se hace visible.
El árbol: árbol de Merkle
Una huella por desistimiento está bien, pero todavía no basta. Tendríamos que publicar cada huella individualmente para hacerlas verificables. Eso sería una pesadilla para la protección de datos, porque a partir de las huellas más la información “esta huella estaba en el servidor en el momento X” se podrían extraer conclusiones.
Los árboles de Merkle lo resuelven de forma elegante. Tomas dos huellas, las combinas y vuelves a aplicar hash al resultado. Tomas este nuevo par de huellas junto con el siguiente par, hasta que al final solo queda una huella: la raíz del árbol.
Desistimiento A → hash_A ─┬───── hash_AB ─┬──────────┐
Desistimiento B → hash_B ─┘ │ │
│ Raíz
Desistimiento C → hash_C ─┬───── hash_CD ─┘
Desistimiento D → hash_D ─┘La raíz solo es exactamente la misma si cada desistimiento situado debajo permanece inalterado. Una sola letra modificada en un solo desistimiento haría cambiar su huella, luego la huella del par superior, luego la siguiente, hasta llegar a la raíz. La raíz ya no coincidiría.
La analogía del notario
Imagina un notario. Cada día a medianoche reúne todos los desistimientos del día, los anota en un libro, sella el libro y lo guarda en una caja fuerte. A la mañana siguiente publica en un panel frente a su casa un código corto que solo corresponde a ese libro.
Si más tarde alguien viene y reclama que su desistimiento está en el libro, el notario puede mostrárselo: “Sí, mire, aquí en la página 47, línea 12. El código del panel coincide exactamente con este libro. Si yo hubiera cambiado algo, el código ya no coincidiría, y todos lo verían en el panel.”
El libro es la base de datos. El sello es la huella SHA-256. El panel es nuestro endpoint público. El código es la raíz de Merkle.
La raíz pública: /proof
Cada día a medianoche calculamos el árbol de Merkle de todos los desistimientos recibidos ese día. Escribimos la raíz en un endpoint público en /proof/root/YYYY-MM-DD.
Cada propietario de tienda recibe un proof_token para cada desistimiento. Es la ruta completa a través del árbol, desde su propio desistimiento hasta la raíz. Con este token, cualquier tercero, también un juez, también el propio cliente, puede verificar su autenticidad.
GET /proof/{token}
Response 200:
{
"revocationHash": "9f86d081884c7d659a2feaa0c55ad015...",
"merkleProof": ["a3f5...", "b2e8...", "c1d4..."],
"merkleRoot": "5d41402abc4b2a76b9719d911017c592...",
"publishedAt": "2026-04-13T00:00:00Z",
"verifiable": true
}Quien quiera comprobar la lógica toma el revocationHash, lo combina según las reglas de los árboles de Merkle con los elementos de merkleProof, y debería obtener al final exactamente el merkleRoot. Esto se puede recalcular en diez líneas de código en cualquier lenguaje de programación.
Protección de datos: por qué sigue siendo compatible con el RGPD
Lo ingenioso del árbol de Merkle es que la raíz no permite extraer conclusiones sobre los desistimientos individuales. No publicamos ni los nombres, ni los correos, ni siquiera las huellas individuales. Solo la raíz y, por desistimiento, la prueba de ruta individual.
La prueba de ruta solo la obtiene quien conoce el proof_token. Y solo lo obtienen el propietario de la tienda, el cliente, y quienquiera que reciba el token de uno de los dos. No existe ninguna lista pública.
Así, la construcción satisface a la vez dos requisitos aparentemente contradictorios: la verificabilidad pública y la protección de datos conforme al RGPD de las operaciones individuales.
Por qué se sostiene ante un tribunal
Un juez no necesita entender cómo funciona SHA-256 para aceptar un peritaje basado en SHA-256. La función está estandarizada desde 2001, la usan en todo el mundo bancos, gobiernos y blockchains, y no está rota criptográficamente.
Lo importante es que la raíz de Merkle se publicó en un momento en que nadie podía influir ya en ella a posteriori. Por eso la escritura a medianoche, y por eso el almacenamiento inmutable. Quien afirme que añadimos un registro a posteriori tendría que explicar cómo modificamos a la vez la raíz que ya se había hecho pública al día siguiente. Esa explicación no existe mientras SHA-256 no esté roto.
En la práctica: lo que ves en el panel
En el panel cada desistimiento recibe un enlace a /proof/{token}. Puedes pasar este enlace a un abogado o comprobarlo tú mismo. En un eventual litigio, esta es tu verificación técnicamente neutral, independiente de nosotros.
Y como nosotros mismos no podemos intervenir en el árbol sin destruir la raíz pública, también nosotros quedamos vinculados por la prueba. No es una promesa de marketing, sino un límite estructural del sistema.
Por qué otros proveedores no tienen esto
La mayoría de los proveedores de botón de desistimiento simplemente escriben la entrada en su base de datos y se fían de las copias de seguridad y de su buena conciencia. Eso basta hasta que el primer litigio se agrava. Entonces te quedas con una fila de base de datos que un perito técnico clasifica como manipulable en diez segundos.
Optamos por el esfuerzo adicional porque la obligación derivada de la Directiva (UE) 2023/2673 (que regula el derecho de desistimiento en el TRLGDCU / Real Decreto Legislativo 1/2007 y se aplica en toda la UE desde el 19 de junio de 2026) es demasiado nueva para fiarse de la costumbre. Las primeras resoluciones judiciales todavía están por llegar. Cuando lleguen, querrás estar en el lado donde están las matemáticas.
Detalles sobre la implementación en nuestra guía o en la página de producto.