The HyperMatch whitepaper

HyperMatch is a cloud escort desk for MT5 gold traders. Trading always stays in the customer's own broker account; HyperMatch provides escort engines (EAs) that run in the customer's own terminal, cloud control and alerts, an account check-up, a verifiable on-chain track record, and optional on-chain escort hedging.

This whitepaper is written for customers, partners and technical reviewers: what the product is made of, how the system is built, where its security boundaries are, which open-source technology it uses, and what we cannot promise.

The on-chain side uses several technical architectures and aggregates several on-chain LPs (liquidity providers), choosing a route by rule. For commercial confidentiality this paper does not name the LPs: signed-in customers see fixed aliases ("LP 1, 2, 3"), and when they sign in their wallet, the wallet shows the actual counterparty.

Official support: Telegram @hypermatch123 (opening windows, questions; the EA downloads on the website).

MT5 gold traders keep running into four problems:

1. Grid and scale-in EAs have no outside risk control. In a one-way market a floating loss can grow fast, and the trader is often away from the computer: the account cannot be seen from a phone, let alone the EA controlled.
2. Results are hard to verify. Screenshots can be edited and history can be added afterwards; a public "track record" can rarely prove it was recorded when it happened.
3. The gap between on-chain and broker prices is often overstated. In the samples we have recorded, the difference between on-chain gold quotes and a broker's quote was mostly a few cents and closed quickly, while one round trip costs several dollars per ounce. The samples are limited and do not yet cover US hours or data releases. The gap itself is not a steady source of return.
4. Handing over money or a trading password is risky. Many "managed" or "copy" schemes ask the customer to give their funds or trading password to a third party, which is hard to undo when something goes wrong.

HyperMatch starts from these four points: risk control runs in the customer's own terminal while the cloud watches and alerts; results are sealed and anchored on chain as they happen; the price gap is only a reference for avoiding a poor opening price, never a promise of return; money and trading rights stay with the customer.

HyperMatch is made of the parts below. Each says what it does, who controls it and how it starts out; what is open today is on the system status page.

Escort engines A–D

Four grid escort engines that run in the customer's own MT5 terminal (the escort EA), risk from low to high. The console estimates how well each engine fits the account balance with a formula and shows "fits", "runs, little room" or "not enough" (with lots sized from the balance: how many units it carries, or "short of funds"; see below); this is a formula, not a backtest and not a forecast of returns.

Every engine has limits the customer sets: layers, lots, deals per day, margin use and a trading time window, with the stop-out guard as the last line (the new EA has no 20% floating-loss stop by default; see below). Engines never start by themselves: an engine places orders in the customer's own terminal only after the customer presses "Start auto mode" (or a manual START) on the MT5 panel, reads what it will do and its risks on the card and confirms; that card is the switch, and no EA input has to be edited. A real account asks once more on the panel: "This is a real account: orders use real money". The EA keeps an advanced kill switch (forced off: no orders, no management, no reports).

In the new escort EA the engine settings (entry timeframe, band, spacing and the like) are not in the public EA file: once the EA is bound to a HyperMatch account, the server delivers them encrypted for that device, and they take effect only while the engine is flat (see Security and risk).

Price-protected start (in development, engines A and B only)

The first order on each side is checked against the on-chain order-book mid price: while the broker's quote is clearly worse, it waits, at most 30 seconds. It only avoids a clearly poor price and never waits for a better one. It starts in observe mode, recording only what it would have done; it switches to acting only after the observed sample passes a statistical bar showing it does not harm the opening.

Take profit

When a run's combined result (the engine's MT5 result in this run, plus the on-chain part, minus the estimated closing cost) reaches the target (+5% by default) at two independent checks at least 30 seconds apart, the EA first closes the engine's MT5 positions, and once they are closed the on-chain part is closed reduce-only; then the run stops. Below the target the escort carries on; the stop-out guard (or a floating-loss stop the customer set) still applies, and a run can still end at a loss.

Fast first order

When a run begins and the engine's own entry signal has not come within about 20 seconds, the engine places a first order of its base lot through its own entry path, on the side given by the price against the engine's band midline. With the price-protected start on, that order passes its price check first and is released at the latest 50 seconds into the entry window, so the first order goes within about a minute; a run started while new entries are closed (the weekend, outside the time window) counts from the moment they open. The fast first order only decides when the first order goes; adds, closes and limits follow the same rules as before, and it does not make that order more likely to profit.

Lots from the balance, the stop-out guard and the frequency

