01 What Vesper is
Vesper is SypherScore’s automated trading product for perpetual futures. Public analytics and guide pages can be read separately from authorizing an execution session on a venue account.
This document explains permission boundaries and checks for users and reviewers. It is not a new security audit, a venue-wide certification or a promise that an account cannot lose funds. Current strategy setup belongs in the Vesper guide library.
Version 1.1, content reviewed 26 September 2026, replaces overly broad statements in the August version. Historical observations are not evidence that a later deployed version has passed the same tests.
02 Custody and trading authority are different
No withdrawal permission does not mean no financial risk. A compromised trading credential can submit unwanted orders, incur fees or cause liquidation. Non-custodial is not a guarantee of loss prevention.
03 Read each authorization separately
Account authentication, session control and venue permission are separate boundaries. The fact that a venue API key is created outside Vesper does not mean the site never asks for an ownership signature.
Check the domain, wallet, action, session binding and validity period. A short-lived signature by itself does not prove replay prevention or cross-user isolation.
Follow the current venue guide. Check whether access allows trading, cancellation, leverage changes, transfers or withdrawals, and whether it is restricted to the intended account. The venue’s current documentation and permission screen are the authority for scope and expiry.
Read the selected mode’s guide and review the actual wallet authorization before signing. Venue fees, funding and trading risks depend on your account and market.
04 Evidence needed for a permission claim
A statement that an API key cannot withdraw needs evidence about the actual credential and venue enforcement. Merely finding no withdrawal call in a source file is insufficient.
| Boundary | Evidence a reviewer needs | What it does not prove |
|---|---|---|
| Venue credential | Current permission scope, account binding, expiry and venue specification. | That every credential type or integration has the same restrictions. |
| Session authorization | Exact deployed revision, signed action/session binding, replay and cross-user negative tests. | That a timestamp window alone prevents replay. |
| Credential storage | Integration-specific processing, storage, access, logging and backup review. | That an empty session record means no secret exists elsewhere. |
| Stop and recovery | Requested action, venue acknowledgements, final positions and open orders. | That a success response or disconnected browser is flat and orderless. |
No new live withdrawal, authorization or attack tests were run for this editorial update. It is not an independent audit certificate.
05 Checks without placing a trade
- Check the domain. Open the intended sypherscore.com page and the venue through a trusted route.
- Read the current guide. Match the account, strategy and permission type to the guide library.
- Inspect permission details. Use the venue’s credential screen and official documentation. Do not approve a different or unexplained action.
- Locate the exit controls. Know where the venue shows positions, open orders and revocation before starting.
- Respect warnings. If a browser or wallet flags a request, stop and investigate it; this document is not a reason to bypass the warning.
Do not test withdrawal rejection on a funded account. Active security testing needs an explicitly authorized, isolated scope and a plan for its side effects.
06 Credential handling and data
Distinguish the main wallet private key from a venue API secret or delegated signer. The main wallet secret must not be supplied to the service. Trading credentials still require careful handling wherever the selected integration processes them.
This document does not certify that every integration is browser-local, encrypted at rest, isolated from every other account, or absent from every log and backup. Those are implementation claims requiring current evidence, not consequences of the word “non-custodial”.
- Never put credentials, signatures, tokens or cookies in a public report.
- Check the active permission and expiry in the venue, not just the local connection label.
- Deleting a local credential, revoking venue permission and deleting history are separate actions.
- Read the privacy policy for public-page analytics, identifiers and data requests. A session-statistics inspection is not a complete credential-storage audit.
07 Threats and residual risk
| Threat | Control to examine | Remaining risk |
|---|---|---|
| Phishing or misleading signature | Domain and request review. | A legitimate-looking page or logo does not establish safe permission. |
| Stolen trading credential | Restricted scope, expiry and venue revocation. | Unwanted orders and losses may occur before access is contained. |
| Compromised application | Venue-side permissions and independent account monitoring. | Application-enforced limits are not a trusted loss cap if the application is compromised. |
| Venue or network outage | State reconciliation and available venue-side controls. | Orders, positions and pending requests can remain unresolved. |
| Paired-leg failure | Check each leg, account and margin balance. | A nominal hedge can leave directional or basis exposure. |
08 Risk controls are not guarantees
Quote size, inventory limits, entry conditions and stop thresholds can constrain intended behavior. Their exact availability and accounting basis depend on the strategy. They cannot guarantee a maximum loss, uninterrupted protection or an exit price.
- Reduce-only: verify the order exists, covers the intended position and is enforced by the venue. The flag does not ensure a fill.
- Stop-loss: price moves, slippage, rejected orders or outages can carry the result past the threshold.
- Expiry: a credential expiring while exposure remains can prevent the bot from completing cleanup.
- Recovery: verify session identity, counters and fills; a new Start is not a substitute for reconciling an unresolved run.
See risk-control limits and the session lifecycle. None of these controls establishes future profitability.
09 Stop, revocation and cleanup
- Request Stop when you want a session to finish, then observe whether cleanup is progressing.
- Verify the venue: the affected markets must have zero remaining position and no open orders before you call cleanup complete. Check every leg of a paired strategy.
- Resolve failures through the venue’s own controls if the bot cannot complete the exit. Do not repeatedly Start while old exposure is unresolved.
- Revoke unwanted access through the venue and verify its confirmation. If compromise is suspected, access containment may take priority; remaining positions and orders still need separate attention.
Revocation does not cancel existing orders or close positions by itself. Venue processing and in-flight requests can affect timing, and revoked access may stop the bot from submitting an exit. Do not equate Disconnect, deletion, expiry or revocation with a flat account.
10 Wallet and browser warnings
Do not dismiss a warning as a false positive just because the product is described as non-custodial. Compare the domain and requested action with trusted venue information; decline a request you cannot explain.
A marketing document cannot certify a live wallet dialog. If the dialog requests unexpected token approvals, transfers, recipients, delegates or fees, stop and verify the flow. Do not share a seed phrase or main wallet private key to “repair” a connection.
The safety of a current deployment must be established from scoped technical evidence. This revision removes broad historical assurances rather than presenting them as new audit results.
11 Contact and review scope
Use Telegram or X to report a concern. Describe the public page, venue, approximate UTC time and unexpected behavior. Redact sensitive identifiers in public; never send a key, seed phrase, signature or cookie.
A technical review should identify the exact deployed revision, permitted test actions, isolated accounts and evidence needed. This page does not authorize production probing or fund movements.
Related: Documentation · Guides · Pricing · Privacy · Terms.