Puntos clave
- Celo opera como capa 2 de Ethereum; la descripción histórica como L1 ya no define su arquitectura actual.
- OP Stack, EVM y EigenDA cubren funciones diferentes dentro del sistema.
- Pagar gas con otra moneda depende del soporte del protocolo y de la wallet utilizada.
¿Qué es Celo?
Celo orienta su infraestructura a aplicaciones de pago y experiencias accesibles desde dispositivos móviles. Su arquitectura actual es una capa 2 de Ethereum basada en OP Stack. Al especificar una integración hay que utilizar esa arquitectura y no trasladar sin revisión las premisas de su etapa como capa 1.
El valor para un producto está en cómo combina contratos EVM, activos disponibles y recorridos de usuario. La selección debe incluir la adquisición del activo de pago, el coste de las comisiones y la salida hacia el sistema que necesita el destinatario.
Cómo funciona
Celo separa ejecución compatible con EVM, disponibilidad de datos mediante EigenDA y liquidación sobre Ethereum. Los contratos del protocolo añaden funciones específicas, entre ellas la gestión de monedas admitidas para pagar comisiones.
Una wallet y el cliente de la aplicación deben construir transacciones compatibles con esas funciones. No basta con mostrar un saldo de stablecoin para asumir que puede utilizarse como gas. Las pruebas verifican la moneda aceptada, su configuración y el comportamiento cuando el usuario no dispone de saldo suficiente o cambia de red.
La moneda de comisiones se configura como parte de la transacción, y su disponibilidad depende de las opciones admitidas por la red. La integración necesita estimar costes con esa modalidad y revisar el soporte del proveedor RPC y de la wallet. Un patrocinio de gas, si se utiliza, añade además un presupuesto y reglas de autorización propios.
Qué aporta Celo
Celo puede encajar en aplicaciones de pago que priorizan la experiencia de uso y necesitan contratos Solidity. Es especialmente relevante evaluar sus opciones de comisiones cuando el usuario debería operar con un activo principal sin gestionar varios saldos de forma habitual.
En Metlabs, comprobamos el recorrido de cobro, envío y conciliación con la wallet concreta del producto. También revisamos los servicios de entrada y salida disponibles para el público objetivo. La mejora de experiencia se valida sobre ese recorrido, sin inferirla únicamente de la orientación móvil de la red.
En una aplicación de remesas o cobros, se prueba qué ocurre si el destinatario recibe el activo pero no puede completar el siguiente paso del recorrido. También se concilian devoluciones y pagos pendientes, diferenciando el resultado del contrato del resultado del proveedor de entrada o salida. La experiencia móvil se evalúa con conectividad intermitente y recuperación de sesión: un envío que tarda en mostrarse no debe inducir una segunda operación.
Limitaciones y criterios de elección
El pago de comisiones en distintas monedas añade compatibilidades que deben comprobarse por wallet y herramienta. La arquitectura L2 incorpora además dependencias de secuenciación, disponibilidad de datos y puentes. Son aspectos diferentes de la seguridad de los contratos de la aplicación.
Stellar puede ser una alternativa para flujos de pago basados en operaciones nativas; otras capas 2 pueden encajar mejor con determinadas dependencias EVM. La comparación debe considerar acceso a activos y servicios, no solo comisiones. Elegir Celo no resuelve automáticamente el recorrido bancario de entrada o salida.
