Wallet Verification
Wallet verification gates blockchain write operations as a second security layer beyond session authentication, supporting PIN, TOTP, backup codes, and passkey-based verification methods.
Purpose
Wallet verification is a dedicated second factor that protects blockchain write operations. Even with a valid authenticated session, no on-chain transaction executes without the user proving control of their wallet through an independent verification method.
- Doc type: Reference
What you'll find here
- Why wallet verification exists as a layer separate from login authentication
- The three standard verification methods (PIN, TOTP, backup codes)
- Passkey-based verification for hardware key and biometric flows
- How verification integrates into API request handling
Related
Why wallet verification exists
Session authentication proves identity. Wallet verification proves intent and control. Separating these concerns means a compromised session token alone cannot trigger asset transfers, minting, burning, or any other state-changing blockchain operation. The attacker must also possess the user's wallet verification credential --- a value that never travels in the session token and rotates independently.
This separation aligns with defense-in-depth: the platform boundary (authentication) and the chain boundary (wallet verification) use independent control mechanisms. See the security overview for how these layers combine.
Verification methods
Three methods are available. Organizations can enable one or more based on their security posture.
PINCODE
A 6-digit PIN set during initial wallet setup. PIN verification provides quick confirmation for routine transactions where the user is already authenticated and working within the platform.
- Setup: User defines PIN during wallet creation
- Usage: Enter 6-digit code alongside the transaction request
- Trade-off: Fastest verification, lower resistance to shoulder-surfing compared to TOTP
Two-factor authentication (TOTP)
Time-based one-time passwords generated by an authenticator app. Codes rotate every 30 seconds following RFC 6238.
- Setup: User scans a QR code into their authenticator app during wallet setup
- Usage: Enter the current 6-digit code from the authenticator app
- Trade-off: Stronger than PIN (codes expire), requires the user's authenticator device
Backup codes
One-time recovery codes generated during wallet setup. Each code works exactly once and is consumed on use.
- Setup: Platform generates a set of codes during wallet configuration; user stores them securely offline
- Usage: Enter any unused code when other methods are unavailable
- Trade-off: Last-resort recovery mechanism; limited supply, no expiration until used
Passkey-based verification
For organizations requiring hardware-bound or biometric verification, DALP supports passkey-based wallet verification. This uses WebAuthn credentials (hardware security keys, platform biometrics) as the verification factor.
- Enrollment: User registers a passkey credential linked to their wallet
- Verification: The platform issues a WebAuthn challenge; the user responds with their hardware key or biometric
- Advantage: Phishing-resistant; the credential is bound to the platform origin and cannot be replayed
Passkey verification is controlled per authentication source through the walletPasskeyEnabled configuration field.
How verification works in requests
API procedures that trigger blockchain write operations accept the verification method and code in the request body:
| Field | Value | Description |
|---|---|---|
verificationMethod | pincode, totp, or backup | Which method the user is presenting |
verificationCode | 6-digit string or backup code | The verification credential |
The Unified API validates the code before forwarding the operation to the Execution Engine. If verification fails, the request is rejected immediately --- no gas is consumed, no custody provider interaction occurs, and no on-chain state changes.
For passkey verification, the flow uses a WebAuthn challenge-response exchange instead of a code field.
API key sessions bypass verification
When a request is authenticated via API key, wallet verification is not required. The walletVerification field can be omitted from the request body. API keys are already scoped, rate-limited credentials intended for machine-to-machine use. The API key itself serves as the authorization factor, making a second interactive challenge unnecessary and impractical for automated workflows.
Security considerations
- Independent rotation: Wallet verification credentials rotate on their own schedule, independent of session tokens or passwords
- Rate limiting: Failed verification attempts trigger progressive lockout to prevent brute-force attacks
- Audit trail: Every verification attempt (success and failure) logs with user identity and timestamp
- No fallback bypass: There is no administrative override that skips wallet verification; recovery requires backup codes or credential re-enrollment
See also
- Security overview for the full defense-in-depth model
- Signing Flow for how wallet verification fits into the transaction lifecycle
- Authentication for API-level rate limiting and RBAC
TimeLock
TimeLock module enforces minimum holding periods using FIFO batch tracking. Covers configuration, identity-based exemptions, and integration with regulatory templates like MAS Singapore.
Overview
Architecture-level operational posture for the DALP platform covering observability infrastructure, database architecture, and failure mode analysis for enterprise deployments.