Security & Trust

The Subscrypts Discord Bot and its related web services are designed to be:

• Non-custodial – you keep control of your wallet and funds
• Privacy-respecting – minimal data, no passwords or emails
• On-chain transparent – all payments and subscriptions are visible on Arbitrum
• Globally accessible – no reliance on banks or card processors

This page explains what that means in practice for Discord members, merchants (server owners), and the wider Subscrypts ecosystem.

Design Principles

Across the dApp, smart contracts and Discord integration, Subscrypts follows a few core principles:

1. Wallets, not accounts
   Identity is based on wallet ownership, proven by signatures — not usernames, email addresses or passwords.

2. On-chain = source of truth
   Subscription state lives in the Subscrypts smart contract suite on Arbitrum One. The bot and dApp read this state; they do not “override” it.

3. Non-custodial funds
   Users approve each subscription transaction from their own wallet. Subscrypts cannot move funds on their behalf.

4. Minimal off-chain data
   Only what is strictly needed for the system to function (e.g., “wallet X has a subscription for plan Y in guild Z”) is stored off-chain.

5. Transparent & MiCAR-aligned
   Token and subscription mechanics are documented in the Subscrypts MiCAR Whitepaper, making it easier for EU-based merchants to understand their responsibilities.

Wallet Linking & Identity Mapping

When a member runs /subs link, the Subscrypts Discord Bot:

1. Opens a private thread in that guild.
2. Sends a secure, per-guild wallet link URL.
3. Asks the user to connect their wallet and sign a message.

Key points:

• The signature proves that “this Discord user controls this wallet” for that specific server.
• The link is time-limited (short expiry) and bound to that guild + user.
• Private keys are never exposed to Subscrypts – only a signed message is received and verified.
• The mapping is per guild:
  • The same wallet can be linked in multiple servers.
  • A different wallet can be used per server if the user prefers.

No emails, passwords, real names or KYC information are required to use the bot.

Short, Signed Subscribe URLs

Guild subscription pages are exposed via short URLs like:

https://discord.onsubscrypts.com/s/<guildId>.<version>.<signature>

These per-guild subscribe links are:

• Generated by the bot using a secret key shared with the webserver.
• Digitally signed (HMAC) so they cannot be forged or tampered with by third parties.
• Versioned per guild — if the merchant changes mappings (plans ↔ roles), a new version is issued and old links can be safely replaced.

When you open such a link:

• The webserver verifies the signature before it shows any content.
• The payload contains only what is needed for subscriptions:
  • Guild identifier
  • Active plans and associated role labels
  • Timestamp/version information

✅ This means that even server admins cannot arbitrarily alter what a signed subscribe link does. To change what users see, they must update on-chain plans and legitimate mappings in the bot. The short URL itself cannot be repointed to a malicious payload without breaking the signature.

For safety, users are advised to only trust subscribe links starting with:

https://discord.onsubscrypts.com/s/...

Data Minimization & Privacy

Subscrypts is designed to operate with as little personal data as possible.

For the Discord bot and webserver, typical data includes:

• Discord identifiers (guild ID, channel ID, user ID)
• Public wallet addresses
• Plan IDs and mapping between plans and roles
• Timestamps and limited operational logs (for debugging and safety)

Notably not collected:

• Real names, addresses, or emails
• Passwords or seed phrases
• Credit card or bank details

This approach:

• Reduces the impact of any data breach (there is no trove of personal info to steal).
• Aligns with data minimization principles in MiCAR/GDPR-style frameworks.
• Keeps the focus on public blockchain data, which is already openly verifiable.

On-Chain Transparency & Non-Custodial Funds

All payment and subscription actions are executed through the Subscrypts smart contract suite on Arbitrum One:

• Subscription billing is always settled in SUBS.
• A subscription’s price can be denominated in SUBS or in USDC:
  • If the user has enough SUBS, the subscription is paid directly in SUBS.
  • If they are short on SUBS but have enough USDC, the smart contract can perform an on-chain fallback swap:
    • It atomically swaps USDC for SUBS.
    • It immediately uses the acquired SUBS to pay for the subscription.
• Automatic renewal currently requires the user to hold enough SUBS at renewal time. USDC fallback is available for direct payments, not for automatic renewals.

Because everything happens on-chain:

• Users can inspect their subscription history using block explorers or dApps.
• Merchants can audit incoming payments to their own wallet address.
• There is no hidden off-ledger accounting.

Crucially:

• Subscrypts never holds your funds.
• The Discord bot cannot transfer tokens — it only observes contract state and reacts with role changes.
• All subscriptions require explicit confirmation from the user’s wallet.

This non-custodial model reduces custodial risk, helps protect the unbanked (they only need a wallet, not a bank account), and facilitates cross-border access without going through traditional financial rails.

RPC Calls, Events & Caching

