Hannibal B2C Non-Custodial Design
Making Users the True Owners of Their Funds
What Does "Custodial" vs "Non-Custodial" Mean?
The Bank Analogy
Custodial (Like a Bank): When you deposit money at a bank, the bank holds your money. You trust them to give it back when you ask. If the bank refuses, gets hacked, or goes bankrupt - you might lose your money.
Non-Custodial (Like Cash in Your Pocket): When you have cash in your pocket, YOU control it. No one can stop you from spending it. No one can take it without your permission.
In Crypto Terms
| Type | Who Holds the Keys? | Who Controls the Money? | Example |
|---|---|---|---|
| Custodial | The platform | The platform | Coinbase, Binance, Current Hannibal Design |
| Non-Custodial | You (the user) | You (the user) | MetaMask, Your hardware wallet |
The Current Hannibal Design (Custodial)
Here's how the current B2C design works:
┌─────────────────────────────────────────────────────────────┐
│ CURRENT CUSTODIAL FLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. You send $100 USDC to Hannibal's wallet │
│ → Hannibal now OWNS your $100 │
│ → You have a "balance" in their database │
│ │
│ 2. You place a bet │
│ → Hannibal updates your database balance │
│ → No actual crypto moves │
│ │
│ 3. You want to withdraw │
│ → You REQUEST a withdrawal │
│ → Hannibal DECIDES to send you money │
│ → If Hannibal refuses... you're stuck │
│ │
└─────────────────────────────────────────────────────────────┘
The Trust Problem
With custodial systems, you must trust that:
- The platform won't steal your money
- The platform won't get hacked
- The platform won't go bankrupt
- The platform will process your withdrawal
This is exactly how FTX worked - and we saw what happened when that trust was broken.
The Non-Custodial Alternative
The Core Idea
Instead of sending money to Hannibal's wallet, you send money to a smart contract - a piece of code that runs on the blockchain.
Key difference:
- A wallet is controlled by whoever has the password (private key)
- A smart contract is controlled by its CODE - no human can override it
┌─────────────────────────────────────────────────────────────┐
│ NON-CUSTODIAL FLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. You send $100 USDC to a SMART CONTRACT │
│ → The CODE holds your $100 │
│ → Only YOU can withdraw it (the code guarantees this) │
│ │
│ 2. You place a bet │
│ → You SIGN a message saying "I bet $100 on Team A" │
│ → Your signature is like a digital fingerprint │
│ → The $100 is now "locked" until the bet settles │
│ │
│ 3. You want to withdraw │
│ → You tell the smart contract "give me my money" │
│ → The contract checks: "Is this money unlocked?" │
│ → If yes: Money goes to YOU automatically │
│ → Hannibal CANNOT stop this │
│ │
└─────────────────────────────────────────────────────────────┘
What is a Smart Contract?
Simple Explanation
A smart contract is like a vending machine:
- You put money in
- You press a button (make a choice)
- The machine gives you what you selected
- No human is involved - the machine follows its programming
A smart contract works the same way:
- You send crypto to it
- You interact with it (place bets, withdraw)
- It follows its code exactly
- No human can change the rules once it's deployed
Example: A Simple Betting Contract
SMART CONTRACT RULES:
─────────────────────
1. Anyone can deposit money
2. Only the depositor can withdraw THEIR money
3. When a bet is placed, that money is "locked"
4. When a bet settles, the winner gets the locked money
5. Hannibal CANNOT touch money that isn't theirs
These rules are written in code and cannot be changed after deployment.
How Non-Custodial Betting Works
Step 1: Deposit (You Stay in Control)
┌─────────────────────────────────────────────────────────────┐
│ DEPOSIT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Your Wallet Smart Contract │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ $500 │ ───────────────► │ Your balance: │ │
│ │ USDC │ You send $100 │ $100 USDC │ │
│ └──────────┘ │ │ │
│ │ Hannibal's │ │
│ You still control this $100! │ balance: $0 │ │
│ The contract knows it's YOURS └──────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Key point: The smart contract KNOWS this $100 belongs to you. Only you can withdraw it.
Step 2: Placing a Bet (Digital Signatures)
When you place a bet, you don't send money anywhere. Instead, you sign a message.
What is a Digital Signature?
Think of it like signing a check:
- Your signature proves YOU authorized the payment
- No one can forge your signature
- Once signed, you can't deny you signed it
In crypto, your wallet creates a digital signature that:
- Proves you authorized the bet
- Cannot be faked by anyone (not even Hannibal)
- Is permanently recorded
┌─────────────────────────────────────────────────────────────┐
│ PLACING A BET │
├─────────────────────────────────────────────────────────────┤
│ │
│ You click "Bet $50 on Manchester United to win" │
│ │
│ Your wallet asks: "Sign this message?" │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Message: │ │
│ │ "I bet $50 on Man Utd vs Chelsea │ │
│ │ Selection: Manchester United │ │
│ │ Odds: 2.5 │ │
│ │ Potential win: $125" │ │
│ │ │ │
│ │ [Sign] [Cancel] │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ You click "Sign" │
│ → Your wallet creates a unique signature │
│ → This signature is sent to Hannibal │
│ → Hannibal co-signs to accept the bet │
│ → Both signatures are stored as PROOF │
│ │
│ Your $50 is now "locked" in the contract until the │
│ match ends. │
│ │
└─────────────────────────────────────────────────────────────┘
Why Two Signatures?
| Signature | Purpose |
|---|---|
| Your signature | Proves YOU wanted to place this bet |
| Hannibal's signature | Proves Hannibal ACCEPTED this bet |
Both signatures together create an unbreakable agreement. Neither party can later claim "I didn't agree to this."
Step 3: Bet Settlement (The Oracle Problem)
Here's the tricky part: How does the smart contract know who won the match?
The contract is just code - it can't watch football! It needs someone to TELL it the result.
What is an Oracle?
An oracle is a service that brings real-world information onto the blockchain.
┌─────────────────────────────────────────────────────────────┐
│ THE ORACLE │
├─────────────────────────────────────────────────────────────┤
│ │
│ Real World Blockchain │
│ ────────── ────────── │
│ Man Utd 2 - 1 Chelsea Smart Contract │
│ │ │ │
│ │ ORACLE │ │
│ └──────────────────────────────┘ │
│ │ │
│ ▼ │
│ "Manchester United won" │
│ │
│ The oracle is the BRIDGE between the real world │
│ and the blockchain. │
│ │
└─────────────────────────────────────────────────────────────┘
Oracle Options
| Option | How it Works | Trust Level |
|---|---|---|
| Chainlink | Multiple independent data providers agree on result | High (decentralized) |
| Hannibal as Oracle | Hannibal reports the result | Lower (trust Hannibal) |
| Optimistic Oracle | Anyone can report, others can dispute | Medium (dispute-based) |
Step 4: The Dispute Window (Your Protection)
To protect users from a dishonest oracle, we add a dispute window.
┌─────────────────────────────────────────────────────────────┐
│ DISPUTE WINDOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ Match ends: Man Utd 2 - 1 Chelsea │
│ │
│ Hour 0: Hannibal reports "Manchester United won" │
│ │ │
│ ▼ │
│ Hours 0-24: DISPUTE WINDOW │
│ │ Anyone can challenge the result │
│ │ If challenged → goes to arbitration │
│ │ │
│ ▼ │
│ Hour 24: No disputes? Result is FINAL │
│ │ │
│ ▼ │
│ Hour 24+: Winners can withdraw their winnings │
│ │
└─────────────────────────────────────────────────────────────┘
Why this protects you:
- If Hannibal lies about a result, you have 24 hours to dispute
- Disputes go to neutral arbitration (not controlled by Hannibal)
- Hannibal has no incentive to lie (they'd lose reputation and face penalties)
Step 5: Withdrawal (Guaranteed by Code)
This is where non-custodial really shines.
┌─────────────────────────────────────────────────────────────┐
│ WITHDRAWAL │
├─────────────────────────────────────────────────────────────┤
│ │
│ CUSTODIAL (Current): │
│ ──────────────────── │
│ You: "I want my $200" │
│ Hannibal: "Let me check... processing... approved" │
│ Hannibal: *sends money* │
│ (What if Hannibal says no? You're stuck.) │
│ │
│ NON-CUSTODIAL (New): │
│ ────────────────────── │
│ You: *click withdraw on smart contract* │
│ Contract: "Is this user's money? Yes. Is it unlocked? │
│ Yes. Sending now." │
│ *Money arrives in your wallet* │
│ (Hannibal cannot stop this. The code executes.) │
│ │
└─────────────────────────────────────────────────────────────┘
The key difference: In non-custodial, withdrawal is a RIGHT, not a REQUEST.
Complete Non-Custodial Flow
┌─────────────────────────────────────────────────────────────┐
│ COMPLETE NON-CUSTODIAL BETTING FLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. DEPOSIT │
│ You send USDC to smart contract │
│ → Contract records: "User X has $100" │
│ → You can withdraw anytime (if not locked in bets) │
│ │
│ 2. PLACE BET │
│ You sign a bet message with your wallet │
│ → Hannibal co-signs to accept │
│ → $50 of your balance is "locked" │
│ → You still have $50 unlocked (can withdraw) │
│ │
│ 3. MATCH HAPPENS │
│ Real world: Manchester United wins │
│ → Oracle reports result to blockchain │
│ │
│ 4. DISPUTE WINDOW (24 hours) │
│ Anyone can challenge if result is wrong │
│ → No challenge? Result becomes final │
│ │
│ 5. SETTLEMENT │
│ Contract calculates: "User X won $125" │
│ → Your balance: $50 (unlocked) + $125 (winnings) │
│ → Total: $175 │
│ │
│ 6. WITHDRAWAL │
│ You call contract: "Withdraw $175" │
│ → Contract sends $175 to YOUR wallet │
│ → No permission needed from Hannibal │
│ │
└─────────────────────────────────────────────────────────────┘
Comparing Custodial vs Non-Custodial
| Aspect | Custodial | Non-Custodial |
|---|---|---|
| Who holds your money? | Hannibal | Smart contract (code) |
| Can Hannibal take your money? | Yes (they have the keys) | No (code prevents it) |
| Can Hannibal block withdrawals? | Yes | No |
| What if Hannibal gets hacked? | You might lose everything | Your funds are safe in contract |
| What if Hannibal disappears? | Your money is gone | You can still withdraw |
| Speed | Instant | Slightly slower (dispute windows) |
| Complexity | Simple | More complex |
| Gas fees | Lower | Higher (more on-chain activity) |
The Hybrid Approach (Best of Both Worlds)
Pure non-custodial has downsides: slower, more expensive, complex UX.
A hybrid approach gives you security guarantees while keeping things fast and cheap.
How Hybrid Works
┌─────────────────────────────────────────────────────────────┐
│ HYBRID MODEL │
├─────────────────────────────────────────────────────────────┤
│ │
│ DEPOSITS: Fully Non-Custodial ✓ │
│ ───────────────────────────────── │
│ • Money goes to smart contract │
│ • You can ALWAYS withdraw unlocked funds │
│ • Hannibal never touches your deposits │
│ │
│ BETTING: Off-Chain with Cryptographic Proofs │
│ ───────────────────────────────────────────── │
│ • Bets happen on Hannibal's fast servers (instant) │
│ • BUT: Every bet is signed by you AND Hannibal │
│ • You have PROOF of every bet (can't be denied) │
│ • If Hannibal cheats, you have evidence │
│ │
│ SETTLEMENTS: Optimistic with Dispute Window │
│ ───────────────────────────────────────────── │
│ • Hannibal posts results (fast) │
│ • 24-hour window to dispute │
│ • No dispute = result is final │
│ │
│ WITHDRAWALS: Fully Non-Custodial ✓ │
│ ───────────────────────────────────── │
│ • You submit your signed proofs to contract │
│ • Contract verifies and releases funds │
│ • Hannibal CANNOT block this │
│ │
└─────────────────────────────────────────────────────────────┘
Why Hybrid is Practical
| Pure Non-Custodial Problem | Hybrid Solution |
|---|---|
| Every bet costs gas fees | Bets are off-chain (free) |
| Slow (wait for blockchain) | Instant betting, only deposits/withdrawals on-chain |
| Complex UX | Simple UX, signing happens in background |
| Expensive oracles | Optimistic oracle with disputes |
Technical Components Needed
1. Smart Contracts (One per Blockchain)
We need to write and deploy smart contracts on:
- Solana (Solana Program)
- Ethereum (Solidity Contract)
- Tron (Solidity Contract)
Each contract handles:
- Deposits
- Balance tracking
- Bet locking/unlocking
- Withdrawals
- Dispute resolution
2. Signature System
Users need to sign messages for:
- Placing bets
- Cancelling bets
- Acknowledging settlements
This requires:
- Frontend wallet integration (MetaMask, Phantom, etc.)
- Backend signature verification
- Signature storage for proofs
3. Oracle System
Options for reporting match results:
| Oracle Type | Description | Cost | Speed |
|---|---|---|---|
| Chainlink | Decentralized data feeds | High | Fast |
| UMA | Optimistic oracle with disputes | Medium | Slow (dispute window) |
| Custom | Hannibal reports + dispute mechanism | Low | Fast |
Recommended: Start with Custom (Hannibal as oracle) + dispute mechanism. Upgrade to Chainlink/UMA later if needed.
4. Dispute Resolution
When someone disputes a result:
┌─────────────────────────────────────────────────────────────┐
│ DISPUTE RESOLUTION │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. User disputes: "The result is wrong!" │
│ → User stakes a dispute bond (e.g., $50) │
│ → This prevents spam disputes │
│ │
│ 2. Evidence submitted │
│ → User provides proof (screenshots, official results) │
│ → Hannibal provides their evidence │
│ │
│ 3. Arbitration │
│ Option A: Multi-sig committee votes │
│ Option B: UMA token holders vote │
│ Option C: Kleros decentralized court │
│ │
│ 4. Resolution │
│ → Winner gets their money + loser's bond │
│ → Correct result is recorded on-chain │
│ │
└─────────────────────────────────────────────────────────────┘
What Changes for Users?
Current (Custodial) Experience
- Login with Google
- Copy deposit address, send crypto
- Wait for balance to appear
- Place bets (click buttons)
- Request withdrawal
- Wait for Hannibal to process
- Receive funds
New (Non-Custodial) Experience
- Login with Google
- Connect your wallet (MetaMask/Phantom)
- Deposit to smart contract (one transaction)
- Place bets (sign messages - one click)
- Wait for settlement + dispute window
- Withdraw directly from contract (one transaction)
- Funds arrive immediately
The Main UX Difference
Signing messages: Users will see a popup asking them to "sign" when placing bets. This is like confirming a transaction, but it's FREE (no gas fee for signing).
┌─────────────────────────────────────────────────────────────┐
│ │
│ MetaMask [X] │
│ ───────── │
│ Signature Request │
│ │
│ Hannibal Betting wants you to sign: │
│ │
│ "Place bet: │
│ Match: Man Utd vs Chelsea │
│ Selection: Manchester United │
│ Stake: $50 USDC │
│ Odds: 2.50 │
│ Potential Return: $125" │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Cancel │ │ Sign │ │
│ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Security Comparison
Custodial Risks
| Risk | Impact | Likelihood |
|---|---|---|
| Hannibal gets hacked | Lose all funds | Medium |
| Hannibal goes bankrupt | Lose all funds | Low |
| Hannibal refuses withdrawal | Can't access funds | Low |
| Insider theft | Lose all funds | Low |
| Database corruption | Balance errors | Low |
Non-Custodial Risks
| Risk | Impact | Likelihood |
|---|---|---|
| Smart contract bug | Lose funds in contract | Low (if audited) |
| Oracle manipulation | Wrong settlements | Low (with disputes) |
| User loses private key | User loses access | Medium |
| Blockchain congestion | Slow withdrawals | Low |
Key insight: Non-custodial shifts risk from "trusting Hannibal" to "trusting code." Code can be audited and verified; human intentions cannot.
Summary: The Key Takeaways
What is Custodial?
- You give your money to someone else (like a bank)
- You trust them to keep it safe and give it back
- If they say no, get hacked, or disappear - you're stuck
What is Non-Custodial?
- Your money stays under your control (via smart contracts)
- Code guarantees you can always withdraw
- No trust required - just math and cryptography
What We Recommend: Hybrid Approach
┌─────────────────────────────────────────────────────────────┐
│ RECOMMENDED HYBRID ARCHITECTURE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ✓ DEPOSITS → Smart Contract (non-custodial) │
│ ✓ BETTING → Off-chain with signatures (fast) │
│ ✓ SETTLEMENTS → Optimistic oracle + disputes │
│ ✓ WITHDRAWALS → Smart Contract (non-custodial) │
│ │
│ Result: Fast betting + guaranteed fund safety │
│ │
└─────────────────────────────────────────────────────────────┘
Why This Matters
- User Protection: Your funds cannot be stolen or frozen by the platform
- Trust Minimized: You don't need to trust Hannibal - verify through code
- Transparency: All balances and settlements verifiable on blockchain
- Regulatory Clarity: Non-custodial platforms have different (often lighter) regulatory requirements
Glossary of Terms
| Term | Simple Explanation |
|---|---|
| Custodial | Someone else holds your money (like a bank) |
| Non-Custodial | You hold your own money (like cash in your pocket) |
| Smart Contract | A program on the blockchain that automatically executes rules |
| Digital Signature | A cryptographic proof that you authorized something |
| Oracle | A service that tells the blockchain about real-world events |
| Dispute Window | Time period where you can challenge a reported result |
| Gas Fee | The cost to execute a transaction on the blockchain |
| Private Key | The secret password that controls your crypto wallet |
| Stablecoin | Crypto designed to always equal $1 (USDC, USDT) |
| Multi-sig | Requires multiple people to approve a transaction |
Document Information
| Item | Value |
|---|---|
| Version | 1.0 |
| Date | February 2026 |
| Status | Draft - For Discussion |
| Related Document | B2C_CRYPTO_DESIGN_DOCUMENT.md (Custodial Design) |
This document explains the conceptual difference between custodial and non-custodial approaches to crypto betting. Implementation details, smart contract specifications, and technical architecture will require separate technical documentation.