Pontos-chave
- Celo opera como Layer 2 de Ethereum; a descrição histórica como L1 já não define sua arquitetura atual.
- OP Stack, EVM e EigenDA cobrem funções diferentes dentro do sistema.
- Pagar gas com outra moeda depende do suporte do protocolo e da wallet utilizada.
O que é Celo?
Celo direciona sua infraestrutura a aplicações de pagamento e experiências acessíveis a partir de dispositivos móveis. Sua arquitetura atual é uma Layer 2 de Ethereum baseada em OP Stack. Ao especificar uma integração, é preciso usar essa arquitetura e não transferir sem revisão as premissas de sua etapa como Layer 1.
O valor para um produto está em como ela combina contratos EVM, ativos disponíveis e jornadas de usuário. A seleção deve incluir a aquisição do ativo de pagamento, o custo das taxas e a saída para o sistema de que o destinatário precisa.
Como funciona
Celo separa execução compatível com EVM, disponibilidade de dados via EigenDA e liquidação sobre Ethereum. Os contratos do protocolo acrescentam funções específicas, entre elas a gestão das moedas admitidas para pagar taxas.
Uma wallet e o cliente da aplicação devem construir transações compatíveis com essas funções. Não basta exibir um saldo de stablecoin para presumir que ele possa ser usado como gas. Os testes verificam a moeda aceita, sua configuração e o comportamento quando o usuário não tem saldo suficiente ou troca de rede.
A moeda das taxas é configurada como parte da transação, e sua disponibilidade depende das opções admitidas pela rede. A integração precisa estimar custos nessa modalidade e revisar o suporte do provedor RPC e da wallet. Um patrocínio de gas, se usado, acrescenta ainda um orçamento e regras de autorização próprios.
O que Celo oferece
Celo pode se encaixar em aplicações de pagamento que priorizam a experiência de uso e precisam de contratos Solidity. É especialmente relevante avaliar suas opções de taxas quando o usuário deveria operar com um ativo principal sem gerenciar vários saldos habitualmente.
Na Metlabs, verificamos a jornada de recebimento, envio e conciliação com a wallet específica do produto. Também revisamos os serviços de entrada e saída disponíveis para o público-alvo. A melhoria de experiência é validada sobre essa jornada, sem inferi-la apenas da orientação móvel da rede.
Em uma aplicação de remessas ou cobranças, testa-se o que acontece se o destinatário recebe o ativo mas não consegue concluir o passo seguinte da jornada. Também se conciliam devoluções e pagamentos pendentes, diferenciando o resultado do contrato do resultado do provedor de entrada ou saída. A experiência móvel é avaliada com conectividade intermitente e recuperação de sessão: um envio que demora a aparecer não deve induzir uma segunda operação.
Limitações e critérios de escolha
O pagamento de taxas em moedas distintas acrescenta compatibilidades que devem ser verificadas por wallet e ferramenta. A arquitetura L2 incorpora ainda dependências de sequenciamento, disponibilidade de dados e bridges. São aspectos diferentes da segurança dos contratos da aplicação.
Stellar pode ser uma alternativa para fluxos de pagamento baseados em operações nativas; outras Layer 2 podem se encaixar melhor com determinadas dependências EVM. A comparação deve considerar acesso a ativos e serviços, não só taxas. Escolher Celo não resolve automaticamente a jornada bancária de entrada ou saída.
