Blockchain para Impacto Social: Lições de Construir com a UNICEF

Em 2021, a Xcapit recebeu investimento do UNICEF Innovation Fund para construir uma carteira blockchain não custodial voltada para a inclusão financeira na América Latina. Na época, eu havia acabado de sair da Deloitte, onde medíamos o sucesso com métricas familiares — TIR, EBITDA, participação de mercado. O que se seguiu foi uma das experiências intelectualmente mais exigentes da minha vida profissional, e não principalmente por razões técnicas. O desafio era descobrir o que o sucesso realmente significava quando os seus usuários são famílias em zonas rurais do Peru acessando as finanças digitais pela primeira vez.

Essa pergunta — o que significa o sucesso aqui? — é a tensão central na tecnologia de impacto social. É uma pergunta que o software empresarial quase nunca precisa responder da mesma forma. O software empresarial falha quando não reduz custos ou não aumenta receitas. O software de impacto social pode falhar mesmo quando é amplamente adotado, se essa adoção não se traduzir em melhoria significativa na vida das pessoas. Essa distinção muda tudo sobre como se constrói, como se mede e como se tomam decisões de produto.

Projetar para o Mundo Real, Não para o Ambiente de Demo

A primeira lição que internalizamos — de forma dolorosa — foi que projetar para ambientes de baixa conectividade não é uma funcionalidade que se adiciona no final do desenvolvimento. É uma restrição arquitetural que deve governar cada decisão desde o primeiro dia. As comunidades andinas do Peru, onde parte do nosso piloto foi realizada, têm conectividade móvel que cai para 2G ou desaparece completamente em muitas áreas. Os fluxos padrão de onboarding em Web3 presumem uma conexão banda larga estável, um smartphone com pelo menos 4GB de RAM e um usuário confortável navegando por múltiplas telas de confirmação. Nenhuma dessas suposições era válida.

Reconstruímos o fluxo de onboarding três vezes. A primeira versão era tecnicamente correta e completamente inutilizável. A segunda era mais simples, mas ainda exigia uma conexão à internet estável para concluir a geração da carteira e o backup da frase semente. A terceira versão — a que realmente funcionou nos testes de campo — armazenava localmente o processo de geração da carteira em cache, guardava a tarefa de backup da frase semente como uma ação recuperável offline e reduzia a transferência de dados do caminho crítico para menos de 50 kilobytes. Isso permitia que os usuários iniciassem o processo durante um momento de conectividade e concluíssem as partes sensíveis em casa, no seu próprio ritmo.

A camada de interação com a carteira baseada em SMS que pilotamos no Peru merece menção especial. Uma parcela significativa da população-alvo usava telefones básicos ou smartphones de baixo custo onde instalar um aplicativo era impraticável por restrições de armazenamento. Construímos um canal de interação paralelo usando USSD e SMS que permitia aos usuários verificar saldos, iniciar transferências e receber notificações sem o aplicativo. Essa não era uma engenharia glamorosa. Exigia integração com APIs de operadoras locais de telecomunicações, mal documentadas e instáveis, a construção de uma máquina de estados para fluxos SMS de múltiplas etapas e testes extensivos com telefones reais de campo em vez de emuladores. Mas expandiu significativamente a população alcançável.

As Métricas de Inclusão Financeira que Realmente Importam

O framework de reporte da UNICEF nos empurrou em direção a métricas de resultado que, honestamente, não teríamos priorizado por conta própria. O fundo não queria apenas saber quantas carteiras tínhamos criado. Queria evidências de mudança no comportamento financeiro. Os usuários estavam poupando de forma mais consistente? Estavam acessando remessas a custos menores do que os canais tradicionais? Estavam construindo históricos de crédito que poderiam eventualmente conectá-los ao crédito formal? Essas perguntas exigem dados longitudinais, o que requer manter relacionamentos com os usuários ao longo do tempo — um modelo operacional completamente diferente das típicas métricas de aquisição SaaS.

