Saku
Numbers Over Addresses.
The problem Saku solves
We Removed Addresses from Money
Crypto adoption didn’t fail because people can’t use apps. It failed because money still speaks machine language.
Every user already has a verified, global identity:
a phone number — trusted, remembered, embedded in social behavior.
But onchain, value moves through hexadecimal addresses:
- memorized by no one
- disconnected from social graphs
- impossible to reason about at human speed
This forces users to translate intent into infrastructure. That friction kills adoption.
Saku removes that translation layer.
We built a non-custodial protocol where numbers replace addresses.
Users send value to phone numbers.
Smart contracts handle everything else.
- No wallet addresses.
- No copy–paste.
- No crypto UI mental model.
This works only onchain.
Why?
- Phone numbers are mapped to wallets via immutable smart contracts
- Transfers are permissionless and trustless
- Ownership is enforced cryptographically, not by servers
This is not a better wallet.
This is a new interaction model for money:
intent → execution → settlement.
Why this scales:
- 8B phone numbers = pre-existing onchain endpoints
- Social graphs = built-in distribution
- No onboarding = users already have an identity
- Non-custodial = no trust assumption
- Base L2 = cheap, instant finality
When abstraction is complete, users don’t know they’re using crypto.
They just send money.
Challenges we ran into
One of the main challenges we ran into was bridging real-world phone numbers with onchain identity without exposing personal data. Phone numbers vary in format and are tightly linked to real identities, while blockchain execution is inherently public. Balancing deterministic identity mapping with privacy preservation required careful handling, as any inconsistency or unintended exposure could undermine user trust.
Another challenge involved maintaining strong security guarantees from the very first interaction. Identity and key generation depend heavily on randomness, and insufficient entropy at this stage could introduce system-level risks. Ensuring secure initialization without adding friction or complexity became a critical design consideration.
A further challenge was onboarding users with little to no crypto experience or gas balance. Although new users could receive value, they were unable to interact onchain without ETH for transaction fees. Designing an onboarding flow that minimized failed transactions while keeping the experience approachable proved to be a significant UX challenge.
Tracks Applied (1)
Base Track
Technologies used
