Remote / Blackbox strategies
A remote strategy (sometimes called blackbox) lets you run signals generated outside Stretus - your own script, a spreadsheet, a third-party service - through Stretus's execution, risk, and monitoring pipeline. Stretus never sees your logic; it only receives the signals you send and executes them under the same capital and risk controls as any other strategy.
This is the one part of the docs aimed at a technical user wiring an external system. Everything else about the strategy - capital, monitoring, paper/live - works exactly as described elsewhere.
When to use this
| Use a remote strategy when. . | Use the AI engine when. . |
|---|---|
| You already generate signals elsewhere and just need execution | You want Stretus to design the strategy |
| Your logic is proprietary and must stay off-platform | You're iterating on ideas conversationally |
| You want Stretus's risk gate, capital model, and monitoring on external signals | You want backtesting on Stretus data |
How it works
| Step | Stage | Detail |
|---|---|---|
| 1 | Your system emits a signal | Your own logic, outside Stretus |
| 2 | The Stretus remote endpoint receives it | Authenticated |
| 3 | The risk gate evaluates it | Capital and configured limits |
| 4 | The order reaches your broker or exchange | Paper or live |
You create a remote strategy, receive an API key, and then deliver signals one of three ways:
- Push: your system calls the Stretus remote endpoint with a signed request whenever it has a signal
- Pull endpoint: you configure a URL Stretus polls to fetch signals on a schedule
- Telegram webhook: signals arrive through a bound Telegram chat
The first two are configured per strategy from its integration page.
Earlier docs described two ingress paths. A third exists: a Telegram webhook with its own authentication and its own per-chat and per-strategy rate limits. See Telegram ingress below.
Setting it up
- Go to Strategies -> New remote strategy (or
/remote-strategy/new) - Name the strategy, choose its asset class and trading account, and set capital allocation - same as any strategy
- On the strategy's Integration page, generate an API key
- Choose your delivery method: push (send signed requests) or a pull endpoint (Stretus fetches from your URL)
- Deploy to paper first to confirm signals arrive and execute as expected, then switch to live
Authentication & security
Remote signals cross the public internet, so the endpoint is secured:
| Control | Purpose |
|---|---|
| API key | Identifies which strategy the signal belongs to |
| HMAC signature | Each request is signed with your key's secret so it can't be forged or tampered with |
| Replay protection | Timestamp/nonce checks reject duplicated or stale requests |
| IP policy | Optionally restrict which source IPs may send signals |
| Rate limits / quota | Protects your strategy from runaway or accidental signal floods |
Telegram ingress
A third path: send signals from a bound Telegram chat.
How it is secured
| Control | Detail |
|---|---|
| Secret token | The webhook authenticates on a secret token Telegram echoes back, configured when the webhook is registered. A request without it is rejected as unauthenticated |
| Chat binding | A chat must be explicitly bound to a strategy through a deep-link connect flow. An unbound chat's messages are terminated with a no-binding decision |
| Rate limits | Enforced per chat and per strategy independently |
| Audit trail | Every decision is recorded with the chat id, the decision, and a hash of the payload |
| Automatic revocation | Blocking or removing the bot revokes the binding immediately |
Response semantics
Worth knowing if you are integrating: the webhook returns 2xx even for a rejected signal, so Telegram does not retry-storm a decision that has already been made. It returns 5xx only on a transient failure on the platform's own side.
The practical consequence: a 200 does not mean your signal was accepted. Read the bot's reply and the strategy's event timeline, not the HTTP status.
When to use it
| Telegram ingress suits | Push or pull suits |
|---|---|
| Signals a human generates or approves | Fully automated systems |
| A low-volume discretionary overlay | High-frequency or high-reliability paths |
| Getting started without building a signed client | Production integrations |
It is not a trading-grade transport. Message delivery is best-effort, ordering is not guaranteed under load, and the account is only as secure as the device it is signed in on. For anything where a missed or duplicated signal matters, use push with HMAC signing.
See Notifications for the outbound direction, alerts about your own strategies.
The signing secret is shown once when you issue a key. Store it in your own secrets manager. If it leaks, rotate the key immediately from the Integration page - rotation issues a new secret and invalidates the old one.
Key rotation & revocation
From the Integration page you can rotate (issue a new secret, retire the old one) or revoke (disable entirely) a key at any time. Rotate on a schedule and whenever you suspect exposure.
Testing before live
Always run a remote strategy in paper first. Watch the Live Terminal as you send test signals - you'll see each signal arrive, pass or fail the risk gate, and fill in the simulator. Only switch to live once the round-trip is clean.