The new escort EA sizes the base lot from the account's funds: the customer picks a safety cushion (Bold, Standard by default, or Steady), which sets how much each 0.01 base lot needs for a one-way gold move of about $100, $150 or $200; the base lot is that many 0.01 lots as the balance carries, and the lot cap grows with it. The lot changes only while the engine is flat, never mid-run. The EA reads the balance number only, never the currency, the account type or a symbol suffix (every account where 0.01 lot × $1 of gold ≈ 1 unit is read alike). Below one unit it runs at the minimum lot of 0.01: auto mode still runs every engine of the level (V2.1; in V2.0 engine A only, B, C and D joining once the balance carries one unit of each), the panel saying "minimum lot 0.01"; a manual start says "minimum lot 0.01" on its confirmation card. The one-way move it survives is then smaller than the cushion, so the stop-out guard is reached sooner. The figures come from the server and can be revised; they are formula estimates, not a backtest.

The former 20% floating-loss stop is no longer a default. The last line is the stop-out guard: when the engine's floating loss reaches 70% of the balance (adjustable 50%–90%), or the margin level falls to 150% (higher where the broker's stop-out is higher), the EA closes all of the engine's positions and resumes by itself after a one-hour cooldown (once the margin level is back above the line; RESET on the panel resumes at once). A one-way move larger than the cushion triggers it and costs about 70% of the balance; gaps and slippage can make the loss larger. The customer may also set a per-run stop of their own (off by default; see below).

The frequency (10%–100%, 100% by default = the engine's own pace) affects only new baskets after each run's first order: lower means stricter entries, a longer wait on a side after its basket closes, and fewer new baskets a day. The fast first order is not affected. All three settings can be changed on the website, on the MT5 panel or in the EA inputs: the lot follows at the next flat moment and the frequency at once; a deeper guard applies at once, a shallower one only once the engine is flat (changing it never closes the positions held now). These three are your own choices and move either way on the website or the panel; the other safety caps can only be tightened.

Risk level 1–10 and the per-run stop (V2.0)

From V2.0 the customer chooses only two things: a risk level from 1 to 10 (5 by default) and a frequency from 10% to 100%. The server delivers a table that turns the level, the balance and the market into the engines, the safety cushion and the stop-out guard's depth (V2.1: an engine below one unit at the minimum lot 0.01; V2.0: A at 0.01 below one unit, the other engines once the balance carries one unit of each; the server also picks each rotation run's engine):

A higher level starts with a larger lot on the same balance, never a smaller one. Levels 7–10 add engine C to A and B, and levels 9–10 add D as well: in a calm market the level's most active engine leads the run (D, then C, B, A; V2.1 runs one below its unit at the minimum lot 0.01, V2.0 only those the balance fits one unit of); one-way, wild and busy markets still wait. C always runs one unit (its own lot ladder, not scaled with the balance), and D runs in auto mode at its minimum lot only. C and D are not in the replay study: formula estimates only, with no historical replay behind them, and C and D can lose more than A and B. Picking a level that adds C or D asks for one more confirmation, on the website's one-click start and on the MT5 panel alike. The A and B figures come from an offline replay of 26 months of history and the formula; A+B auto mode on the bold cushion reached the stop-out guard once or twice in the replay. A replay is no forecast; no profit is guaranteed. The settings themselves can be changed: Advanced lets the customer choose the engine, the cushion or the guard; a manual A or B follows auto mode's market rules by default (no new run in one-way, wild or busy markets), which can be turned off.

Per-run stop (optional, off by default): you may set a maximum loss per run of your own (from 3% of the balance, or a fixed amount); it is off by default, and with both set whichever comes first. It closes the engine's positions of the run through the usual close path and stops; auto mode stops too and waits for START. A price gap can lose more than the limit, and too tight a stop cuts baskets that would have recovered: in the historical replay most deep baskets later closed in profit.

Engine rotation and auto mode

Rotation runs one engine per run, one run after another: it picks among the engines the customer ticked by market type (range, one-way, wild, busy hours), and by default waits for calm in a one-way or wild market and in busy hours. Engines change only while flat, and a daily maximum of runs can be set (6 by default).

