01 What SypherScore is
SypherScore is a non-custodial analytics and automated market-making platform for perpetual futures. Users connect a wallet to view their own trading statistics, and optionally to run an automated market-making session on their own exchange account.
Supported venues: Arcus, RISEx, Perpl, Ondo, Phoenix, Hotstuff.
The platform does two things.
- Analytics. On-chain and venue-sourced statistics: volume, fees, funding, per-trader scoring, liquidations. Read-only, and no signature is required.
- Automated market making. With the user's explicit authorization, our engine quotes on the user's own exchange account. It places, amends and cancels limit orders according to the parameters the user chose: clip size, inventory cap, leverage, stop-loss, session duration.
This document describes the security model of the second, because that is where authorization is requested and where the platform's trust boundary lies.
02 Core guarantee: we never take custody
Three statements define the whole model. Each one is enforced by the exchange, not by our promise.
There is no path in the system by which a SypherScore process, or an attacker who fully compromised one, could move a user's funds to an address the user does not control.
03 How authorization works, venue by venue
We do not use a single custom authorization scheme. On each venue we use that venue's own native trading-credential primitive, and nothing else. This matters for review: the security boundary is defined and enforced by the exchange, so it can be checked against the exchange's documentation rather than ours.
The six venues fall into three groups.
The user creates a trading API key inside the exchange's own interface, in the
Arcus key section or at app.perpl.xyz/apikeys, then pastes it into our dashboard.
The exchange mints the key and scopes it. SypherScore is not part of that transaction at all.
We only store the resulting credential and sign order requests with it.
On these venues our site never requests a wallet signature. A user can run a
full session without our page ever calling eth_sign, personal_sign,
eth_signTypedData_v4 or eth_sendTransaction.
The user signs a standard SIWE (Sign-In With Ethereum) login challenge. That is
an authentication message, not a transaction and not an approval. The resulting session mints
an API key with scopes: ["trade"]. The transfer scope is never
requested and never granted.
Here the user does sign an authorization in their wallet.
- RISEx. EIP-712
RegisterSigner, authorizing a freshly minted session signer that is trade-only by the venue's design. Expiry is capped by RISEx at 30 days. - Hotstuff. EIP-712
addAgent, authorizing an agent wallet that can trade and can never withdraw. We set a 30-day TTL. - Phoenix (Solana). The user grants a delegation, and the venue forbids a delegate from moving collateral. The user's key stays with the user. We verify the delegation by reading the account bytes on-chain, not by trusting a transaction response.
In all three cases the signature authorizes a named, revocable, trade-only delegate registered with the exchange. It is not a token approval, an allowance, or a transfer.
04 Why withdrawal is impossible, per venue
This is the section we expect a security reviewer to care about most, so each row states the venue's own enforcement rather than a general assurance from us.
| Venue | Credential we hold | Why it cannot withdraw |
|---|---|---|
| Arcus | Ed25519 API key user-created |
Withdrawals are self-authenticated by a secp256k1 EIP-712 signature from
the master wallet, and they do not accept the X-API-Key headers at
all. Verified against the live API: a key-signed withdrawal returns 401.
Withdrawals are also withdraw-to-self only, so the recipient is always the signing
wallet. |
| Perpl | Ed25519 API key trade scope |
Perpl forbids withdrawals and transfers-out via any API key, regardless of scope. |
| Ondo | HMAC-SHA256 API key | Minted with scopes: ["trade"]. The transfer scope is
never requested and never granted. |
| RISEx | Session signer | The session signer is trade-only by the venue's design. Withdrawal requires the account wallet. Expiry is capped at 30 days by RISEx. |
| Hotstuff | Agent wallet addAgent |
The agent primitive permits trading and cannot withdraw. We set a 30-day TTL. |
| Phoenix | Solana delegation | The venue forbids a delegate from transferring collateral. The user's key never leaves the user. |
On no venue does the inability to withdraw depend on our conduct, our good intentions, or our infrastructure staying secure. It is unavailable to us because the exchange does not offer it to the credential type we hold.
- A seed phrase or private key, under any circumstance
- ERC-20 token approvals of any kind, unlimited or otherwise
setApprovalForAllor NFT approvalseth_sendTransaction. We never ask the user to send a transaction- Any signature that transfers, approves, or otherwise moves an asset
- Any custody of funds. There is nowhere to deposit
The only signatures we ever request are the venue-native delegate registrations of Group C and the SIWE login of Group B. On Arcus and Perpl we request no signature at all.
05 Verify it yourself
Every claim above can be checked without taking our word for it. The checks below run against third-party sources, not ours.
- Read the exchanges' own API docs. Every primitive we use is documented by the venue,
including its withdrawal rules: the Arcus API key, the perpl
tradescope, the Ondo scope list, the RISExRegisterSigner, the HotstuffaddAgent, the Phoenix delegation. None of it is our invention. - Attempt a key-signed withdrawal on Arcus. It returns
401. The withdrawal endpoint requires an EIP-712 signature from the master wallet and rejects the API-key headers outright. - Watch the wallet dialogs. Open a session on Arcus or Perpl and observe that our site never triggers a signature request at all. On the venues where it does, inspect the typed data: it names a trade-only delegate, not an approval and not a transfer.
- Check for token approvals. Inspect any user's wallet after a session, on a block explorer or an approval checker. There are none from us, because we never request any.
- Revoke without us. Delete the API key or revoke the delegate at the exchange. Our engine loses access immediately, and there is nothing we can do to prevent or reverse that.
We will also help with a review directly: a walkthrough of the signing flow, a funded test account on any venue, read access to the relevant source, or a call with our team.
06 Key management
What we store: venue trading credentials only, trade-scoped and withdrawal-incapable. No master keys, no seed phrases, and no user wallet credentials of any kind.
How they are protected
- Filesystem isolation. Credentials live in per-venue directories with mode
0700, individual files0600, owned by the trading process user. They are gitignored and never committed to version control. - Encrypted replication. When credentials are replicated to the standby host for failover, each file is encrypted with Fernet (AES-128-CBC + HMAC-SHA256). The standby holds no plaintext on disk, and files are decrypted in memory only. The master key is supplied through the environment, never stored alongside the data.
- Never exposed. Credentials are never returned by any API, never logged, and never printed. Only the delegate address ever leaves the storage module.
- Per-user isolation. One credential per user account, in a file keyed by that user's address. A single compromised credential exposes one account, and only to trading.
Bounded worst case. If our infrastructure were fully compromised, the attacker's maximum capability is placing bad orders on user accounts. They could not withdraw a single dollar from any of the six venues. That ceiling is imposed by the exchanges, not by a policy of ours, which is why bad-trading risk is handled separately in section 08.
07 Threat model
| Threat | Mitigation |
|---|---|
| User's private key leaks to us | It cannot. The key never leaves the user's browser, and on Arcus and Perpl we never even request a signature. |
| Our servers compromised, funds stolen | Not possible. No credential we hold can withdraw on any venue (section 04). |
| Our servers compromised, malicious trading | Per-session risk limits, inventory cap, stop-loss, kill switch (section 08). |
| A single credential is compromised | Per-user isolation confines it to one account, trading only. The user revokes it at the venue. |
| Credential outlives the user's intent | Everything is time-limited: 30 days on RISEx and Hotstuff, at most 180 on Arcus. Renewal always requires the user. |
| A phishing site impersonating us | Users should check that the domain is exactly
sypherscore.com. |
08 Risk controls
Because the bounded worst case is bad trading rather than theft, the second line of defence is per-session risk limiting. Every session carries user-chosen parameters, enforced by the engine on every cycle.
- Inventory cap. The maximum position the bot may accumulate.
- Stop-loss. The session halts and flattens when equity falls below the user's threshold.
- Maximum duration. The session ends automatically after a chosen time.
- Clip size. The size of each individual quote.
- Kill switch. The user stops the session at any moment from the interface.
On stop, on stop-loss, and on error, the engine performs a verified flatten. It cancels resting orders and closes the position, then confirms with the venue that the account is actually flat rather than assuming it.
Credential expiry is handled conservatively. An expired credential raises rather than silently falling through to an unauthenticated state, and the engine flattens and pauses before expiry rather than being cut off mid-position.
09 Revocation
The user is in control at all times.
- Stop the session. One click. Trading halts, orders are cancelled, the position is closed.
- Revoke at the venue. Delete the API key or revoke the delegate on the exchange itself, independently of us. This works even if our infrastructure is offline, unreachable, or hostile.
- Everything expires. 30 days on RISEx and Hotstuff, at most 180 on Arcus. We cannot renew silently, because renewal requires a fresh action by the user and we never hold the key that would authorize it.
Revocation at the venue is the one that matters: it does not require our cooperation.
10 On automated flagging
A site that connects a wallet and then trades looks, to an automated classifier, similar to the pattern a wallet drainer uses. That is a reasonable thing for a classifier to be cautious about, so we would rather answer it with specifics than object to it.
The distinguishing facts can all be checked independently of us.
- On two of the six venues we request no wallet signature at all. On Arcus and Perpl the
user creates the trading key inside the exchange's own interface. Our site never calls
eth_sign,personal_sign,eth_signTypedData_v4oreth_sendTransactionthere. - We never request a token approval of any kind, on any venue. No allowances, no
setApprovalForAll, noeth_sendTransaction. - Where we do request a signature, it registers a venue-native, trade-only, revocable delegate. That object is defined and enforced by the exchange and documented in the exchange's own API docs.
- No credential we hold can withdraw funds on any of the six venues (section 04), and on Arcus withdrawals are additionally withdraw-to-self only.
- There is nowhere to deposit. User collateral never leaves the user's own exchange account. No pooled wallet, no bridge, no contract of ours in the path.
We welcome a review and will help with it actively. Section 05 lists five checks a reviewer can run against third-party sources.
11 Contact
We respond to security reports promptly and will cooperate fully with any review, including providing a funded test account, a walkthrough of the signing flow, or read access to the relevant source.