Security Overview

Our security model

Most security failures involving digital assets come from a single mistake: concentrating control. A custodial service that holds everything becomes a single target, and a user who hands over a seed phrase loses everything if that service is compromised.

We take the opposite approach. The platform is engineered so that we hold as little as possible, and so that the strongest security control available — your private key — never leaves your possession. As a result, the class of incident we can suffer is structurally narrower than for a custodian: we can lose account data, but we cannot lose customer assets, because we never have them.

Non-custodial by design

We do not hold your assets, your private keys or your seed phrase. This has several practical consequences:

• There is no pooled reserve of user assets at Web3 Sync for an attacker to target.
• A compromise of our systems cannot move assets out of your wallets.
• We cannot recover a lost seed phrase, because we never had it.
• You can revoke our wallet connection from your own wallet at any time, without our involvement or permission.
• If we ceased operating entirely, your assets would remain accessible to you through your own wallets.

Authentication

Sign-in

Accounts are protected by a password and a second authentication factor. Passwords are stored only as a salted hash generated with a deliberately slow algorithm, so that even a complete read of our database would not disclose them in a usable form.

Transaction PIN

Outgoing transfers require a separate four-digit transaction PIN. This is a deliberately distinct control from your login password: holding an authenticated session is not sufficient to move funds. The PIN is also stored only in hashed form, and repeated failures are rate-limited.

Recovery and rate limiting

Second-factor recovery codes are issued when you enable two-factor authentication, and are intended to be stored offline. Sign-in, registration, email verification, PIN and withdrawal endpoints are all rate-limited to slow automated guessing and credential-stuffing attacks. Account recovery requires identity verification before access is restored.

Encryption

• All traffic between your browser and the platform is encrypted in transit using TLS.
• Sensitive fields, including personal details and verification records, are encrypted before being written to storage.
• Passwords and transaction PINs are irreversibly hashed rather than encrypted, so they cannot be recovered even by us.
• Session identifiers are held in secure, HTTP-only cookies, reducing exposure to script-based theft.
• Secrets and credentials used by the service are held in environment configuration, never in source control.

Wallet linking

Linking a wallet grants the platform read access to public addresses only. We never request, receive or store a private key or seed phrase, and we will never ask you for one — not during onboarding, not for support, and not to "verify" your account.

Because blockchain addresses are public by nature, linking one does not reveal anything that is not already visible on a block explorer. It does, however, associate that address with your account, which is precisely why we encrypt address records at rest.

Withdrawals and confirmations

• A withdrawal request requires an authenticated session and a valid transaction PIN.
• Where a second factor is enabled, it is also required for withdrawal.
• Every withdrawal is recorded with a timestamp, amount, asset and destination address.
• Unusual destination addresses, or abrupt changes in withdrawal behaviour, trigger additional review.
• Because a broadcast blockchain transaction is irreversible, transaction details are presented for confirmation immediately before submission.

Infrastructure

Production systems run on managed hosting with network-level protections, automatic security patching, and isolated environments for development and production. Administrative interfaces are separated from the public application and protected by a distinct authentication guard and a separate session cookie, so that a failure in one does not grant access to the other.

Backups are encrypted and tested for restorability. Access to backup media is restricted and logged. We apply the principle of least privilege to all service accounts and rotate credentials on a defined schedule.

Monitoring and logging

Security-relevant events — sign-ins, failed sign-ins, PIN changes, second-factor changes, withdrawal requests and administrative actions — are logged with timestamps and origin information. Logs are retained for a defined period and used for investigation, audit and dispute resolution.

Automated rules flag anomalies such as a sign-in from an unusual location, a burst of failed authentication attempts, or a withdrawal pattern that departs from your normal behaviour. Flagged events are queued for human review, and our support team can be reached around the clock when something needs explaining.

Staff access and process

Access to production data is restricted to staff who require it to perform their role, granted on a least-privilege basis, reviewed periodically, and revoked promptly when no longer needed. Administrative actions are logged and attributable to an individual.

Support staff will never ask for your password, transaction PIN, seed phrase or private keys. Anyone who does is not us, regardless of how they contact you or what they claim. Treat any such request as hostile.

Incident response

We operate a documented incident response process, covering:

• Containment — limit the scope and prevent further exposure.
• Assessment — establish what was affected, how, and which users are impacted.
• Remediation — close the vulnerability and verify that the fix is effective.
• Notification — inform affected users and any relevant regulator without undue delay, as required by applicable law.
• Review — record the root cause and change process so the same failure cannot recur.

Because we are non-custodial, a compromise of our systems cannot result in the loss of customer assets. It can, however, affect account data, and we treat that with the seriousness it warrants.

Assurance and verification

We review our security practices on a regular schedule, track and patch dependencies, and engage external specialists where a control requires expertise we do not hold in-house. Findings are tracked to resolution with a named owner.

We do not currently publish third-party audit reports. Institutional and business clients can request our security questionnaire, architecture summary and data-processing terms through their account specialist, and we will provide them under confidentiality.

We also welcome external scrutiny. If you find a weakness, reporting it privately under section 13 is the fastest route to a fix, and we will credit researchers who wish to be acknowledged.

Protecting yourself

Security is shared. To protect your own account:

• Use a unique password for this platform, generated and stored in a password manager.
• Enable the second authentication factor and store your recovery codes offline, not in your email inbox.
• Keep your seed phrase offline and written down. Never type it into a website, a chat message or a support form.
• Treat unsolicited contact about your account as hostile until independently verified. We will not initiate contact asking for credentials.
• Double-check the destination address and network before confirming any withdrawal. An address on the wrong network will result in permanent loss.
• Consider holding significant balances in cold storage rather than a connected wallet.
• Keep your device, browser and wallet software up to date.
• Be cautious of anyone offering to "recover" lost funds for an upfront fee. That is a common fraud.

Responsible disclosure

If you believe you have found a security vulnerability, please report it privately to [email protected] with enough detail for us to reproduce it — the affected endpoint or component, the steps involved, and the impact you believe it has.

When researching, please:

• Do not access, modify, download or exfiltrate data that is not yours.
• Do not degrade, interrupt or overload the service, or run automated scans that generate significant load.
• Give us reasonable time to investigate and remediate before publishing anything.
• Do not use social engineering or physical intrusion against our staff or premises.

We will acknowledge reports promptly, keep you informed of progress, and will not pursue legal action against researchers who act in good faith within these conditions.

Contact

Security questions, vulnerability reports and requests for our security questionnaire can be sent to [email protected], or raised through live chat on the contact section of our homepage.