Shuttle

Security architecture

Your infrastructure never sees a private key. Neither does ours.

Custody is split into two shares that only ever meet inside a hardware-isolated enclave. They come together to produce one signature and the key is discarded. There is no moment at which a complete key sits on a disk, in a process you control, or in one we do.

Read the SDK

What happens when you ask for a signature.

Your application never holds key material. It calls an API; everything that touches custody happens inside the enclave, and the only thing that comes back out is a signature.

Your appShuttle APIIsolated EnclaveShare AShare BPolicy check → signSignature

The key exists for milliseconds

Shares are brought together to sign and the reconstructed key is discarded immediately. There is no window in which a complete key sits somewhere waiting to be stolen, because there is no persistent complete key at all.

No disk, no network, no shell

The enclave has no filesystem to write to, no outbound network to exfiltrate over, and no interactive access for anyone — including us. It receives a request and returns a signature. That is the entire interface.

Every signature is logged

Each signing operation appends to an immutable audit log with its actor, target and outcome. Records are added, never rewritten, so the log is evidence rather than a status page.

Why splitting the key is the whole point.

Most custody claims reduce to “we keep the key somewhere safe”. That answer still has a key, and therefore still has a place to steal it from.

Two shares, never one key
Custody is split. Neither share signs anything on its own, and neither is ever assembled into a usable key outside the enclave — not on your servers, not on ours.
Your infrastructure is out of scope
Your application calls an API. It never holds key material, so a compromise of your servers, your CI or your developer laptops does not put the wallet at risk.
Our infrastructure is out of scope too
This is the part that matters. An attacker with our production credentials still has no key: the shares only meet inside attested, isolated compute that no operator can open.
Policy is checked before the signature exists
Limits and rules are evaluated inside the enclave, at signing time. A transaction that violates a policy is never signed — there is nothing to reconcile or reverse afterwards.

Who is allowed to authorize a signature.

Embedded wallets

Authorized by the end user who owns them. Backend coordination never transfers owner authority, and browser code is treated as an untrusted caller throughout.

Server wallets

Deliberately service-controlled for treasury, payouts and network fees. They act only as the named service identity, inside policies, limits and approval rules.

Fixed at creation

A wallet is one mode or the other for its whole life. There is no silent migration between them, and end-user authentication never grants service authority.

Authorization, not just authentication.

Authentication establishes who is calling. Authorization is a separate step, and it is bound to the exact thing being authorized.

Authorization binds to one operation
Every authorization response binds the exact action, wallet, actor, request ID, payload identity and expiry. It is valid for that operation only: it cannot authorize a different request, a changed payload or a later action.
A backend credential is not owner proof
A server credential cannot stand in for an embedded wallet's owner, cannot authorize its own recovery, and cannot elevate an end user into a server-wallet service role.
Multi-party agreement always terminates
Where agreement from several authorized actors is required, the operation exposes progress and still reaches succeeded, denied, expired or failed. Agreement is never a dead end with no completion path.
Uncertainty is never resolved by retrying
Every mutation carries a caller-generated stable request identity. A timeout after dispatch means the outcome is unknown, not rolled back — you recover it with getOperation instead of re-sending under a new identity.

What you can check yourself.

Trust that cannot be verified is just a claim with better typography.

Audit log
Every operation is recorded with its actor, target and outcome, in a log you read yourself rather than request from us.
Signed notifications
Deposit and transfer events are signed by service event-authentication keys — never by wallet fund-signing keys. Your verifier authenticates the exact raw bytes before parsing, then checks the timestamp window, key ID, tenant and wallet.
Key export, at any time
Export your keys in a format any wallet can import. No proprietary format, no exit fee, no notice period. The risk of you leaving stays with us, which is the only honest way to ask for custody.
SOC 2 report
Available under NDA, along with the whitepaper and threat model. If a specific control matters to your review, ask for it directly.

Compliance.

Shuttle is SOC 2 certified.

The report is available under NDA. Ask and we will send it, together with the whitepaper, the threat model, reproducible build instructions and published enclave measurements.

A certificate is a floor, not a finish line. The architecture above is what actually protects your users’ funds, and it is designed so that the worst case — someone compromising us — still does not produce a usable key.