Bringing Blockchain to 2.5B+ Offline Users

Open-source middleware enabling blockchain transactions via USSD/SMS and SIM Toolkit. No internet required.

Protocol Architecture
1
User Layer
SIM Card + USSD/STK Interface
→ USSD/STK Menu: Wallet operations via familiar mobile interface
2
Network Layer
GSM/2G/3G/LTE Bearer
→ USSD/SMS Transport: Transaction intents over cellular
3
Middleware Layer
Transaction Relay + Mempool
→ Intent Parser: Converts USSD/SMS to signed blockchain transactions
4
Chain Layer
Ethereum Node
→ Transaction Execution: On-chain settlement and confirmation
bash
# Clone the repo git clone https://github.com/stk2chain/stk2eth   # Run local node make dev   # Test USSD/SMS → ETH relay make test   # Expected output: ✓ USSD received and parsed ✓ Transaction signed ✓ Relayed to Ethereum ✓ Confirmation SMS sent   Latency: 12.3s | Gas: 0.0001 ETH

Blockchain Accessibility for 2.5B+ Offline Users

The infrastructure gap preventing billions from participating in decentralized economies

2.5B+
People without stable internet access
90%
Global GSM network coverage
$1B+
Daily Mobile-Money transaction volume
Limited Internet Access
Blockchain adoption is hindered in regions with unreliable or expensive internet connectivity. Current Web3 infrastructure excludes billions of potential users.
High Onboarding Barriers
Current blockchain wallets and dapps are internet-dependent with complex UX. Users need smartphones, data plans, and technical knowledge to participate.
Mass Adoption Gap
Existing blockchain solutions don't cater to the billions of users reliant on basic mobile devices. We need infrastructure that meets users where they are.

Bridge GSM → Ethereum

Leverage ubiquitous GSM infrastructure to enable blockchain access for everyone

Offline Functionality
Unlike internet-dependent wallets, STK2Chain operates primarily on GSM networks. Send ETH, check balances, and interact with smart contracts via SMS.
Ease of Use
Familiar STK-based interfaces ensure low learning curves. Users interact with blockchain through the same menu system they use for mobile money.
Massive Scalability
Design supports rapid deployment in regions with high mobile penetration but low internet coverage. Works on any phone with a SIM card.

Protocol Components

Technical specifications and implementation details

Bearer Types

  • GSM (2G) - Basic SMS transport
  • 2.5G (GPRS/EDGE) - Enhanced data
  • 3G (UMTS/HSPA) - Faster relay
  • LTE (4G) - Optimized latency
  • BIC - Bearer Independent Protocol

Security Model

  • Hardware-backed key storage
  • Secure Element integration
  • PIN-protected transaction signing
  • Encrypted SMS communication
  • eUICC security framework
// eSIM Profile Structure const eSIMProfile = { iccid: "89014103211118510720", imsi: "310410123456789", bearer: ["GSM", "LTE"], securityDomain: { type: "GlobalPlatform", keyStorage: "SecureElement", applets: ["STK2Chain"] } };
View source code

Menu Flow

  • 1. Deposit - Display wallet address
  • 2. Send ETH - Enter recipient & amount
  • 3. Check Balance - Query current holdings
  • 4. Swap - Token exchange interface
  • 5. Smart Contracts - Interact with dApps

Transaction Signing

  • PIN-based authentication
  • Transaction preview before signing
  • Gas fee estimation display
  • Confirmation prompts
  • SMS notification on completion

SMS Notifications

  • Send/Receive confirmations
  • Balance updates
  • Transaction status
  • Encrypted sensitive data
  • Gas fee alerts
// STK Menu Initialization public class STK2ChainApplet extends Applet { private static final byte MENU_DEPOSIT = 0x01; private static final byte MENU_SEND = 0x02; private static final byte MENU_BALANCE = 0x03; public void process(APDU apdu) { byte[] buffer = apdu.getBuffer(); switch (buffer[ISO7816.OFFSET_INS]) { case MENU_SEND: handleSendTransaction(apdu); break; } } }
View source code

Open Research Questions

  • → Self custodian or delegated signing model?
  • → eUICC-based key management or custom HSM?
  • → Who has control over transaction relaying?
  • → Multisig requirements for high-value operations?
  • → What levels of abstraction for ERC-4337?

Community Discussion

These architectural decisions require community input. We're researching best practices from wallet developers and the broader Ethereum ecosystem.

