Blockchain Wallet RFP Template: Security, UX, and Compliance Questions

Short description: A field-tested RFP template for evaluating blockchain wallet vendors with precise, current questions covering cryptography, key management, account abstraction (ERC‑4337/EIP‑7702), mobile security, interoperability, and global compliance (FIPS 140‑3, EU Travel Rule, OFAC/FinCEN, ISO 27001:2022, SOC 2, PCI DSS v4).

---

How to use this template

• Who it’s for: Product, security, compliance, and procurement leaders at startups and enterprises selecting a wallet SDK, white‑label wallet, or custody/MPC vendor.
• What to do: Copy questions into your RFP, score proposals on “evidence provided,” and request artifacts (certs, policies, attestations) up front.
• Why now: Ethereum’s Pectra (May 7, 2025) activated EIP‑7702, unlocking programmable features for EOAs; the EU Travel Rule has applied since December 30, 2024; NIST finalized PQC standards in August 2024; PCI DSS v4 future‑dated requirements became mandatory in 2025. Your RFP should reflect these realities. (pectra.org)

---

1) Security architecture and cryptography

Ask vendors to be explicit about algorithms, modules, certifications, and migration plans.

• Which cryptographic modules protect keys at rest and in use? Are they validated to FIPS 140‑3, and if not, when? If still FIPS 140‑2, confirm sunset plan before September 22, 2026. Provide certificate numbers and CMVP listing URLs. (csrc.nist.gov)
• Post‑quantum readiness (must‑answer):
  • What is your timeline to support NIST’s PQC standards ML‑KEM (FIPS 203), ML‑DSA (FIPS 204), and SLH‑DSA (FIPS 205)? Do you track the upcoming FN‑DSA (FALCON) standardization? Provide a crypto‑agility plan and key rotation runbook. (csrc.nist.gov)
  • Do you publish a Cryptographic Bill of Materials (CBOM) to inventory algorithms, key sizes, and libraries across apps, services, and HSMs? If so, which format (CycloneDX v1.6+/v1.7)? (cyclonedx.org)
• Threshold cryptography/MPC:
  • Which schemes (e.g., GG18/GG20, FROST) and curves do you support? If using Schnorr/Ed25519 or secp256k1 variants, can you provide protocol details and audits? Note FROST was standardized as RFC 9591 in 2024. (datatracker.ietf.org)
• RNG and entropy:
  • How do you seed entropy on mobile and server? Do you attest hardware‑backed key generation on Android (TEE/StrongBox) and bind to Secure Enclave on iOS? Provide attestation verification procedures. (developer.android.com)
• Data‑in‑transit security:
  • Do you enforce modern TLS cipher suites and certificate pinning? How do you respond to certificate rollover? What is your CVSS v4 scoring process and patch SLO for criticals? (NVD supports CVSS v4 since 2024; use CVSS‑BTE where possible.) (nvd.nist.gov)

What good looks like:

• FIPS 140‑3 certificates (or interim plan) with CMVP links; CBOM/SBOM (CycloneDX 1.6+ or SPDX 3.0) in every release; a documented PQC migration plan targeting ML‑KEM/ML‑DSA for key exchange/signatures; CVSS v4 policy and linkage to CISA KEV. (cyclonedx.org)

---

2) Key management, backups, and recovery

These decisions drive both UX and risk.

• Wallet type coverage:
  • EOAs, smart contract accounts (ERC‑4337), and “Smart EOAs” via EIP‑7702. Can the same UX support all three? (eips.ethereum.org)
• Recovery models you support (check all that apply) and evidence of production usage:
  • Social/guardians, time‑lock with recovery, hardware‑bound passkeys, SLIP‑39 (Shamir mnemonic shares), and BIP‑85 deterministic entropy for sub‑wallets. Provide audit reports for the recovery flow and rate‑limit/lockout specifics. (slips.readthedocs.io)
• Bitcoin policy controls:
  • Do you support output descriptors and Miniscript for safe spending policies (timelocks, multisig, Taproot trees)? Ask for descriptor examples and sign/verify flows (BIP‑380/383/387/379/386). (bips.dev)

