What is BEMXC? The Zero-Fake Signal Protocol & Verification Engine

Definitive protocol overview

BEMXC is a non-custodial, zero-fake trading signal verification protocol for the forex market. BEMXC is analytical software. BEMXC is not a broker, not a liquidity venue, not a fund, and not an advisory firm. The protocol’s unit of work is a signal: a structured FX call that states currency pair, side (BUY or SELL), entry, take-profit (TP), stop-loss (SL), and a publish timestamp.

Zero-fake is a verification claim, not a performance claim. BEMXC guarantees that a displayed win rate, R:R, and Trust Score are computed from the same committed objects that the provider published. BEMXC does not guarantee that those objects will be profitable. Skill is inferred from settlement. Popularity, screenshots, and paid badges have zero protocol weight.

What the protocol is, and is not

The Transparency Engine

Retail signal channels fail because the record is mutable. A provider can screenshot a winner, delete a loser, move a stop after the fact, or fabricate a MetaTrader window with inspect-element. BEMXC’s Transparency Engine exists to make those attacks non-scoring. The engine treats the published call as a frozen scientific observation: once committed, the observation can be settled, but it cannot be rewritten.

Canonical payload

At publish time the Terminal constructs a canonical JSON object. Field order is protocol-defined. Prices are normalized to the pair’s pip precision. Timestamps are UTC. The hash input is that canonical string, not the rendered UI. Inspect-element on a follower’s browser cannot change the digest that already exists on the log.

payload = {
  pair, side, entry, tp, sl, broker, tf, expiry
}
digest = SHA-256( canonical_json(payload) || nonce )
log.append({ digest, utc, provider_id, payload })  // write-once

Attacks the engine is designed to stop

• Hindsight bias. A call published after the print is not a call. The log’s UTC stamp is compared to the first market print that could have filled the stated entry. If the stamp is later than a valid fill window, the object is rejected or voided. You cannot “call” a move that has already occurred.
• Post-deletion. The log is append-only. A provider may un-follow their own marketing copy; they cannot un-write a digest. Hidden losers remain in the sample used for win rate and Elo. Deletion attempts are themselves a scored integrity event.
• Inspect-element and fake screenshots. Followers never settle against a PNG or a DOM node. Settlement reads entry, TP, and SL from the hashed payload. A doctored screenshot that disagrees with the log is not evidence. It is noise.
• Stop-widening after adversity. Moving SL after commit would require a new digest. The original object still settles at the original SL. A “new” stop is a new signal, with a new clock, not a rewrite of history.

Read-only means operators, moderators, and the publishing desk have no UPDATE or DELETE on committed rows. Corrections, if any, are compensating entries: a void with a public reason code, never a silent mutation. That is the mechanical meaning of zero-fake.

Signal lifecycle

Every BEMXC signal travels the same path. Publication does not imply execution. Execution does not rewrite verification. The stages are strictly ordered.

Stage 1 — Open Playground

Anyone with a Terminal identity may publish. There is no follower minimum and no paid badge gate. The Playground is where a ROOKIE desk and a VIP desk submit identical object types. Credibility is not an admission ticket; it is an output of later stages. A Playground call that fails structural checks (missing SL, missing TP, non-canonical pair) never reaches the log.

Stage 2 — Verification

On a valid submit, the Transparency Engine commits the digest. The call remains open until one of three terminal states: TP is printed (win), SL is printed (loss), or the expiry / void rule fires. Settlement uses the broker or liquidity tape referenced on the payload, not the provider’s word. Win rate on BEMXC is settled wins divided by settled decisions. Voids are excluded from that ratio and separately monitored for abuse. Elo updates only after terminal state. Details of scoring live in the Credibility Scoring article.

Stage 3 — Broker webhook execution (optional)

If a follower has configured a non-custodial webhook, the Terminal may emit a signed payload to an endpoint the follower owns — typically a worker that calls the follower’s FX broker API. BEMXC does not place the order as principal. BEMXC does not size the lot. BEMXC does not hold margin. Fill, reject, slippage, and downtime belong to the broker of record. A signal can fully verify on the ledger while the follower’s account never enters the market. That divergence is expected. Verification answers “was the call honest?” Execution answers “did your broker fill you?” They are different questions.

1. Open Playground: structured publish.
2. Transparency Engine: hash, stamp, freeze.
3. Market path: TP, SL, or void.
4. Elo and tier update on the provider identity.
5. Optional webhook: follower’s keys, follower’s broker, follower’s risk.

Platform safeguards and non-custodial disclaimer

BEMXC never holds user funds. BEMXC never requests withdrawal-capable broker credentials. BEMXC never operates a pooled account, never nets positions across users, and never is the counterparty to a fill. If a third party solicits deposits “to BEMXC,” that third party is not describing this protocol.

BEMXC never guarantees returns. A verified VIP desk can lose the next ten calls. Elo is a consistency statistic over settled, adequately paid-off decisions. It is not a forecast. Automated routing of a verified signal can still lose the full stop, plus spread, commission, and slippage. The legal and operational expansion of this clause is the Automated Webhooks & Non-Custodial Execution Disclaimer.

BEMXC’s zero-fake guarantee is a verification guarantee. It is not a custody relationship and it is not a performance guarantee.

Software identity

FAQ