Proposed Architecture

  • SMS gateway integration
  • Transaction intent parser
  • Mempool management
  • Gas price oracle
  • Relay to Ethereum node

Security Considerations

  • End-to-end encryption
  • Rate limiting per user
  • Transaction validation
  • ERC-4337 account abstraction
  • Social recovery mechanisms
// Middleware SMS Parser (Proposed) async function parseSMSIntent(smsBody: string) { const intent = parseTransaction(smsBody); const validated = await validateAddress(intent.to); const gasEstimate = await estimateGas(intent); return { to: validated.address, value: intent.amount, gasLimit: gasEstimate, data: intent.calldata || "0x" }; }
View source code (WIP)

Node Requirements

  • Full or archive node access
  • WebSocket connection support
  • Mempool monitoring capabilities
  • Gas price API integration
  • Transaction status tracking

Transaction Building

  • EIP-1559 transaction formatting
  • Dynamic gas pricing
  • Nonce management
  • Transaction serialization
  • Signature verification

Gas Optimization Strategies

  • Batch transaction processing
  • ERC-4337 gasless transactions
  • Priority fee optimization
  • Network congestion monitoring
  • Fallback to L2 solutions
// Transaction Relay to Ethereum async function relayTransaction(signedTx: string) { const provider = new ethers.JsonRpcProvider(RPC_URL); const tx = await provider.sendTransaction(signedTx); // Monitor confirmation const receipt = await tx.wait(1); // Send SMS notification await sendSMSNotification({ to: userPhone, message: `TX Confirmed! Hash: ${tx.hash.slice(0,10)}...` }); return receipt; }

Testnet Deployment Guide

Deploy to Sepolia or Goerli for testing:

# Deploy middleware npm run deploy:testnet # Configure SMS gateway export TWILIO_ACCOUNT_SID="..." export TWILIO_AUTH_TOKEN="..." # Start relay service npm run start:relay
View source code

Functionally Testable in 6 Months

Phase 1 - Month 1
Research and Design
Finalize protocol design and architecture through stakeholder interviews and community engagement

Middleware security specifications (ERC-4337 integration)
eUICC security framework for hardware wallet functionality
Java Card applet security audit
STK interface prototypes and user flows
Phase 2 - Months 2-4
Development and Testing
Build and test eSIM profile, STK menu, and middleware components with blockchain testnets

Functional middleware with transaction relay
eSIM profile with STK menu implementation
Comprehensive test reports (latency, bandwidth, security)
100% unit test coverage for core modules
Phase 3 - Months 5-6
Deployment and Feedback
Pilot deployment and user testing in target regions with real-world validation

Live pilot program in emerging market region
User feedback analysis and system refinement
Production-ready protocol documentation
Performance metrics: <30s latency, 99% uptime

Active Community Bounties

Code is our only currency. Claim a bounty, submit a PR, get paid.

Middleware SMS Parser
$2,500
Build the core SMS → transaction intent parser with encryption support. Must handle USSD codes, validate addresses, and parse amounts.
Rust Cryptography Phase 2
Java Card STK Applet
$3,000
Develop the SIM Toolkit menu interface with wallet operations (send, receive, balance, swap). Must work on Java Card 3.0.4+.
Java Card STK Phase 2
ERC-4337 Account Abstraction
$2,000
Integrate ERC-4337 for gasless transactions and social recovery. Research best practices from wallet dev community.
Solidity ERC-4337 Phase 1
E2E Latency Testing Suite
$1,500
Create comprehensive testing suite measuring SMS → chain confirmation latency, bandwidth usage, and reliability across different networks.
TypeScript Testing Phase 2

Core Principles

The community is my co-founder and code is my only currency

1
Functionality > Form
Ship working code first, refine later. No opinions, only code. Every contribution must be testable, mergeable, and functional.
2
Community as Compiler
Use real-time feedback to iterate. Peer review is mandatory. 2+ community devs review every PR. No payouts for unfinished work.
3
Decentralized Critical Mass
Grow via "popup village" sprints (IRL + virtual). 72-hour focused development sessions to ship features and onboard contributors.
4
Kill Metrics
If it can't be measured, it doesn't exist. Track contributor growth, bounties paid, latency, uptime, test coverage, and merge frequency.

Ready to Contribute?

Join the movement to bring blockchain to billions. Code, bounties, and community await.