Blockchain for Social Impact: Lessons from Building with UNICEF

In 2021, Xcapit received investment from the UNICEF Innovation Fund to build a non-custodial blockchain wallet aimed at financial inclusion in Latin America. At the time, I had come from Deloitte, where we measured success with familiar metrics — IRR, EBITDA, market share. What followed was one of the most intellectually demanding experiences of my professional life, and not primarily for technical reasons. The challenge was figuring out what success actually meant when your users are families in rural Peru accessing digital finance for the first time.

That question — what does success mean here? — is the central tension in social impact technology. It is a question that enterprise software almost never has to answer in quite the same way. Enterprise software fails when it does not reduce cost or increase revenue. Social impact software can fail even when it is widely adopted, if that adoption does not translate into meaningful improvement in people's lives. This distinction changes everything about how you build, how you measure, and how you make product decisions.

Designing for the Real World, Not the Demo Environment

The first lesson we internalized — painfully — was that designing for low-connectivity environments is not a feature flag you add at the end of development. It is an architectural constraint that must govern every decision from day one. Peru's Andean communities, where part of our pilot ran, have mobile connectivity that drops to 2G or disappears entirely in many areas. Standard Web3 onboarding flows assume a stable broadband connection, a smartphone with at least 4GB of RAM, and a user who is comfortable navigating multiple confirmation screens. None of those assumptions held.

We rebuilt the onboarding flow three times. The first version was technically correct and completely unusable. The second version was simpler but still required a stable internet connection to complete wallet generation and seed phrase backup. The third version — the one that actually worked in field trials — cached the wallet generation process locally, stored the seed phrase backup task as a recoverable offline action, and reduced the critical-path data transfer to under 50 kilobytes. This meant users could start the process during a moment of connectivity and complete the sensitive parts at home, on their own timeline.

The SMS-based wallet interaction layer we piloted in Peru deserves particular mention. A meaningful share of the target population used feature phones or low-end smartphones where installing an app was impractical due to storage constraints. We built a parallel interaction channel using USSD and SMS that allowed users to check balances, initiate transfers, and receive notifications without the app. This was not glamorous engineering. It required integrating with local telecom APIs that were poorly documented and unreliable, building a state machine for multi-step SMS flows, and testing extensively with actual field phones rather than emulators. But it expanded the addressable population significantly.

The Financial Inclusion Metrics That Actually Matter

UNICEF's reporting framework pushed us toward outcome metrics that, honestly, we would not have prioritized on our own. The fund did not just want to know how many wallets we had created. They wanted evidence of financial behavior change. Were users saving more consistently? Were they accessing remittances at lower cost than traditional channels? Were they building credit histories that might eventually connect them to formal lending? These questions require longitudinal data, which requires maintaining relationships with users over time — a completely different operational model than typical SaaS acquisition metrics.

We partnered with local NGOs for ground-truth data collection. We ran structured interviews at 3-month and 6-month intervals. We learned that wallet activation rates — which look great in a deck — tell you almost nothing about impact. Of 100 users who activated a wallet, roughly 60 made at least one transaction within the first week. By month three, only about 30 were still active. By month six, about 15. Those 15 users, however, showed meaningful indicators of financial behavior change: more consistent savings patterns, reduced reliance on informal money lenders, and higher confidence scores on financial literacy assessments. They were also more likely to recommend the product to family members, which became our primary growth mechanism.

The lesson here is uncomfortable for growth-oriented founders: your headline number will be the one that looks worst. Activation is easy; retention is hard; behavioral change is harder still. UNICEF pushed us to measure the hard things, and that discipline made us build a better product. When we stopped optimizing for activation and started optimizing for six-month retention, everything changed — the onboarding content, the notification strategy, the support model, the partnerships we prioritized.

Navigating Regulatory Complexity Without a Compliance Department

Blockchain regulation in Latin America during 2021 to 2023 was, to put it diplomatically, evolving rapidly. Peru, Colombia, Argentina, and Brazil each had different frameworks — some explicit, some implicit, all subject to change. As a startup operating across multiple jurisdictions with a non-custodial wallet (meaning we never held user funds directly), we existed in a gray area that was simultaneously freeing and anxiety-inducing. The non-custodial model was a deliberate choice to reduce regulatory risk: we were building infrastructure, not holding deposits.

