Channel Policies
Channel policies decide what a Studio bot is allowed to do inside a specific Telegram or Discord context. They are especially important for community trading bots, where the same bot may be safe in a private admin channel but too powerful for a public group.
What policies can control
A channel policy can describe:
- Whether trading commands are allowed.
- Whether analysis-only responses are allowed.
- Whether trades require approval.
- Whether fast-buy or contract-address detection is enabled.
- Which Telegram users, Discord roles, guilds, or channels are allowed.
- Which users, roles, guilds, or channels are blocked.
- Which default strategy should apply to that channel.
- Whether activity should carry partner attribution or fee-share metadata.
The exact fields vary by platform and current UI state, but the principle is the same: keep channel power explicit.
Recommended policy patterns
| Channel type | Suggested policy |
|---|---|
| Personal DM | Trading and analysis allowed, manual or semi-auto approvals while testing. |
| Private admin group | Trading allowed only for trusted operators; keep risk guardrails active. |
| Public community group | Analysis allowed, trading disabled or approval-required. |
| Signal channel | Analysis and contract detection enabled; trade execution reviewed elsewhere. |
| Partner/widget context | Attribution enabled only where the partner relationship is configured. |
Trading permissions
Do not enable unrestricted trading in public channels. A good rollout sequence is:
- Start with analysis only.
- Enable manual approvals for trusted operators.
- Test small trade sizes.
- Move to semi-auto only after the bot behaves predictably.
- Keep emergency stop and risk guardrails available.
Fee-share and attribution
Some channel and widget contexts can carry partner attribution and fee-share configuration. This is useful for communities or projects where trading activity is associated with a group, channel, or embedded widget.
This is not the same as a referral code:
- Channel/widget fee-share is tied to activity attribution in a channel or widget context.
- Referral rewards are tied to referral codes and referred-user tracking.
Docs should describe fee-share as configured and tracked. Do not promise automatic payouts, payout timing, or settlement rails unless the current product flow explicitly exposes and verifies them.
Telegram-specific notes
For Telegram, policy commonly starts with access mode and owner username:
private: owner-only.whitelist: specific usernames.public: anyone who can reach the bot.
Use mention-only behavior in groups to prevent the bot from replying to every message.
Discord-specific notes
For Discord, policy commonly uses guild, channel, and role IDs:
- Allowed channel IDs narrow where the bot can respond.
- Blocked channel IDs override allowed lists.
- Required role IDs gate who can interact.
- Blocked role IDs exclude users even if they also have an allowed role.
Use a dedicated test channel before opening access to a large server.
Common issues
Trading commands are ignored. Check that trading is enabled for the channel and that the bot's risk policy allows the requested action.
The bot responds too often. Turn on mention-only behavior and narrow the allowed channel list.
A community member can trigger more than intended. Tighten access mode, role gates, or approval settings. Prefer whitelists and role gates for trading-enabled bots.