De «¿cuánto te debo?» a una sola transacción

Domingo por la tarde. Cuatro amigos vuelven de un fin de semana fuera. Camille reservó el alojamiento, Alex hizo la compra y Lou pagó el aparcamiento. Sam pregunta cuánto tiene que enviar.

Los personajes y los importes son inventados. Hagamos las cuentas. Para mantener las mismas cifras hasta el pago, los gastos del ejemplo ya están expresados en USDC, el token que utiliza Spliz para los pagos.

Camille ha adelantado 120. Alex, 60. Lou, 20. Sam todavía no ha adelantado nada. El total es de 200 USDC, repartidos a partes iguales: 50 por persona.

Camille tiene que recibir 70 y Alex 10. Sam debe pagar 50; Lou, 30.

Sam ya sabe cuánto. Todavía le falta saber a quién enviárselo. Y Camille acaba de encontrar otro recibo en el bolsillo.

Al crear Spliz, tuvimos que dar cabida a cada uno de esos momentos. El recibo que aparece tarde, el importe aceptado, el dinero enviado. Pueden sucederse en segundos o quedar pendientes durante semanas. La aplicación tiene que reflejar en qué punto están las cuentas.

Cuatro saldos, tres transferencias

Los amigos podrían liquidar los saldos actuales con estos pagos:

Después de las tres transferencias, cada persona habrá asumido su parte de 50 USDC. De los 200 gastados durante el viaje, solo quedan 80 por mover. En este primer cálculo dejamos aparte las posibles comisiones de la liquidación.

Este mecanismo se llama compensación. Se calcula cuánto ha adelantado cada persona, se resta su parte y se conectan los pagos pendientes con los importes por recibir.

Hay distintas formas de elegir las transferencias. Reducir el dinero total que circula y reducir el número de transferencias son objetivos distintos. La tesis de David Vávra (2012) describe como máximo N−1 transferencias para N participantes, sin garantizar el mínimo.

Son problemas estudiados desde hace tiempo. En 2018, Adrien Arcuri describía un contrato de Ethereum para compartir gastos, con acuerdos de los participantes y pagos en Ether.

Esos trabajos establecen las bases. En nuestro ejemplo, las cuentas caben en unas líneas. Para enviar los 80 USDC todavía falta algo que ningún cálculo puede producir.

Mostrar un importe no autoriza a cobrarlo

Supongamos que Sam acepta pagar sus 50 USDC. Antes del pago, Camille añade el recibo olvidado: otros 40 USDC para el grupo. La parte de cada persona aumenta en 10. Sam ahora debe 60.

Haber aceptado 50 no autoriza un cobro de 60.

Hay que precisar, por tanto, qué significa confirmar. En Spliz, la aprobación de la liquidación toma la forma de un mensaje firmado. Incluye el identificador del Spliz, el participante, su papel como pagador o receptor, su importe y un límite de comisiones. Una marca de tiempo acota su validez.

El formato, EIP-712, define cómo firmar datos estructurados. Un contrato, el programa que ejecutará la liquidación en Base, puede comprobar quién firmó y detectar cambios en los campos firmados. El contexto de la firma también identifica la red y el contrato correspondientes.

Registrar un gasto en la aplicación nunca concede, por sí solo, permiso para mover fondos.

En el flujo de la aplicación, un cambio que modifica los saldos elimina las confirmaciones existentes. El grupo debe aceptar el nuevo cálculo. Esta invalidación ocurre en el servidor: borrar una aprobación de la base de datos no borra los bytes de una firma ya creada.

Conviene dejar clara esa separación. El contrato comprueba las autorizaciones y la coherencia de las transferencias que recibe. No lee el recibo de Camille ni recalcula todos los gastos. Conectar el registro con la liquidación sigue siendo responsabilidad de la aplicación.

Después llega el permiso para gastar

Volvamos al cálculo inicial, antes del recibo olvidado. Sam acepta pagar 50, Lou 30, Camille espera recibir 70 y Alex 10.

El contrato dispone de sus acuerdos. También necesita permiso para transferir los USDC de quienes pagan.

