Introduction
We’ve been building ZTippy, a Zcash tipping bot for Telegram, and wanted to share it with the community while development is still in progress. The bot is live on mainnet and working; this post is about what it does, why it exists, and where it’s going.
The project is a collaborative efforts of students of the Workshop
The goal is simple: make distributing ZEC within Telegram communities as frictionless as sending a message.
Why Telegram?
Telegram has become the default coordination layer for many Zcash communities — especially across Africa, Latin America, and Southeast Asia. Ambassador groups, regional communities, developer circles, and educational initiatives run on Telegram.
These groups regularly organize:
- Community calls and workshops
- Quizzes and educational programs
- Hackathons and developer discussions
- Day-to-day engagement and announcements
Despite Telegram being the center of this activity, distributing ZEC rewards is still a manual process.
The Problem
The current workflow for rewarding community members looks like this:
- Announce the activity and ask participants to share their wallet addresses
- Collect addresses manually (often in a spreadsheet)
- Verify recipients didn’t submit duplicates or invalid addresses
- Send transactions one by one
- Track what was sent and follow up with anyone who didn’t receive
For organizers running weekly programs across multiple groups, this is exhausting. For newcomers, being asked to provide a Zcash address before they’ve ever used ZEC is a hard stop. Many just drop off.
This friction compounds over time.
The Solution
ZTippy removes that overhead entirely.
Users interact with the bot directly inside Telegram — no external apps, no browser tabs, no clipboard management. Tipping, receiving, and managing ZEC happens in the same interface where communities already spend their time.
Automatic Wallet Creation
When a user sends /register, ZTippy:
- Derives a Zcash wallet from a seed phrase using ZIP-32 hierarchical deterministic key derivation
- Generates a Unified Address (ZIP-316) tied to that user’s Telegram account
- Makes the wallet immediately ready to receive ZEC
This matters because it eliminates the biggest onboarding barrier: a newcomer can receive their first ZEC before they’ve ever installed a wallet. Their first interaction with Zcash is receiving value, not navigating setup screens.
Features
Currently Live
Instant Tipping
/tip @username 0.001 sends ZEC peer-to-peer within any group the bot is active in. Tips settle against balances held by the bot and can be withdrawn to any Unified Address at any time.
Lazy Registration
If a user tips someone who hasn’t registered yet, the ZEC is held in a pending balance. When that user eventually runs /register, the funds are credited automatically. Nobody loses a tip because the recipient wasn’t signed up yet.
Rain
/rain 0.1 10 distributes ZEC equally across a specified number of recent participants in a group — useful for rewarding active engagement during community calls or quizzes.
Deposits
Each registered user has a unique Unified Address. Shielded ZEC sent to that address is detected automatically by an on-chain scanner running against a self-hosted zebrad full node and lightwalletd instance.
Withdrawals — ZEC and Cross-Chain
Users can withdraw to any Unified Address, or swap out to BTC, ETH, BNB, USDC, or USDT across five chains (Bitcoin, Ethereum, Arbitrum, Base, BSC) via NEAR Intents 1Click API. The cross-chain flow is fully non-custodial on the receiving end — ZTippy holds ZEC, the solver network handles the swap, and funds auto-refund if the swap fails.
Transaction History
/history shows recent tips sent and received.
Wallet Management
/balance, /deposit, /withdraw — standard wallet commands available in both group and DM contexts.
Planned
- Community leaderboards (top tippers, most active members)
- Giveaway and raffle commands with configurable eligibility
- Community treasury support (group wallets managed by moderators)
- Community analytics for organizers
/deposit near— accept any token as deposit, auto-swap to ZEC on arrival
Technical Stack
For developers curious about the internals:
- Bot runtime: Node.js + Telegraf, deployed on Railway
- Full node:
zebrad(mainnet) on a self-hosted VPS - Compact block streaming:
lightwalletdgRPC - Key derivation & note encryption: Rust native addon using
orchard,zcash_keys,zcash_note_encryptioncrates via napi-rs - Deposit detection: Trial-decryption of Orchard compact actions against the bot’s IVK — no address watching, no transparent addresses
- Database: Turso (libSQL) with embedded replica sync between Railway and VPS
- Cross-chain swaps: NEAR Intents 1Click API
- Address standard: ZIP-316 Unified Addresses exclusively — no transparent or Sapling-only outputs
Here is the link to the Github Repo
Privacy
ZTippy follows Zcash’s privacy-first design:
- All user addresses are Unified Addresses — Orchard pool by default
- Deposits are detected via trial-decryption of shielded compact actions, not by watching transparent addresses or using viewing keys shared with third parties
- Withdrawals go to shielded addresses only
- The bot holds funds in a single shielded wallet and uses diversified addresses per user
The UX deliberately hides this complexity. Users see a balance and an address — they don’t need to understand note encryption to use it.
Target Communities
ZTippy is designed for:
- Ambassador and regional communities
- Educational programs and onboarding initiatives
- Developer groups and hackathons
- Local meetups and community campaigns
- Governance initiatives that want to reward participation
The focus for the initial rollout is African Zcash communities, where Telegram is dominant and the need for frictionless ZEC distribution is most acute. But the architecture is generic — any Telegram community can deploy it.
Current Status
The bot is running on Zcash mainnet with a live zebrad node, active lightwalletd sync, and an operational deposit scanner. Core tipping, withdrawal, and cross-chain swap flows are working.
What’s still being built: leaderboards, giveaway commands, treasury support, and per-user IVK scanning for more precise deposit attribution.
This is an active project, not a proposal. The purpose of sharing it here is to get feedback from people who understand the ecosystem better than I do in certain areas — and to surface any existing infrastructure or tooling I should be building on.
What I’d Like Feedback On
- Security: Are there attack vectors in the single-wallet custody model I should be thinking about more carefully?
- Wallet architecture: Is there a better approach to per-user key isolation than diversified addresses under one USK?
- UX: What do community organizers actually need that I haven’t thought of?
- Infrastructure: Is there existing Zcash tooling — scanners, indexers, SDKs — that would serve this better than what I’ve built?
- Scalability: As user count grows, what breaks first?
- Integration ideas: Are there other Zcash projects or community platforms this should connect with?
Closing
Zcash has world-class cryptography and a community that genuinely cares about what the technology is for. ZTippy is an attempt to make that technology accessible in the spaces where community-building already happens.
Feedback, criticism, and ideas are all welcome. Happy to share more technical detail on any part of the stack.