Mooncoin Telegram Wallet Bot and Query Bot Prototype

Context

This devlog captures a dual-bot experiment: a mooncoin telegram wallet bot for controlled wallet interactions and a query-focused bot for read-only chain information.

The core hypothesis is that chat-native interfaces may expand access and support workflows, but only if custody, authorization, and execution boundaries remain explicit. In other words, convenience is acceptable only when security-critical actions are isolated by design.

Objective

Define safe command patterns for wallet and query actions in Telegram.
Keep signing authority and funds movement explicitly separated from read-only features.
Validate whether bot interfaces can support mooncoin dev operations and user support use cases.
Maintain compatibility with existing mooncoin node and Electrum-backed backend services.

Technical Approach

The prototype uses a command-class model with clear privilege separation and backend routing rules.

Command classes under evaluation:

Read-only: network height, address status, tx lookup
Sensitive: draft transaction request, confirm/reject workflow
Restricted: any value-moving action behind explicit authorization gates

Representative query command model:

/height
/addr <mooncoin_address>
/tx <txid>

Representative API-side query shape:

curl -sS https://<api-host>/v1/address/<address>/history

Backend health verification sample:

mooncoin-cli getblockcount
mooncoin-cli getnetworkinfo

What We Implemented / Verified

Verified

Initial command taxonomy for wallet and query actions is defined.
Backend routing concept through mooncoin node and Electrum-backed services is documented.
Role-separation direction between query capabilities and wallet-action capabilities is explicit.

Partially Verified

Confirmation flow UX is drafted but not stress-tested with ambiguous user inputs.
Bot-side abuse controls are identified, not fully implemented.
Operator observability requirements are defined at a high level, not fully instrumented.

Not Yet Verified

Production-safe key management approach for wallet-action commands
Replay-resistant command signing scheme for high-risk actions
Long-session reliability for mixed query and authorization workflows

Risks and Open Questions

Should wallet-action commands be limited to pre-authorized device fingerprints?
Is Telegram-only identity sufficient for transaction authorization?
Where should the hard boundary sit between convenience and custody risk?
Which command classes should be disabled by default in early public testing?

Failure boundary example

If query and transaction commands share the same trust channel without clear mode separation, phishing-style prompt confusion can cause users to approve unintended operations. This is primarily an authorization design failure, not a consensus failure.

Next Steps

Implement strict role separation between query bot and wallet-action bot.
Add command-level audit logs and human-readable action digests.
Run adversarial prompt tests before enabling any fund-moving command paths.
Define release gates for enabling higher-risk command classes.

FAQ

Why build both a wallet bot and a query bot instead of one bot?

Splitting roles reduces confusion and limits blast radius. Query workflows stay low-risk, while wallet-action workflows can enforce stricter authorization and auditing.

Does the Telegram bot replace a mooncoin wallet app?

No. The bot prototype is an interface layer. It complements, but does not replace, dedicated wallet clients and mooncoin node infrastructure.

Is Telegram identity enough for value-moving commands?

Not by itself. High-risk actions should require additional controls beyond chat identity, such as explicit confirmation gates and replay-resistant authorization.

Is this ready for production fund movement?

Not yet. Key management, anti-replay controls, and adversarial testing remain incomplete for production-grade wallet-action commands.