Esta segunda autorización utiliza un permit, definido en ERC-2612. Sam y Lou firman un permiso de gasto para el contrato, con un importe y una fecha límite. El importe cubre su pago y las comisiones aplicables. Un contador impide presentar el mismo permit repetidamente.

Quien paga firma, por tanto, dos objetos distintos: su acuerdo con la liquidación y la autorización para gastar el token. Conviene explicarlo cuando ambos se reúnen bajo un botón de confirmación.

Las firmas se generan fuera de la cadena. Los amigos pueden confirmar en momentos distintos. Un servidor, llamado relayer, reúne las firmas necesarias y envía la transacción a Base. También paga la comisión de red, conocida como gas, de esa operación.

Los USDC permanecen en las carteras de los participantes hasta la transferencia. Esta liquidación no exige un depósito previo en un fondo común.

1. La aplicación calcula los saldos a partir de los gastos.
2. Los participantes aprueban la liquidación. Quienes pagan también firman un permit.
3. El relayer envía las autorizaciones al contrato en Base.
4. El contrato las comprueba y ejecuta las transferencias en una misma transacción.

Cubrir el gas no elimina todos los costes. La versión descrita aquí cobra el 0,1 % del importe transferido, con un mínimo de 0,10 USDC. Nuestro ejemplo de 80 USDC añade, por tanto, 0,10 USDC de comisión, repartidos entre quienes pagan. Comprar USDC o convertirlos de nuevo también puede costar dinero.

La última transferencia puede deshacer las anteriores

Supongamos que a Lou solo le quedan 25 USDC al ejecutarse el pago. El contrato inicia las transferencias. Los 50 de Sam pasan. Los 20 de Lou para Camille también. A Lou le quedan 5: la transferencia de 10 para Alex falla.

En la liquidación atómica de Spliz, ese fallo revierte los efectos de las transferencias anteriores de la misma transacción. Camille no conserva una parte del pago mientras Alex espera el resto.

Ese es el significado preciso de atómica: las transferencias de esa transacción se completan juntas o ninguna surte efecto. El relayer sigue pagando el gas consumido por una transacción fallida.

El contrato comprueba las firmas antes de ejecutar las transferencias. También verifica que los importes enviados y recibidos coincidan con las aprobaciones, que no haya participantes duplicados y que ese Spliz no se haya liquidado antes. Los USDC pasan directamente de la cartera de quien paga a la de quien recibe.

Una sola transacción contiene varias transferencias. Agruparlas también reduce el número de transacciones que hay que enviar, pero aquí importa especialmente que compartan el resultado.

Otro detalle apenas se ve en una demostración: el teléfono puede perder la conexión después del envío. Ese silencio no dice nada del resultado en Base. La aplicación tiene que localizar la transacción y comprobar su estado antes de anunciar un éxito o preparar otro intento.

Firmar, enviar y confirmar son etapas distintas. Confundirlas puede hacer que la pantalla muestre «pagado» antes de que el pago se haya completado.

El pago ocurrió. El cero ya no basta.

Después de un reembolso, el saldo de Sam queda a cero. Al día siguiente quiere salir del Spliz.

Una regla parece razonable: una entrada con saldo cero ya no tiene deuda y se puede borrar. Fue uno de los problemas que surgieron al diseñar el registro de Spliz.

Sin embargo, ese cero puede contar dos historias. Sam ha devuelto 50 USDC. Otra persona nunca tuvo ningún gasto ni pago. Si la regla de borrado solo mira el saldo, trata ambas situaciones por igual.

La entrada de Sam contiene una prueba que puede necesitar más adelante. Si dentro de dos semanas Camille cree que falta un reembolso, Sam debe poder mostrar qué ocurrió.

Hay que conservar los hechos que explican el saldo. Un gasto registra un adelanto y su reparto. Un pago registra un movimiento de dinero. El saldo se calcula a partir de esos elementos; no puede sustituirlos.

Esta distinción también cambia cómo se corrige un error. Si el grupo revisa un reparto después de un reembolso individual, ese pago sigue contando. El nuevo cálculo debe incluirlo.

Vávra también registra cambios en el 25 % de las operaciones, entre febrero y abril de 2012. En Spliz habrá que medirlo con uso real.

