Security Policy

This page summarizes how Milky Wei Games Inc., an Ontario, Canada corporation operating the Hotpipe SaaS platform (“Hotpipe,” “we,” “us,” or “our”), protects the data and systems behind the Platform. Security questions and vulnerability reports: [email protected].

1. Purpose and scope

Hotpipe is a trading-automation SaaS product: you connect your own brokerage accounts and configure webhook sources and trade rules that can place real orders. The most sensitive assets we handle are broker credentials and the transaction state that can place or alter live trades — so we treat integrity (preventing unauthorized changes) with the same weight as confidentiality.

The Platform runs on managed cloud services. We operate no physical servers of our own.

2. Data we protect

We classify Platform data by impact if it were disclosed, changed, or misused. Highest priority goes to credentials and controls that could enable account takeover or unauthorized trading — including broker connection material, session secrets, webhook authentication, and active trade rules. We also protect account identifiers, order history, webhook payloads, billing status, and related logs.

• Broker credentials and related key material are encrypted at the application layer before storage, and are decrypted only in memory for the short time needed to perform an authorized broker operation.
• Secrets that only need to be checked (such as webhook secrets) are stored in non-recoverable form. Webhook secrets are shown once at creation; login codes are short-lived, single-use, and attempt-limited.
• Sensitive values are kept out of routine logs and error messages wherever practical.
• Production data is not copied into development or test environments; each environment uses separate credentials and keys.
• When you disconnect a broker or delete an account, associated high-sensitivity material is removed from active systems; residual copies in backups expire with the backup retention window.

3. Access control

Your access

• Sign-in is passwordless email one-time codes — short-lived, single-use, and rate-limited.
• Sessions use short-lived access tokens and rotating refresh tokens in HttpOnly, Secure cookies. Tokens are not exposed to page JavaScript.
• Browser origins for credentialed requests are restricted to an allowlist.
• Non-public API access requires authentication (or dedicated webhook authentication), and data access is scoped to the owning account.
• API rate limiting applies globally and per webhook source.

Our access

• Administrative access is limited to named accounts and re-checked on each privileged request.
• Support and administrative personnel cannot retrieve decrypted broker credentials and cannot impersonate customer sessions.
• Infrastructure and vendor consoles use individual accounts with multi-factor authentication. Shared logins are prohibited.
• Production changes ship through controlled deployment pipelines, not ad-hoc production edits.
• Platform secrets live in managed secret storage — not in source code. User broker credentials are stored encrypted separately from the keys that decrypt them.

4. Encryption

• Public endpoints use HTTPS. Session cookies use the Secure flag in deployed environments. Database connections use TLS.
• Broker credentials are encrypted before they are written to the database, with ciphertext bound to the owning account so material cannot simply be moved between users.
• Our cloud, database, and secret-storage providers encrypt data at rest as part of their platform guarantees.
• Broker API traffic uses the broker's required secure channels and signing schemes.

5. Transaction safety

Protecting credentials is necessary but not sufficient for a trading platform; we also constrain what can be done with them:

• Orders are created only through the trade-rule pipeline (authenticated webhook → mapping → validation → rule evaluation → order plan). Rule logic runs in our own bounded evaluator — not as arbitrary remote code execution.
• Broker access uses the narrowest permissions available for trading APIs. Hotpipe does not request withdrawal, transfer, or cash-movement capability.
• We apply practical controls against duplicate webhook processing and keep order records tied to the rules that produced them. No automation system can eliminate all duplicate or failed-delivery risk; you should still monitor your brokerage account.
• You can halt automation unilaterally: disable a trade rule, delete a webhook source, disconnect a broker connection, or revoke Hotpipe's access at your broker — which works even independently of our infrastructure.

6. Vulnerability and change management

• Dependencies are pinned and reviewed for advisories on an ongoing basis. Exploitable issues are prioritized by real-world risk in our deployment.
• Hosting, edge, and database platforms are patched by their vendors. Application images are rebuilt on deploy.
• Releases are gated on automated tests. Security-sensitive areas (authentication, cryptography, order placement, webhook verification, rule evaluation, and tenant isolation) receive extra review attention.
• Suspected vulnerabilities — internal or reported by users — go to [email protected] and are triaged under our incident process.

7. Incidents and recovery

A security incident includes suspected unauthorized access to sensitive customer data or unauthorized order activity. We investigate, contain (including rotating secrets and disabling affected access), remediate, and learn from each incident with a post-mortem.

Hotpipe documents breaches of security safeguards involving personal information and retains those records as required. Where a breach creates a real risk of significant harm, we report it to the Office of the Privacy Commissioner of Canada and notify affected individuals as soon as feasible, and we notify other parties when required by law or when doing so can reduce harm.

The application tier is rebuilt from source on release; durable state lives in managed database and secret storage with provider-backed recovery options. After a serious disruption, we prioritize restoring account access and webhook intake, and we are cautious about re-enabling automated order placement until we have reasonable confidence in execution state. Prefer interrupting automation over submitting an uncertain order.

8. Physical security

Hotpipe operates no data centers or on-premises production equipment. Physical security of production infrastructure is inherited from our cloud providers, which we evaluate using available independent audit reports, certifications, or equivalent evidence as appropriate. Devices used to access production systems must use full-disk encryption, screen lock, and a vendor-supported OS with updates. A lost or stolen device is treated as a security incident.

9. Service providers

We rely on a small set of service providers for functions such as cloud hosting and secrets, managed databases, edge hosting and DNS, source control and CI/CD, transactional email, payment processing, and brokerage APIs you choose to connect. Providers are evaluated before adoption and re-reviewed periodically or on material change. They receive only the data needed for their role, as described in our Privacy Policy. Card payment data is handled by our payment processor and does not touch Hotpipe systems in full.

10. Your responsibilities

Hotpipe's controls protect the Platform; some of the security of your trading automation is necessarily in your hands. Protect the email account you sign in with and the devices you use; treat webhook URLs and secrets as credentials; review the rules you enable and the activity in your brokerage account; and disconnect brokers or disable rules you no longer use.

11. Continuous improvement

Security is ongoing work. We review our practices periodically and after material changes to architecture, vendors, or law. We describe controls that exist rather than controls we only plan to build. No system can eliminate all security risk.

12. Reporting a vulnerability

If you believe you have found a security issue in Hotpipe, email [email protected]with enough detail to reproduce it. Please do not access other users' data or disrupt the service while testing. We will acknowledge your report, keep you informed, and credit you if you would like.