{"id":232223,"date":"2026-09-25T07:21:49","date_gmt":"2026-09-25T07:21:49","guid":{"rendered":"https:\/\/mycryptomania.com\/?p=232223"},"modified":"2026-09-25T07:21:49","modified_gmt":"2026-09-25T07:21:49","slug":"no-code-crypto-trading-and-backtesting-tools-from-strategy-idea-to-evidence","status":"publish","type":"post","link":"https:\/\/mycryptomania.com\/?p=232223","title":{"rendered":"No-code crypto trading and backtesting tools: from strategy idea to evidence"},"content":{"rendered":"

I wanted to test strategies on crypto perpetual futures without coding\u200a\u2014\u200awith trade management, funding, fees and out-of-sample validation included, then run them live\u200a\u2014\u200awithout rebuilding the strategy every time the idea\u00a0changed.<\/strong><\/p>\n

Image Is Generated By\u00a0ChatGPT<\/p>\n

Search for \u201cno code crypto trading bot\u201d<\/strong> and you get plenty of ways to automate trading without programming.<\/p>\n

That part is no longer\u00a0unusual.<\/p>\n

There are tools that let you build rules visually, backtest them, optimize parameters and sometimes take the same strategy into paper or live\u00a0trading.<\/p>\n

The problem I kept running into was different:<\/p>\n

How do I get from a trading idea to evidence I can actually evaluate, without spending most of the time implementing the\u00a0idea?<\/strong><\/p>\n

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.<\/p>\n

I should say this early: I eventually became one of the people building the tool I wanted. It is called VESKALD<\/a>, so this is obviously not an independent comparison of trading platforms.<\/p>\n

But the requirements came first, and they are still the way I think about this category.<\/p>\n

We did look at existing tools. The problem was not that no-code trading software did not\u00a0exist.<\/p>\n

None of these ideas is new in isolation.<\/strong> Visual strategy building, backtesting, optimization, out-of-sample testing, portfolio analysis and automated execution all existed long before\u00a0Veskald.<\/p>\n

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\u00a0form.<\/p>\n

What we wanted was to shorten the distance between a trading idea and a trustworthy test.<\/p>\n

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\u00a0it.<\/p>\n

What \u201cno code\u201d means to me\u00a0now<\/h3>\n

The question was not really code versus no\u00a0code.<\/p>\n

It was strategy versus implementation<\/strong>.<\/p>\n

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\u00a0did.<\/p>\n

I wanted the engine to carry that complexity while I stayed focused on the trading logic\u00a0itself.<\/p>\n

That is probably the simplest way to describe what Veskald\u00a0became:<\/p>\n

Veskald is a strategy research environment, not a visual programming environment.<\/strong><\/p>\n

That distinction ended up mattering more to me than whether a strategy was built with blocks, forms or natural language.<\/p>\n

Because the entry is only the beginning of a strategy.<\/p>\n

The entry is not the\u00a0strategy<\/h3>\n

Two strategies can use exactly the same entry and behave like completely different systems.<\/p>\n

Imagine both enter short on the same condition.<\/p>\n

One closes the entire position at\u00a0+3R.<\/p>\n

Another takes part of the position at +1R, moves the stop to break-even, starts trailing later and closes the remainder if momentum reverses.<\/p>\n

A third exits after N candles if the trade has gone nowhere and reduces risk after a sequence of\u00a0losses.<\/p>\n

The signal is identical.<\/p>\n

The trading system is\u00a0not.<\/p>\n

That changed what I was looking for in a no-code platform.<\/p>\n

I did not just\u00a0want:<\/p>\n

condition \u2192 buy\/sell \u2192 stop \u2192\u00a0target<\/strong><\/p>\n

I wanted the strategy to describe the whole trade\u200a\u2014\u200aincluding skip rules, risk, sizing, stops, take-profits and position management.<\/p>\n

Once I started looking at tools this way, the number of indicators and the style of the visual builder mattered much\u00a0less.<\/p>\n

The more important questions became:<\/p>\n

Can it describe the whole trade in rules I can read\u200a\u2014\u200aor mainly the entry, with the rest hidden in generated code?<\/strong><\/p>\n

How quickly can I change one part of the idea and test it\u00a0again?<\/strong><\/p>\n

And is the thing that was validated actually the thing that will run\u00a0live?<\/strong><\/p>\n

What I actually needed from a no-code crypto backtester<\/h3>\n

My requirements became fairly\u00a0simple:<\/p>\n

Take a trading idea\u200a\u2014\u200amine or someone else\u2019s\u200a\u2014\u200aand 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\u00a0rules.Risk per trade that changes on its own after a streak\u200a\u2014\u200afor example, half the risk after three stops in a row, back to normal after the next\u00a0win.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\u00a0trading.Keep the trading API key on my own machine and compare live fills with what the model expected.<\/p>\n

Most of those capabilities exist somewhere.<\/p>\n

The combination and the workflow around them were what mattered to\u00a0us.<\/p>\n

Backtesting crypto perpetual futures without\u00a0coding<\/h3>\n

Funding was one of the things I initially underestimated.<\/p>\n

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\u00a0result.<\/p>\n

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\u00a0weeks.<\/p>\n

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.<\/p>\n

Average holding time ranged from about 26 days to about 3\u00a0days.<\/p>\n

The result ranged from roughly +2.4R to\u00a0+15.8R.<\/p>\n

The entry had not\u00a0changed.<\/p>\n

The strategy\u00a0had.<\/p>\n

That experiment convinced me that treating position management as a few settings attached to an entry signal hides too much of the actual\u00a0system.<\/p>\n

Full numbers are here: The edge is in the exit\u200a\u2014\u200aposition management<\/a><\/p>\n

A profitable backtest is evidence, not a\u00a0decision<\/h3>\n

A single historical result tells you what happened for one parameter set over one path through\u00a0history.<\/p>\n

It does not tell you how fragile that result\u00a0is.<\/p>\n

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.<\/p>\n

So I wanted several checks built into the workflow.<\/p>\n

Holdout data<\/h3>\n

Tune on one part of the history, freeze the strategy, then expose it to another part the optimizer has not\u00a0seen.<\/p>\n

In Veskald the holdout is kept out of optimization, so the optimizer cannot turn it into training\u00a0data.<\/p>\n

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\u00a0holdout.<\/p>\n

It is no longer clean validation data.<\/p>\n

But at least the optimizer itself never touched\u00a0it.<\/p>\n

Monte Carlo<\/h3>\n

Monte Carlo does not prove that an edge\u00a0exists.<\/p>\n

What it can show is how different the path might have looked given the trades you observed.<\/p>\n

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.<\/p>\n

Other markets and\u00a0regimes<\/h3>\n

If I believe a rule captures some general market behaviour, I want to know what happens when the same strategy runs on other\u00a0pairs.<\/p>\n

It does not have to make money everywhere.<\/p>\n

But if one pair produces an exceptional result while everything else collapses, that is useful information.<\/p>\n

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.<\/p>\n

None of these tests\u00a0says:<\/p>\n

\u201cThis is a good strategy.\u201d<\/strong><\/p>\n

They make weak evidence harder to\u00a0ignore.<\/p>\n

Research should not end at deployment<\/h3>\n

What I eventually wanted was not a one-way path from strategy to\u00a0bot.<\/p>\n

It was a continuous research\u00a0loop:<\/p>\n

create \u2192 test \u2192 verify \u2192 deploy \u2192 compare with reality \u2192\u00a0improve<\/strong><\/p>\n

And \u201ccreate\u201d does not necessarily mean inventing a strategy from\u00a0scratch.<\/p>\n

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\u00a0does.<\/p>\n

Deployment is not the end of that process\u00a0either.<\/p>\n

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.<\/p>\n

That evidence should feed the next version of the\u00a0idea.<\/p>\n

The unit of research does not have to be one\u00a0strategy<\/h3>\n

Another requirement was to stop judging strategies only in isolation.<\/p>\n

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.<\/p>\n

So at some point the unit of research stops being a single strategy.<\/p>\n

It becomes a portfolio of strategies sharing the same\u00a0capital.<\/p>\n

The important distinction for us is that the portfolio should not become a coordinator that strategies depend on in order to function.<\/p>\n

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\u00a0failure.<\/p>\n

Each Veskald strategy remains self-contained.<\/p>\n

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\u00a0doing.<\/p>\n

The portfolio layer has a different job.<\/p>\n

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\u00a0set.<\/p>\n

So the question is not\u00a0only:<\/p>\n

\u201cIs this strategy\u00a0good?\u201d<\/strong><\/p>\n

It is\u00a0also:<\/p>\n

\u201cWhat does this strategy do to the portfolio?\u201d<\/strong><\/p>\n

For us, the portfolio should measure strategies together, not become the brain they depend on to\u00a0work.<\/p>\n

The part I cared about more than the visual\u00a0builder<\/h3>\n

There was another requirement that came more from being an engineer than from being a\u00a0trader.<\/p>\n

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\u00a0trading.<\/p>\n

Every translation step is another place where the two versions can\u00a0diverge.<\/p>\n

In Veskald a strategy is stored as one structured configuration, and the same object moves\u00a0through:<\/p>\n

builder \u2192 backtest \u2192 optimizer \u2192 validation \u2192 execution<\/strong><\/p>\n

Historical data calls the strategy engine candle by\u00a0candle.<\/p>\n

Live trading calls the same logic when the latest completed candle\u00a0arrives.<\/p>\n

There are still modelled differences between historical and live markets. For example, a historical entry is placed at the open of the next\u00a0candle.<\/p>\n

But there is no second implementation of the strategy that has to be rewritten for production.<\/p>\n

That gives us a useful invariant:<\/p>\n

the strategy we validate is the strategy we\u00a0deploy.<\/strong><\/p>\n

Change the stop, break-even trigger or skip rule and the strategy itself has\u00a0changed.<\/p>\n

What happens between backtest and\u00a0reality<\/h3>\n

Position size is one example of something I did not want to treat as a fixed\u00a0number.<\/p>\n

The strategy defines risk and the stop defines distance. Position size follows from those two numbers by formula, not by\u00a0eye.<\/p>\n

The engine rounds the result to the instrument\u2019s quantity step, caps it against recent volume and calculates the leverage from the stop distance and the exchange\u2019s bracket table, so that liquidation always stays beyond the\u00a0stop.<\/p>\n

If a valid position cannot be constructed under those constraints, the trade is not\u00a0opened.<\/p>\n

Those trades go into a skip log with the reason, separately from signals blocked by the strategy\u2019s own skip\u00a0rules.<\/p>\n

That distinction matters.<\/p>\n

A backtest showing 40 attractive trades looks different once you see how many other signals could not actually be executed under the strategy\u2019s assumptions.<\/p>\n

And even after all of that, a backtest is still a\u00a0model.<\/p>\n

Once a strategy runs live, Veskald puts each strategy-generated order next to what the exchange actually\u00a0filled.<\/p>\n

Entry against actual\u00a0entry.<\/p>\n

Stop against actual\u00a0stop.<\/p>\n

Take-profit against actual take-profit.<\/p>\n

Manual interventions stay separate from the strategy\u2019s own\u00a0trades.<\/p>\n

The purpose is not to prove the model was\u00a0right.<\/p>\n

It is to make it obvious when it was\u00a0wrong.<\/p>\n

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\u00a0curve.<\/p>\n

Running the bot without giving the platform your trading\u00a0key<\/h3>\n

The execution architecture was mostly a trust decision.<\/p>\n

The normal hosted setup is simple: give the platform an exchange API key with trading permissions and let its servers place\u00a0orders.<\/p>\n

I did not want\u00a0that.<\/p>\n

Veskald uses read-only exchange access to follow position and account\u00a0state.<\/p>\n

The trading key stays with an open-source executor running on the user\u2019s own machine or\u00a0VPS.<\/p>\n

The platform sends instructions.<\/p>\n

The local executor places\u00a0orders.<\/p>\n

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.<\/p>\n

That boundary is deliberate.<\/p>\n

The part we backtest and validate stays reproducible.<\/p>\n

The part you want to extend stays\u00a0yours.<\/p>\n

There is a trade-off.<\/p>\n

The local bot is an executor, not an autonomous copy of Veskald. If the platform stops sending events, it does\u00a0nothing.<\/p>\n

I prefer stating that limitation directly.<\/p>\n

Deliberate constraints<\/h3>\n

One of the more opinionated choices in Veskald is that you cannot insert arbitrary Python, JavaScript or an ML model inside a strategy.<\/p>\n

That is deliberate.<\/p>\n

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\u00a0live.<\/p>\n

Arbitrary code would make the strategy language more expressive, but it would weaken those guarantees.<\/p>\n

Custom logic can still exist after a signal leaves Veskald, on the user\u2019s side of the self-hosted execution interface. We keep it outside the strategy whose historical and validation results are being\u00a0judged.<\/p>\n

There are other\u00a0limits.<\/p>\n

Veskald currently focuses on crypto perpetual futures.<\/p>\n

There is no market-wide screener.<\/p>\n

You cannot insert your own scripts or ML models inside the strategy.<\/p>\n

And the platform does not decide that a strategy is\u00a0\u201cgood\u201d.<\/p>\n

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.<\/p>\n

The decision stays with the\u00a0trader.<\/p>\n

Three questions I would ask any no-code trading\u00a0platform<\/h3>\n

After going through this, I think three questions quickly show what kind of tool you are looking\u00a0at:<\/p>\n

Can it describe the whole trade in rules I can read\u200a\u2014\u200aor mainly the entry, with the rest hidden in generated code?<\/strong><\/p>\n

Can I change an idea and get back to evidence quickly, or am I effectively programming again?<\/strong><\/p>\n

Does the research continue after deployment by comparing the model with what actually happened?<\/strong><\/p>\n

If I cannot read the rules, I cannot answer why they stopped working when that day\u00a0comes.<\/p>\n

We had been running strategies on the Veskald engine for some time before opening the platform to other\u00a0traders.<\/p>\n

The original reason for moving strategies out of code was practical: testing the next idea had become slower than executing the previous\u00a0one.<\/p>\n

The more important consequence was that once the strategy became structured data, the system could understand what every part of it\u00a0meant.<\/p>\n

That made it possible to keep the strategy at the centre of a continuous loop:<\/p>\n

create \u2192 test \u2192 verify \u2192 deploy \u2192 compare \u2192\u00a0improve<\/strong><\/p>\n

The goal is not to make strategy programming easier.<\/p>\n

It is to shorten the path from a trading idea\u200a\u2014\u200ayours or someone else\u2019s\u200a\u2014\u200ato evidence you can actually evaluate, and then keep improving that evidence once the strategy meets the real\u00a0market.<\/strong><\/p>\n

No-code crypto trading and backtesting tools: from strategy idea to evidence<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":"

I wanted to test strategies on crypto perpetual futures without coding\u200a\u2014\u200awith trade management, funding, fees and out-of-sample validation included, then run them live\u200a\u2014\u200awithout rebuilding the strategy every time the idea\u00a0changed. Image Is Generated By\u00a0ChatGPT Search for \u201cno code crypto trading bot\u201d and you get plenty of ways to automate trading without programming. That part is […]<\/p>\n","protected":false},"author":0,"featured_media":232224,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-232223","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/232223"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=232223"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/232223\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/232224"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=232223"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=232223"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=232223"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}