[OPEN] Mobit.Exchange Bug Bounty Campaign | Get Paid for Reporting Bugs

[ContentWriter]

Title: Invalid JSON Example in Failed API Response Due to Trailing Comma

Still on the API documentation, I also found out that the `Response (failed)` code example contains a trailing comma before the closing brace, making it invalid according to the JSON specification.

Here's the documentation example:

Code:

{
  "result": 
    {
      "status": "failed",
      "error": "tx-size | timed-out",
      "error_msg": "Your order...",
    },
  "error": null
}

The comma after `"

Code:

Your order.../code]"` should be removed.

Here's the corrected version of the code:

[code]{
  "result": {
    "status": "failed",
    "error": "tx-size | timed-out",
    "error_msg": "Your order..."
  },
  "error": null
}

[/code]

[ContentWriter]

Title: Privacy Policy Contradiction Regarding Usage Data Collection and Storage

While reviewing the Privacy Policy on MoBit.Exchange I noticed a contradiction in the “Information We Collect” section capable of creating confusion about what data is actually collected and retained.

The policy currently states:

“Usage Data: Non-personal data such as browser type, IP address, and activity on our Website is not collected or stored unless explicitly stated otherwise by Us.”

This wording stood out because it simultaneously claims usage data is not collected while also introducing an exception that implies it may be collected. The phrase

“unless explicitly stated otherwise by Us”

weakens the original claim and creates uncertainty about the actual logging practices.

Also, I wonder why IP addresses are classified as “non-personal data.” This is not consistent  with common privacy regulations such as GDPR, where IP addresses are generally considered personal data. Of course we know IP is personal data.

Considering this, I would be at a loss regarding actual data handling practices. This may lead to reduced trust in the privacy guarantees and potential legal/compliance uncertainty depending on jurisdiction


Suggestions:
Mobit Exchange should clarify the policy with a direct and consistent statement. For example:

“We do not collect browser type, IP addresses, or activity logs except where required for security, fraud prevention, or abuse mitigation. Any changes to this practice will be reflected in an updated Privacy Policy.”

IP addresses should be reclassified as personal data.

[ContentWriter]

Title: Privacy Policy Inconsistency Between “No Usage Data Collection” and Security/Fraud Prevention Statements

I noticed inconsistency between the “Information We Collect” section and the “How We Use Your Information” section. The policy states that usage data such as browser activity and IP addresses is not collected or stored. However, another section, it says collected information is used. That means information is collected contrary to what Mobit claims.

Theysay collected info is used:

To improve the User experience
To ensure the security of our Website and Services
To prevent fraudulent activities

Anyone with a technical background in these knows that these goals typically require some level of logging or telemetry such as IP-based abuse detection, request monitoring, fraud analysis and error/debug logging. So we can conclude that the Mobit policy ststement does align with basic tracking mechanisms.

Recommendations:

Mobit should clarify exactly what operational/security data is collected and why. Something like this makes more sense:

We may temporarily process limited technical metadata such as IP addresses or request patterns solely for security, anti-abuse, and operational stability purposes. This data is retained only as long as necessary.

This would align the privacy claims with the platform’s stated security objectives and make the policy more transparent.

[ContentWriter]

Title: Uncertainty Over Data Retention Language in Privacy Policy

Still on Mobit's Privacy Policy, I noticed unclear wording regarding transaction data retention. The policy states thst transaction information may be retained for up to 15 days. However, it does not explain whether this is a fixed retention period, a maximum retention period, or whether retention varies depending on circumstances. This made it unclear how long transaction-related metadata actually remains accessible or stored.

Mobit should make their data retention logic more precisely like we see in some non-KYC exchanges. A ststement like this provides a clearer explanation and would improve transparency while reducing user uncertainty regarding data storage.

Transaction-related records are retained for a maximum of 15 days for support, refund handling, and dispute resolution purposes, after which they are permanently deleted.

[ContentWriter]

Title: Missing User Feedback for Invalid Destination Address During Exchange Creation

While testing the exchange flow, I pasted a Monero address instead of an Ethereum address. After submitting the form, no order was created, but the platform did not display any validation error or warning explaining that the destination address format was invalid for the selected currency.