Auto mode runs in the EA, in the customer's own terminal: it starts only after the customer presses "Start auto mode" on the MT5 panel and confirms the card that says what it does and what the risks are. It rotates run by run over the risk level's engines as far as the balance fits them (A and B at level 5; levels 7–8 add C and levels 9–10 add D as well, D at its minimum lot only), and each run's first order is a fast first order; when a run's combined result reaches the take-profit target (+5% by default) it closes and starts the next run by itself. After the stop-out guard (or the customer's own per-run stop) auto mode pauses and resumes by itself an hour later; after a run that ends below zero it goes on after 15 minutes. The customer can resume at once on the panel. The website's one-click start can save auto mode and send it to the EA, but never starts it for the customer.

Either way, safety caps sent from the website (layers, lots, deals, the per-run stop, the margin floor, the time window) can only tighten, never loosen, the EA's own inputs; the risk level, the safety cushion, the frequency and the stop-out guard depth are your choices, set on the website or the panel. Picking by market type is no promise of more profit; in historical replays the +5% target was rarely reached, and most runs ended flat when the market turned.

Realized results first

The MT5 panel and the web console lead with realized results: the total since install (from the escort engine's first deal, as far as the terminal's history goes), this run, today and this month, and the closes in profit: one side of the engine going flat is one close, a result above zero counts as closed in profit, shown as "Closed in profit N of M". The take-profit target looks at the whole run, so it is shown as progress only. The floating result of open positions is not the headline: it sits on a separate Risk page (an expandable "Risk" on the website) with how much of the safety cushion it uses, how far gold can still move against the position before the stop-out guard, equity and the margin level. Closed results only, commissions and swaps included; the figures come from the customer's own terminal, are past results and do not predict future ones.

Cloud console and alerts

See each account as last reported, from a phone or a computer: realized results, the balance and the engine's state; equity, the floating result, the margin level and the distance to a stop-out open under "Risk". When needed, pause or resume new entries, close the escort positions (with a confirmation), switch engines and adjust safety settings:

• A command from the website lapses if it is not delivered within 120 seconds; the EA carries it out or refuses it.
• The EA has an "allow remote control from the website" switch; with it off, every website command is refused.
• An email sign-in can only pause new entries; resuming, closing, switching engines and changing settings need a passkey or wallet sign-in.

Alerts cover floating loss, margin level, a stopped engine and an EA gone offline; the default rules are 20% floating loss, 200% margin level, engine stopped and 5 minutes offline. Alerts go by email, and by Telegram once configured.

Account check-up

Assesses risk from the account snapshot: grid depth on each side, the largest single lot, floating loss against balance, margin level, how far gold would have to move to reach stop-out, and weekend exposure. The check-up only reads; it changes nothing in the account.

Broker read (read only, nothing to install)

For administrators only at present; customers install the EA and bind it by scanning.

No EA and no open terminal: HyperMatch reads the account, deals and quotes straight from the broker through its own read-only protocol gateway. The gateway only calls read endpoints, whichever password the customer gives; the platform can also switch to accepting investor (read-only) passwords only.

On-chain track record (opening gradually)

Every deal and each day's account summary is fingerprinted as it happens and anchored to an Ethereum L2 in hourly batches (see Architecture). A record is private by default and published only by its owner: the public page shows the results and an "anchored on chain" badge; the detailed proofs are open to the account owner, who can create a share link that expires and can be revoked at any time.

Optional: on-chain escort hedging

When an engine's floating loss reaches the trigger line the customer set, a position on the opposite side is opened by rule in the customer's own on-chain account to slow the loss, and closed step by step once the loss falls back to the release line. The hedge size is capped by the wallet size, and the hedge can lose money too. The feature is hidden under "Advanced (on-chain)" by default and has to be turned on separately.

Chain sim account (a simulation, not real money)

At the start, a customer's results come mainly from the escort engine in their own MT5: the console and the MT5 panel show the MT5 realized result first, and the chain sim account is every customer's default companion view, with nothing to open. A customer can see how the on-chain part would work on their own account without depositing anything on chain first: every bound escort EA connection has a chain sim account by default, with a virtual 500 USDT (300 / 500 / 1000 or a custom amount; it can be reset at any time and earlier records stay). It holds no funds, signs nothing, places no order anywhere and never makes the EA trade.

The simulation uses real data only: the customer's own MT5 quotes (sent by the EA with its heartbeat when needed), the real resting orders and depth of an on-chain order book, live fees and funding, and the order-to-fill time we measure. Two parts:

• Arbitrage pairs follow the arbitrage engine's own rules: a resting order on chain counts as filled only when a trade goes through its price, only for that trade's size; the MT5 side is priced at the customer's bid/ask plus slippage and commission. One pair at a time, sized at the customer's MT5 minimum lot.
• The escort hedge and its recovery leg: when the escort engine on the customer's computer asks for a chain hedge, the same decision rules as the real escort hedge apply (trigger, release, recovery leg, closing together with take-profit, the wallet cap), every order a taker order walking the depth after the measured order-to-fill time; a small simulated balance hedges only part of the request.

Only closed results count as realized: the console and the MT5 panel show today, this month, since the start, the number of trades and how many made a profit; open positions appear only under "Risk". The console also shows the local MT5 escort's realized figures and "Total (real + simulated)", which says plainly that it includes simulated results. The simulation leaves out failed orders, venue pauses, depth vanishing in extreme markets and other traders taking the same fills; real results can be worse, and simulated results do not predict future returns.

"Open real on-chain" is an optional next step: after watching for a while, a customer can choose it on the same card: when deposits are open it leads to the USDT deposit step; until then it says "Coming soon" and offers "Tell me when it opens".

Gold price-gap and funding monitor

A public page shows the composite gold quote, spread and funding ranges HyperMatch aggregates from several on-chain LPs, set against MT5 round-trip costs. The arbitrage engine in observe mode only records and never places an order.

HyperMatch has four layers: the MT5 terminal layer on the customer's side, the cloud control plane, the execution and liquidity layer, and the proof layer. Money and trading rights stay in the customer's accounts at the outer edge; the further in a layer sits, the fewer rights it holds.

MT5 terminal layer

• Escort EA: opens, adds to and closes orders in the customer's own terminal by the engine's rules; off by default.
• HyperMatch EA V2.2 (two public builds, Chinese and English, with the same features; V2.0 and V2.1 keep working): reports heartbeats, deal events and quotes (the relay) and carries the escort engines, which place, add and close orders in the customer's own terminal by the engine rules; off by default, they start only after the customer confirms on the panel. Every 12 hours the panel reads the version list on the website and says when a new version is out; the HyperMatch updater downloads from the same list and checks the SHA-256 before it installs into MT5. The major-data reminder reads MT5's own economic calendar and only reminds: trading is unchanged. The read-only relay build is used internally for tests only.
• Broker-read gateway: nothing to install, read only; reads the account and deals from the broker.

A device is bound by scanning: the customer presses "Bind HyperMatch" on the MT5 panel, which shows a QR code and an 8-character code (valid for 10 minutes); the customer scans it with a phone, or types the code at hypermatch.org/b, signs in, checks the MT5 account, server and code, and confirms. The device token goes straight to that EA, never through the phone. A personal settings file (.set) created in the console still works as the other way. The server keeps only a hash of the device token; it stays valid while the MT5 account runs on a paid window (long-term licence), lapses after 30 days offline without one, and stops working the moment it is revoked in the console or unbound on the EA.

Cloud control plane

• Edge network: TLS, security headers and a Content Security Policy (CSP); public pages are cached at the edge, so heavy traffic does not read the database on every visit.
• Serverless compute (Node.js): sign-in, device pairing, the command queue, alert decisions, and merged, cached reads of public data.
• Managed PostgreSQL: transactional writes; evidence tables are append-only and guarded by database triggers; each background service uses its own least-privilege database role.
• Background jobs: scheduled alert sweeps, the observe-mode arbitrage ledger, proof batching and the copy execution process, each with its own host account and database role.

Execution and liquidity layer

The on-chain side uses several technical architectures (in live routing today: order book and oracle-priced) and aggregates several on-chain LPs, choosing a route by rule. The browser never connects to an LP: whatever the customer has to sign is built by the server in the LP's official format, the customer signs it in their own wallet, and the server relays the signed request once, exactly as signed. The signature covers every field, so the server cannot change any of them.

Features that must keep executing on their own (on-chain escort hedging, for example) use an execution key the customer authorises separately; its rights are limited by that LP's own authorisation scheme, and the customer can revoke it at any time. We never ask for, and never store, the private key or seed phrase of a customer's main wallet.

Execution keeps four invariants:

1. The execution intent is persisted before it is dispatched.
2. Once a dispatch may have happened, it is never blindly resent and never moved to another LP.
3. An unknown outcome is marked "outcome unconfirmed": added risk pauses and the original identifiers are reconciled.
4. Risk-reducing actions such as closing are never blocked by entry filters.

Proof layer

• Fingerprint: each deal and each day's account summary is ABI-encoded and hashed twice with keccak256 into a leaf. The MT5 login and server name appear only as salted hashes.
• Batch: every hour the new leaves form a Merkle tree laid out as OpenZeppelin's published StandardMerkleTree specification describes (sorted leaves, sorted-pair hashing).
• Anchor: each batch writes its root to an Ethereum L2 in one transaction, a zero-value transaction to its own address whose 48 bytes of call data hold only the batch number, the leaf count and the root. All accounts share that one transaction, so it costs very little.
• Sealing and late deals: a UTC day is sealed 15 minutes after it ends; a deal received more than an hour after it happened is marked "late", still anchored but counted in no figure.
• Verification: anyone holding a proof can query the anchor transaction from a public node in their own browser and recompute the leaf and the Merkle proof, without trusting our server.

The anchor proves that a record existed in exactly this form no later than the anchoring block; it does not prove that the EA reported every deal, and it says nothing about future results.

One heartbeat, end to end

The EA sends a heartbeat to the cloud at a regular interval with the account snapshot, the escort state and receipts for the last commands. The cloud checks and stores it, decides whether an alert line was crossed (recording and notifying only on a crossing), and puts any pending commands in the reply; while a command waits for delivery, the cloud asks the EA to speed its heartbeat up to every 3 seconds for up to two minutes. The EA carries each command out or refuses it and reports the result in its next heartbeat.

Sign-in and authorisation

• Three ways to sign in: a passkey (WebAuthn, with user verification required), a wallet signature, or an email code. A wallet sign-in signature only signs you in: it moves no money and approves no trading.
• The session cookie is HttpOnly and SameSite=Strict and lasts 24 hours.
• Authority is graded by risk: an email sign-in can only pause new entries; resuming entries, closing, switching engines and changing settings need a passkey or wallet sign-in.
• Administrators are named by an allowlist in the deployment and must sign in with a wallet or passkey. Content editors can edit public content such as this page and cannot reach any money or trading feature.
• Write requests are checked for their origin and rate-limited per account and per network.

Where cloud control stops

• What the website sends is a request the EA carries out or refuses; safety caps sent from the website (layers, lots, deals, the stop, the margin floor, the time window) can only be stricter than the EA's own inputs, while the safety cushion, the frequency and the stop-out guard depth are the customer's own choices.
• START exists only on the MT5 panel; the website cannot start an engine for the customer.
• The EA can switch off "allow remote control from the website" with one input.

The engines' cloud license

• The new escort EA opens a new position only with three things: an account bound to HyperMatch, the engine settings the server delivers encrypted for that device (AES-256 with message authentication; the keys are derived from the device token, the MT5 account, the server, the terminal id and a fresh random value on every heartbeat), and an entry authorization of about 3 minutes that each heartbeat renews.
• One MT5 account opens new positions from one terminal at a time; the customer can move new entries to another terminal in the console.
• Open positions are always managed: offline for days, with an expired authorization, unbound or revoked, the EA keeps managing and closing its open positions with the settings sealed on that computer; it only opens nothing new.

Sealed credentials

The password broker read needs is encrypted in the customer's browser with the gateway's public key (RSA-OAEP-256) before it is sent. The website stores only ciphertext it cannot open; only the read-only gateway can. Revoking the connection deletes the ciphertext at once, and after 30 days without a broker connection the password is no longer used and is deleted. Where possible, use the investor (read-only) password: with it, even the reading service could not trade.

Read-only broker access

The broker-read gateway calls read endpoints only, listens on the local loopback address only and is isolated by network rules; its log fields are allowlisted and account numbers masked.

Risk controls

• The stop-out guard (a per-run stop optional: from 3% of the balance or a fixed amount, off by default), lots sized from the balance (risk level 1–10), trading time window, hard caps on layers and lots, and a cap on margin use.
• The size of an on-chain hedge is capped by the wallet size.
• Stale data leads to no new decision: when the escort state is out of date, for example, the on-chain part holds still and opens no new risk.

Where the money stays

• HyperMatch holds no broker funds, and running the EA does not need the customer's MT5 password.
• On-chain features such as escort hedging and copying run in the customer's own on-chain account; if an advanced feature ever involves funds held by the platform, its page says so separately and asks for a separate confirmation.
• Each LP's own official interface always remains a way out that does not depend on HyperMatch.

Confidentiality and transparency

Public pages, public APIs and the code a browser downloads name no LP; signed-in customers see fixed aliases. The server prepares what a customer signs, and the page checks the values it knows itself (its own trading key, the customer's address, the amount and fee it shows) before it asks for a signature. When a customer signs in their wallet, the wallet shows the actual counterparty; we do not hide that, and could not. A signed request cannot be changed afterwards: at most the server could delay or drop it, and the console then shows it as "outcome unconfirmed". Quick trading is the exception to the wallet prompt: once it is on, orders are signed without a wallet prompt by a short-lived trading key in the page, over the order the server prepared. The page lets that key sign orders only; it cannot withdraw, and it expires with the session (at most 8 hours).

HyperMatch is built on mature open-source software. The table lists the main open-source components the website and its clients actually use; versions follow the repository's lock files, and only the major version is given here.

• Merkle tree: our own implementation, laid out as OpenZeppelin's published StandardMerkleTree (MIT) specification describes, so anyone can verify it independently with the standard Merkle-proof fold.
• MetaTrader 5 and MQL5 are a third-party commercial platform, not open source; the escort engines run on it.
• The table covers the main open-source components the website and its clients use; each LP's integration components are used on the server only, under their own licences.

Engineering practices

A few practices we keep, each of which can be checked:

• Persist before dispatch: anything executed outside is written to the database before it is sent.
• Idempotent commands: every command has a unique ID and the EA remembers the IDs it handled recently, so a repeated delivery never runs twice.
• Fencing tokens: used in compare-and-swap write conditions and at the signing and sending boundary, so a stale executor cannot write.
• Append-only evidence: database triggers forbid updating or deleting evidence tables.
• Least privilege: one database role per background service, granted only the tables and operations it needs.
• Exact numbers: amounts and quantities are decimal strings or integer atoms, never floating point.
• Merged, cached public reads: many public requests at the same moment become one read, cached briefly at the edge.

What we collect

• Sign-in identifiers: a wallet address, an email address or a passkey's public key.
• MT5 account snapshots and deal events, reported by the EA in the customer's terminal or read through broker read.
• The customer's settings: alert rules, engine and safety settings, and whether the track record is public.

What we do not collect

• The private key or seed phrase of a main wallet: never asked for and never stored.
• Plain-text passwords: apart from the read-only credential broker read needs, sealed in the browser, no password is stored.

What is public

Only the track records customers choose to publish: the alias they pick, the results and the "anchored on chain" badge. The MT5 login appears on chain and on public pages only as a salted hash; the broker server name is hidden unless the customer chooses to show it.

Who can see what

• Your data is read only through your own session; other customers cannot see it.
• On-chain proofs (transaction hashes, Merkle proofs, anchor details) are open to the account owner only; the owner can create a share link that expires and can be revoked at any time. The share token sits after the "#" in the address, so it never reaches a server log.

Keeping and deleting

• Revoking a connection ends its device token at once and deletes the encrypted broker-read password; a password with no broker connection for 30 days is retired and deleted as well.
• Chain sim account: the quotes the EA sends for the simulation are deleted after 30 minutes; simulated trades are kept 180 days; each connection's simulated totals are kept with the connection and deleted with the account data on request.
• Deal and proof records are kept as evidence. A Merkle root already anchored on chain cannot be withdrawn, but it holds only hashes and nothing that identifies an account.
• To have account data deleted, contact us through the official community or support channels.

The roadmap carries no dates: until an item passes acceptance and its switch is on, the product and the system status page mark it "in development" or "opening gradually".

In development

• The on-chain record, switched on: once the proof service is live and the first batches are anchored, record pages start showing "anchored on chain".
• Price-protected start moves to acting: after the observed sample passes its statistical bar.

Next

• More LPs and liquidity architectures, for more execution routes to choose from.
• More instruments.
• Partner-quoted books (the architecture interface is ready; not yet used for live routing).

Ongoing

• Security hardening.
• Chinese, English and Russian kept in step.

HyperMatch is built and run by a cross-functional team, organised by function:

• This paper is not investment advice and promises no return. Past results, replays and simulations do not predict future results.
• Grid and scale-in strategies can lose heavily in a one-way market. The stop-out guard and a per-run stop limit a loss but cannot remove it (a price gap can lose more than the limit); a one-way move larger than the cushion triggers the guard and costs about 70% of the balance; gaps and slippage can go past the line.
• On-chain risks: smart-contract bugs, oracle or market failures, liquidation, funding, network congestion, wallet security, and the LPs' own operational risks.
• Broker risks: changes in quotes, swaps and trading conditions, and disconnections.
• Technical risks: while an EA is offline, the network is down or a service is unavailable, commands may not arrive and data may be out of date.
• Law and compliance: customers must check for themselves whether their jurisdiction allows the products and services involved.
• HyperMatch is not a broker and gives no investment advice. Leveraged gold trading is high risk and you can lose all of your margin.