What good looks like:

• Documented key ceremonies; tested disaster recovery (RTO/RPO); tamper‑evident backups; optional SLIP‑39 with group thresholds; descriptor‑driven Bitcoin safeties with Miniscript tooling.

---

3) Account abstraction, UX, and programmability

The wallet should meet users where they are today (EOA) and tomorrow (native AA).

• ERC‑4337 support:
  • Which EntryPoint versions are supported? How do you isolate validation (simulation) and handle paymasters? Show bundler compatibility, nonces (key, sequence), and UserOperation receipt tooling. (eips.ethereum.org)
• EIP‑7702 (Pectra) readiness:
  • Since May 7, 2025, Ethereum mainnet supports transaction type 0x04 (authorization list) enabling EOAs to delegate to contract logic. How do you expose batching, gas sponsorship, and least‑privilege delegation (revocation UX)? Provide test vectors and monitoring for authorization drift. (pectra.org)
• Modular smart accounts:
  • Which modular standards are supported—ERC‑7579 (minimal modular interfaces) and/or ERC‑6900? Do you integrate module registries/attestations like ERC‑7484? Provide module audit inventory. (eips.ethereum.org)

What good looks like:

• One codebase that supports EOA, smart contract accounts (4337), and delegated EOAs (7702) with consistent UX (queued actions, session keys, spending limits, gas abstraction) and a pluggable module system (7579 + registry attestations). (eips.ethereum.org)

---

4) Mobile client security and passkeys

Your RFP should demand platform‑native security, not just “we encrypt.”

• OWASP MASVS conformance:
  • Provide the latest MASVS v2 mapping and MASTG tests (profiles instead of L1/L2). Include penetration test results and jailbreak/root resilience. (mas.owasp.org)
• Hardware‑backed keystores and attestation:
  • Android: Do you require StrongBox where present and verify attestation chains (TrustedEnvironment/StrongBox)? Do you bind keys to user‑presence when signing (setUserPresenceRequired)? (developer.android.com)
  • Apple: Do you bind signing to Secure Enclave and support “secure intent” confirmations (e.g., double‑press flow) for high‑risk operations? (support.apple.com)
• Passkeys/WebAuthn:
  • Do you support device‑bound or synced passkeys for wallet unlock / account login? Provide FIDO2/WebAuthn interoperability details and anti‑phishing origin checks. (fidoalliance.org)

What good looks like:

• MASVS v2‑aligned controls, attested hardware‑backed keys, passkey login, biometric gating of large transfers, and secure‑intent confirmations for irreversible actions.

---

5) Compliance, risk, and audits

Ask for certificates and reports—not promises.

• Information security programs:
  • SOC 2 (2017 TSC with 2022 revised points of focus) and ISO/IEC 27001:2022 (Annex A: 93 controls across Organizational/People/Physical/Technological). Provide latest reports and SoA. (aicpa-cima.com)
• Payments:
  • If you process card payments (on‑ramps/fees), confirm PCI DSS v4 compliance, including future‑dated requirements that became mandatory in 2025. Provide AoC/ROC and the compensating controls worksheet. (rsmus.com)
• Sanctions and AML:
  • EU Travel Rule: Confirm compliance with Regulation (EU) 2023/1113 and EBA guidelines (effective Dec 30, 2024). Provide policy on handling incomplete originator/beneficiary data and unhosted wallet interactions. (eur-lex.europa.eu)
  • U.S. OFAC: Provide a sanctions compliance program (screening, IP geo‑controls, wallet screening, chain analytics) aligned to OFAC’s 2021 guidance for virtual currency. (ofac.treasury.gov)
  • U.S. FinCEN: Explain whether the business model is an MSB/money transmitter; cite FIN‑2019‑G001; describe Travel Rule controls and stance on CVC mixing NPRM (Oct 19, 2023). (fincen.gov)