Fizemos parceria com ONGs locais para a coleta de dados em campo. Conduzimos entrevistas estruturadas nos intervalos de 3 e 6 meses. Aprendemos que as taxas de ativação de carteira — que parecem ótimas numa apresentação — dizem quase nada sobre o impacto. De 100 usuários que ativaram uma carteira, aproximadamente 60 realizaram pelo menos uma transação na primeira semana. No terceiro mês, apenas cerca de 30 ainda estavam ativos. No sexto mês, cerca de 15. Esses 15 usuários, no entanto, apresentavam indicadores significativos de mudança no comportamento financeiro: padrões de poupança mais consistentes, menor dependência de emprestadores informais e pontuações mais altas em avaliações de educação financeira. Também eram mais propensos a recomendar o produto a familiares, o que se tornou nosso principal mecanismo de crescimento.

A lição aqui é desconfortável para fundadores orientados ao crescimento: o seu número principal será o que parece pior. A ativação é fácil; a retenção é difícil; a mudança comportamental é ainda mais difícil. A UNICEF nos pressionou a medir as coisas difíceis, e essa disciplina nos fez construir um produto melhor. Quando paramos de otimizar para a ativação e começamos a otimizar para a retenção em seis meses, tudo mudou — o conteúdo de onboarding, a estratégia de notificações, o modelo de suporte, as parcerias que priorizamos.

Navegando a Complexidade Regulatória sem um Departamento de Compliance

A regulamentação de blockchain na América Latina entre 2021 e 2023 estava, para dizer diplomaticamente, evoluindo rapidamente. Peru, Colômbia, Argentina e Brasil tinham frameworks diferentes — alguns explícitos, alguns implícitos, todos sujeitos a mudanças. Como startup operando em múltiplas jurisdições com uma carteira não custodial (ou seja, nunca mantivemos fundos de usuários diretamente), existíamos em uma zona cinzenta que era simultaneamente libertadora e geradora de ansiedade. O modelo não custodial foi uma escolha deliberada para reduzir o risco regulatório: estávamos construindo infraestrutura, não captando depósitos.

O desafio prático era explicar essa distinção a reguladores que eram, compreensivelmente, cautelosos com tudo relacionado à blockchain após vários colapsos de alto perfil no setor. Investimos tempo significativo em educação regulatória — não lobbying, mas compartilhamento genuíno de conhecimento com equipes de bancos centrais e organismos reguladores financeiros. Isso era incomum para uma startup do nosso tamanho, mas o apoio institucional da UNICEF abriu portas que de outra forma teriam permanecido fechadas. A lição: as relações regulatórias não são apenas uma função de compliance; são um ativo estratégico, especialmente quando se opera em mercados emergentes com tecnologia inovadora.

Também aprendemos da forma mais difícil que os requisitos de compliance em diferentes jurisdições não se encaixam de forma ordenada. Os padrões de KYC na Argentina exigem verificação biométrica que os usuários peruanos não conseguiam completar praticamente. Os limites de monitoramento de transações diferem em ordens de magnitude entre os mercados. Construir um produto que seja compliant em todos os lugares significa construir conforme o padrão mais restritivo em todos os lugares, o que pode minar a missão de inclusão financeira ao adicionar atrito exatamente para os usuários que se tenta alcançar. Por fim, construímos uma camada de compliance ciente da jurisdição que aplicava os requisitos corretos com base na localização do usuário, mas isso acrescentou três meses ao nosso cronograma e uma carga de manutenção contínua significativa.

O que a Certificação de Bem Público Digital Realmente Exige

Obter a certificação de Bem Público Digital (BPD) da Digital Public Goods Alliance foi um marco que perseguimos deliberadamente, e o processo foi mais rigoroso do que antecipamos. O padrão BPD avalia nove critérios: relevância para os Objetivos de Desenvolvimento Sustentável, licenciamento aberto, propriedade clara, independência de plataforma, documentação, extração de dados, proteção de privacidade, aderência a padrões de privacidade e — fundamentalmente — evidência de não causar dano. Esse último critério é genuinamente difícil de satisfazer no espaço blockchain, onde o consumo de energia e os casos de uso especulativos são preocupações legítimas.

