Security and trust

Scrya lets a business confirm that a customer holds crypto without the customer handing anything over. This page explains how the proof works and how Scrya protects the information involved. It’s written for compliance teams assessing Scrya and for customers who want to know exactly what happens to their data.

At a glance

No custody. Scrya never takes control of funds, never moves funds, and never asks for a seed phrase or wallet private key.
Wallet proofs use a signed message. Signing is not a transaction and costs nothing.
Exchange proofs use a read-only API key. Scrya only reads balance and account information.
Exchange credentials are encrypted before they’re stored, and are never shown again in the app.
Each organisation’s data is kept separate by the database itself.
Accounts are invitation-only, and every user can turn on two-factor authentication.
Changes are recorded in an audit log that users can read but can’t edit or delete.

How the proof works

Private wallets: signing a one-time message

The customer enters their wallet address, and Scrya issues a one-time message to sign.
The message is single-use and expires 15 minutes after it’s issued.
The customer signs it in their own wallet, either by connecting a browser wallet (Connect & Sign with …) or by copying the message into their wallet and pasting the signature back.
When the customer submits, Scrya checks that the signature was made by the key for the address the customer entered, over the message Scrya issued, and that the message hadn’t expired. A signature that doesn’t match fails straight away.
Only then does Scrya read that address’s balance from the blockchain. An address is never marked verified on a balance read alone, and editing the address after the check means it has to be signed again.

Bitcoin Taproot addresses (starting bc1p) can’t be verified this way. Use an address starting 1, 3 or bc1q instead.

Signing a message is not a transaction. Nothing is sent to the blockchain, no network fee (gas) is paid, and no funds can move. The wallet’s private key never leaves the wallet. Scrya only receives the public address, the message and the signature.

Balances are read from public blockchain data. These reads use only the public address.

See How wallet verification works.

Exchanges: a read-only API key

The customer creates an API key in their exchange account with read-only permission, following the Setup Instructions Scrya shows for that exchange.
They paste the key, the secret and, for OKX, the passphrase into Scrya. These travel over an encrypted (HTTPS) connection to Scrya’s server.
Scrya’s server connects to the exchange and reads the balance straight away.

Scrya’s exchange connections only request balance and account information. They contain no trading or withdrawal functions. A read-only key can’t be used to trade or withdraw by anyone who holds it.

It’s up to the customer to create the key as read-only, and each exchange guide shows exactly which permission to choose. If you created a key with trading or withdrawal access by mistake, delete it at your exchange and create a read-only one.

See How exchange verification works.

How exchange credentials are protected

Encrypted before storage. The API key, secret and passphrase are each encrypted with AES-256 before they’re saved.
The encryption key is kept separately. It’s stored apart from the encrypted credentials and is never sent to a browser.
Decrypted only for the balance check. Credentials are decrypted on Scrya’s servers, only while a balance check runs.
Never shown back. The app never displays a stored key, secret or passphrase, to the customer or to the business. Credentials are removed from audit records and are left out of data exports.
Reuse is re-checked live. If a customer verifies with the same exchange again, they can pick a saved key under Use a saved API key or add a new one. The picker only shows the exchange, the asset and a date. Scrya runs a fresh balance check with the saved key, so a key that’s been deleted at the exchange fails.
Deleted after 30 days, or sooner. 30 days after a verification completes, Scrya deletes the stored credentials. If a connection fails, they’re deleted straight away. If a verification expires, they’re deleted within a day.

Customers can delete the key at their exchange once their verification shows Verified. See Revoking your API key.

Separation between organisations

Many businesses use Scrya, and their data is kept apart. Access rules are enforced at the database level, not only in the app, so every request returns only the records that person is allowed to see.

Business users only see the customers, requests and results in their own organisation.
Customers only see their own requests.
Sensitive actions, such as sending invitations, checking an exchange balance or erasing data, are authorised on Scrya’s servers, never in the browser.
Scrya’s own administrator and support accounts can see records across organisations so they can run and support the service.

Invitation-only. There’s no public sign-up. Every account starts from an invitation: Scrya invites each business’s first users, Business Admins invite their team, and businesses invite their customers.
Passwords. Passwords must be at least 8 characters and include an uppercase letter, a lowercase letter and a number. They’re stored as hashes, never as plain text.
Two-factor authentication. Any user can turn on two-factor authentication with an authenticator app (such as Google Authenticator, Authy or 1Password) under Settings. After their password, they enter a 6-digit code from the app. New users are prompted to set it up, but it’s optional for each user. See Two-factor authentication.
How often a code is needed. Business Admins set the organisation’s MFA challenge frequency, from Every log-in (the default) to Every 48 hours. It applies to users who have two-factor authentication turned on. If a customer belongs to more than one organisation, the strictest setting applies.
Idle sign-out. After 1 hour with no activity, you’re signed out and need to sign in again.
Scrya staff. Scrya’s own staff accounts need an extra verification step every time they sign in.

Audit logging

Business users can open Audit Log from the sidebar. It automatically records every change to the organisation’s data, showing who made the change, when, and which values changed.

Audit records are written automatically. Users can read them but can’t edit or delete them.
Signatures, signed messages and exchange credentials are stripped out of audit records.
Audit records are kept for 24 months. Records about a customer are also removed if that customer’s data is erased.

See Audit log.

Data retention and deletion

Scrya clears data on a schedule:

What	When it’s cleared
Signatures, signed messages and stored exchange credentials	30 days after the verification completes
Full wallet address	Shortened to its first 6 and last 4 characters 30 days after the verification completes
Audit log records	After 24 months
In-app notifications	90 days after being read, and after 12 months at the latest
Operational logs, such as email delivery and error records	Between 90 days and 12 months, depending on the type

Business Admins can also export everything stored about a customer, or permanently erase it, from the customer’s page. Exports leave out signatures and exchange credentials. See Exporting or erasing customer data and Your data and privacy.

For how Scrya handles personal information, see the Privacy Policy.

Encryption in transit

The Scrya app is only served over HTTPS, and browsers are told to always use HTTPS for it. Scrya’s connections to exchanges and blockchain data providers also use HTTPS.

Where Scrya runs

Scrya runs on established cloud providers for hosting, its database, email, error monitoring and billing. The Privacy Policy lists each provider that handles personal information, what it does and where it runs.

Wallet balances are read using public addresses only. If an error happens in the app, error monitoring may capture a screen recording, with all on-screen text and form inputs masked.

Reporting a security concern

If you think you’ve found a security problem, or someone contacts you claiming to be Scrya and asks for sensitive information, email support@scrya.io.