The practical challenge was explaining this distinction to regulators who were, understandably, cautious about anything blockchain-adjacent following several high-profile collapses in the space. We invested significant time in regulatory education — not lobbying, but genuine knowledge-sharing with central bank staff and financial regulator teams. This was unusual for a startup our size, but UNICEF's institutional backing opened doors that would otherwise have been closed. The lesson: regulatory relationships are not just a compliance function; they are a strategic asset, especially when operating in emerging markets with novel technology.

We also learned the hard way that compliance requirements across jurisdictions do not stack neatly. KYC standards in Argentina require biometric verification that Peruvian users could not practically complete. Transaction monitoring thresholds differ by orders of magnitude between markets. Building a product that is compliant everywhere means building to the most restrictive standard everywhere, which can undermine the financial inclusion mission by adding friction for exactly the users you are trying to reach. We eventually built a jurisdiction-aware compliance layer that applied the correct requirements based on user location, but this added three months to our timeline and significant ongoing maintenance burden.

What Digital Public Good Certification Actually Requires

Achieving Digital Public Good (DPG) certification from the Digital Public Goods Alliance was a milestone we pursued deliberately, and the process was more rigorous than we anticipated. The DPG standard assesses nine criteria: relevance to the Sustainable Development Goals, open licensing, clear ownership, platform independence, documentation, extraction of data, privacy protection, adherence to privacy standards, and — critically — evidence of non-harm. That last criterion is genuinely difficult to satisfy in the blockchain space, where energy consumption and speculative use cases are legitimate concerns.

Our DPG application required us to document not just what the product did, but how decisions about the product were made, who could contribute to the codebase, and how community feedback was incorporated. The open-source requirement meant making our codebase fully public, which required a security audit to ensure we were not exposing vulnerabilities. The privacy protection criteria required documenting our data flows in a level of detail that most startups only achieve when a regulator demands it. The process took approximately four months from initial application to certification.

The interesting thing about DPG certification is that it made us better at building software, not just better at achieving a credential. The documentation standards required for certification are genuinely useful for engineering teams. The privacy-by-design requirements that certification demands are valuable for all users, not just the populations we were originally targeting. When we subsequently built enterprise products for clients outside the social impact space, the habits and practices from DPG certification improved those products too.

What Enterprises Can Learn from Social Impact Projects

I have presented these lessons at UNGA78 and SXSW to audiences primarily composed of enterprise leaders, not startup founders. The question I hear most often is: what can a large organization with structured processes and substantial resources learn from a startup trying to reach unbanked communities in the Andes? The answer is more than you might expect.

First, designing for constraints produces better products. When you engineer a system to work in low-connectivity, low-literacy environments, you build something more robust and more accessible for everyone. Enterprise systems routinely fail in edge cases — network interruptions, browser compatibility issues, accessibility gaps for users with disabilities — precisely because those edge cases were not considered primary design constraints. Social impact design forces you to make edge cases central.

Second, measuring what is genuinely hard to measure creates accountability. Enterprise organizations measure what is easy — revenue, cost, cycle time. The harder metrics — employee wellbeing, customer trust, long-term relationship quality — are often the ones that predict sustainable performance. UNICEF's framework forced us to build measurement infrastructure for hard metrics. The discipline transfers directly to enterprise contexts.

Third, regulatory engagement as a strategic practice rather than a compliance checkbox changes outcomes. We built relationships with regulators across four countries not because we had to, but because those relationships gave us early warning of regulatory changes, access to regulatory sandboxes, and credibility with institutional partners. Enterprise organizations in highly regulated industries — finance, healthcare, energy — consistently underinvest in this kind of proactive regulatory engagement.

• Design for your hardest users first: low-connectivity, low-literacy environments produce more robust products for all users
• Measure behavioral change, not activity: wallet activations and page views tell you about acquisition, not impact
• Build compliance infrastructure early: retrofitting privacy-by-design and jurisdiction-aware compliance is three to five times more expensive than building it from the start
• Regulatory relationships are strategic assets: engage regulators as partners in knowledge-sharing, not just as gatekeepers
• Open-source discipline improves all products: the documentation and security standards required for DPG certification make internal codebases better too
• Six-month retention reveals product truth: activation metrics are vanity in social impact contexts; behavior change metrics are reality

At Xcapit, the lessons from our UNICEF Innovation Fund experience have shaped how we approach every blockchain project, whether the client is a multilateral agency, an energy company, or a financial institution. If you are evaluating blockchain for your organization — whether for social impact, supply chain transparency, or financial infrastructure — we would welcome the conversation. Explore our case studies at xcapit.com/case-studies to see how these principles translate across industries and scales.