Security, custody, and what we do not have

There is no exchange account and no omnibus wallet with your balance in it. You trade from a self-custodial embedded wallet, keys stay under your control on your device, and every position settles to an address you own. That is a structural property rather than a policy: there is no ledger entry we could freeze, and no balance of yours for us to lose.

The embedded wallet and the authentication behind it come from Privy, a specialist provider used by the same class of application. Naming it matters: "non-custodial" is a claim anyone can print, and the meaningful question is whose key infrastructure stands behind it and what their own security posture is, which is something you can go and read for yourself.

The gateway prepares an order, computes the fee and hands you something to sign. It cannot sign for you. That is why the app can route to several venues without you holding an account at any of them, and it is also the boundary that stops a compromise of our infrastructure from becoming a compromise of your funds: an attacker who reached the gateway could disrupt the service, not move your balance.

The agent and the MCP connector are read-first by design. An assistant can read your portfolio and the market, and it can stage a trade, but staging is where its authority ends: the order renders as a confirmation you have to approve in the app, and the confirmation link expires after two minutes. API keys are read-only by default, and a trade scope is a deliberate second step rather than something granted by connecting.

• Read-only scope by default on every issued key
• Trade scope is opt-in and separate
• Staged trades expire after two minutes if not confirmed
• Client-side signing venues cannot be traded headlessly at all

The data we do hold, which is account metadata, positions history, alerts and points, sits behind row-level security policies at the database rather than only at the application, so a query path that forgets to filter by user returns nothing rather than everything. Access to the trading API requires either a Privy-issued session or a scoped API key.

No third-party security audit of the Hypertradeworx application has been published, and we are not going to imply otherwise by linking to the audits of the venues we route to. Those audits are real and they cover those protocols, which is where your funds actually sit while a position is open, but they say nothing about our code. The mitigation, and the reason the architecture is worth reading, is that our code never has custody in the first place. Treat that as the reason to use it, not as a substitute for an audit we have not had.

Self-custody moves the failure modes to your side. Device compromise, a lost recovery path, an approval signed without reading it, or a phishing page dressed as ours are all outside anything we can reverse. There is no support channel that can undo a signed transaction, because there is no privileged position from which to undo it.