Scaffolding de un contrato de escrow en Celo

Antes de escribir lógica compleja, conviene dibujar el esqueleto. El scaffolding de un contrato inteligente consiste en definir qué variables y métodos vivirán dentro del contrato, sin entrar todavía en la implementación detallada. Es la forma más clara de razonar el diseño antes de programar.

En este recorrido vas a ver cómo planear un sistema de venta con retención de pago en Celo, pensado para compradores, vendedores y un árbitro que resuelve disputas.

¿Qué problema resuelve este contrato inteligente en Celo?

La idea es simple: un comprador paga por un producto, pero el dinero no llega directo al vendedor. Queda retenido en el contrato hasta que el comprador confirme que recibió lo prometido.

Si algo sale mal, por ejemplo si el comprador quiere desconocer la entrega, entra en juego un árbitro que decide qué hacer con el pago. Esa lógica de escrow es la magia que permite blockchain: confianza sin intermediarios bancarios.

¿Qué es el scaffolding en un contrato inteligente? Es el proceso de definir la estructura básica del contrato (variables y funciones vacías) antes de escribir la lógica interna. Te ayuda a razonar el diseño completo desde el inicio.

¿Qué variables de estado necesita el contrato?

Para que el contrato funcione, necesitas guardar información clave sobre los participantes y la etapa del proceso. Acá entra el concepto de state variables, que son los datos persistentes en la blockchain.

El contrato requiere estas variables:

• La dirección del comprador, almacenada como tipo address.
• La dirección del vendedor, también como address.
• La dirección del árbitro, quien resuelve disputas.
• Una variable bool llamada depósito listo, que se activa cuando el comprador realiza el pago inicial.
• Una segunda bool que indica que el comprador confirmó la recepción del producto.
• Una tercera bool que marca que el proceso está completo, cuando el vendedor retira su pago.
• Una variable numérica que guarda el monto del pago administrado por el contrato.

Usar tres variables booleanas es una decisión de diseño. Podrías reemplazarlas por un código de estado (un enum o un uint), pero acá se eligió el camino más explícito para que cada etapa tenga su propia bandera.

¿Por qué separar el constructor del depósito?

Podrías hacer que el comprador deposite el dinero al momento de crear el contrato, todo en el constructor. Pero separar ambos pasos da más flexibilidad: primero se despliega el contrato y después el comprador deposita cuando esté listo. Es una decisión arquitectónica que vale la pena entender.

¿Qué funciones debe tener el contrato inteligente?

Con las variables claras, toca definir los métodos que mueven al contrato de un estado a otro. Cada función representa una acción concreta de uno de los actores.

Las funciones del scaffolding son:

1. Constructor: recibe los parámetros iniciales (direcciones del comprador, vendedor y árbitro) y setea las variables de estado.
2. Depositar pago: la ejecuta el comprador para enviar el monto al contrato. Activa la variable depósito listo.
3. Confirmar recepción: la ejecuta el comprador cuando recibe el producto conforme. Da luz verde al siguiente paso.
4. Retirar pago: la ejecuta el vendedor para cobrar, una vez que el comprador confirmó.
5. Intervención del árbitro: se activa si hay disputa. El árbitro decide cómo se libera el pago.

¿Qué hace el árbitro en un contrato de escrow? Es una tercera parte neutral que interviene cuando comprador y vendedor no llegan a un acuerdo. Tiene la potestad de ejecutar el pago según su criterio.

¿Cómo se conectan variables y funciones en el flujo?

El flujo natural va así: se despliega el contrato con el constructor, el comprador llama a depositar pago, recibe el producto, llama a confirmar recepción y finalmente el vendedor ejecuta retirar pago. Si algo se rompe en el medio, aparece el árbitro.

Cada bool funciona como un candado. La función de retirar pago no debería ejecutarse si la confirmación de recepción no está activa. Esa lógica de validación es la que vas a programar más adelante con condicionales.

¿Por qué usar booleanos en lugar de un enum? Los bool son más explícitos y fáciles de leer cuando hay pocos estados. Un enum o código de estado escala mejor si el flujo tiene muchas etapas.

Con este esqueleto, el contrato ya tiene forma. Falta darle vida con condicionales, validaciones y manejo de fondos, pero el diseño general está sobre la mesa. ¿Cómo organizarías tú las variables de estado en un contrato de venta? Cuéntame en los comentarios.