Skip to content
Guides · Onchain execution

MT5 to Web3 execution, step by step

An MT5 deal is expressed in lots, at a broker whose contract sizes it defines itself. An onchain perpetual is expressed in units of a contract someone else deployed, with its own margin, funding and trading hours. Turning one into the other is five separate decisions, and each of them can make the copy impossible.

1. Observation is not control

The first thing a copy system needs is a signal, and the safest signal is one that cannot act. The HyperMatch Bridge is an MT5 expert advisor that reads new deals on the account it runs on and posts them to a web endpoint. It carries no order-submission code at all: the published source contains deal-history reads and no OrderSend, CTrade or position-open call. That is the relay bridge; the HyperMatch EA with escort engines is a different program that can place orders in your own terminal, and only after you switch an engine on and press START.

It starts paused and collects nothing until a relay session starts. Every session runs from the moment it starts, so nothing before that moment is ever replayed, and a period when the relay is paused leaves no backfill. By default the EA starts a session by itself when you start following on the website, and the START RELAY button on the panel still starts one by hand; the website never undoes a pause you make on the panel. Transport is at-least-once, which means a duplicate delivery is possible and the receiving side has to be the thing that deduplicates.

  • The device token that pairs a terminal is stored hashed and can be revoked on its own; it stays valid while the MT5 account runs on a paid window, and without a paid window it lapses after 30 days offline.
  • Pairing proves that someone controls a terminal logged into that account. It is not an independent broker attestation of account ownership.
  • Revoking the token stops ingestion. It does not close a position and it is a different control from a venue permission.
A source event being stored is not an order being submitted, and neither is an order being filled. Those are three different states and this site keeps them separate everywhere.

2. One lot is not one anything

A lot is a broker-defined multiplier. The same symbol at two brokers can mean two different quantities, and the destination market has its own contract size and its own minimum step. Converting requires the broker specification as data, not an inference from a symbol name.

HyperMatch performs the conversion as a single exact rational calculation and floors once to the destination step. It never rounds source exposure up: an order that cannot be expressed exactly comes out smaller, never larger, than the source.

  • The reference contract sizes used in our documentation (100 oz per lot for gold, one coin per lot for BTC or ETH) are placeholders to be replaced with your own broker specification.
  • Two sizing policies exist and they disagree: preserving the USD notional, or preserving the underlying units. Any tool that does not tell you which one it used is hiding the difference.
  • Arithmetic is done in fixed-point integers, not binary floating point, so a quantity cannot drift by a rounding artefact.

3. Leverage is a ceiling, not a multiplier

An MT5 account configured at 1:500 or 1:1000 has a high margin ceiling. It does not mean the account is carrying that much exposure, and it does not mean any destination venue will offer the same ceiling on the same instrument.

The number that matters is the exposure you actually hold against the equity you actually have. As an arithmetic illustration: an account configured at 1:1000 holding 10,000 USD of equity against a gold position of 4,375.50 USD notional is running roughly 0.438 times its equity in exposure, far below its 1:1000 setting. The configured ceiling had no effect on that position at all.

  • Changing the leverage setting at a venue does not change profit or loss on the same notional. It changes how much collateral is locked and how close liquidation sits.
  • Collateral is not shared between venues. Each eligible destination needs its own available margin.
  • A stop does not guarantee a loss budget. Gaps, funding, liquidation and actual execution can all differ from the level you set.

4. The destination market decides what is possible

A market with a familiar name is not automatically an equivalent instrument. A gold symbol on a perpetuals venue is a contract with its own oracle, its own trading hours, its own collateral asset and its own operator rules. Equivalence has to be checked property by property, and HyperMatch treats the absence of that check as a reason to reject a route rather than to try one.

Minimum notional, size decimals, funding rates, session restrictions and available depth all decide whether a given size can be placed at all, and what it costs to leave again. Spread is one component of that cost, and rarely the largest.

  • Leverage maxima differ widely between LPs and change with the trading session. They are parameters, not guarantees: session and news restrictions can lower them at any time, and the figure that matters is the one in force when an order is placed.
  • Those figures are that venue’s, they were true on the date shown, and they can change without notice. Runtime metadata from the venue beats any table copied into a web page, including this one.
  • A venue appearing in our directory is a description of an integration stage. It is not an approved route and not a promise of execution.

5. What a receipt actually says

Accepting an event means the engine stored it durably. It does not mean the event was routed, filled, settled, or that anything is withdrawable. HTTP success is the weakest of all the signals in this chain.

Route decisions in the current workspace are paper decisions. They are marked in the response itself: no persistence, a scenario scope rather than a ledger, and synthetic market data for the simulated leg. Public order book data read from a venue is real and is labelled non-executable; a paper receipt derived from it is a simulation and does not submit an order.

Paper receipts should be read as scenarios derived from observed events. They are not live execution and they are not a reconstruction of historical fills.

6. What to check in any copy system

These questions are not specific to HyperMatch. They are the ones that separate a system that can tell you what happened from one that cannot.

  • Does the source connection have any ability to place orders? If yes, the blast radius of a bug includes your source account.
  • What happens to trades opened while the relay was off? Silent backfill is how an account inherits positions nobody chose.
  • Which sizing policy is applied, and is the destination quantity ever rounded up?
  • What does the system do when an outcome is unknown? Retrying a possibly-executed order is how one signal becomes two positions.
  • Can you revoke the source connection and the trading permission separately, and does either close a position?
  • Are source performance, simulation and destination execution presented as three datasets, or blended into one curve?

Where HyperMatch stands today

The stage words below are the ones used in the codebase and the delivery notes, unchanged.

MT5 bridge, observation modeAvailable to install
Compiled EA delivering events from a terminal end to endNot yet independently verified
Public market data (BTC, ETH, evaluation gold market)Connected, non-executable
Paper route decisionsAvailable, simulated
Funded testnet order verificationNot yet verified
Authenticated live execution workerNot enabled
Live signer and venue ordersNot enabled
Venue parameters quoted on this page were observed on 2026-09-19 and are other operators' settings, not ours. Check them at the source before relying on them.