To understand how the bot keeps everything in sync, it helps to know three concepts:

What is an RPC?

An RPC (Remote Procedure Call) is how applications talk to a blockchain node. On EVM chains like Arbitrum, this is usually JSON-RPC over HTTPS.

The Subscrypts Discord Bot uses RPC calls to:

• Read subscription state (via view functions in the FacetView of the Subscrypts contracts).
• Check whether a subscription is active, expired or cancelled.
• Retrieve plan metadata and pricing details when needed.

Event listeners

The smart contracts emit events such as:

• _subscriptionPay – when a subscription is started or renewed
• _subscriptionStop – when a subscription is cancelled or reaches end-of-term

The bot and its web services:

• Subscribe to these events via trusted infrastructure.
• Use them to trigger sync work quickly, instead of constantly polling the chain.

Ephemeral, non-authoritative caching

To avoid overloading RPC providers and to keep responses snappy, the bot uses short-lived caches:

• Caches are scoped per guild (per Discord server).
• They store things like:
  • Plan → role mappings
  • Recent subscription lookups
  • Internal status snapshots
• They are invalidated via time-based TTLs and event-triggered refreshes.

Importantly:

• Caches are never treated as the final truth.
• Role decisions are always confirmed against authoritative on-chain data before being applied or changed.
• The refresh frequency can be tuned as the service scales, balancing:
  • Freshness of data
  • RPC rate limits
  • Overall performance

In other words: caching makes the system faster and more robust, but the blockchain always wins in case of conflict.

For a deeper look at this behavior, see Subscription Synchronization.

Discord Permissions & Least Privilege

The Subscrypts Discord Bot works entirely within Discord’s permissions model:

• The server owner (or someone with Manage Server) chooses which permissions to grant:
  • Manage Roles, Manage Channels, Create Private Threads, Read Message History, etc.
• The bot can only:
  • Manage roles below its own bot role in the role hierarchy.
  • Read/write in channels where it has been granted access.

Recommendations:

• Place the bot’s role above the premium roles it must grant/revoke, but not above your highest administrative roles if you want strict separation.
• Use private threads and correctly configured channels (as described in Getting Started for Admins) to keep wallet linking flows and admin logs scoped to the right audience.

Most of the bot’s responses (especially command results) are sent as ephemeral messages where appropriate — visible only to the user who invoked the command, and not to the whole server.

Webserver & Webhook Security

The embedded webserver that powers wallet-link pages and subscribe pages is secured with multiple layers:

• Signed payloads

  • The bot sends compact, signed payloads describing each guild’s active plans and role labels.
  • The webserver verifies these signatures using a shared secret before accepting or updating data.

• Signed short URLs

  • /s/... links embed a signature tied to the guild and version.
  • If someone tries to forge a link or alter its structure, signature verification will fail and the request is rejected.

• Scoped updates

  • Subscribe pages and per-guild views only show data for that guild.
  • Requests that don’t match a valid guild/signature combination are ignored.

• No private key handling

  • The webserver never asks for or handles seed phrases or private keys.
  • Wallet interactions happen via standard browser wallet integrations (e.g., MetaMask).

Combined, this ensures that:

• Guild admins can’t silently change the behavior of subscribe links without using legitimate tools.
• Attackers can’t easily impersonate the official subscription flows.
• Users can verify they’re on the real site by checking the domain and the /s/... path.

What This Means for Merchants

For Discord server owners and merchants, the security model delivers:

• Lower compliance surface – you do not process card data or store user PII; you receive on-chain SUBS payments into your own wallet.
• Clear separation of concerns – the smart contracts handle billing, the bot handles access control, Discord handles community features.
• Cross-border reach – anyone with a wallet and internet access can subscribe, regardless of local banking infrastructure.
• Protection against fraud/chargebacks – on-chain payments cannot be reversed the way card chargebacks can.

You remain responsible for:

• Communicating your offering and terms clearly.
• Configuring roles and channels correctly.
• Following any local regulations that apply to your business.

Subscrypts provides the technical rails; you control the community and value.

What This Means for Subscribers

For members, this model ensures:

• Self-custody – you keep your keys, you approve each transaction.
• Privacy – your Discord identity is linked to a wallet address, not to real-world identity data collected by the service.
• Portability – you can move funds between wallets and chains outside of Subscrypts’ control.
• Borderless access – as long as you can use a wallet on Arbitrum, you can subscribe, even without a bank account or credit card.

If you no longer trust a server or simply want to leave:

• You can let your subscription expire, or cancel it where supported.
• You can unlink your wallet from that server with /subs unlink.
• Your funds remain in your wallet; the bot cannot touch them.

Summary

For broader context, see:

• Architecture & Integration – how all components fit together.
• Subscription Synchronization – how on-chain state becomes Discord roles.
• Best Practices & Troubleshooting – tips to keep your server safe and reliable.