Riddo

Founding Engineer / Lead Product Engineer Rust, React Native, Node.js, PostgreSQL, FIDO2 | 2025

TL;DR > I led the engineering of Riddo, a seamless digital asset exchange that allows users to trade Crypto and Gift Cards for Naira. I architected a custom, non-custodial wallet abstraction layer that eliminated the need for seed phrases and implemented a FIDO2-inspired authentication system to secure user funds without compromising on mobile UX.

The Problem

• The UX Barrier: Traditional Web3 wallets require users to manage 12-24 word seed phrases. For the average user in Nigeria looking to swap USDT for Naira, this is a massive friction point and a high risk for total fund loss.
• The Security-UX Paradox: We needed a custodial-like experience (ease of use/recovery) with non-custodial levels of security. As a small team on a tight budget, we couldn't afford expensive enterprise KMS (Key Management Systems) or Vault services.
• Trust in P2P: In the gift card and crypto market, speed is trust. Users need instant verification and near-immediate fiat payouts to their local bank accounts.

My Role & Ownership

As the Founding Engineer, I designed the security protocols and the core transaction engine:

• Security Architecture: Authored the wallet generation and authentication protocols from scratch to ensure zero-knowledge storage of sensitive keys.
• Multi-Chain Integration: Built the infrastructure to support Bitcoin, Ethereum, and EVM-compatible chains (USDT/USDC) within a single unified interface.
• Full-Stack Implementation: Developed the high-performance backend in Rust for cryptographic operations and the mobile frontend in React Native.
• Fiat Rails: Integrated local payment gateways to automate instant Naira withdrawals and bank account verification.

Key Technical Decisions

• Rust for Backend Services Why? Needed memory safety and high performance for cryptographic signing and HMAC generations.
  Impact: Zero runtime crashes in the auth/signing modules and lightning-fast transaction processing.

• Non-Custodial Abstraction Why? To remove the "Key Management" burden from the user while ensuring we (the platform) never held the plain-text keys.
  Impact: Achieved a Web2-like login experience with Web3 security.

• FIDO2/WebAuthn Logic Why? To tie transactions to a specific physical device and a user-known PIN, creating a true two-factor hardware-bound security layer.

Deep Dive 1: Deterministic Wallet Abstraction

The Challenge

We needed a way for users to access multi-network wallets (BTC, ETH, etc.) without memorizing seed phrases, while also ensuring that Riddo never stored these mnemonics on our servers.

The Solution: Human-Readable Entropy

I engineered a secure algorithm that generates standard 12/24-word mnemonics deterministically from a single "Secure Word" (e.g., a user-generated secret) provided by the user.

1. Key Stretching: The user’s "Secure Word" is salted and peppered, then passed through a high-iteration PBKDF2/Argon2 process to increase complexity.
2. Mnemonic Derivation: This processed string serves as the entropy source to generate a standard BIP-39 mnemonic.
3. Zero-Storage Policy: The mnemonic is generated on-the-fly to sign transactions and is immediately wiped from memory. It is never stored in a database or on the device's persistent storage.

The Result: Users only need to remember one word. Even if our database is fully compromised, there are no private keys or mnemonics to steal.

Deep Dive 2: Hardware-Bound Auth & Recovery

The Challenge

Sending a user's PIN over the network for every transaction is a massive vulnerability. We needed a system where the PIN stays on the device but remains verifiable by the server.

The Solution: FIDO2-Style Challenge-Response

I implemented an asymmetric cryptographic system where each account setup generates a unique key pair.

1. The Secure Enclave: The Private Key is stored in the device’s hardware security module (Secure Enclave). The Public Key is sent to our server.
2. Challenge-Response: To authorize a trade, the server sends a random "challenge" string. The device signs this challenge using the private key (unlocked by the user's PIN) and sends the signature back. The server verifies it using the public key.

Handling Device Recovery

A major edge case was: What happens when a user loses their phone? Since the PIN is verified on-device via a local HMAC, a new device wouldn't recognize it.

The "Recovery HMAC" Pivot: I designed a secondary, highly-iterated HMAC (the Recovery HMAC) that is generated during the initial signup. This is the only "hint" stored on our server. When a user switches devices, we use a combination of:

• Email OTP (Possession)
• The Recovery HMAC match (Knowledge)
• A "Secure Word" check (Identity)

This allows the user to securely re-provision a new hardware-bound key pair on their new device without ever exposing their plain-text PIN to our backend.

Outcomes

• Bank-Grade Security: Successfully protected user assets using hardware-bound keys, making it virtually impossible to hijack an account without physical access to the device and the user's PIN.
• Seamless UX: Users are able to trade thousands of dollars in assets without ever seeing a "Seed Phrase," leading to higher conversion rates than traditional wallets.
• Zero-Loss Record: Maintained 100% fund security through multiple network upgrades and thousands of concurrent transactions.
• Engineered for Trust: The "Instant Payout" engine automated gift card verification and Naira settlement, reducing wait times from hours to minutes.

• Website: https://www.riddohq.com

  Building Riddo required a "Security First" mindset where every line of code was written with the assumption that the network or database could be compromised. It solidified my expertise in asymmetric cryptography and mobile security.