From a user perspective, the behavior was confusing because the request appeared to silently fail. There was no visible feedback indicating that the address format was incorrect. Usually, exchanges notify users if the address did not match the selected cryptocurrency or at least show them why an order was rejected.

This could lead users to repeatedly retry submissions, believe the platform is malfunctioning.

Suggestions:

Client-side and/or server-side validation messages should be implemented when the destination address does not match the selected cryptocurrency. Something like this would suffice:

The provided address is not a valid Ethereum address.

[ContentWriter]

Title: Unhandled 400 Error Page When Changing Currency Mid-Flow

While testing swaps on Mobit, I changed the selected currency partway through the exchange flow and the application returned a raw “400 Bad Request” page. This should have been handled better since the response made it seem as if the process broke.

From a user perspective, this felt like the site had crashed unexpectedly. There was no related error message, redirect, or explanation of what could have caused the issue.

This was triggered by changing currencies during the flow, which seems to me to be like a normal user action.

A better handling mechanism would improve user experience. Say instead of exposing a raw 400 error page, the form could be reset. This preserve valid input fields. Alternatively, a message explaining that the current exchange parameters became invalid after the currency change should be displayed

.

[ContentWriter]

Title: Improper Input Validation Allows Wallet Address to Be Parsed as Exchange Amount

While testing MoBit.Exchange, I intentionally pasted a Monero wallet address into the Monero amount field instead of entering a numeric value. Instead of rejecting the input, the application transformed the address into the following malformed value.

Here is the original XMR address input:

4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45 DJ852K5Jv2684Rge

Here is the transformed output:

46653e54494585252684

Interestingly, the system still created an exchange order requiring only the minimum deposit amount. This is despite the BTC field displaying 1 BTC while the Monero field contained malformed alphanumeric data rather than a valid amount.

On the first attempt, `

Code:

/init_tx

` returned an empty page. On the second attempt, the order was successfully created.

I think the application may be loosely parsing or sanitizing non-numeric input because strict numeric validation on amount fields was not enforced. The presence of `e` inside the transformed value also raises the possibility of scientific-notation parsing behavior.
This  clearly shows that invalid input is not rejected cleanly before order creation. Strict server-side validation should ensure amount fields only accept properly formatted numeric values. Arbitrary alphanumeric input should be rejected with a clear validation message.

[ContentWriter]

Title: Contradictory Refund Language Creates Unclear User Rights

While reviewing the Terms of Service, I noticed conflicting if not contradictory language regarding refunds. According to section 4.1:

All Exchanges are final, and amounts are generally non-refundable once processed.

However, later sections discuss valid refunds, refund initiation windows, and refund queues, implying that refunds are possible under several conditions.
It is not clear what the policy meant by “generally non-refundable” and what qualifies as “processed.”

The wording could lead users to believe refunds are impossible even though later sections describe refund mechanisms. It is necessary to explain clearly when funds are refundable, non-refundable and when they have been processing while making that statement.

[ContentWriter]

Title: Undefined “Reasonable Efforts” Clause for Held Funds

Section 4.6 states that MoBit will make “reasonable efforts” to return certain held funds but is “not liable for the final outcome.”

The issue is that “reasonable efforts” is undefined. Mobit should make it clear what recovery steps they actually perform, how users can claim funds and even when a recovery effort has failed.

It would be more user transparent to specify possible recovery conditions and timelines and what constraints determine recovery success.

[ContentWriter]

Title: Ambiguous Definition of “Dramatic Market Changes”

Section 4.4 defines dramatic market movement as "a price movement of 4% or more in either direction."But it didn't specify the timeframe the 4% is measured, the oracle determines the rate or whether the calculation is based on spot or some internal pricing. This makes it easy for Mobit to be the sole determinant of when the market "changes dramatically." There's no way a user can independently confirm Mobit's claim when they override fixed-rate exchanges.

The pricing source and window  period should be clarified to improve fairness and predictability.

[ContentWriter]

Title: “Experimental Utility” Statement Conflicts with Financial Service Nature

Section 7.1 states:

