How to check a crypto exchange service

Find the legal entity named in the terms, its jurisdiction, and the service it says it provides. Search the relevant regulator’s own register, then match the entity, license type, current status, and permitted activity to the website you are using. A copied license number or a similarly named company does not establish that a domain belongs to that operator. A working quote or order-processing interface does not verify the operator’s license.

• Save the official register URL, date checked, exact entity name, and license or charter type. If the entity or website association cannot be matched, keep the claim unverified.
• For a New York virtual-currency claim, consult NYDFS’s Regulated Entities table; it distinguishes virtual-currency licenses, money-transmitter licenses, and limited-purpose trust charters.
• Check the activity and jurisdiction covered. Company incorporation, a registration entry, and a license are different records; none is a blanket guarantee of security or permission for every product everywhere.
• Evaluate no-account access, geographic access, and licensing separately. Neither a working form nor a no-KYC policy proves regulatory status.

• NYDFS: virtual-currency licensing and regulated entities (opens in a new tab)
• no1.exchange service and provider conditions

Stop if someone asks for your seed phrase, private key, wallet password, or remote control of your device to complete an exchange. Treat an unexpected demand for another deposit to release an existing payout as a warning, not a recovery procedure. Open the service using its verified domain and compare any claimed operator or license with the original source; a professional-looking dashboard and displayed balance can be fabricated.

• Check the spelling of the domain and reach support through a channel published by the service, rather than an unsolicited message or search-ad contact.
• Look for pressure to act immediately, guaranteed profits, unexplained release payments, or a license badge that cannot be matched to the operator.
• Save the original order reference and transaction hash if funds have already been sent. Keep private order links and unrelated wallet details out of public reports.

• Ethereum: wallet security, impersonation, and scam prevention (opens in a new tab)

In the no1 workflow, funds move from your sending wallet to the exchange order’s deposit address, then the payout is sent to your selected destination. You do not give the interface your private key, but sending a deposit can put funds under the exchange operator’s control during processing. Wallet-to-wallet describes the endpoints; it does not prove an atomic swap or eliminate the risk between deposit and payout.

1. 01Your sending wallet
2. 02Order deposit address
3. 03Your destination

Read the terms for expired, failed, and refunding orders. A REFUND status is not evidence that a refund has reached your wallet, and recovery is not guaranteed.

• Distinguish a self-custody destination from a custodial exchange deposit address. In the latter case, the destination service controls access after receipt.

• no1.exchange funding, status, and refund boundaries
• no1.exchange order data and private access

Proof of reserves can show control of specified assets at a snapshot time. Liabilities are the balances and other obligations owed to customers or creditors. Seeing assets alone does not show how much the operator owes, whether the assets are borrowed or pledged, or whether every liability was included. Compare a report’s date, entity, covered balances and assurance level before relying on its reserve ratio.

• A Merkle inclusion proof can show that your balance was included; it does not by itself prove that every other customer or debt was included.
• A verified signature can demonstrate control of a wallet key at that time. It does not establish exclusive, unencumbered ownership or rule out funds borrowed for the snapshot.
• Check what the report says about liabilities outside its scope and changes after the snapshot. A reserve ratio is not a full financial-statement audit or a promise of future withdrawals.
• A successful quote from no1.exchange is not a reserve attestation. These historical report examples do not attest no1.exchange or the exchange processing service, and are not a complete list of exchanges with verified reserves.

A blockchain’s validation rules do not protect every wallet, website, or exchange connected to it. A stolen key can authorize a transaction the network considers valid, and a compromised exchange can lose control of its own wallets. For a swap, assess who controls the deposit, whether the destination accepts the asset and network, and how you will trace a payout if processing stops.

• Service: HTTPS and a responsive quote do not demonstrate solvency or successful settlement.
• Asset and network: understand the confirmation process and any token or smart-contract dependency. A valid-looking address does not prove that the destination can credit that token.

• Ethereum: wallet and phishing risks (opens in a new tab)
• no1.exchange destination and network checks

Public blockchains let you verify transfers and, with a self-custody wallet, control the keys used to authorize spending. An asset can lose market value even when its network works correctly, while a successful transfer does not prove that a service or investment is legitimate.

• Self-custody gives you control over signing, but losing the recovery phrase or exposing it can cause a loss that an exchange cannot reverse.
• Public transaction records support independent checks, but also reveal activity associated with addresses; transparency is not anonymity.
• Separate market risk from wallet theft, provider custody, and smart-contract or network risk. A token swap changes what you hold; it does not remove those risks.

• Ethereum: account control and private keys (opens in a new tab)
• Ethereum: security and scam prevention (opens in a new tab)

Digital signatures and network consensus address different problems. A signature authorizes spending from a key-controlled account; consensus determines which valid transactions and blocks the network accepts. Ethereum’s documentation explains both, but neither mechanism certifies an exchange, checks your intended recipient, or makes stolen keys harmless.

• Digital signatures: nodes can verify that a transaction was authorized by the relevant key without receiving the private key. If that key is stolen, the resulting signature may still be valid.
• Consensus and validation: participants apply protocol rules and agree on a chain history. Ethereum uses proof of stake; other networks use different mechanisms with different assumptions and attack risks.

• Ethereum accounts: public keys, private keys, and signing (opens in a new tab)
• Ethereum consensus mechanisms and validation (opens in a new tab)

Finding no disclosed incident does not establish that an exchange has never been hacked. A search with no results describes only the sources and period searched. It cannot rule out an undisclosed event, a compromised customer account, theft from the provider’s wallets, or an exploit in an outside protocol.

• Identify the legal operator, product, incident date, and affected system before calling an event an exchange hack. A customer account takeover is not the same as a breach of exchange custody; an exploit in a token, bridge, or protocol does not by itself show that exchange systems were breached.
• For each event, record the primary disclosure or regulator/investigator record, publication date, scope, confirmed loss or outcome, containment or recovery, later corrections, and what remains unknown. Mark the finding confirmed, disputed, or unverified; do not present a rumor as an established incident.
• State the period and source types searched, such as operator disclosures, regulator or court records, and independent incident reporting. If no disclosure is located, report only that none was found in the sources reviewed, not that the exchange was never hacked.
• Compare incident records only after matching the operator and product. Past incident history does not establish current security, solvency, or the chance of future loss; review custody terms, account controls, and how customer assets are handled separately.