Brazil has one of the highest rates of crypto adoption in the world. That’s not an accident.
The country has lived through hyperinflation that wiped out savings overnight. It has a banking oligopoly where five institutions control most of the country’s financial assets. It charges an IOF, a government tax on international transactions, that quietly extracts value every time someone sends money abroad. For a lot of Brazilians, “the system” isn’t an abstraction. It’s a specific set of institutions that have, at various points, failed them.
When crypto people say “your keys, your money,” they usually mean it as a philosophical stance. In Brazil, it lands as something closer to common sense.
This is the market Picnic is building for. An international stablecoin account, a debit card accepted in 180+ countries, no annual fee, no IOF, and the lowest FX rates they could offer. The pitch isn’t just better rates. It’s a fundamentally different relationship with your money. But that pitch only holds if the product actually delivers what it promises.
The Builder’s Dilemma
Most teams building consumer crypto apps face a version of the same decision early on: custodial or non-custodial?
Custodial is the fast path. You integrate a provider that handles key management on your behalf, typically using MPC (multi-party computation) or TEE (trusted execution environments), and your users get a clean email or social login. The tradeoff is real: the keys don’t live with the user. They live on a server. If that provider has an outage, a policy change, a breach, or shuts down, access to your users’ funds flows through someone else’s infrastructure.
For a lot of products, that’s an acceptable tradeoff. Speed to market matters, and most users don’t think about key custody.
But Picnic was building a product whose entire value proposition is that it’s different from the institutions users already distrust. “We’re managing your keys on our servers, trust us” doesn’t sit well next to “we’re different.” It’s the same promise with a different logo.
Non-custodial is the harder path. There’s no third party to call if something goes wrong. Users need a way to sign that doesn’t require a seed phrase, because mainstream users don’t manage seed phrases. And they need a recovery path that doesn’t reintroduce a custodial dependency through the back door.
For a long time, that combination didn’t exist in a form you could ship to consumers. It does now.
“In Brazil, people don’t just want better rates. They want to know the money is actually theirs. A product that promises sovereignty but holds your keys on a server is just a bank with better UX. We needed to build this properly, and Candide gave us the infrastructure to do it without starting from zero.” — Picnic team
The Stack
Picnic built on Safe, using two modules from Candide’s AbstractionKit. The web app runs multichain across Ethereum, Arbitrum, Optimism, Base, Polygon, Avalanche, and Gnosis Chain. The mobile app runs on Gnosis Chain.
Passkeys Module. Users sign transactions with their device’s biometrics: Face ID, Touch ID, or a PIN. There is no MPC provider, no TEE server, no custodial key management. The signing key lives in the device’s secure enclave and syncs to the user’s cloud password manager, iCloud Keychain or Google Password Manager. If someone gets a new phone, they restore their passkeys the same way they restore their other credentials. No seed phrases. No support ticket to a key custodian.
Social Recovery Module. Passkeys solve the custody problem. They don’t solve every recovery scenario. When cloud recovery isn’t enough, social recovery provides a second layer.
Picnic’s recovery setup is threshold-based. Users aren’t locked into a single guardian model. They can designate their own recovery contacts, and the system requires a configurable threshold of guardians to approve a recovery before it goes through. Picnic also kept their previous custodial provider as one guardian in the set. A deliberate design choice: the provider holds partial power, never unilateral control. No single party can move funds on its own.
Two additional safeguards sit on top.
First, the account owner gets notified the moment a recovery is triggered. If they didn’t start it, they know immediately. Second, recovery only finalizes after a grace period. That window exists so the user can cancel. A stolen device, a social engineering attempt, someone who got to one guardian but not enough. All of it can be stopped before the recovery completes.
The logic lives in the contract. Picnic can’t override it. Candide can’t override it. The rules execute as written.
Trustless, Not Trusted
There’s an instinct to frame this as a story about trust. Picnic built a trustworthy product. They earned user trust. That framing misses the point.
The value of this architecture is that users don’t have to trust Picnic at all. Or Candide. Or anyone. The contracts enforce the rules. The keys live with the user. Recovery requires threshold consensus, with alerts and a grace period baked in. There is no privileged back door. No override. No “contact support if you get locked out and we’ll sort it.”
This matters in Brazil because users there have calibrated, earned skepticism about institutions and their promises. “We promise we won’t misuse access to your funds” is a weaker guarantee than “we technically cannot access your funds.” The second guarantee doesn’t require good intentions. It requires good contracts.
Trustless infrastructure is what turns a product promise into something verifiable. That’s the shift Picnic made. It’s also the architecture that Ethereum-aligned builders recognize immediately as correct. Not because it’s the easiest path, but because it’s the one where the product does what it says.
What This Looks Like to Build
Building passkeys and threshold social recovery from scratch is months of security-critical engineering. Getting the cryptography right, auditing the recovery flow, handling edge cases across iOS and Android, integrating with Safe. It’s not impossible, but it’s the kind of work that delays your real product by a quarter or more.
Picnic integrated both modules through Candide’s AbstractionKit, the same SDK they were already using for their Safe-based account infrastructure. The modules are composable and didn’t require rebuilding their stack. The complexity is abstracted away by the SDK. The experience is simple.
Today, Picnic’s users in Brazil sign transactions with Face ID, recover their accounts through trusted contacts, and hold stablecoins on a card that works in 180+ countries without IOF, without annual fees, and without a custodian who can be compelled, breached, or shut down.
Who Holds the Keys
If you’re building a consumer product in a market where users have earned their skepticism of institutions, the question of who holds the keys is a product question, not a technical footnote.
Picnic answered it. This is what the answer looks like.
The passkeys and social recovery modules are open and documented. If you’re working through the same architecture decision, the AbstractionKit docs are a good place to start.