Jarod VyentLLC
Start a conversation
Skip to the SciPHR overview

SciPHR / Architecture overview

Keys on the device.
Trust boundaries you can follow.

SciPHR coordinates identity and transactions around xCIPHR, while the user’s wallet signs locally. This is a guided view of the architecture; the full documentation lives on sciphr.io.

Read full SciPHR docs Explore the workflows

01 / System boundary

Coordination is not custody.

Private / device

The user’s device

  • Master & regular signing keys
  • Local transaction review
  • Device authorization key

Signs and decrypts locally

Coordination / cloud

SciPHR services

  • Prepare unsigned intent
  • Verify the signed result
  • Broadcast to the ledger

Cannot sign for the user’s wallet

Content-addressed storageEncrypted recovery envelopeSealed master recovery materialPublic identity documentReferenced by the ledger
Public / ledger

XRP Ledger

  • xCIPHR identity anchor
  • DID document reference
  • Signing authorization state

Validates signed transactions

Plaintext wallet seeds and regular private keys do not go to the backend. Encrypted master recovery material can be stored in the cloud; storage alone does not give SciPHR the ability to decrypt it or sign.

Ed25519 wallet signing uses device-held keys. The Secure Enclave P-256 key serves device authorization; it is a separate role.

02 / Follow the authority

Three workflows.
One custody boundary.

Select a workflow to trace the handoffs. Arrows show responsibility, with local operations drawn as a loop.

Workflow 01

Create locally. Anchor publicly.

An identity starts with keys on the device. Cloud storage and ledger records make the encrypted backup discoverable without publishing the keys.

  1. Generate & seal

    Generate the master and regular signing keys. Encrypt the master into a recovery envelope on the device.

    Device · local operation

  2. Store the encrypted backup

    Send the sealed envelope and public identity document to content-addressed storage.

    Device → Services

  3. Authorize onboarding

    The device signs the onboarding transactions; private signing keys remain local.

    Device → Services

  4. Record public references

    Broadcast the signed transactions. The ledger records the identity anchor and authorization state.

    Services → XRP Ledger
The ledger anchors the encrypted envelope and public DID document by reference. It does not store the full backup or DID document.

Workflow 02

Preparation is separate from permission.

The service can construct a transaction. The device decides whether to sign the intent presented to the user.

  1. Prepare the intent

    Return an unsigned transaction for the device to inspect.

    Services → Device

  2. Review & sign locally

    Check the transaction, obtain user approval and sign with the device-held regular key.

    Device · local operation

  3. Verify the signed result

    Return the signed transaction for comparison with the prepared intent.

    Device → Services

  4. Broadcast & validate

    The service broadcasts; the XRP Ledger validates the signature and transaction rules.

    Services → XRP Ledger
The backend checks the signed result against the prepared intent before broadcast. A mismatch is refused.

Workflow 03

Restore authority on the new device.

The recovery-code path needs the user’s written code and an intact encrypted backup. No SciPHR key participates in this restore.

  1. Read the public reference

    Read the NFT’s reference to the encrypted recovery envelope.

    XRP Ledger → Device

  2. Fetch & verify the backup

    Retrieve the encrypted envelope from off-ledger storage and verify its integrity against the public anchor.

    Services → Device

  3. Open the backup locally

    Use the recovery code on the device to unlock the master key and generate a fresh regular key.

    Device · local operation

  4. Replace the regular signing key

    The recovered master signs the key replacement locally. The ledger must confirm the change.

    Device → Services → XRP Ledger

  5. Prove control again

    The fresh regular signing key proves control so the device can be re-registered.

    Device → Services
This is the recovery-code flow. It does not describe a deployed operator-assisted quorum service or promise recovery without the required materials.

03 / Continue in the reference docs

Go deeper at sciphr.io.

Local signingFollow the transaction signing model ↗Cloud architectureUnderstand the hosting boundary ↗Public identity anchorsInspect what is recorded on the ledger ↗Content integrityRead how references are verified ↗

For product details and integration references, use the SciPHR documentation. For the engineering story, read the case study.