1) What TRALADAL is and what it is not
https://www.tradingview.com/script/oc2K8Hkq-TradingView-Alert-Adapter-for-AlgoWay
TRALADAL is an open-source TradingView strategy that acts as a universal adapter between indicator signals and automated execution through AlgoWay.
The adapter focuses on three operational goals:
- Convert indicator outputs into a backtestable strategy, so you can measure win rate, drawdown, and profit factor objectively.
- Use the same entry/exit logic to produce structured alerts.
- Embed execution parameters (routing and risk fields) into the alert payload for AlgoWay.
TRALADAL does not generate trading ideas and does not provide “signals” by itself. It evaluates inputs you connect (sources/values) and translates them into consistent strategy actions.
2) High-level architecture
TRALADAL is built around an input source–based model.
Instead of hardcoding indicators, it reads values from user-selected input.source fields.
This allows the adapter to work with:
- event outputs (1 / non-zero values, arrows, shape streams),
- continuous lines (EMA, VWAP, RSI, MACD, custom lines),
- invite-only or locked indicators (because you only need their plotted/streamed output).
Internally, the strategy uses a three-layer logic model:
- Signal — the primary entry trigger (the “reason” to trade).
- Confirmation — directional validation (the “permission” to trade).
- Filter — noise reduction (the “environment check”).
Each layer can be enabled independently, and layers can be combined using AND / OR logic, allowing multi-indicator systems without writing Pine code.
3) Execution modes
TRALADAL supports two execution philosophies:
3.1 Strategy Mode (Backtest-first)
- Risk rules (SL/TP/Trailing) are applied inside Strategy Tester.
- The goal is to measure system quality, not to produce a “live-ready” payload.
- Alerts can still be emitted, but Strategy Tester becomes the primary truth source.
3.2 Alert Mode (Automation-first)
- Strategy decisions are converted into a structured alert payload.
- Risk parameters are embedded into the JSON message and executed by AlgoWay.
- The goal is consistent live execution across platforms through a unified payload.
4) Signal pipeline (Signal → Confirmation → Filter)
4.1 Core boolean states
TRALADAL reduces your connected indicator outputs into booleans:
-
long_signalandshort_signal -
long_confirmandshort_confirm -
filter_ok(or separate long/short filters)
The adapter then computes final permissions:
final_long_ok = long_signal AND/OR long_confirm AND filter_ok
final_short_ok = short_signal AND/OR short_confirm AND filter_ok
4.2 Recommended combination logic
This section describes recommended patterns you can apply depending on what your indicator outputs represent.
Pattern A — Strict gate (recommended for multi-indicator systems)
- Signal is a precise trigger (entry arrow / crossover event).
- Confirmation is a trend permission (EMA slope, MACD sign, higher timeframe regime).
- Filter is volatility / session / spread safety.
final_long_ok = SignalLong AND ConfirmLong AND FilterOK
final_short_ok = SignalShort AND ConfirmShort AND FilterOK
Pattern B — Flexible triggers (when signal is “soft”)
- Signal is not a strict event, but a condition that can remain true for many bars (e.g., RSI > 50).
- Confirmation adds specificity (crossover, pivot, structural break).
final_long_ok = (SignalLong OR ConfirmLong) AND FilterOK
final_short_ok = (SignalShort OR ConfirmShort) AND FilterOK
Pattern C — Layer disabling (minimal setup)
Minimal setup for quick testing:
- Only Signal is used.
- Confirmation and Filter are disabled.
final_long_ok = SignalLong
final_short_ok = SignalShort
Minimal setup is useful for: verifying that you wired the correct sources, confirming that long/short polarity is correct, and validating alert firing frequency.
5) Entry logic — what “entry” means in TRALADAL
5.1 Entry types
TRALADAL can represent entries in two practical forms:
- Event-based entry — the entry is a single bar trigger (e.g., arrow prints, crossover happens).
- State-based entry — the entry condition is a persistent state (e.g., RSI > 50 for 20 bars).
5.2 How to avoid repeated entries
If your input sources represent states, you must ensure that the adapter triggers only when the state changes, otherwise you can get repeated alerts on every bar.
Recommended practice:
- Use event signals whenever possible (crosses, transitions, “1” markers).
- If your indicator only provides a state, convert it into a transition at the indicator level if possible.
- If you cannot change the indicator, use strict Confirmation as the “event” layer.
6) Exit logic — the “Task: Flat” concept
6.1 Exit is not always “stop-loss / take-profit”
TRALADAL separates two concepts:
- Risk exits: SL / TP / Trailing (pips-based).
- Logic exits: explicit “Flat” signals (neutral state or close trigger).
6.2 Flat triggers (logical close)
A “Flat” task can be triggered by one of these families:
- Neutral signal — the system becomes neutral and must close open positions.
- Opposite signal — a reverse triggers close + new entry.
- Explicit close source — a dedicated close signal line / value from an indicator.
6.3 Exit policies
In automated execution you must choose one clear policy:
Policy 1 — Reverse on opposite signal
- When a short entry triggers while long is open, close long and open short.
-
Payload typically sends
task=sell(and AlgoWay handles the reversal according to webhook mode).
Policy 2 — Flat on neutral, enter on fresh signal
- When the system goes neutral, close current position.
- Only open a new position when a new entry trigger fires.
Policy 3 — Flat only (no reverse)
- Opposite signal does not open a new position immediately.
- It only closes the current position (risk reduction mode).
Recommended for multi-indicator systems: Policy 2, because it avoids whipsaw flips when two indicators disagree on consecutive bars.
7) Risk parameters (pips) and what they mean
TRALADAL supports risk fields typically used in AlgoWay automation:
- Stop Loss (pips)
- Take Profit (pips)
- Trailing Stop (pips)
7.1 Minimal values
Minimal values depend on:
- instrument volatility,
- spread / commission,
- timeframe and signal frequency.
7.2 Practical recommendations
- Use SL that is larger than typical spread spikes for the instrument.
- Use TP that is not smaller than your average excursion, otherwise you clip winners.
- Use trailing only when your system demonstrates trend persistence; otherwise trailing increases noise exits.
8) Multi-indicator setups — recommended wiring patterns
8.1 Two-indicator classic (Trigger + Trend)
Recommended:
- Signal: your precise entry trigger (arrow/crossover)
- Confirmation: trend regime (EMA direction, MACD sign, higher timeframe state)
- Filter: session/time/volatility guard
8.2 Three-indicator system (Trigger + Trend + Momentum)
Recommended:
- Signal: breakout / arrow
- Confirmation: trend filter
- Filter: momentum confirmation (e.g., histogram sign) OR volatility constraint
8.3 Many indicators at once (avoid “OR soup”)
If you combine many indicators, avoid “OR everywhere”. This creates frequent entries with low quality.
Recommended:
- Keep Signal as a single primary trigger.
- Put all “permissions” into Confirmation and combine them with AND.
- Keep Filter strict and simple (one or two checks max).
9) Alert mechanics — how payload is formed and sent
9.1 TradingView alert type
In the TradingView alert dialog, TRALADAL is designed to be used with:
- Condition: TRALADAL (strategy)
- Option: alert() function calls only
9.2 Payload principles
The payload must be:
- deterministic (same inputs → same JSON),
- explicit (task must be Buy / Sell / Flat),
- platform-aware (routing field must exist),
- risk-aware (SL/TP/Trailing must be included only when enabled).
9.3 Example payload (reference format)
The exact field names must match the TRALADAL code. This is a reference example used in AlgoWay-style routing:
{
"uuid": "YOUR_WEBHOOK_UUID",
"platform": "metatrader5",
"symbol": "{{ticker}}",
"task": "buy",
"risk": 1.0,
"sl_pips": 25,
"tp_pips": 50,
"trail_pips": 0,
"comment": "TRALADAL"
}
IMPORTANT: The “Inputs (Menu)” section below is where each input is mapped to: a) internal strategy variables, b) payload fields, c) recommended ranges. To make it 100% exact, paste the full Pine source code from “Source code”.
10) Inputs (Menu) — Full Technical Reference
This section is intentionally structured as a full “menu-by-menu” reference. Each row explains:
- the input name as it appears in the script,
- what it does technically,
- how it changes the final JSON payload,
- minimal and recommended values,
- usage notes for multi-indicator systems.
10.1 AlgoWay Routing & Identification
| Input (Menu Name) | Type | Technical Role | Payload Impact | Minimal / Recommended |
|---|---|---|---|---|
| Webhook UUID (placeholder) | string | Identifies which AlgoWay webhook should receive the alert. This must match the webhook you created in AlgoWay. |
Sets uuid field in JSON.
|
Minimal: non-empty string. Recommended: copy/paste exact UUID from AlgoWay dashboard. |
| Platform (placeholder) | enum | Selects the destination connector behavior (MT5 / cTrader / TradeLocker / Crypto exchange etc.). |
Sets platform field in JSON.
|
Minimal: one valid platform value. Recommended: keep one platform per alert route. |
| Symbol Mapping / Override (placeholder) | string | Overrides TradingView ticker with broker/exchange symbol when they differ. |
Affects symbol field in JSON.
|
Minimal: empty (use TV ticker). Recommended: set mapping only when required. |
10.2 Signal Sources (Primary Entry Triggers)
| Input (Menu Name) | Type | Technical Role | Payload Impact | Minimal / Recommended |
|---|---|---|---|---|
| Long Signal Source (placeholder) | source | The indicator output line/value that defines a bullish trigger. Can be event-based (1) or value-based. |
Controls when task becomes buy.
|
Minimal: connect to any output that represents long trigger. Recommended: connect to event output (single-bar trigger). |
| Short Signal Source (placeholder) | source | The indicator output line/value that defines a bearish trigger. |
Controls when task becomes sell.
|
Minimal: connect to any output that represents short trigger. Recommended: connect to event output (single-bar trigger). |
| Signal Threshold / Comparator (placeholder) | float / enum | Defines how source values become a boolean (e.g., > 0, == 1, cross). | Changes the timing and frequency of buy/sell tasks. |
Minimal: keep default comparator. Recommended: use strict comparators for non-event sources. |
10.3 Confirmation (Directional Validation)
| Input (Menu Name) | Type | Technical Role | Payload Impact | Minimal / Recommended |
|---|---|---|---|---|
| Enable Confirmation (placeholder) | bool | Turns on/off the confirmation layer entirely. |
When OFF, confirmation does not gate task.
|
Minimal: OFF for quick wiring test. Recommended: ON for live automation. |
| Long Confirmation Source (placeholder) | source | A value/line that must validate a bullish entry (trend permission). |
Gates task=buy in final_long_ok.
|
Minimal: connect to trend sign or slope. Recommended: higher-timeframe trend permission. |
| Short Confirmation Source (placeholder) | source | A value/line that must validate a bearish entry. |
Gates task=sell in final_short_ok.
|
Minimal: connect to trend sign or slope. Recommended: higher-timeframe trend permission. |
| Confirm Combine Logic (placeholder) | enum | Defines if Signal and Confirmation are combined by AND or OR. | Changes when buy/sell is allowed. |
Minimal: AND. Recommended: AND (strict gate). |
10.4 Filter (Noise Reduction)
| Input (Menu Name) | Type | Technical Role | Payload Impact | Minimal / Recommended |
|---|---|---|---|---|
| Enable Filter (placeholder) | bool | Turns on/off the filter layer entirely. | When OFF, filter does not gate tasks. |
Minimal: OFF for first test. Recommended: ON for noisy instruments. |
| Filter Source (placeholder) | source | A condition input that must be “OK” for entries (volatility/session/spread proxy). | Blocks buy/sell tasks when filter fails. |
Minimal: connect to a stable condition. Recommended: volatility regime filter. |
| Filter Comparator (placeholder) | float / enum | Defines what “filter ok” means (e.g., > 0, == 1). | Changes blocking behavior. |
Minimal: keep default. Recommended: use strict equality for event filters. |
10.5 Risk & Positioning
| Input (Menu Name) | Type | Technical Role | Payload Impact | Minimal / Recommended |
|---|---|---|---|---|
| Stop Loss (pips) (placeholder) | int/float | Defines SL distance in pips for risk exits. |
Sets sl_pips in JSON when enabled.
|
Minimal: 0 (disabled). Recommended: instrument-dependent, must exceed spread spikes. |
| Take Profit (pips) (placeholder) | int/float | Defines TP distance in pips for risk exits. |
Sets tp_pips in JSON when enabled.
|
Minimal: 0 (disabled). Recommended: align to system expectancy. |
| Trailing (pips) (placeholder) | int/float | Defines trailing stop in pips. |
Sets trail_pips in JSON when enabled.
|
Minimal: 0 (disabled). Recommended: enable only for trend systems. |
| Risk / Size (placeholder) | float / enum | Defines sizing rule alignment between strategy and alerts. |
Sets risk (or size field) in JSON.
|
Minimal: use default strategy sizing. Recommended: keep consistent with AlgoWay side sizing rules. |
10.6 Exit & Flat behavior
| Input (Menu Name) | Type | Technical Role | Payload Impact | Minimal / Recommended |
|---|---|---|---|---|
| Enable Flat Task (placeholder) | bool | Enables explicit flat (close) tasks based on logic exits. |
Allows task to become flat.
|
Minimal: OFF for entry-only tests. Recommended: ON for realistic automation. |
| Close Source (placeholder) | source | A dedicated input that triggers a close condition. |
Converts close event into task=flat.
|
Minimal: none (disabled). Recommended: use if your indicator provides explicit close/exit markers. |
| Reverse Policy (placeholder) | enum | Defines how opposite signals are handled (reverse vs flat vs ignore). | Changes task emission order and flat behavior. |
Minimal: reverse. Recommended: flat-on-neutral, reverse-on-confirmed. |
To make every row above 100% exact (names, group labels, defaults, and field mapping), paste the Pine source code from the “Source code” tab. Then this table becomes a literal code-to-documentation mapping, with no placeholders.
11) Practical setup guide (with multiple indicator scenarios)
11.1 Minimal setup (fast validation)
- Connect Long Signal Source and Short Signal Source to your indicator outputs.
- Disable Confirmation and Filter.
- Set SL/TP/Trailing to 0.
- Create alert: TRALADAL → alert() function calls only.
11.2 Recommended setup (live automation)
- Use strict AND gate: Signal AND Confirmation AND Filter.
- Use Confirmation as trend permission.
- Use Filter as environment guard.
- Enable Flat tasks for correct close behavior.
11.3 If you run several indicators at once
- Avoid OR across many sources (too many entries).
- Keep Signal as one “trigger” source.
- Put additional conditions into Confirmation and Filter (AND).
- Use Flat-on-neutral to prevent flip spam.
12) Final mapping: Signals → Tasks (Buy / Sell / Flat)
| System State | Condition | Task Emitted | Meaning for AlgoWay |
|---|---|---|---|
| Bull Entry | final_long_ok becomes true | buy |
Open/maintain long according to webhook mode |
| Bear Entry | final_short_ok becomes true | sell |
Open/maintain short according to webhook mode |
| Neutral Close | close condition or neutral state triggers | flat |
Close position (full close) |
13) Next step (to finalize exact Inputs list)
Send the full Pine source code from the TRALADAL “Source code” tab. Then this page will be updated to:
- list every input with its exact menu name and group,
- describe the exact internal variables (step-by-step),
- document the exact JSON field names and formatting logic,
- explain exact entry/exit evaluation order as implemented in the code.
