Security
Connecting an exchange to a website is a fair thing to hesitate over. This page is the specific answer: what the key can do, where it is kept, what is never asked for, and what is not claimed.
Every claim below names the behaviour behind it. Nothing here is a badge.
Read-only
When you add a connection, the key is checked before anything is read with it. Where a venue will tell us what a key is allowed to do, a key that can withdraw is rejected outright and never stored.
Venues differ in what they expose. Where the permissions of a key can be read, they are read, and a key with withdrawal rights is refused with the reason. Where a venue does not expose them, the connection still only ever calls read endpoints — but the guarantee then rests on the permissions you set, which is why the product tells you to set them.
Whatever a venue reports, there is no code in UnifyTrade that places, amends or cancels an order, and none that moves a balance. A key with more permission than it needs is a risk you are carrying at your venue; it is not a capability this product has.
A key stays yours. Revoke it at your venue at any time and the connection simply stops reading.
Credentials
A stored API key is encrypted with AES-256-GCM, in a file of its own, and no route anywhere hands one back. How much that encryption is worth depends on one choice the operator makes, so here it is.
The Admin Control Center shows whether an integration is configured and nothing else. Operating the service does not come with the ability to read what its users connected.
When a credential has to change you enter the new one; there is no flow anywhere that reveals the old one first, because a flow that can show you a secret can show it to somebody else.
There is no endpoint that hands back an exchange key, a Stripe secret, a mail key, a storage secret, a two-factor seed or a password hash. Not a user route, and not an admin one.
Given the key as an environment variable, an installation holds nothing that would open its own credentials file — copy the data away and it stays unreadable. Left to itself it generates one into the same directory instead, which guards a file shared by accident but not somebody who already has the files. It is one variable, and the stronger arrangement is the operator’s to set.
Wallets
Tracking a wallet means storing the address you would put on an invoice. That is the whole of it.
The public address. It is already public — it is on the chain — and it is enough to read balances and history.
A seed phrase, a recovery phrase or a private key. The product has no field for one and no code that would use one. Anything asking you for one is not UnifyTrade.
A WalletConnect session requests the chain and no signing methods at all. There is nothing for you to approve beyond letting it see the address, because there is nothing else it could do.
Separation
Every user has their own store. A request is served inside the caller’s tenant and cannot reach across into another one.
Which data a request may touch is decided from the session on the server, never from an id in the URL or the body. Changing a number in a request does not change whose data comes back.
The administrative surface is the only place that reads across tenants, and its role check runs on the server — not as a hidden menu in the browser.
If you give a mentor or an advisor sight of your journal, they get a scrubbed read and nothing else, and you can withdraw it whenever you like.
Your account
The things that protect an account only work if you can see them, so they are all in Settings rather than described here and hidden there.
Stored as a scrypt hash with a random per-user salt. The password itself is never written down anywhere, which is also why nobody can send it back to you.
Every signed-in session is listed with when it started, when it was last used and what browser it came from. Revoke any of them, including the one you are not sitting at.
An administrator account can be required to carry a time-based second factor, and the requirement is enforced when the session is created rather than when a page is drawn.
Sign-in, password reset and the public forms are rate limited, so guessing at an account is slow whatever else is true.
Not losing it
Most of what goes wrong with a small service is not an attacker. It is a crash halfway through a write.
Every sensitive write goes to a temporary file, is flushed to disk and then renamed into place. A process that dies in the middle leaves the previous version intact rather than half of the new one.
An instance lock stops a second copy of the server from opening the same data and the two of them overwriting each other.
Backups are taken on a schedule, carry a manifest, are kept to a retention policy and can be verified. An off-host copy to object storage can be configured by the operator.
What this page does not say
A security page that only lists reassurance is the kind you should not trust. These are the parts that are genuinely yours to weigh.
No service is, and any that says so is telling you something it cannot know. What is written above is what the code does — it is not a promise that nothing can ever go wrong.
Payments, email delivery and off-host backup are implemented and tested locally. Where one of them has not yet been run against the real provider, it is not described as production-tested, here or anywhere else.
UnifyTrade can be run by someone other than us. Server access, the encryption key and the backups belong to whoever runs the installation you are using, and no application can protect you from the machine it is running on.
Use a read-only key, watch what it reads, and revoke it the moment you want to. Nothing here depends on trusting the description.