BundlyGuard technology
Proof of holding, with one token and zero trust in the user.
Everything BundlyGuard does, the exact order it does it in, and what it will never do.
The whole flow
Telegram user BundlyGuard Solana
| tap Verify | |
|---------------------->| new keypair, sealed AES-256-GCM |
|<-- private address ---| |
| | |
| send 1 token -------------------------------------------> transfer
| | read at confirmed <-------------|
| | sender = wallet that lost 1 token|
| | balance(sender) >= minimum ? |
|<-- invite or approve --| |
| | proof token left in place |
| | re-check balance every hour ---->|Two-group portal
First choose the group where BundlyGuard posts the Verify and join portal. Then the bot immediately asks for a separate private group for verified holders. These cannot be the same group.
BundlyGuard must be an admin in both groups, with Invite users and Ban users rights in the private holders' group. The portal is published only after both groups and the token rule are confirmed. Once verified, members receive an invitation into the private group, never into the public portal.
The one-token proof
Only the owner of a wallet can move tokens out of it. So instead of asking people to connect an app or sign a message, BundlyGuard asks for a plain transfer of exactly one token to a private, one-time address.
When that transfer is confirmed, the wallet that lost the token is, provably, a wallet the member controls. The bot then reads that wallet's full balance and compares it with the community's rule.
The proof token is not burned or moved: it simply stays at the one-time verification address. Supply never changes.
Why no wallet connection
Wallet connection flows are the favourite hunting ground of drainers. Teaching members to connect wallets inside Telegram trains exactly the wrong reflex.
A transfer works from any wallet, including hardware wallets and mobile apps, with no extra software and no signature request to trust.
Confirmation rules
Transfers are accepted at confirmed commitment: a supermajority of Solana validators has voted on the block, usually about a second after sending. A failed transaction, or one only processed, never unlocks anything.
Detection is live: the moment you tap I sent it, the bot watches the chain every 1.5 seconds. A background worker keeps watching after that, and switches itself off when no verification is open.
Each proof transaction signature can be used exactly once across all communities. The same transfer cannot verify two sessions.
If a transfer arrives after the 30 minute window, it is still detected for 24 hours, so a slow send is never lost.
Monitoring safety
Verified wallets are re-read every hour. A read that fails because a data provider is down never changes anyone's status.
Only two consecutive confirmed readings below the threshold count as a real sale. Then the admin's rule applies: alert, mute, or remove. Removed members can verify again at any time.
Tiers move both ways. Buy above the Whale line and the next check promotes you.
Privacy model
Inside Telegram groups the bot only ever writes verified, tier and aggregate counts. No wallet, balance, transaction or address mapping is ever posted.
Admins receive alerts with a Telegram user id and the action taken, never the wallet behind it.
The link between a Telegram account and a wallet is stored server side only, behind row level security with no public read access, to run monitoring.
Keys and custody
Verification addresses are generated on the server. Their secret keys are sealed with AES-256-GCM under a key derived through HKDF-SHA-256 with a per-address salt and a dedicated context, separate from trading and game wallets.
These addresses only ever hold the single proof token sent to them. There is no export path. BundlyGuard never holds member funds.
Honest limits
Solana only in this version, for SPL and Token-2022 tokens. Tokens with transfer fees may deliver slightly less than one token; the check still works.
The member pays one token plus a normal network fee, and the small account rent on first receipt for the verification address.
Never send the proof from an exchange account: the exchange wallet would be the sender, not you.
Tokens held inside liquidity pools, staking contracts or exchanges are not counted as the member's balance.