How to check a swap site before you send: a ten-minute checklist

A swap site asks for one thing you cannot take back: a deposit to an address it gave you. Everything else — the rate, the fee, the timing — can be argued about afterwards; the deposit cannot. So the useful question before the first swap on any site is not "is this a good service?" but "what can I check in ten minutes that would make me walk away?"

This is that list. It names no services other than Sablebolt, and the last section applies every item to Sablebolt itself, including the items where a young site does not score well.

Ten items, roughly a minute each apart from the test swap, which takes as long as the route's confirmations.

1. Domain age and the registration record

Look the domain up in a WHOIS or RDAP service: the registry for the top-level domain runs one, and most registrars offer a lookup. You are reading for two things. The registration date: a site that describes years of operation but was registered last month has a story that does not fit. And the name: the brand on the page and the domain in the address bar should be the same, letter for letter. Look-alike domains — a swapped letter, a different ending — are the most common way a deposit goes to the wrong party.

Age alone proves little: a new domain can be an honest new service, and an old one can change hands. Treat the date as context, not as a verdict.

2. HTTPS and the headers

The padlock means the connection to the server is encrypted and the certificate was issued for the domain you see. Click it and read the domain in the certificate; it should be the one you typed. A certificate for a different name, or a warning page, ends the check.

Headers take one more step. Open the browser's developer tools, reload the page and read the response headers of the main document, or use any header-inspection service. Two lines matter most:

• Strict-Transport-Security tells the browser to use HTTPS for this domain for a stated time, so a later visit cannot be downgraded to plain HTTP.
• Content-Security-Policy lists where the page may load scripts from and which hosts it may talk to. A short list, naming only the site and its own API, means a script injected from elsewhere has nowhere to run.

Headers do not guarantee honesty; they show that someone configured the site with care.

3. Terms, fees and how it works

Three pages, read in five minutes. The fees page should say what the price is made of and where the fee is shown; if it only says "low fees", you have learned nothing. The how-it-works page should say what the site asks you for and what it never asks for. The terms should exist; if they are a draft, the page should say so rather than present itself as settled.

What you are looking for is specificity. A page that says "the final amount is set when the deposit confirms" has told you something you can hold it to. A page that says "best rates guaranteed" has not.

4. A support channel you can test

Find the support page. It should name a channel — an e-mail address at the site's own domain, a chat, a form — and say what to include in a message. Before your first swap, send a short, specific question and see whether a person answers the question you asked. Be careful with channels off the site's own domain: a support account on a messaging app can be imitated by anyone with the same display name, and the site's page is the only place that says which account is real.

5. A status page per swap

A swap has a life of a few minutes to an hour, and you should be able to watch it. The honest shape is a page per swap, with its own link, showing the deposit address, the amount expected, the current stage, and — once they exist — the deposit transaction hash and the payout transaction hash, each linked to a block explorer. Keep that link. It is the record of the swap on your side, and the first thing support will ask for.

A site that shows only "processing" with no hashes is asking you to trust it about the one thing you could verify yourself.

6. The security contact

Open /.well-known/security.txt on the domain. This is a standard location, defined in RFC 9116, for a plain-text file that tells security researchers where to report a vulnerability. The standard requires a Contact line and an Expires line (checked against the RFC text at rfc-editor.org on 12 October 2026). A site that has one has thought about receiving bad news. A missing file is not damning, but a present one is a point in favour.

7. The small test swap

Nothing on this list replaces a first swap for an amount you would not mind losing, above the route's minimum and no larger than that. Pick a route that is cheap to send on and fast to confirm — a stablecoin from TRON, for instance — so the test costs little and finishes in minutes. Send to an address you control, not to a third party. Then compare: the amount the status page said would arrive, the amount that arrived, and the time it took against the estimate the form gave.

If the test passes, you have learned more than any page can tell you. If it does not, you have lost a small amount and kept a large one.

8. One deposit address per swap

During the test, create a second swap on the same route and compare the deposit addresses. They should differ. A deposit address generated for your swap is how the site matches your payment to your order; a shared address means the site is matching by amount or by timing, which is fragile, and it means other people's funds pass through the same address as yours. Do not send to a deposit address you received anywhere other than the status page you opened yourself: not from a chat, not from an e-mail, not from a screenshot.

9. What a block explorer confirms

The status page links each hash to an explorer. Open both.

An explorer is the one witness in this process that neither you nor the site controls. If the status page and the explorer disagree, the explorer is right, and the disagreement is what you report to support.

10. Red flags

Any one of these is reason enough to stop.

• A guaranteed rate for an amount you have not yet sent, on a route that floats. A rate can be shown and refreshed; it cannot be promised for the time it takes your deposit to confirm, unless the site is taking that risk itself and says so.
• Pressure. Countdown timers that threaten a worse rate, messages urging you to send now, anyone chasing you in a chat. A swap site has no reason to hurry you.
• A request for your seed phrase or private key. No swap requires it, under any circumstances, for any reason, including "verification" or "recovery".
• A request to connect a wallet or sign a message. A swap between two addresses is paid for with an ordinary transaction from your wallet. Connecting a wallet to a site, or signing something you did not read, gives the site standing permissions it does not need.
• A deposit address that arrives by chat, e-mail or screenshot rather than on the status page you opened yourself.

The checklist applied to Sablebolt

Honesty requires running the list on the site publishing it.

Beyond the list, Sablebolt publishes three files meant for machines that also help a person checking the site: /openapi.json describes the public API, /llms.txt indexes every page in plain text, and each page has a markdown twin. What they contain, and how an assistant uses them, is in how Sablebolt talks to machines. None of this replaces item 7.

Before you send: the short version

• The domain in the address bar is the brand's domain, spelled exactly.
• The certificate is for that domain and the headers include HSTS and a content security policy.
• You read the fees page and the how-it-works page and found specific statements, not slogans.
• You know how to reach support and what they will ask for.
• You ran a small swap to your own address and the explorer agreed with the status page.
• Your second swap got a different deposit address from the first.
• Nobody asked for a seed phrase, a wallet connection or a signature, and nobody hurried you.
• The deposit address you are about to pay came from the status page you opened yourself.

FAQ