MTP integration Original EA development experiment notes 1｜Not sure if it will become a usable EA. Therefore, we will document the development process.
Hello, this is Tsumo.
This article isthe first note of the MTP Integration Original EA Development Experimental Notebook.
In this series, we will build an EA that is not yet complete from here on out.
This is not a showcase of a finished product.
It is not an advertisement for a winning EA.
It is not an article that merely lists beautiful backtests.
We test the ideas as they come to mind.
Turn them into code.
Backtest them.
See them in forward testing.
If the results differ from expectations, discard them.
Keep only parts of them.
Rebuild again.
We will document that process.
Ultimately, there will be logic that we determine cannot be used.
Rather than avoiding it, we will also write about that.
What is truly important in EA development is not just looking at the successful results.
Why it failed.
Where was the danger?
Why we did not adopt it.
Where does potential remain?
Seeing that far will bring us closer to real operation.
This notebook is not a promotion for a finished product.
It is a record of developing and validating whether it becomes a usable EA.
If you are interested in MTP integration, please also take a look here.
MTP: Master [Free]
https://www.gogojungle.co.jp/tools/indicators/79103?via=usersMTP: Slave [Paid]
https://www.gogojungle.co.jp/tools/indicators/79106?via=users
Why start this series
MTP is a mechanism to read the movements of a copied EA and receive them on the live account side.
The structure is as follows.
Run the copied EA on the demo account side.
MTP: Master reads that movement.
MTP: Slave on the live account side follows it.
Until now, the MTP installation guide and the MTP development notes mainly discussed the “receiving side.”
Where to follow from.
What lot size to receive with.
What filter to stop it with.
How to view it in Dashboard.
How to create an exit.
How to view account health.
In other words, this is the design on the MTP side.
But, there is one thought here.
Perhaps the copied EA itself can be designed to be more compatible with MTP.
This is it.
It is possible to receive existing EAs as-is with MTP.
However, not every EA is easy to receive with MTP.
Entry intervals are too tight.
Lot increases are too abrupt.
TP is too shallow.
Drawdowns are formed roughly.
Orders enter normally around major indicators.
There are few logs, making later verification difficult.
EAs like this become difficult to receive with MTP as well.
Therefore, I want to consider original EAs that are inherently friendly to MTP from the start.
That is the starting point of this series.
Not an MTP-only EA
First of all, let me be clear here.
The EAs created in this series are not dedicated to MTP.
I do not intend to create EAs that can only be used with MTP.
What I aim for is an EA like this.
Operates as a standalone EA.
Can be used as a copied EA on a demo account.
Easy to read by MTP: Master.
Easy to manage lot sizes, step numbers, and exits when received by MTP: Slave.
Easy to verify later.
Visible drawdowns.
In other words,
Can be used as a standalone.
And easy to handle when paired with MTP.
We will aim for both.
Not “MTP-only,”an original EA that is well-suited to MTP.
This is important.
Make an EA that is easier to operate than one that merely wins
When people talk about EA development, many first ask “Will it win?”
Of course, an EA that cannot win has no meaning.
But for real-world use, that alone is not enough.
High win rate.
A neat profit curve in backtests.
High monthly return.
Large maximum profit.
These numbers are attractive.
But behind them,
Drawdown is too large.
Losses are being postponed.
Too-narrow averaging intervals.
Abrupt lot increases.
Long holding times.
Hard to reproduce in forward testing.
If there are these problems, real operation is scary.
Especially if you are receiving it with MTP, you cannot judge by win rate alone.
Is it easy to receive on the MTP: Slave side?
Do the lots not run wild?
Is the number of steps easy to read?
Can drawdown be managed?
Does it play well with filters?
That is what I want to examine.
Therefore, in this series, I will prioritizean EA that is easy to operateover one that just wins.
Look at how it fails rather than how it wins.
This will be the axis.
Show not only the successful results
In EA development, dangerous is to look only at the successful results.
A cleanly rising backtest.
Results trimmed to convenient periods.
Parameters tuned to fit.
A logic that happened to fit the market.
If you only look at that, EA development seems easy.
But in reality, it is not.
Many ideas will not be usable.
Even if it looks good at first, it collapses when you change the period.
It collapses when you change the currency pair.
It collapses when spreads widen.
Forward testing shows a different picture.
Drawdown deeper than expected.
Too few entries.
Or too many entries.
These things happen often.
Therefore, in this series, I will also document what didn’t work.
I will write the reasons for discarding them.
Why I had expectations.
What differed from expectations.
Where was the danger.
Whether there is value in further improvement.
Whether to discard it.
All of this will be included as part of the EA development record.
There will be episodes where we judge it as “unusable”
In this series, I think there will be episodes where we decide something cannot be used.
In fact, there should be.
That is okay.
EA development is not only about adoption. It is also about discarding.
Decide that an unusable logic cannot be used.
Admit that a dangerous logic is dangerous.
Judge that a backtest-good logic may not be suitable for live operation.
This is quite important.
If you force use of unusable ones, your account will tell you later.
And it usually costs a lot of money.
Therefore, I will also write the discard decisions as part of development.
“This didn’t work.”
“Expected it to hold, but it collapsed badly.”
“Too rough for receiving with MTP.”
“Even as a standalone, it is hard to handle as the copied EA.”
I will leave these judgments as well.
Not only successful examples, but failures too become assets.
What I want to see in this series
In this series, when creating an EA, I will look at the following points:
Entry conditions.
Entry frequency.
Presence or absence of averaging (nanshin).
Averaging interval.
Maximum number of steps.
Lot size increase.
TP width.
Handling of SL.
Maximum drawdown.
Maximum number of positions.
Holding time.
Compatibility per currency pair.
Spread resilience.
Behavior around important indicators.
Ease of reading by MTP: Master.
Ease of receiving by MTP: Slave.
Emphasis is on maximum drawdown and how it collapses.
It is not only about profitability.
Where will it become difficult?
From which step does it become risky?
How much does it reduce account health?
How long does drawdown stay?
This is what I will observe.
EA reveals its true nature more when things are tough than when they are winning.
So I will observe how it behaves in difficult times.
Do not rely on backtests alone
Backtests are important in EA development.
But judging only by backtests is dangerous.
Backtests verify against past market conditions.
It was good for that period.
It was good for that currency pair.
It was good under those spread conditions.
That is the story.
Of course, backtests are necessary.
But being good in backtests does not guarantee usability in real operation.
Therefore, we also look at forwards.
How it behaves in actual price movement.
How order execution changes results.
What happens when spreads widen.
Whether it runs stably on a VPS.
Whether MTP: Master reads correctly.
Whether it is easy to handle when received by MTP: Slave.
This is what I want to see.
Backtests are entry points, not conclusions.
What makes an EA compatible with MTP
As of now, an EA that is compatible with MTP is like this.
Clear entry reasons.
Stage-wise design is easy to understand.
Position spacing is not too narrow.
Lot increases are not too abrupt.
Maximum number of steps is defined.
Drawdown is readable.
TP is not too shallow.
Holding time is not too long.
Comments and Magic are organized.
Logs allow post-hoc verification.
Easy to read by MTP: Master.
Easy to manage lots on the MTP: Slave side.
Conversely, an EA that is hard to handle looks like this.
Entrants too frequent.
A averaging interval that narrows too much.
Lot size expands abruptly.
Maximum number of steps is not visible.
Drawdown held too long.
TP too shallow and incompatible with MTP management.
Comments and Magic are unclear.
Cannot tell why it entered from logs.
We will verify these aspects while actually building.
We will move from theoretical ideals to actual operation.
First, formulate a hypothesis
You cannot create a perfect EA at once.
First, formulate a hypothesis.
For example,
What about an EA that trades in the direction of the trend?
What about a breakout-buy/ pullback-sell type?
What about a contrarian strategy using RSI?
Use moving average deviation?
Will you use averaging?
If you do, how many steps?
Is the interval fixed or variable?
Is TP fixed or based on average entry price?
Should a time-filter be included?
What about around important indicators?
There is no answer from the start.
We will try.
And if it fails, we will fix it.
If fixing fails, we discard it.
This is the cycle.
There is a shortcut to EA development.
But there is no magic.
Comments and consultations are welcome
In this series, I will not only show completed EAs.
The intermediate approach to development.
Uncertainty.
Verification results.
Reasons for discarding.
I will document that as well.
Therefore, I would be happy to receive comments or questions from the EA development perspective.
“It would be good to view this condition too.”
“This logic might break in this market.”
“Backtests should also consider maximum drawdown.”
“If receiving with MTP, it is better to confirm entry intervals.”
“Would it be better to have a variable parameter rather than fixed?”
Such opinions are very helpful.
Of course, I cannot adopt everything.
Still, viewing the EA in development from various angles is very meaningful for improving its completeness.
Thinking alone can narrow one’s view.
Sometimes the numbers of backtests alone look convincing.
Conversely, we sometimes discard a usable-looking logic too early due to instinct.
Therefore, including readers’ perspectives, we will determine whether it can become a usable EA.
How this series progresses
This series typically proceeds as follows.
First, decide the development theme.
Next, think about the logic.
Then implement it as an EA.
Backtest it.
Look at the results.
If good, confirm what is good.
If not, confirm why it is bad.
If needed, improve it.
If improvement fails, discard it.
If usable, verify in forward testing.
Additionally, read easily with MTP: Master and check ease of handling when received by MTP: Slave.
The flow is as follows.
Form a logic hypothesis
Implement as an EA
Backtest
Examine maximum drawdown, steps, and lots
Identify weaknesses
Improve
If unusable, discard
If usable, perform forward testing
Check compatibility with MTP integration
We will proceed in this flow.
Points to verify this time
整理 this discussion.
This series does not introduce a finished EA.
We will build an EA that does not yet exist.
Not an MTP-only EA, but an original EA well-suited to MTP.
Assume it can operate as a standalone EA.
Also emphasize readability by MTP: Master.
Also look at ease of management when received by MTP: Slave.
Aim for an EA that is easier to operate than a winning one.
Do not judge solely by backtest results.
Observe maximum drawdown, steps, lot size, and holding time.
Decide unusable logic cannot be used.
Also document discard reasons.
We welcome comments and consultations.
This will be the policy for this series.
In conclusion
In MTP Integration Original EA Development Experimental Notebook 1, I organized the policy for this series.
This notebook is not a promotion for a finished product.
It is a record of building an as-yet-nonexistent EA.
I will document not only successful results but failures as well.
I will also write about disappointing results.
If something is deemed unusable, I will state that clearly.
EA development is about discovering successful logic.
But at the same time, discarding unusable logic is part of it as well.
Operates as a standalone EA.
Easy to handle when combined with MTP.
Drawdown is less volatile.
Drawdown visibility is clear.
Easy to verify.
Easy to operate.
We will develop toward such an EA.
Today's conclusion
Whether it becomes a usable EA is not yet determined. Therefore, I will document the development process.
Next time, I will decide the initial development theme.
What EA is well-suited to MTP?
Which logic should be tested first?
What should be adopted as a criterion, and what should be discarded?
From here, we will begin actual EA development.
If you are interested in MTP introduction, please also take a look here.
MTP: Master【Free】
https://www.gogojungle.co.jp/tools/indicators/79103?via=usersMTP: Slave【Paid】
https://www.gogojungle.co.jp/tools/indicators/79106?via=users
Risk notices
※This article reflects the author’s personal trading philosophy, MTP design philosophy, and EA development process.
※The EAs discussed in this series are in development/testing and do not guarantee profits in real trading.
※Even if backtest results are good, they may not translate to forward or live performance.
※There are cases where ultimately it is judged unusable.
※MTP does not guarantee profits.
※MTP does not completely prevent losses.
※FX/algorithmic trading/copy trading carry significant risks.
※Depending on settings, lot, behavior of the copied EA, and market conditions, large losses can occur.
※Use of the EA, opening accounts, deposits, VPS contracts, and operation should be done at your own risk.
※In initial operation, always confirm operation with a small lot or a demo account.