Trust, Memory, and the Operator’s Evidence
CloddsBot’s trust problem begins outside the order gate. A self-hosted instance connects users and channels to credentials, wallets, model tools, external APIs, local state, and records that must remain understandable after an action. This chapter examines those trust zones and the evidence they produce, so the reader can distinguish confidentiality, authorization, continuity, integrity, and operational readiness instead of treating them as one promise called “security.”
The trust boundary follows the key
Self-hosting changes where responsibility sits. CloddsBot keeps its gateway, database, sessions, and local configuration on the operator’s machine or server, rather than requiring every interaction to pass through a hosted trading intermediary. That can reduce the amount of operational data shared with a third party and makes local experimentation convenient. It also places the host, its filesystem, its network exposure, its updates, and its backups inside the system’s security model.
The most obvious asset is the credential. CloddsBot’s credentials manager stores trading credentials per user and platform, encrypting the payload with AES-256-GCM using a key supplied through CLODDS_CREDENTIAL_KEY. At startup, the application can generate a random key and persist it in the local environment file when one is not already present. At runtime, handlers receive a trading context that resolves credentials when needed rather than asking the model to carry raw secrets in its conversational prompt. Failed authentication can put a credential into an expanding cooldown, reducing repeated attempts with a bad key.
Those are meaningful boundaries, but encryption at rest has a specific scope. It protects the stored payload when the encryption key remains separate and protected. If an attacker controls the running host, can read the environment file, can inspect process memory, or can obtain an unprotected database backup, the existence of AES does not restore confidentiality. Automatic key generation improves setup and restart behavior; it does not turn the host into a hardware security module. The operator still owns key permissions, backup handling, rotation, and the decision to use a trading wallet separate from a primary wallet.
The source also reveals that “per-user credentials” is not one uniform implementation across every advertised integration. The current credentials context builder explicitly loops through Polymarket, Kalshi, and Manifold, while the broader type and documentation surfaces cover additional exchanges and chains. Other handlers may use environment variables, configuration, or an execution-service reference. That does not invalidate the isolation design; it means the operator should verify the credential path for each capability rather than infer universal behavior from the interface name.
Authentication has several layers. Channel policies can use pairing, allowlists, or blocklists for direct messages. The pairing service stores pending requests and paired users in SQLite, uses expiring codes, and distinguishes owners, paired users, and strangers. It can auto-approve local connections and, when configured, Tailscale peers. Those defaults are convenient for a local installation, but auto-approval is a trust decision about network identity. A machine reachable through a private network is not automatically a person the operator intended to authorize.
The HTTP gateway has its own boundary. Sensitive endpoints can require a bearer token through CLODDS_TOKEN; IP-based rate limiting can restrict request volume; HTTPS enforcement and HSTS are available; JSON bodies have a size limit; and CORS handling avoids allowing credentials with a wildcard origin. Webhooks require HMAC signatures by default and compare them in constant time. These controls answer different threats: endpoint access, abuse volume, transport exposure, cross-origin requests, request authenticity, and replay or tampering concerns. None replaces the others.
The effective configuration matters more than the existence of the middleware. The main configuration starts with a local-oriented gateway and an empty gateway-auth object, while channel-specific pairing policies and deployment options decide how much protection is active.