Gate a Telegram community with onchain rules

Telegram lets an invite link create a join request instead of admitting someone directly. Auth401 sits on that request: it asks the person to prove they control a wallet, reads that wallet on Robinhood Chain, and approves or declines based on rules you set.

Three things have to be true before anyone gets in, and all three are checked on our server - never in the visitor's browser:

• Telegram vouches for who they are, by signing the data the Mini App sends.
• They sign a one-time challenge, proving they control the wallet.
• That wallet meets your policy, read live from chain at the moment of approval.

1. 01Create your Telegram group, then add @auth401bot to it and promote it to administrator. It needs the rights to manage the chat, invite users, restrict members and delete messages.
2. 02Run /setup in the group. The bot checks its own permissions and tells you exactly what is missing if anything is. Everyone who is a Telegram admin of the group becomes an Auth401 admin.
3. 03Run /console. The bot sends you a private link by direct message - never posted in the group. Open it and create your policy.
4. 04Run /invite to generate a protected invite link. This is the link you share.
5. 05In Telegram group settings, turn on Approve New Members, then revoke any other invite links you have shared previously.

Group commands are admin-only. If a non-admin runs one, the bot refuses.

A policy is a set of rules combined with AND (a member must satisfy all of them) or OR (any one is enough). Each rule picks its own chain, so one policy can mix networks — for example hold 100 BONK on Solana, or 0.1 ETH on Base.

Supported chains

Arc Testnet balances have no real value, so use the Arc mainnet network when gating a real community.

Rule types

Members with more than one wallet

A member links a wallet for each kind of chain the policy reads: an EVM wallet for Robinhood, Ethereum, Base, BNB Chain or Arc, and a Solana wallet for Solana. One EVM wallet covers every EVM chain.

• A balance rule passes if any one linked wallet holds enough. Holdings are not added up across wallets.
• A blocklist fails if any linked wallet is on it, so a blocked wallet cannot be hidden behind a clean one.
• If a rule needs a Solana wallet and the member has only linked an EVM wallet, the join request stays open and they are asked to link the other one — it is not declined.

Amounts are entered in whole tokens

Type the amount the way you would say it. Enter 500000 for five hundred thousand tokens, or 0.5 for half a token. The console reads the token's decimals from its contract and does the conversion for you.

you type    the gate requires
500000   -> 500,000 DVK
0.5      -> 0.5 SOL
100      -> 100 USDC   (6 decimals on Base, 18 on BNB Chain — handled)
1        -> 1 NFT

Editing a policy

Saving creates a new version rather than overwriting the old one, so the audit trail stays honest. New join requests use the new policy immediately. Existing members are re-evaluated on the next scheduled recheck, not instantly.

What a visitor experiences, and what happens behind each step:

1. 01They tap your protected link. Telegram creates a join request instead of adding them.
2. 02If they have verified a wallet with Auth401 before, the bot reads that wallet on chain right away. If it still meets your policy they are approved instantly - nothing to tap or sign.
3. 03Otherwise the bot sends a direct message listing exactly what your policy requires, with a button for each wallet app - MetaMask, Phantom, Trust, Coinbase, Solflare - plus a link for any other wallet or a desktop browser.
4. 04Tapping their wallet opens the verification page inside that wallet's own app, where they tap Verify with this wallet. No WalletConnect, no switching apps, no network to add. The link lasts 24 hours;/verify in the bot chat sends a fresh one.
5. 05They sign a one-time challenge tied to their Telegram account, your community, that wallet and that chain. It expires in five minutes and cannot be reused.
6. 06The server verifies the signature, reads the wallet on chain, evaluates your policy, and approves or declines the join request - all in the same request.

If they fail, the message names the shortfall rather than refusing vaguely - for example "needs to hold at least 100 - has 5 HOOD". They can top up and request again.

A scheduled job re-checks everyone who currently has access. This is what makes the gate ongoing rather than a one-time check at the door.

The grace period is yours to set in the console. It gives someone time to top back up after a dip rather than ejecting them instantly. Set it to 0 to revoke on the first failed check.

Removal is a ban immediately followed by an unban - it ejects the member but lets them request to join again if they re-qualify later. Paused communities are skipped entirely.

There is no password and no separate account. Access comes from Telegram: send /console to the bot and it checks you administer a community before sending a private link. The link expires in 15 minutes and signs you in for 7 days.

You only ever see communities you administer. Admins of other communities using Auth401 cannot see yours, and you cannot see theirs.

• Wallets are read, never spent. Only message signatures are requested. No transactions, no approvals, no custody.
• Challenges are single-use. Each is bound to one Telegram account, community, wallet and chain, expires in five minutes, and is consumed before the signature is even checked.
• Telegram identity is verified cryptographically on every request, so a browser cannot claim to be someone else.
• Decisions are made server-side. Nothing the visitor's browser reports is trusted.
• Every decision is logged with the on-chain values it was based on, visible in the Events page.

The gate depends on Telegram permissions. If the bot is removed or demoted, gating pauses automatically rather than silently pretending to work.

The Events page is the first place to look for anything user-facing - every decision is recorded there with the values behind it.