• SBOMs and supply chain:
  • Deliver SBOMs per SPDX 3.0 and/or CycloneDX; include CBOM for cryptography inventory. Provide signed attestations and vulnerability disclosure program using CVSS v4 for severity. (linuxfoundation.org)

What good looks like:

• Current SOC 2/ISO 27001 certs, PCI DSS v4 AoC (if applicable), Travel Rule playbooks for cross‑jurisdiction transfers, OFAC‑aligned sanctions controls, and machine‑readable SBOM/CBOM with signed attestations.

---

6) Privacy, telemetry, and data governance

Wallets should minimize data and prove it.

• Data minimization:
  • List all PII collected (device IDs, IPs, crash logs). Provide retention schedules and regional storage locations.
• Observability without deanonymization:
  • How do you monitor fraud and performance without linking on‑chain identities to PII unless necessary? Do you provide opt‑outs and regional controls (GDPR/CCPA awareness)?
• Incident response:
  • Provide the IR plan, breach notification SLAs, and examples of past incident postmortems. Confirm CVSS v4 usage and CISA KEV tracking. (first.org)

---

7) Interoperability and developer UX

Reduce integration risk with standards, not proprietary glue.

• Ethereum connectivity in browsers:
  • Do you implement EIP‑6963 for multi‑injected provider discovery to avoid “last‑in wins” issues? (eip.info)
• Sign‑in and delegated capabilities:
  • Do you support SIWE (EIP‑4361) and ReCaps (EIP‑5573) for scoped authorization flows? Provide anti‑phishing domain binding. (eips.ethereum.org)
• Tooling:
  • CLI/SDKs with type‑safe APIs; testnets and simulators for 4337/7702; sample apps for iOS/Android/web; observability hooks; error taxonomies and localization.

What good looks like:

• Clean SDKs, SIWE + ReCaps flows, EIP‑6963 support, and reference implementations for 4337/7702 with robust test suites. (docs.erc4337.io)

---

8) Platform‑specific hardening

Demand concrete platform guarantees.

• Android:
  • Proof you verify StrongBox/TEE attestation roots and

    attestationSecurityLevel

    . Provide policy for devices lacking hardware‑backed keystore. (developer.android.com)
• Apple platforms:
  • Secure Enclave usage, secure intent, and any Secure Element/NFC integrations for credential storage on iOS 18.1+ (if relevant). (support.apple.com)
• Desktop:
  • Key storage isolation, hardware token support (FIDO2), and anti‑tampering protections.

---

9) Operational excellence

• SRE and change management:
  • Describe zero‑downtime deployment practices, canarying, and automated rollbacks for critical wallet services.
• Vulnerability management:
  • SLA for criticals (CVSS v4 “Critical” in CVSS‑BTE context), cadence for routine patching, and third‑party library update policy. (first.org)
• Responsible disclosure:
  • Public policy, submission process, and bounty ranges; how quickly do you issue advisories and hotfixes?

---

10) Evidence checklist (attach with proposal)

Request these artifacts with the RFP response to prevent “hand‑wavy” answers:

• Certifications/reports:
  • FIPS 140‑3 certificate numbers (or FIPS 140‑2 with sunset plan by Sep 22, 2026). SOC 2 (latest), ISO 27001:2022 certificate/SoA, PCI DSS v4 AoC (if applicable). (csrc.nist.gov)
• Compliance playbooks:
  • EU Travel Rule SOPs and EBA guideline mapping; OFAC sanctions procedures; FinCEN MSB determination and Travel Rule controls; policy on CVC mixing NPRM monitoring. (eba.europa.eu)
• Security docs:
  • SBOMs (SPDX 3.0/CycloneDX), CBOM, cryptography‑agility roadmap for ML‑KEM/ML‑DSA/SLH‑DSA; mobile MASVS v2 mapping; pen test and code audit reports (including threshold/MPC protocols). (linuxfoundation.org)
• Ethereum AA evidence:
  • 4337 support matrix (EntryPoint, bundlers, paymasters), EIP‑7702 test coverage, modular smart account standard (ERC‑7579/6900) adoption and module registry attestations. (eips.ethereum.org)