“Using the Website may involve financial risks and should be treated as an experimental utility.”

Really? This wording is unusually inappropriate for a live cryptocurrency exchange handling real financial transactions.

From a user perspective, the phrase “experimental utility” may conflict with expectations of operational reliability. This is especially so since the platform processes real-value asset exchanges and advertises structured refund and support procedures.

The statement could unintentionally undermine user confidence or create ambiguity regarding service stability and dependability.

[ContentWriter]

Title: Unlimited Unilateral Suspension Rights Without Appeal Process

Sections 3.1–3.3 allows Mobit to suspend or terminate access for several reasons such as at sole discretion, without notice, explanation and liability.

While moderation rights are normal, the Terms currently provide no review mechanism, appeal process or explanation standards. This means that for users with pending transactions or refund requests, this creates uncertainty about account or order accessibility during disputes. We have seen projects confiscate funds for any and every reason so I believe that a minimal review or support escalation clause would improve transparency and fairness.

[ContentWriter]

Missing Idempotency Allows Duplicate Order Creation

While using the MoBit Exchange, I noticed that the system does not prevent duplicate order creation when submitting the same exchange request multiple times within the same browser session.

I created an exchange order using the website and repeated the exact same process three times without changing any input fields or refreshing the page. Each submission was done in separate tabs of the same Chrome browser session.

Instead of recognizing the repeated request as a duplicate, the system generated a new and separate order each time.

The following Order IDs were created from identical inputs:

9834d7919dab4551a6506ccb8ddf1f22
313d03ef6e534bd6807408cd48101e23
5dedf385a37b4b96abc249f631571311

All three orders were created successfully and appeared active at the same time. There was no warning, no duplicate detection, and no reuse of an existing order ID.

I would expect the system to either block duplicate submissions or return the same existing order instead of creating multiple independent transactions from identical input data.

This implies that the order creation flow lacks proper idempotency controls or duplicate request detection, which could lead to accidental creation of multiple orders and potential user confusion.

[ContentWriter]

Order Page Does Not Display User’s Intended Exchange Amount After Order Creation

While testing the exchange flow on MoBit, I noticed that the order page does not clearly display the actual amount the user intended to exchange after the order is created. I created an order to exchange 1 BTC to ETH. If the “Calculate” button is clicked first, the interface shows the estimated amount of about 34 ETH the user would receive. However, if the “Exchange” button is clicked directly without first using the calculator, the order page is generated.

The order page displays the minimum amount to send: 0.00062896 BTC and makes the user know that transaction has not yet been received. The page shows the deposit address and recipient wallet but there is no visible indication of:

• the original BTC amount the user entered
  the expected ETH output
  or the intended exchange amount tied to the order

This becomes confusing because once the order page loads, the user has no way to confirm the amount they originally intended to exchange unless they remember it. At this point, the previous page is no longer acessible even if they click the back arrow .

I also noticed that different orders created for the same intended 1 BTC exchange displayed slightly different “Minimum Amount To Send” values, such as:

• 0.00062868 BTC
  0.00062896 BTC
  0.00062938 BTC

This may confuse users into believing the required exchange amount has changed or that the order itself is inconsistent. This creates a usability and transaction integrity issue.  The order page should clearly display:

• the intended amount to be sent by user
  an estimated of the amount they would receive
  the selected exchange pair
  and the minimum deposit threshold separately

All these should be on the order page to reduce user confusion and improve trust in the exchange flow.

[ContentWriter]

PGP Letter of Guarantee Missing Exchange Amount Information

I noticed that the Letter of Guarantee (LoG) does not include the actual exchange amount or expected payout amount. The signed message confirms the order ID, deposit address, and destination address, but it does not cryptographically prove how much BTC the user intended to exchange or how much ETH was expected in return.

This makes the evidentiary value of the LoG weak in disputes. This is because two completely different orders could produce nearly identical guarantees even if different transaction values were involved. It also omits the exchange rate and fee breakdown charged by Mobit at the time of order creation.

To improve integrity and dispute resolution, the signed LoG should include the requested send amount, estimated receive amount, exchange rate, and minimum accepted deposit within the PGP-signed message itself.