How it works.
SciPHR is self-custodial. Your iPhone generates the wallet, holds the keys, and signs every transaction, all on the device. SciPHR's backend never receives a plaintext seed and cannot sign for you. What lives on-chain is an encrypted backup of your master key and a set of recovery rules the XRP Ledger enforces itself.
Custody is the bottleneck.
Every wallet has one secret, a seed, that can move its funds and sign as its owner. Today you get three bad options for holding it, and SciPHR was built to refuse all three.
Raw seed phrases
Twelve words on paper. Lose them, leak them, or mistype them and the identity is gone forever. The burden, and the risk, sits entirely on the human.
Custodial services
An exchange or vault holds the keys for you, and can freeze, fail, or get breached. Security rests on the company's promise, and you have no way to verify it yourself.
Hardware wallets
Strong security, painful experience. A separate dongle, a fragile backup, and no real story for multi-device access or enterprise recovery.
SciPHR's answer
Generate the keys on the device and keep them there. Back the master key up as sciphrtext that only your device, your iCloud, or your recovery code can open, and let the XRP Ledger itself hold the rules for rotating and recovering the account. The secret lives only on your device, sealed under a key that you alone can open.
Separation of concerns, by design.
The cleanest security comes from giving each mechanism a single job. On-device custody keeps the keys in your hands. XRPL-native recovery means you keep the account even if you lose a device. Different mechanisms, different failure modes, and neither routes a key through SciPHR.
Keys that live on the device
Your XRPL keys (Ed25519) are generated on the iPhone and stored in the iOS Keychain, device-only, non-syncing, gated by Face ID. The master key is also sealed into an encrypted envelope (AES-256-GCM under a one-time Wallet Backup Key) so a simple restore is possible. SciPHR holds no key that can open it.
Rules the ledger enforces
The account itself carries recovery rules. A regular key signs day to day; a signer list forms an M-of-N quorum that can re-key the account if a device is lost. SciPHR sits in that list below quorum, a helpful co-signer that can never act alone.
Below, each system is shown as a live flow. They run on a loop, hit replay to watch again.
Deep dive Why on-device, and why a signer list? ▸
On-device custody is what makes "non-custodial" a literal, auditable fact. The wallet is generated on your iPhone with xrpl.js; the Ed25519 key lives in the iOS Keychain, device-only, non-syncing, and released only behind a live biometric. The Secure Enclave holds a separate P-256 key that authorizes the device and wraps your backup key, it never holds or unwraps the Ed25519 wallet key itself. (The Enclave can't hold an Ed25519 key, so it never signs XRPL transactions; the wallet key is released by the Keychain under a live biometric, sits in app memory only for the instant of a signature, then the app drops its reference, with device-only flags and jailbreak detection narrowing that window.)
XRPL-native recovery is the other half. SetRegularKey assigns a day-to-day signing key separate from the master, and SignerListSet establishes an M-of-N quorum, other devices, a recovery-code key, and a SciPHR co-signer whose weight sits below quorum. If a device is lost the quorum re-keys the account with no SciPHR custody; because our co-signer can never reach quorum alone, the system satisfies the legal test for non-custody as well as the engineering one.
This is why custody is described plainly as self-custody: the keys are made and kept on your device, the backend holds nothing that can sign or decrypt, and recovery is enforced by the ledger itself.
From the chip in your pocket to the public ledger.
Sensitive keys live on your device; the rules that protect them live on a public ledger. Operations flow through four tiers, the security chip, the keychain, a zero-custody backend, and the ledger. Open each to see what runs there.
A dedicated security chip generates and stores a P-256 key with two jobs: it authorizes this device (its public key is your device entry in the on-chain DID) and it wraps your Wallet Backup Key via ECIES, so the device-held copy of the backup never leaves the chip. The private key is created inside the Enclave and cannot be extracted by the app, the OS kernel, or a jailbreak. Your Ed25519 wallet key, separately, is released by the Keychain itself under a live Face ID.
Handles: device-key generation · wrapping the Wallet Backup Key via ECIES · registering the device's public key in the DID.
Your XRPL keys (Ed25519 master and regular) live here, encrypted in the Keychain, device-only, non-syncing, and biometric-gated. Transactions are signed in the app, after it independently re-decodes and shows you every field of what it's about to sign. The key is in memory only for the instant of a signature, then the app drops its reference; only an iCloud wrap key can sync.
Handles: local Ed25519 signing · what-you-see-is-what-you-sign field validation · sealing the master key into the backup envelope · dropping key material references after use.
The backend holds no key, generates no seed, and cannot sign. It prepares unsigned transactions, pins your encrypted envelope to content-addressed storage, records public DID and NFT metadata, and broadcasts the signed blob your device returns. Hard invariants, enforced in code, review, and tests, forbid it from ever holding, generating, decrypting, or signing a user secret.
Handles: unsigned-transaction preparation · envelope pinning · public metadata · broadcast · audit trail · an optional sub-quorum recovery co-signer that can never act alone.
The ledger is where the account, its identity, and its recovery rules live. The xCIPHR NFT anchors a provenance pointer, sciphr:v5:<cid>#<sha256>, to the encrypted backup envelope, stored off-chain in content-addressed storage (the XRPL NFT URI is capped at 256 bytes). An XLS-40 DID document holds device public keys; a signer list holds the recovery quorum. All public, all immutable; ledgers close roughly every 3.5 seconds.
Handles: NFT provenance anchor (CID + hash) · on-chain DID documents · the recovery signer list · transaction validation · the permanent audit trail.
› Want to click through this as a live map? See the interactive architecture demo ↗
What happens when you sign.
Once an identity is minted, every action is signed on your device, and the most sensitive thing that ever leaves it is an already-signed transaction. Notice that the backend never holds a key, and the app never signs something you haven't seen in full.
- You initiate an actionSend XRP, sign a message, prove identity. The app raises a Face ID prompt.
- The app shows exactly what you'll signIt independently decodes the transaction and displays every field that matters, destination, amount, fee, network. What you see is what you sign.
- The Keychain releases the keyYour biometric releases the regular key from the Keychain, device-only and non-syncing. The private key never leaves the device, and is held in memory only for the instant of a signature.
- The app signs locallyThe wallet key signs with Ed25519 in app memory, then the app drops its in-memory reference after the signature exists.
- The backend broadcastsIt validates policy and relays the signed transaction. It never saw a key and could not have signed; the worst a compromised backend can do is propose a transaction, which your device can refuse.
- XRPL validates and settlesThe network confirms the signature and writes the result to the immutable ledger, typically within one close.
Deep dive Recovery & multi-device, two tiers ▸
Because the identity lives on-chain, you keep the account even if you lose the device. Recovery comes in two tiers, and neither routes a key through SciPHR:
Tier 1, same person, new device. Restore the master key from your backup envelope via iCloud Keychain or your recovery code. The synced copy is an iCloud wrap key that, paired with your public backup envelope, unwraps the Wallet Backup Key; we prompt you to turn on Apple's Advanced Data Protection, and the app can add an optional restore passphrase for another factor.
Tier 2, catastrophic loss or key compromise. A quorum of your signer list re-keys the account with SetRegularKey, other devices plus a recovery-code key, with the SciPHR co-signer below quorum. A stolen device alone can't enroll an accomplice; catastrophic re-key still takes a real quorum, enforced by the ledger itself.
Add a device by signing in with Apple and enrolling its key in the DID; retire one by removing it. Only a valid on-chain signature can change the identity, even SciPHR cannot rewrite it.
What an attacker has to defeat.
Each architectural choice maps to a concrete property an attacker has to defeat. The point is structural: the system is built so that even we cannot expose a key.
| Attack | Why it fails |
|---|---|
| Stolen NFT or envelope | Inert sciphrtext. The envelope is AES-256-GCM, and its Wallet Backup Key can be unwrapped only by your device, your iCloud, or your recovery code, none of which SciPHR holds. |
| Stolen / unlocked device | Signing requires a live biometric, and the key is device-only and never exportable. Even then, a signer-list quorum can re-key the account out from under a thief. |
| Compromised backend | It holds no key and can't sign or decrypt. The worst it can do is propose a transaction, which your device decodes and shows you in full, and which you can refuse. |
| Phished iCloud account | iCloud is one restore path, not a SciPHR-held key. Advanced Data Protection and the optional restore passphrase harden this path; the signer-list quorum still stands for catastrophic re-key. |
| Insider at SciPHR | No employee holds a key that can sign or decrypt. Enforced invariants plus a public ledger make "trust us" unnecessary. |
| Lost device | The account lives on-chain. Restore from the envelope, or re-key via the signer list, without anyone ever holding your funds. |
- Self-custodial, by construction, keys are generated and stored on your device; SciPHR cannot access your funds or recovery material.
- Recoverable without custody, XRPL-native SetRegularKey + SignerListSet re-key the account; our co-signer can never act alone.
- What-you-see-is-what-you-sign, the device validates every transaction field before signing, so every signature is over something you have read in full.
- Standards-grounded, Ed25519, AES-256-GCM, Argon2id, W3C DID, XLS-40, XLS-20, audited and widely reviewed throughout.
A note on self-custody
This is the literal, auditable kind: non-custodial. Your keys are generated and stored on your device. SciPHR cannot access your funds or your recovery material, and because the backend holds no signing or decryption key, you can verify how custody works by reading the code.