> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sphyre.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Sphyre ALV

> Next.js holder wallet for DID, credential, consent, and presentation flows

# Sphyre ALV

Sphyre ALV is the holder wallet. It is implemented as a Next.js App Router application and communicates with Fortro Engine for wallet registration, credentials, presentation approvals, consent records, and activity history.

<CardGroup cols={2}>
  <Card title="Technology" icon="code">
    **Framework:** Next.js `15.3.1`<br />
    **React:** `19.0.0`<br />
    **Language:** TypeScript<br />
    **Styling:** Tailwind CSS `3.3.5`
  </Card>

  <Card title="Core Libraries" icon="box">
    `bip39`<br />
    `tweetnacl`<br />
    `ethers`<br />
    `qrcode`, `qrcode.react`, `jsqr`
  </Card>
</CardGroup>

## Implemented App Routes

```text theme={null}
/
/onboarding
/create-wallet
/setup-pin
/unlock
/recovery
/ReviewOnboarding
/SSIWalletIdentity
/SSIWalletActivity
/MyCredentials
/CollectCredentials
/CredentialRequest
/RequestCredential
/CredentialSelection
/CredentialConfirmation
/PresentCredential
/ShareCredentials
/AttributeConsent
/ConsentManagement
/CachedContexts
/QRScanner
/UserProfile
/ChangePIN
/VerificationSuccess
/VerificationFailure
/PrivacyPolicy
/TermsOfUse
```

## Responsibilities

* Create or recover a wallet from a BIP39 seed phrase.
* Protect local wallet state with a PIN-based unlock flow.
* Derive and use holder DID keys for API authentication and presentation approval.
* Fetch and display credentials from `GET /api/wallet/:did/credentials`.
* Request credentials through the wallet credential-request endpoints.
* Scan credential offers and presentation requests.
* Approve or reject presentation requests.
* Manage consent records and revocation.

## API Client Surface

The application keeps API calls in `src/lib/api` and `src/services`. Important service areas include authentication, wallet operations, issuer lookup, verifier flows, and consent management.

## Runtime Data Boundary

| Area        | Local responsibility                                                                                           | Backend responsibility                                                                                                     |
| ----------- | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Wallet keys | Generate and recover BIP39 seed material, derive DID keys, protect local unlock state with PIN flow.           | Store user profile, wallet metadata, encrypted seed backup endpoints, and challenge verification state.                    |
| Credentials | Render active credentials, prepare selected attributes, request anonymous proofs, and submit holder decisions. | Persist credential records, filter revoked/expired credentials, serve evidence/IPFS metadata, and verify blockchain state. |
| Consent     | Show verifier purpose, selected data categories, and revocation actions.                                       | Persist consent records, enforce expiration policy, and optionally anchor grant/revoke actions on-chain.                   |
| QR flows    | Scan and route credential offers or presentation requests.                                                     | Resolve short URLs and create offer/request payloads through `/api/qr/*` and wallet/verifier routes.                       |

## Implemented API Calls

```text theme={null}
POST /api/auth/login
POST /api/auth/register
POST /api/auth/create-wallet
POST /api/auth/login-wallet
POST /api/auth/wallet/encrypted-seed
POST /api/auth/wallet/encrypted-seed/get

GET  /api/wallet/:did
GET  /api/wallet/:did/credentials
GET  /api/wallet/:did/activities
GET  /api/wallet/:did/credential-requests
POST /api/wallet/:did/credentials/import
POST /api/wallet/:did/credentials/share
POST /api/wallet/:did/credentials/:credential_id/anonymous-proof
POST /api/wallet/:did/evidence/upload
GET  /api/wallet/:did/consents
POST /api/wallet/:did/consents/:consent_id/revoke
DELETE /api/wallet/:did/consents/:consent_id

POST /api/wallet/credential-request
GET  /api/wallet/:did/credential-request/:request_id
GET  /api/wallet/presentation-requests/:holder_did/pending
POST /api/wallet/presentation-requests/:request_id/approve
POST /api/wallet/presentation-requests/:request_id/reject

GET  /api/issuer/templates
GET  /api/issuer/templates?schema_id=:schema_id
GET  /api/issuer/:did/templates/:template_id
GET  /api/issuer/:did

GET  /api/verifier/:did/info
GET  /api/verifier/verify/ipfs/:ipfs_hash
POST /api/verifier/presentations

GET  /api/wallet/offers/:offer_id/challenge
POST /api/wallet/offers/:offer_id/accept
GET  /api/qr/resolve/:short_id
```

## Security Notes

* Seed phrase and PIN handling stay client-side; backend authentication is DID challenge/JWT based.
* The wallet sends explicit holder decisions for credential requests, presentation approvals, and consent revocation.
* Credential displays should treat `credential_preview_encrypted`, anonymous credential fields, and evidence metadata as sensitive application data.

## Extension Points

Future wallet capabilities should be added to this page only after the corresponding route, service, and UI flow exist in the codebase.