Nossa candidatura ao BPD nos exigiu documentar não apenas o que o produto fazia, mas como as decisões sobre o produto eram tomadas, quem poderia contribuir para o codebase e como o feedback da comunidade era incorporado. O requisito de código aberto significou tornar nosso codebase totalmente público, o que exigiu uma auditoria de segurança para garantir que não estávamos expondo vulnerabilidades. Os critérios de proteção de privacidade exigiram documentar nossos fluxos de dados com um nível de detalhe que a maioria das startups só atinge quando um regulador exige. O processo levou aproximadamente quatro meses da candidatura inicial à certificação.

O interessante sobre a certificação BPD é que ela nos tornou melhores na construção de software, não apenas melhores na obtenção de uma credencial. Os padrões de documentação exigidos para a certificação são genuinamente úteis para as equipes de engenharia. Os requisitos de privacy-by-design que a certificação exige são valiosos para todos os usuários, não apenas para as populações que originalmente estávamos visando. Quando posteriormente construímos produtos enterprise para clientes fora do espaço de impacto social, os hábitos e práticas da certificação BPD também melhoraram esses produtos.

O que as Empresas Podem Aprender com Projetos de Impacto Social

Apresentei essas lições na UNGA78 e no SXSW para públicos compostos principalmente por líderes empresariais, não por fundadores de startups. A pergunta que ouço com mais frequência é: o que uma grande organização, com processos estruturados e recursos substanciais, pode aprender com uma startup que tenta alcançar comunidades sem acesso a serviços bancários nos Andes? A resposta é mais do que se esperaria.

Primeiro, projetar com restrições produz produtos melhores. Quando se projeta um sistema para funcionar em ambientes de baixa conectividade e baixa alfabetização, constrói-se algo mais robusto e acessível para todos. Os sistemas empresariais falham rotineiramente em casos extremos — interrupções de rede, problemas de compatibilidade de navegador, lacunas de acessibilidade para usuários com deficiência — precisamente porque esses casos extremos não foram considerados restrições primárias de design. O design para impacto social força você a tornar os casos extremos centrais.

Segundo, medir o que é genuinamente difícil de medir cria accountability. As organizações empresariais medem o que é fácil — receitas, custos, tempo de ciclo. As métricas mais difíceis — bem-estar dos colaboradores, confiança dos clientes, qualidade dos relacionamentos de longo prazo — são frequentemente as que predizem o desempenho sustentável. O framework da UNICEF nos obrigou a construir infraestrutura de medição para métricas difíceis. A disciplina se transfere diretamente para contextos empresariais.

• Projete primeiro para seus usuários mais exigentes: ambientes de baixa conectividade e baixa alfabetização produzem produtos mais robustos para todos
• Meça a mudança comportamental, não a atividade: ativações de carteira e visualizações de página falam de aquisição, não de impacto
• Construa a infraestrutura de compliance desde o início: incorporar privacy-by-design e compliance multi-jurisdicional depois custa de três a cinco vezes mais
• As relações com reguladores são ativos estratégicos: envolva-os como parceiros no compartilhamento de conhecimento, não apenas como guardiões
• A disciplina de código aberto melhora todos os produtos: os padrões de documentação e segurança exigidos para a certificação BPD também melhoram os codebases internos
• A retenção em seis meses revela a verdade do produto: métricas de ativação são vaidade em contextos de impacto social; métricas de mudança comportamental são a realidade

Na Xcapit, as lições da nossa experiência com o UNICEF Innovation Fund moldaram como abordamos cada projeto blockchain, seja o cliente uma agência multilateral, uma empresa de energia ou uma instituição financeira. Se você está avaliando blockchain para sua organização — para impacto social, transparência na cadeia de suprimentos ou infraestrutura financeira — estamos abertos para uma conversa. Explore nossos estudos de caso em xcapit.com/case-studies para ver como esses princípios se aplicam em diferentes setores e escalas.