Security at EBCMX
Security here is a set of mechanisms, not a promise. Everything below is built and running today, described plainly enough that you can check it against what the product actually does.
Where your assets are held
EBCMX writes no wallet, key-management or custody code. Custody of the assets held for you is provided by an institutional custody provider, and no private key or seed phrase exists anywhere in our codebase or our database.
Deposit addresses are issued to you for one asset on one network. An incoming transfer is attributed to your account and credited only after the confirmations that asset and network require, and our credit policy is aligned to the custody provider’s own.
Withdrawals go only where you already allowed
A withdrawal address has to be saved to your account and confirmed from a link we email you before it can be used at all. And if the credentials protecting the account changed recently — a password change while no second factor is set, or a second factor that was switched off — a newly added address is held for a period before it becomes usable, so that taking your own protection off is not itself a route to moving funds.
Requesting a withdrawal means proving a second factor again; an open session is not enough on its own, and that proof holds only briefly before the next request asks for it once more. What we hand the custody provider is a destination registered in advance, never an address typed at the moment of sending, and a request whose destination registration has not been approved is refused before anything moves.
Once a request is accepted, the amount and its fee leave your balance into a suspense account first, and only then is the transfer submitted. The submission is keyed to the withdrawal’s own identifier, so a retry after a network timeout returns the same transfer instead of sending a second one.
Every movement is written twice
A balance on EBCMX is not a number we set; it is a projection of an append-only double-entry ledger. Every deposit, trade, fee and withdrawal is written as signed legs that sum to zero for each asset, and the database itself refuses to commit a transaction where they do not. Ledger rows are never edited or deleted — a mistake is corrected by posting its reversal, so what happened stays readable after the correction.
The application can only do what its code needs
The exchange connects to its database as a role that owns nothing and holds only the grants its code actually uses, table by table, with permission to delete rows only where the product genuinely deletes them. Schema changes run as a separate owner role, and the cluster superuser is kept for break-glass use. The application verifies its own database identity before it will use a connection and refuses to proceed on any other role, which is what keeps the ledger’s guarantees from resting on application code alone.
The controls on your account
- Two-factor authentication
- A code from an authenticator app on top of your password, with single-use backup codes issued at setup.
- Passkeys
- A passkey is a second factor at sign-in and never a replacement for your password. There is no passwordless sign-in on EBCMX.
- Step-up verification
- Changing anything about your second factors means proving one first. Knowing your password is not enough to take your own protection off, and neither is holding a live session.
- Global Settings Lock
- One control freezes the settings an attacker would have to change first: adding a withdrawal address, changing your password, managing two-factor authentication. Unlocking starts a waiting period you chose in advance and emails you when it starts, so a request that was not you can be cancelled. A registered Master Key passkey unlocks immediately.
- Sessions
- Every signed-in browser is listed and can be signed out individually, or every other one at once, and a session signs itself out after an idle period you choose.
- Devices
- The browsers that have signed in to your account are listed with when each first signed in and when it was last active, and any of them can be removed.
- Security notices
- Sign-ins, passkey changes, regenerated backup codes, password changes, new withdrawal addresses and settings-unlock requests are emailed to the address on the account. Each of those notices carries a one-click link that locks the account, for when the answer is that it was not you.
Identity documents
Verification documents are reviewed by our own compliance team; we run no automated face-matching, liveness or text-recognition over them. They are stored under a compliance-mode retention lock, which means a stored document cannot be altered or deleted before its retention expires — by anyone, ourselves included. Access is limited to the staff roles whose work requires it, and each access is written to an audit log.
Report a vulnerability
If you have found a security issue in EBCMX, tell us. The contact is support@ebcmx.com, which is also the address published in our security.txt.
We do not yet publish a formal vulnerability-disclosure policy; one is being prepared with counsel, and this page will carry it when it exists. Until then, please report privately and let us fix the issue before it is described publicly.
What this page does not claim
Two things a security page is often expected to carry are deliberately absent. We hold no third-party security certification and publish no audit report, and we publish no proof-of-reserves attestation. Both are real undertakings with real preconditions, and neither is in place today. If that changes it will be stated here, with whatever it actually covers.