Ahora comprobamos cada regla con una pregunta concreta: después de una acción, ¿puede alguien recuperar el importe que debe, su destinatario y los registros que lo explican? Si desaparece una de esas respuestas, el modelo ha perdido algo.

La blockchain no sabe qué había en el recibo

El recibo olvidado de Camille puede ser correcto. También puede incluir una compra personal. Ninguna firma resuelve esa duda.

Un contrato ejecuta autorizaciones según unas reglas. No sabe quién estaba en la cena. Tampoco aporta los fondos de un amigo al que le falta dinero ni obliga a nadie a confirmar.

En un artículo de 2017 sobre retrasos en los pagos, Matteo Pelati proponía compensar deudas entre empresas. La idea reduce el dinero necesario cuando unas obligaciones compensan otras. Los importes restantes siguen requiriendo un pago.

Para nuestros amigos, esperar todas las aprobaciones tiene un coste: la liquidación colectiva depende de la última persona que esté lista para pagar. Es una razón para mantener una vía de reembolso individual.

Los pagos realizados por otros medios exigen el mismo cuidado. Si Lou devuelve el dinero en efectivo, la aplicación puede registrar su declaración. No debe mostrarla como una transferencia que haya observado en la red. Quien lea el historial tiene que entender qué acredita cada entrada.

También existen otras dependencias. Spliz utiliza un servidor para el registro y un relayer autorizado para enviar las liquidaciones. El contrato puede pausarse. Las transferencias en una cadena pública son visibles. Una dirección de cartera también puede vincularse a una persona, como recuerda la autoridad francesa de protección de datos, CNIL. Llevar la ejecución a Base no hace autónoma a toda la aplicación ni privados sus pagos.

El camino que queda hasta la cuenta bancaria

¿Por qué USDC? Este token, emitido por Circle, busca mantener el valor de un dólar estadounidense. Puede circular mediante contratos, incluido el de Spliz. Circle explica su respaldo y funcionamiento.

Así se evita denominar los reembolsos en un activo como Ether, cuyo precio puede variar mucho. Quedan otras condiciones: USDC depende de su emisor y un importe en USDC no equivale a ese mismo importe en euros. Nuestro ejemplo deja fuera la conversión de divisas.

Un grupo que ya tiene USDC en Base puede pagar con esos fondos. Quien quiere pagar desde su banco y recibir en su banco todavía debe pasar por una compra o conversión, a veces verificar su identidad y posiblemente retirar los fondos.

Todo ese recorrido tiene que resultar útil. La velocidad de la transacción final no basta para evaluar el tiempo y el esfuerzo que han invertido los amigos.

El próximo fin de semana

La compensación, las firmas y la atomicidad son mecanismos conocidos. Combinarlos en Spliz plantea cuestiones que se pueden comprobar en el código. Saber si la gente quiere usar la aplicación exige otro tipo de pruebas.

Queremos observar a grupos registrar gastos, encontrar un error y devolverse el dinero sin necesitar nuestras explicaciones. Medir dónde dudan. Ver si vuelven a abrir Spliz en otra ocasión.

Camille debe poder añadir su recibo. Sam debe entender por qué cambia su importe antes de aceptarlo. Una vez completado el reembolso, debe poder encontrar su registro sin pedirle a Camille que rehaga las cuentas.

El próximo fin de semana, nos gustaría que el mensaje fuera: «Ya he creado el Spliz».

Fuentes

• David Vávra (2012): algoritmos y uso, secciones 2.4 y 5.2.2.
• Adrien Arcuri (22 de marzo de 2018): gastos compartidos en Ethereum, acuerdos y pagos.
• Matteo Pelati (8 de julio de 2017): compensación de deudas entre empresas.
• EIP-712 (2017): firmas de datos estructurados y separación de dominios.
• ERC-2612 (2020): permisos de gasto firmados, importes, nonces y fechas límite.
• Documentación de Solidity: propagación de errores y reversión de cambios en las llamadas afectadas.
• Ethereum.org: transacciones, comisiones de red y etapas de confirmación.
• Circle: funcionamiento de USDC y reservas de su emisor.
• CNIL, autoridad francesa de protección de datos: blockchain, identificación de participantes y datos personales (en francés).

Fuentes consultadas el 7 de septiembre de 2026.