ECAI DAMAGE Market Maker: Know the Strategy Before You Risk the Capital
A trader-first introduction to the ECAI DAMAGE paper market maker: understandable quoting rules, inventory and risk controls, historical market data, honest performance reporting, and proposed future directions.
You do not need to write a trading bot to ask the right questions about one.
What is it buying? What is it selling? How much of your balance could end up in one asset? What happens when the market moves sharply or the price feed goes quiet? And when the dashboard shows a profit, did the strategy earn it, or did the coins it was already holding simply go up?
The ECAI DAMAGE Market Maker is a way to investigate those questions on a node you control. It combines market observation, rule-based simulated quotes, a paper-trading ledger, and a locally stored price history inside DamageBDD.1, 2
The version described here is paper-only. It does not place exchange orders or trade real funds. It follows DAMAGEUSDT on Coinstore and uses BTCUSDT for comparison. Enabling it does not earn exchange fees, provide live liquidity, or turn the node into a passive-income product.1, 3
The invitation is not “trust the AI”. It is: understand the behaviour before considering the exposure.
What you get today
Think of the current system as a market-making practice desk, not an automatic money manager.
It reads public prices and the DAMAGE order book, calculates where a rule-based strategy would quote, and records the paper activity it processes. The dashboard lets an authorised node administrator inspect the results and change the reviewed settings. The public market-data feed does not require exchange trading keys.4, 5
The word node means the computer or server running these services. Your browser is the control panel; the records and settings live on that server. Closing the browser is not the same as switching off the engine.5
That gives an interested trader somewhere to ask practical questions. Would this quoting rule make you a more aggressive buyer when your DAMAGE balance is already high? Does it back away when recent price movements get larger? Does it stop treating old prices as current?
What it does not provide today is equally important. There is no live order placement, automatic BTC hedge, or complete point-and-click trading simulator. Starting a funded paper experiment and entering simulated fills still require operator support. Historical charts do not automatically run a trading strategy over the past.3, 6, 5, 2
How it decides where to quote
The strategy responds to three things: the market it has just observed, its simulated balances, and the settings chosen for the experiment. Given the same inputs, the quote calculation follows the same rules. It does not ask a language model whether DAMAGE will rise tomorrow.7
Inventory changes the balance between buying and selling
Imagine a paper experiment with a target of 50% DAMAGE and 50% USDT by value. This is an illustration of the mechanism, not an allocation recommendation.
When DAMAGE becomes a larger share than the target, the strategy shifts its quotes to be a less eager buyer and a more competitive seller. When DAMAGE falls below the target share, it shifts the other way. The aim is to influence the balance of future trades rather than keep buying in the same way regardless of what is already held.7
That adjustment cannot force a trade to happen. A more competitive sell price is still only a proposed price, not a completed sale.
Spreads respond to fees and recent price movement
The settings define the distance between the reference price and the proposed buys and sells. The calculation takes account of configured fee assumptions and widens that distance as its recent price-movement measure increases. Additional quotes form a ladder at progressively wider prices.7
The default base half-spread is 30 basis points: 0.30% on each side before the other adjustments. That is a quoting input, not a promised return. The calculation also respects configured price increments, minimum trade sizes, available paper funds, and limits on individual orders and each side of the ladder.7
The default live polling interval is ten seconds. This is periodic market observation, not a claim to compete in a sub-millisecond execution race. Fee assumptions and other defaults are software settings, not a statement of your exchange's actual fees or suitable risk limits.8
The controls that matter to a trader
Once the node is installed, the relevant controls are under Settings → ECAI → Marketplace & rewards. The engine can be enabled or disabled there, and reviewed settings can be changed without editing code. The settings affect the node, not just the person currently viewing the page.5
| Control | The trading question it addresses |
|---|---|
| Spread and quote spacing | How close to the reference price should the strategy quote? |
| Inventory target and skew | How should quotes change as the DAMAGE/USDT balance changes? |
| Order and per-side sizes | How much simulated value can be offered in the quote ladder? |
| Price-jump and drawdown rules | When should paper quoting pause for review? |
| Maximum feed age | When is a market observation too old to use? |
| Historical-data settings | How much price history should be requested and how often? |
There is one important naming caveat. The setting called maximum inventory ratio currently influences how strongly quotes are adjusted. It is not a hard ceiling that prevents every simulated fill from leaving the account above that inventory share. Hard inventory limits are a proposed future improvement, discussed below.7
The engine can pause on excessive observed price jumps or drawdown. Its worst recorded drawdown remains relevant to the resume check; a price recovery does not simply erase that record. These are paper-engine controls, not guaranteed stop-loss protection for a live account.9
Feed failures invalidate quotes. Changing strategy settings clears existing quotes, and a fresh market observation is required before replacement quotes can be used. Restarting preserves the recorded paper history without reviving old quotes as though nothing happened.1
Two charts, two different kinds of evidence
Market history tells you what prices did
The historical cache stores completed price candles for DAMAGEUSDT and BTCUSDT. It makes the node useful as an observer before a paper experiment has built up much of its own activity.2
By default, the history feature requests 720 hourly candles and 720 daily candles for each pair, with refreshes every five minutes. Those are request sizes, not a guarantee of complete coverage. The provider may return less history, and the implemented requests cannot retrieve arbitrary dates outside the available recent windows.2
DAMAGE and BTC observations are aligned by time. Missing intervals remain visible rather than being filled in to make a smoother picture. The archive is kept on the node and can remain readable when the live feed is unavailable or the paper engine is off.2
That last point matters: a populated historical chart does not prove that the live order book is fresh. The live feed has its own age checks, and reading a cached price does not make its original timestamp newer.2
Paper P&L tells you what happened to the simulated account
The paper ledger reports account value in USDT, changes from its opening value, simulated fees, turnover, fill count, and maximum drawdown. It also provides a BTC buy-and-hold comparison.3
Consider a simple example. A paper account starts with 500 USDT in cash and DAMAGE worth another 500 USDT. DAMAGE rises 10%, with no trades recorded. The account is now worth 1,050 USDT. The 50 USDT gain came entirely from holding DAMAGE, not from buying and selling around a spread.
That is why a green P&L number is not enough to establish a market-making edge. Ask what was held, what actually filled in the simulation, and what assumptions were used. The BTC comparison offers context, but the engine does not trade BTC to protect the DAMAGE position or separately calculate how much profit came from spread capture.3
Nor does the current engine assume that a candle touching a quote means your order would have filled. Paper fills must be supplied explicitly and are checked against active quotes, remaining quantities, fresh data, and available simulated balances. There is no realistic model of your position in an exchange's order queue in this implementation.6
A year of price candles is not a year of trading results.
What ECAI adds — without asking you to read the code
In this implementation, the useful ECAI distinction is an explicit calculation and a recorded history, rather than a black-box trading opinion.
The engine records events such as setting changes, accepted price observations, simulated fills, and pauses. It links those records using cryptographic checks, including elliptic-curve fingerprints. Think of this as a way to check the consistency of the retained local record, not as a signal predicting the next market move.10
The limits are straightforward. A consistent record does not prove that an exchange price was correct, that a simulated trade occurred in the real market, or that a strategy is profitable. Someone able to replace the whole local record and its checkpoints could also replace the story it tells; independently retaining a checkpoint matters when checking for that kind of replacement.10
For a trader, the point is accountability. The rules and recorded behaviour can be examined. They should still have to earn your confidence.
Running a node without becoming a developer
You can be the person deciding what a strategy should do without being the person installing the server. Those are different responsibilities.
Have the technical foundation prepared
The current feature needs a working DamageBDD deployment containing the market-maker, Settings, and price-history changes. Someone must install it, verify the live connection, protect administrator access, and arrange persistent storage and backups. At this stage, the browser dashboard is the trader-facing control panel, not a replacement for technical deployment and maintenance.5, 2
Ask the person preparing the node to demonstrate that prices arrive, history survives a restart, and the dashboard shows the actual engine state. The supplied build notes do not establish a completed end-to-end validation of the deployed service, so this check belongs on the node you will actually use.11
Start by observing
Once it is prepared, sign in as a node administrator, open ECAI → Marketplace & rewards, enable ECAI paper market maker, and leave automatic historical population enabled. Open the market-maker dashboard at /ecai/market-maker.5, 2
Give history requests time to complete. Look at the latest observation, reported feed age, missing periods, and any errors. An empty chart can mean that a request has not completed or the provider has not supplied the data; it is not a trading signal.
No exchange deposit is part of this workflow. Initial simulated balances default to zero, so a working feed with no funded quotes is not necessarily a fault.5
Define the paper experiment before evaluating it
Agree with the operator on the simulated starting balances, the settings being tested, and how any paper fills will be entered. Starting balances are currently managed outside the ordinary dashboard controls, and changing a setting is not a deposit or a reset of the existing ledger.5, 1
Then focus on behaviour. Change one setting at a time. Compare how quotes respond to inventory and price movement. Check why quoting stops. Keep the assumptions behind simulated fills explicit, rather than reading them into a chart after the event.
You do not need to inspect an Erlang function to ask whether the strategy is doing what you expected.
Future directions: from a practice desk to a fuller trading toolkit
The current foundation is market observation, rule-based paper quoting, local records, and historical context. The directions below are proposals for future development, not features already available or a committed release schedule. They extend the trader workflow described here; they are not claims about unimplemented capabilities.
A genuinely trader-friendly setup and paper account
A natural next step would be a guided setup that explains each setting in trading language, checks feed health, and helps an operator start a clearly labelled paper experiment.
A dedicated paper-account screen could let a trader choose fictional starting balances, enter simulated fills, and begin a new experiment without overwriting an older record. Example configurations could illustrate different behaviours without being advertised as “profitable presets”.
The benefit would be less dependence on a technical operator for routine experimentation. It would not remove the need to maintain the underlying node.
Better answers to “did the strategy add value?”
Future performance reports could separate gains from simply holding DAMAGE from the contribution of recorded trades and fees. Comparisons against holding the same starting DAMAGE/USDT balance, and against BTC, could make results easier to interpret over the same period.
More realistic replay would be another step. It would need explicit assumptions about missed fills, partially filled orders, the queue ahead of you, and price movements immediately after a fill. Candles alone cannot establish those outcomes; richer market records and a stated simulation model would be necessary.
The goal would be a report that explains an experiment, including its weaknesses, rather than merely displaying its best percentage.
Harder risk limits and clearer intervention
The present inventory adjustment could be complemented by hard checks on how much DAMAGE a new simulated fill would leave the account holding. Limits on combined open-order exposure could make the distinction between a quoting preference and an enforced boundary clearer.
A future dashboard could also explain pauses in plain language and send alerts when data becomes stale, a limit is reached, or the node needs attention. Such features should make intervention easier without suggesting that any software threshold can guarantee an exit price.
For a trader, the central question is not how many controls exist. It is which limits are actually enforced, and what happens when they are reached.
Broader market context and more useful comparisons
Additional data sources and trading pairs could help a trader distinguish a move on one venue from a move visible elsewhere. Clear source labels, matching timestamps, and visible disagreements would be more useful than silently blending every price into one apparently authoritative number.
BTC-denominated views or tools for comparing hypothetical hedges could also be explored. Those would be separate capabilities: the current BTC reference is not an automatic hedge, and adding more charts would not itself create cross-exchange execution.
Expansion should make differences easier to inspect, not disguise them behind a larger dashboard.
Live execution — a separate decision, not another toggle
An eventual live-trading extension would need to earn its place after the paper workflow is tested. It would require an exchange connection capable of placing, changing, and cancelling orders, with a reliable account of partial fills, rejected orders, and what happened during a disconnection.
It would also need appropriate controls over trading credentials, exchange-specific price and quantity rules, enforced exposure limits, and a clear distinction between simulated and real balances. Restarting safely would mean reconciling the node's records with the exchange's actual orders and holdings, not merely reopening a dashboard.
There is no live-execution capability in the implementation described here. Any move in that direction should be a separately reviewed product decision, with evidence about its behaviour, not a suggestion that the current paper engine is ready for capital.
The reason to participate now
A trader can contribute something important before any live adapter exists: a demanding definition of what good behaviour looks like.
Which inventory limits would you expect to be absolute? What would convince you that a return came from trading rather than market direction? Which warning would make you stop the experiment? What would you need to see after a restart before trusting the display again?
Those are trading questions, not programming questions.
The reason to run an ECAI DAMAGE node at this stage is to build an understandable experiment and a market record you control. It is not a promised yield. The platform's value to a trader should be judged by the quality of its observations, the clarity of its rules, and the honesty of its results.
Observe first. Understand the exposure. Make the strategy explain itself.
About this article and its sources
This article describes the supplied market-maker implementation together with the node-settings and price-cache extensions. It is not a production audit, an offer of live execution, or an investment recommendation. Numerical examples are illustrative, not market observations. The future directions are editorial proposals, not a confirmed product roadmap.
Footnotes:
apps/damage/src/ecai_mm.erl, together with ecai-market-maker-node-settings.patch and ecai-price-feed-cache-history.patch: paper-only execution, saved state, configuration changes, feed checks, and recorded events.
ecai-price-feed-cache-guide.md and ecai-price-feed-cache-history.patch: requested history windows, closed candles, timestamp alignment, local persistence, restart behaviour, live-data freshness, and separation of market history from paper performance.
apps/damage/src/ecai_mm_ledger.erl: marked account value, paper P&L, fees, turnover, fill count, drawdown, and BTC comparison. There is no BTC execution leg or separate spread-profit attribution in these modules.
apps/damage/src/ecai_mm_feed.erl and its TLS/cache extensions: public Coinstore depth and ticker requests. This article does not independently verify current exchange availability.
apps/damage/docs/ecai-market-maker-settings.md and the supplied settings/controller extension: node-admin access, server-side configuration, worker start/stop, dashboard route, private starting paper balances, and startup requirements.
Paper-fill handling in ecai_mm.erl and ecai_mm_ledger.erl: explicitly supplied simulated fills, quote and balance checks, and no exchange queue-position model.
apps/damage/src/ecai_mm_curve.erl and the price-movement calculation in ecai_mm.erl: inventory-sensitive quote adjustment, spread calculation, size constraints, and deterministic quoting. The maximum inventory-ratio input is not a hard post-fill inventory ceiling.
ecai_mm_curve.erl and ecai_mm_config.erl: source defaults and validation. These values are not a verified venue fee schedule or recommended trading parameters.
ecai_mm.erl and ecai_mm_ledger.erl: price-jump checks, retained maximum drawdown, pause state, and resume checks.
ecai_mm_curve.erl and the event-history verification in ecai_mm.erl: local hash-linked records and elliptic-curve fingerprints. These do not establish exchange-data authenticity, real execution, or automatic public anchoring.
“Verification and tests” in ecai-price-feed-cache-guide.md: reported browser and patch checks do not establish completed Erlang, authenticated backend, or live-exchange validation in that build environment. The deployed node still needs its own verification.