Security
How funds and data are protected
A service converting digital assets concentrates two coveted things: funds in transit and complete identity files. This page describes the architecture that separates them, the access rules that govern them, and what we cannot yet guarantee.
Custody of funds
The founding principle: we are a flow, not a custodian. What is not held cannot be stolen.
- No reusable balance
- Your account carries no balance. A deposit is tied to an order, converted, then paid out. There is no storage function, no withdrawal to a third party and no transfer between accounts.
- Minimal holding time
- The time funds sit under our control is limited to network confirmation, compliance checks and payout issuance. Shortening that window is the most effective security measure, ahead of any technical device.
- Dedicated deposit address
- Each order gets its own address. A deposit is therefore unambiguously attributable, and an address cannot be reused to mislead a customer about the destination.
- Hot and cold separation
- Only the operational fraction needed to settle in-flight orders stays on connected signers. The rest is held offline, with split keys and a multi-signature threshold.
- Segregated customer funds
- Funds in the course of conversion are accounted for separately from own funds. They finance no company activity and are neither lent nor pledged.
- Dual approval on payouts
- Above a threshold, a payment instruction requires two separate approvals. A single compromised internal access is therefore not enough to move funds out.
Encryption and data
Identity verification files are the most sensitive data in the product. They are treated accordingly.
- Encryption in transit
- All traffic runs over TLS, with no exception and no plaintext fallback. Strict transport is enforced by header, which prevents an initial unencrypted request.
- Encryption at rest
- Databases, backups and document storage are encrypted. Identity document images and liveness captures live in a store separate from account data.
- Secrets and keys
- No secret in the code or in the logs. Encryption keys are held by a dedicated service, with scheduled rotation and separation between whoever holds the key and whoever accesses the data.
- Scrubbed logs
- Bank identifiers, payout keys and document contents are stripped from application logs at write time. An incident on the logs therefore exposes no usable payment details.
- Passwords
- Stored as a hash with a slow derivation function and a unique salt. We cannot read them, so we cannot remind you of one — only let you reset it.
Internal access
Most incidents come not from an exotic flaw but from internal access being too broad. That is where the effort goes.
- Least privilege
- Access is granted by role and for a task. Support does not see identity documents; compliance cannot change an amount; engineering does not reach customer files in production.
- Mandatory second factor
- No internal access without a hardware second factor. Text-message codes are not accepted for internal access: they are vulnerable to number hijacking.
- Access logging
- Every opening of a verification file is recorded with the agent and a timestamp. Logs are retained and reviewed periodically.
- No production data elsewhere
- Development and test environments run on synthetic data. Copying a production database onto a workstation is forbidden, and technically prevented.
- Offboarding and access review
- Access is revoked when someone leaves and reviewed periodically. Unused access is removed rather than kept “just in case”.
What you control on your account
Part of the security depends on you. The product is built so those steps are simple and hard to bypass.
- 01
Turn on a second factor
Authenticator app or hardware key. It becomes mandatory above the second verification tier. The absence of a second factor remains the leading cause of payout diversion seen in this sector.
- 02
Check your sessions
Active sessions are listed with their device, approximate location and date. You can revoke one remotely without changing your password.
- 03
Cooling-off on a new beneficiary
Adding a destination account triggers a notification and a delay before it can receive a high amount. That delay exists so fraudulent access does not turn instantly into a transfer.
- 04
Change notifications
Password change, beneficiary added, second factor enabled or disabled: every event sends a message to the registered address, including when you did it yourself.
- 05
Recognise phishing
We will never ask for your recovery phrase, never ask you to deposit to an address sent by message, never ask you to convert funds to “secure” an account. A deposit address exists only inside your order.
What the browser enforces
These headers are set by the server on every response. You can check them yourself in your browser’s developer tools.
| Header | Effect |
|---|---|
| Strict-Transport-Security | Forces the browser to use encrypted connections only, even if a link points at an insecure version. |
| X-Frame-Options: DENY | Prevents the site being embedded in a third-party frame, which neutralises clickjacking. |
| X-Content-Type-Options: nosniff | Stops the browser guessing a file’s type, a classic source of unintended execution. |
| Referrer-Policy | Limits what leaks to a third-party site when you follow an outbound link: the origin, never the full path. |
| Permissions-Policy | Cuts access to the microphone, geolocation and the payment interface. The camera stays allowed on our own origin, for identity verification. |
| Cross-Origin-Opener-Policy | Isolates the site’s window from other browsing contexts, blocking a class of shared-window attacks. |
These headers come from the server configuration, not from an optional layer. They do not replace application controls: they close the doors only the browser can close.
Continuity and incidents
An incident plan never rehearsed is not a plan. Here is the procedure and what you would see of it.
- 01
Detection and triage
Alerts on abnormal access, series of failed authentications and reconciliation gaps. An alert is triaged by a person, never closed automatically.
- 02
Containment
Revocation of the access concerned, payout freeze if the doubt touches a movement of funds, isolation of the affected component. The service can be deliberately interrupted: we prefer an outage to a doubtful payment.
- 03
Notification
A personal data breach likely to create a risk is notified to the supervisory authority within 72 hours, and directly to the people concerned where the risk is high.
- 04
Return to service
Restoration from encrypted backups whose restore procedure is tested — a backup never restored is not a backup.
- 05
Public note
We publish an incident note describing what happened, what was exposed and what changed, even where individual notification is not required.
Responsible disclosure
We would rather learn about a flaw from a researcher than from an incident. The times below are commitments.
| Severity | First response | Fix target |
|---|---|---|
| Critical — funds, keys or identity data exposed | 4 h | Fix or mitigation within 72 hours |
| High — authentication or authorisation bypass | 24 h | Fix within 14 days |
| Medium — limited information leak, partial denial of service | 72 h | Fix within 60 days |
| Low — configuration defect with no demonstrated impact | 120 h | Handled in the regular development flow |
What we do not guarantee
A credible security page states its limits. Here they are, unsoftened.
- No external audit to date
- No third-party penetration test and no certification has been carried out. We therefore display no audit logo, no seal and no certification claim. The day an audit is run, its scope and date will appear here.
- An on-chain transaction cannot be undone
- No security measure makes a confirmed transfer on a public network reversible. That is a property of the network, not a gap on our side.
- A compromised device
- If your computer or phone is compromised, an app-based second factor can be bypassed. A hardware key remains the only genuinely resistant protection in that case.
- Payment providers
- Once the instruction reaches the payment institution, routing depends on its infrastructure and on intermediary banks. We choose our providers, we do not operate them.
- Zero risk
- We will not promise it. What we can promise is a reduced surface, fast detection and communication that does not minimise.
Frequently asked security questions
Do you hold my crypto?
No. There is no balance, no wallet and no storage function. A deposit is tied to an order, converted, then paid out. The time funds sit under our control is limited to processing the operation.
What happens if your system is compromised during my order?
Payouts are frozen as soon as an incident touching a movement of funds is triaged. An order already converted is still owed: the conversion and the payment obligation are recorded independently of the affected component.
Is a text-message second factor accepted?
For a customer account, yes, but we recommend an authenticator app or a hardware key: phone number hijacking is a common and cheap attack. For internal access, text messages are not accepted.
Are you certified or audited?
No, and we display it nowhere. No external penetration test and no certification has been carried out to date. The day that changes, the exact scope and date will appear on this page.
I found a flaw. What should I do?
Write to the security address with the component concerned, the impact and reproduction steps. The authorised scope, the testing rules and our commitment not to pursue good-faith research are published.