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 --| |
| | burn 1 token + close account --->| supply - 1
| | re-check balance every hour ---->|The burn 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 then burned on-chain with a Burn instruction, and the temporary token account is closed. Its rent returns to the Guard fee wallet, which is how the system pays for its own burns.
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 for the minutes before it is burned. 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 that goes to the burn fee wallet.
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.