I wanted to test strategies on crypto perpetual futures without coding — with trade management, funding, fees and out-of-sample validation included, then run them live — without rebuilding the strategy every time the idea changed.
Image Is Generated By ChatGPT
Search for “no code crypto trading bot” and you get plenty of ways to automate trading without programming.
That part is no longer unusual.
There are tools that let you build rules visually, backtest them, optimize parameters and sometimes take the same strategy into paper or live trading.
The problem I kept running into was different:
How do I get from a trading idea to evidence I can actually evaluate, without spending most of the time implementing the idea?
I trade crypto perpetuals systematically, with no discretionary entries, and I wanted to research strategies without writing a new implementation every time I changed something.
I should say this early: I eventually became one of the people building the tool I wanted. It is called VESKALD, so this is obviously not an independent comparison of trading platforms.
But the requirements came first, and they are still the way I think about this category.
We did look at existing tools. The problem was not that no-code trading software did not exist.
None of these ideas is new in isolation. Visual strategy building, backtesting, optimization, out-of-sample testing, portfolio analysis and automated execution all existed long before Veskald.
The trade-off was usually wrong for what we wanted. Some tools hid too much behind a black box. Others were extremely flexible, but expressing and changing a non-trivial strategy through code, graphs or blocks could become a programming task in another form.
What we wanted was to shorten the distance between a trading idea and a trustworthy test.
And that idea does not have to be ours. It can be something we came up with, something another trader described, or a strategy we paid for and want to verify before putting money behind it.
What “no code” means to me now
The question was not really code versus no code.
It was strategy versus implementation.
Code, visual graphs and block-based systems can all be extremely flexible. But as a strategy grows, that flexibility comes with implementation work: more state to reason about, more connections to maintain and more time between changing an idea and seeing what that change actually did.
I wanted the engine to carry that complexity while I stayed focused on the trading logic itself.
That is probably the simplest way to describe what Veskald became:
Veskald is a strategy research environment, not a visual programming environment.
That distinction ended up mattering more to me than whether a strategy was built with blocks, forms or natural language.
Because the entry is only the beginning of a strategy.
The entry is not the strategy
Two strategies can use exactly the same entry and behave like completely different systems.
Imagine both enter short on the same condition.
One closes the entire position at +3R.
Another takes part of the position at +1R, moves the stop to break-even, starts trailing later and closes the remainder if momentum reverses.
A third exits after N candles if the trade has gone nowhere and reduces risk after a sequence of losses.
The signal is identical.
The trading system is not.
That changed what I was looking for in a no-code platform.
I did not just want:
condition → buy/sell → stop → target
I wanted the strategy to describe the whole trade — including skip rules, risk, sizing, stops, take-profits and position management.
Once I started looking at tools this way, the number of indicators and the style of the visual builder mattered much less.
The more important questions became:
Can it describe the whole trade in rules I can read — or mainly the entry, with the rest hidden in generated code?
How quickly can I change one part of the idea and test it again?
And is the thing that was validated actually the thing that will run live?
What I actually needed from a no-code crypto backtester
My requirements became fairly simple:
Take a trading idea — mine or someone else’s — and turn its rules into a complete, explicit strategy without programming it.Let entry conditions use several timeframes.Backtest perpetual futures with historical funding, fees and slippage assumptions.Model the open position: multiple take-profits, break-even, trailing, early exits and skip rules.Risk per trade that changes on its own after a streak — for example, half the risk after three stops in a row, back to normal after the next win.Change one part of the idea and test it again without rebuilding the implementation.Keep an untouched part of history away from optimization.Stress the result with Monte Carlo, other markets and regime analysis.Use the same strategy definition in research and live trading.Keep the trading API key on my own machine and compare live fills with what the model expected.
Most of those capabilities exist somewhere.
The combination and the workflow around them were what mattered to us.
Backtesting crypto perpetual futures without coding
Funding was one of the things I initially underestimated.
A perpetual position can remain open for days or weeks and accumulate repeated funding payments. Depending on the exchange, contract, direction and market conditions, that can materially change the result.
Fees and slippage matter for the same reason. A system taking hundreds of short-duration trades has a very different cost profile from one holding positions for weeks.
We ran one experiment using the same short entry, the same stop logic and the same fixed risk per trade, changing only the rules used to manage the position.
Average holding time ranged from about 26 days to about 3 days.
The result ranged from roughly +2.4R to +15.8R.
The entry had not changed.
The strategy had.
That experiment convinced me that treating position management as a few settings attached to an entry signal hides too much of the actual system.
Full numbers are here: The edge is in the exit — position management
A profitable backtest is evidence, not a decision
A single historical result tells you what happened for one parameter set over one path through history.
It does not tell you how fragile that result is.
A system built from 30 trades carries enormous uncertainty. A system that works on BTC may fail when the same logic is applied to ETH. A strategy may make nearly all its money during one volatility regime and quietly lose everywhere else.
So I wanted several checks built into the workflow.
Holdout data
Tune on one part of the history, freeze the strategy, then expose it to another part the optimizer has not seen.
In Veskald the holdout is kept out of optimization, so the optimizer cannot turn it into training data.
That still does not solve the harder human problem. If I look at OOS, dislike the result, change the strategy and test it on the same period again, I have learned from the holdout.
It is no longer clean validation data.
But at least the optimizer itself never touched it.
Monte Carlo
Monte Carlo does not prove that an edge exists.
What it can show is how different the path might have looked given the trades you observed.
The same wins and losses can produce very different drawdowns and losing streaks depending on sequence. I want to see that distribution rather than only the historical ordering.
Other markets and regimes
If I believe a rule captures some general market behaviour, I want to know what happens when the same strategy runs on other pairs.
It does not have to make money everywhere.
But if one pair produces an exceptional result while everything else collapses, that is useful information.
The same applies to regimes. If nearly all the profit comes from one high-volatility cluster while every other environment is flat or negative, I want that visible before deployment.
None of these tests says:
“This is a good strategy.”
They make weak evidence harder to ignore.
Research should not end at deployment
What I eventually wanted was not a one-way path from strategy to bot.
It was a continuous research loop:
create → test → verify → deploy → compare with reality → improve
And “create” does not necessarily mean inventing a strategy from scratch.
It can mean reconstructing a strategy someone else described, checking a system you bought, changing an existing strategy, or testing whether a rule you have used for years still behaves the way you think it does.
Deployment is not the end of that process either.
Once a strategy runs live, it produces new evidence: whether fills matched the model, whether execution assumptions held and whether the strategy is behaving like the system that was actually validated.
That evidence should feed the next version of the idea.
The unit of research does not have to be one strategy
Another requirement was to stop judging strategies only in isolation.
A strategy can look mediocre on its own and still be extremely valuable inside a portfolio if it behaves differently from the others, makes money in different regimes or reduces the combined drawdown.
So at some point the unit of research stops being a single strategy.
It becomes a portfolio of strategies sharing the same capital.
The important distinction for us is that the portfolio should not become a coordinator that strategies depend on in order to function.
We did not want another stateful layer sitting above the strategies and deciding when each one is allowed to act. That creates another dependency, another source of hidden behaviour and another potential point of failure.
Each Veskald strategy remains self-contained.
Its entry filters, skip rules, risk logic, position management and exits belong to the strategy itself. It should continue to behave according to its own validated rules regardless of what the portfolio layer is doing.
The portfolio layer has a different job.
It evaluates what happens when those independent strategies share capital: combined equity, drawdown, drawdown correlation between strategies and whether a strategy that looks unremarkable on its own improves the behaviour of the whole set.
So the question is not only:
“Is this strategy good?”
It is also:
“What does this strategy do to the portfolio?”
For us, the portfolio should measure strategies together, not become the brain they depend on to work.
The part I cared about more than the visual builder
There was another requirement that came more from being an engineer than from being a trader.
I did not want a strategy that is drawn in a builder, then read by one engine for the backtest and by a different engine for live trading.
Every translation step is another place where the two versions can diverge.
In Veskald a strategy is stored as one structured configuration, and the same object moves through:
builder → backtest → optimizer → validation → execution
Historical data calls the strategy engine candle by candle.
Live trading calls the same logic when the latest completed candle arrives.
There are still modelled differences between historical and live markets. For example, a historical entry is placed at the open of the next candle.
But there is no second implementation of the strategy that has to be rewritten for production.
That gives us a useful invariant:
the strategy we validate is the strategy we deploy.
Change the stop, break-even trigger or skip rule and the strategy itself has changed.
What happens between backtest and reality
Position size is one example of something I did not want to treat as a fixed number.
The strategy defines risk and the stop defines distance. Position size follows from those two numbers by formula, not by eye.
The engine rounds the result to the instrument’s quantity step, caps it against recent volume and calculates the leverage from the stop distance and the exchange’s bracket table, so that liquidation always stays beyond the stop.
If a valid position cannot be constructed under those constraints, the trade is not opened.
Those trades go into a skip log with the reason, separately from signals blocked by the strategy’s own skip rules.
That distinction matters.
A backtest showing 40 attractive trades looks different once you see how many other signals could not actually be executed under the strategy’s assumptions.
And even after all of that, a backtest is still a model.
Once a strategy runs live, Veskald puts each strategy-generated order next to what the exchange actually filled.
Entry against actual entry.
Stop against actual stop.
Take-profit against actual take-profit.
Manual interventions stay separate from the strategy’s own trades.
The purpose is not to prove the model was right.
It is to make it obvious when it was wrong.
If the slippage assumption is bad, I want to see it. If liquidity was overestimated, I want to see it. If live execution systematically diverges from the backtest, I would rather find that order by order than infer it months later from a worse equity curve.
Running the bot without giving the platform your trading key
The execution architecture was mostly a trust decision.
The normal hosted setup is simple: give the platform an exchange API key with trading permissions and let its servers place orders.
I did not want that.
Veskald uses read-only exchange access to follow position and account state.
The trading key stays with an open-source executor running on the user’s own machine or VPS.
The platform sends instructions.
The local executor places orders.
Anything the user wants to put between those two steps can stay on their side: an additional filter, a model deciding whether to accept a signal or a different executor speaking the same interface.
That boundary is deliberate.
The part we backtest and validate stays reproducible.
The part you want to extend stays yours.
There is a trade-off.
The local bot is an executor, not an autonomous copy of Veskald. If the platform stops sending events, it does nothing.
I prefer stating that limitation directly.
Deliberate constraints
One of the more opinionated choices in Veskald is that you cannot insert arbitrary Python, JavaScript or an ML model inside a strategy.
That is deliberate.
Because the engine understands every element of the strategy, it can validate it, optimize it, compare versions, reproduce it and execute the same object historically and live.
Arbitrary code would make the strategy language more expressive, but it would weaken those guarantees.
Custom logic can still exist after a signal leaves Veskald, on the user’s side of the self-hosted execution interface. We keep it outside the strategy whose historical and validation results are being judged.
There are other limits.
Veskald currently focuses on crypto perpetual futures.
There is no market-wide screener.
You cannot insert your own scripts or ML models inside the strategy.
And the platform does not decide that a strategy is “good”.
It shows the historical result, OOS result, Monte Carlo distribution, cross-asset runs, regime clustering and, once the strategy is live, the difference between modelled and actual execution.
The decision stays with the trader.
Three questions I would ask any no-code trading platform
After going through this, I think three questions quickly show what kind of tool you are looking at:
Can it describe the whole trade in rules I can read — or mainly the entry, with the rest hidden in generated code?
Can I change an idea and get back to evidence quickly, or am I effectively programming again?
Does the research continue after deployment by comparing the model with what actually happened?
If I cannot read the rules, I cannot answer why they stopped working when that day comes.
We had been running strategies on the Veskald engine for some time before opening the platform to other traders.
The original reason for moving strategies out of code was practical: testing the next idea had become slower than executing the previous one.
The more important consequence was that once the strategy became structured data, the system could understand what every part of it meant.
That made it possible to keep the strategy at the centre of a continuous loop:
create → test → verify → deploy → compare → improve
The goal is not to make strategy programming easier.
It is to shorten the path from a trading idea — yours or someone else’s — to evidence you can actually evaluate, and then keep improving that evidence once the strategy meets the real market.
No-code crypto trading and backtesting tools: from strategy idea to evidence was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.