> ## 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 Verifier

> Next.js verifier portal for presentation requests, QR flows, and verification history

# Sphyre Verifier

Sphyre Verifier is the verifier-facing application. It lets organizations create presentation requests, show QR codes to holders, track holder responses, verify submitted presentations, and manage reusable request presets.

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

  <Card title="Core Libraries" icon="qrcode">
    `lucide-react`<br />
    `react-qr-code`<br />
    `@yudiel/react-qr-scanner`<br />
    `ethers`, `bip39`, `tweetnacl`
  </Card>
</CardGroup>

## Implemented App Routes

```text theme={null}
/
/onboarding
/login
/seed-phrase-setup
/setup-pin
/recovery
/recover-seed-phrase
/VerifierHome
/RequestCredential
/WaitingForHolder
/VerifierActivity
/PresetConfiguration
/Scan
/VerificationSuccess
/VerificationRejected
/Settings
/Settings/PrivacyPolicy
/Settings/ResultScreenDisplay
/Settings/ReviewOnboarding
/Settings/TermsOfUse
/verify/[ipfsHash]
```

## Main Workflows

* Register or recover a verifier identity.
* Create presentation requests with `POST /api/verifier/requests`.
* Render QR codes for wallet scanning.
* Poll request and presentation status while waiting for holder action.
* Verify submitted presentations with `POST /api/verifier/presentations/:id/verify`.
* View received presentations with `GET /api/verifier/:did/presentations`.
* Manage request presets through `GET/POST /api/verifier/:did/presets`.
* Resolve public credential verification pages through `/verify/[ipfsHash]`.

## Implementation Notes

The frontend keeps API integration in `src/services`, shared UI in `src/components/ui`, and route pages under `src/app`. New UI should follow the existing Tailwind and component patterns.

## Implemented API Calls

```text theme={null}
POST /api/verifier/:did/set-auth
POST /api/verifier/:did/authenticate
GET  /api/verifier/:did/info
PUT  /api/verifier/:did/update

POST /api/verifier/requests
GET  /api/verifier/requests/:id
POST /api/verifier/presentations
GET  /api/verifier/:did/presentations
GET  /api/verifier/presentations/:id
POST /api/verifier/presentations/:id/verify
PUT  /api/verifier/presentations/:id/status
POST /api/verifier/presentations/:id/resend

GET  /api/verifier/:did/presets
POST /api/verifier/:did/presets
GET  /api/verifier/:did/presets/:preset_id
PUT  /api/verifier/:did/presets/:preset_id
DELETE /api/verifier/:did/presets/:preset_id

GET  /api/verifier/verify/ipfs/:ipfs_hash
POST /api/verifier/qr/presentation-request
GET  /api/qr/resolve/:short_id
GET  /api/blockchain/status
```

## Verification Contract

Verifier requests define the purpose, required credentials, requested attributes, optional predicates, and expiration. Holder responses create presentation records. Verification returns:

```json theme={null}
{
  "success": true,
  "verification_result": {
    "is_valid": true,
    "errors": [],
    "prover_did": "did:alyra:holder...",
    "verifier_did": "did:alyra:verifier..."
  },
  "blockchain_verification": {
    "on_chain": true,
    "revoked": false,
    "verified": true
  },
  "status": "verified",
  "auto_approved": true,
  "consent_valid": true
}
```

## Security Notes

* Verifier pages should only show data that was explicitly disclosed by the holder or derived from accepted predicate proofs.
* Presets are reusable request definitions; changing a preset should not mutate already-issued presentation requests.
* Public IPFS verification pages should treat IPFS content as untrusted until Fortro Engine confirms signature, anchor, and revocation status.