• Bitcoin policy:
  • Example descriptors/Miniscript policies with reviewable test transactions. (bips.dev)

---

Example RFP questions (copy/paste)

Security and crypto

• List all cryptographic libraries and versions. Provide CBOM/SBOM links and your process to transition RSA/ECC to NIST PQC (ML‑KEM/ML‑DSA/SLH‑DSA). What is your cutover plan for hybrid key exchange and signature algorithm agility? (csrc.nist.gov)
• Provide CMVP certificate numbers for HSMs/SDK crypto modules. Confirm readiness for the FIPS 140‑2 sunset in September 2026. (csrc.nist.gov)
• Describe threshold/MPC design (e.g., FROST/secp256k1) and key share storage. Include rate‑limit and tamper‑evidence controls. (datatracker.ietf.org)

Account abstraction and UX

• For ERC‑4337, provide UserOperation simulation strategy, replay protection (nonce lanes), and paymaster risk controls. For EIP‑7702, show how users can review, time‑bound, and revoke delegations. (eips.ethereum.org)
• Which modular smart account standards (ERC‑7579/6900) do you support, and how do you validate third‑party modules (ERC‑7484 registry attestations)? (eips.ethereum.org)

Mobile and passkeys

• Demonstrate hardware‑backed key generation/attestation on Android (TEE/StrongBox), Secure Enclave usage on Apple, and passkey/WebAuthn sign‑in with phishing‑resistant origin checks. Provide MASVS v2 mapping. (developer.android.com)

Compliance

• Provide: SOC 2 report, ISO 27001:2022 certificate, PCI DSS v4 AoC (if processing cards). Share Travel Rule gap analysis and OFAC/FinCEN policies (including CVC mixing NPRM monitoring). (bdo.com)

Interoperability

• Confirm EIP‑6963 support for multi‑injected providers; SIWE (EIP‑4361) and ReCaps (EIP‑5573) for delegated capabilities; sample apps for 4337/7702. (eip.info)

Bitcoin controls

• Provide example descriptors and Miniscript policies for spending conditions, with Taproot multisig (BIP‑387) and testing methodology. (bips.dev)

---

Emerging best practices to require (2025 edition)

• Treat PQC as a program, not a project:
  • Maintain a CBOM; plan for ML‑KEM/ML‑DSA/SLH‑DSA; test hybrid handshakes; align with CNSA 2.0 timelines as applicable. (csrc.nist.gov)
• Embrace native AA:
  • Design UX that spans EOAs, 4337 smart accounts, and EIP‑7702 delegated EOAs; reduce gas friction with paymasters; implement session keys and rate limits via modular accounts. (eips.ethereum.org)
• Ship SBOM/CBOM every release:
  • Use SPDX 3.0 or CycloneDX 1.6+ with signed attestations; tie vulnerabilities to CVSS v4 and CISA KEV; publish remediation timelines. (linuxfoundation.org)
• Travel Rule‑ready infrastructure:
  • Implement data collection, validation, and exception handling per EBA guidelines; ensure sanctions screening and wallet analytics don’t over‑collect PII. (eba.europa.eu)
• Mobile hardening by default:
  • MASVS v2 mapping, hardware‑attested keys, secure‑intent confirmations for high‑risk actions, and jailbreak/root risk handling. (mas.owasp.org)

---

Brief example: scoring a vendor answer

• Weak: “We’re preparing for PQC and follow best practices.”
• Strong: “We publish a CBOM (CycloneDX 1.7) per release; have a 12‑month migration roadmap to ML‑KEM and ML‑DSA; maintain hybrid KEM for backward compatibility; and rotate server keys quarterly. See attached CBOM, PKI runbook, and test harness results.” (cyclonedx.org)

---

Final note

This RFP template favors verifiable evidence. Ask for artifacts (certificates, SBOM/CBOM, audits, test vectors) and production references. Vendors that can’t produce them should not be piloted—no matter how polished the demo.