Trust & security

Deposits are made in USDT on the TRON network to a deposit address issued to you. That address is derived from a wallet OGuard generated and controls. The wallet’s master secret is held by OGuard, encrypted at rest under a dedicated key. Deposited balances are periodically consolidated into an OGuard treasury address. Withdrawals are sent from OGuard payout wallets derived from that same wallet, one per blockchain family.

Money leaving the platform is the path that matters most, so it carries the most controls. Each of the following is in force today.

• Whitelisted destinations only.A withdrawal can only be sent to an address on your own whitelist, and each entry is valid for one asset on one network. Adding an address requires your account password and a one-time code emailed to you, plus your authenticator code if you have one enrolled. A new address cannot be used until a security waiting period has passed — we tell you exactly when — and removing one never deletes its history. If an address looks like an exchange’s pooled deposit address you are warned, and must confirm, before it is added.
• A one-time code on every withdrawal. No withdrawal can be created from a session alone. If you have an authenticator app enrolled you are asked for a code from it; if you have not, a one-time code is emailed to your verified address. The asset, network, amount, fee, amount received and destination you approved are bound into that challenge, so a withdrawal cannot be created on different terms from the ones you confirmed.
• Administrator approval, informed by a risk check. Every withdrawal is assessed when it is created and is then reviewed and approved by an administrator before any payment is made. The assessment flags what deserves the closest look — withdrawals over a size threshold, above a per-account daily or platform-wide hourly limit, soon after a password or two-factor change, or to an address first used soon after it was added. Administrators can pause withdrawals for every asset, one asset or one network in a single step.
• Your funds are held, not spent, until the payment is proven. The amount is held in your Funding balance from the moment you confirm. It is released back to you only if the withdrawal is cancelled, declined or fails before anything is signed, and it is settled only once the payment is verified on chain.
• A server-signed, exactly-once payout engine. The on-chain payment is built and signed on our servers under a state machine designed so that a crash, a retry, or two servers acting at once cannot produce two payments. The signed transaction is recorded before it is broadcast, a rebroadcast always replays the same signed bytes, a replacement signature is made only once the original is proven unable to land, and database uniqueness constraints backstop the whole path.
• Verification before completion. A withdrawal is marked sent only after the transaction on chain is checked: the right network and asset, sent from our payout wallet, to your whitelisted address, for exactly the amount you were quoted, successfully executed and final. Anything that does not match stops the automated path and goes to an administrator with your funds still held.
• Two people for any manual payout. If a payment has to be completed by hand, one administrator records the transaction and a different administrator must approve it, each with their own authenticator code, and it is accepted only once the chain proves it.

One clarification, because it is easy to over-read: the payout wallets that send withdrawals are hot wallets holding a limited working float, separate from OGuard’s treasury. OGuard also controls where its owntreasuryis: changing it requires the acting administrator’s own authenticator code, every administrator is notified, and operators can pin the addresses it may ever be. That control protects OGuard’s consolidation address; your own whitelist, above, is what protects where your withdrawals can go.

• Your session token is stored in a cookie that page scripts cannot read, and is attached to API calls on the server. It is never exposed to JavaScript running in your browser.
• Two-factor authentication at sign-in is optional: you can enrol an authenticator app, or turn on emailed one-time codes. Enrolling an authenticator issues ten single-use recovery codes — store them somewhere other than the phone holding the app.
• Repeated wrong passwords against your account from one device arm a lockout that lengthens with each further attempt, up to one hour. It is scoped to the device attempting it, so somebody guessing at your email from elsewhere cannot lock you out of your own account.
• Sign-in, registration and password reset are protected by a Cloudflare challenge.
• Signing out ends that session immediately and the token cannot be reused afterwards. If you think a device is compromised, tell support: an administrator can revoke every session on your account at once, and reset your password so the old one stops working.

• Administrator accounts are entirely separate accounts from customer accounts, with separate credentials and separate sessions. Sharing an email address does not share access.
• The administrative interface is on a separate hostname behind an identity gate; an address must be on an allow list to reach the sign-in screen at all.
• Money-critical wallet operations ask for an authenticator code at the moment of the action. Retargeting the treasury always requires the acting administrator’s own code; triggering a consolidation, approving, retrying or refunding a withdrawal, and loosening the withdrawal limits require it from every administrator who has an authenticator enrolled. Completing a withdrawal by hand needs two different administrators.
• Administrator actions against a customer account are written to an audit log. If an administrator views the platform as a customer, every change made in that state is recorded as such.
• Credentials and wallet secrets are encrypted at rest with AES-256-GCM under keys held outside the database.

Operating the platform means a small number of third parties handle some of your data on our behalf:

Transactions on public blockchains are public and permanent by design. Anyone who knows your deposit address, or an address you withdraw to, can see what has moved through it.

When trading has to be paused, the platform enters a maintenance state: orders, deposits and withdrawals are refused with an on-screen explanation while your existing positions and balances remain visible. Changes to your funding requests are emailed to you as they happen.

OGuard does not operate a public status page today. During an incident, updates go out by email to affected customers and through the in-app support inbox. If something looks wrong and you have seen no message, contact support rather than assuming it is known.

If you believe you have found a vulnerability, email support@oguard.io with enough detail to reproduce it. Please report it to us before disclosing it anywhere else, and do not access, modify or exfiltrate data belonging to another customer while investigating.

We do not currently run a paid bug-bounty programme and we do not publish a formal safe-harbour policy, so we will not pretend to offer either. We will acknowledge your report and tell you what we did about it.