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

How to use this template

Who it's for: This is designed for people working in product, security, compliance, and procurement, whether you're at a startup or a large corporation. If you're looking for a wallet SDK, a white-label wallet, or a custody/MPC vendor, this is definitely for you!
What to do: Take these questions and toss them into your RFP. After that, don’t forget to evaluate the proposals based on the "evidence provided." Oh, and make sure you ask for stuff like certificates, policies, and any attestations as soon as you can. It’s better to get those things sorted out early!
Why now: Exciting times ahead! Ethereum’s Pectra just launched on May 7, 2025, and it’s already made waves by activating EIP‑7702. This update is bringing some awesome programmable features to EOAs, making things more interesting! Oh, and just a heads-up: the EU Travel Rule has been in effect since December 30, 2024. Also, NIST finished up its PQC standards back in August 2024. Looking ahead, starting in 2025, the new requirements for PCI DSS v4 are going to be mandatory. So, definitely stay on top of that! Just a heads up--make sure your RFP reflects all these updates! (pectra.org).

1) Security architecture and cryptography

Don't forget to chat with the vendors about their algorithms, modules, certifications, and migration plans. It's super important to get a clear picture of how everything works!

Cryptographic Modules
Hey there! I'm curious about the cryptographic modules you're using to protect your keys, whether they're stored or actively in use. Are they validated to FIPS 140‑3? If not, do you have a timeline for when you plan to make that transition? And if you’re still on FIPS 140‑2, could you let me know your sunset plan before September 22, 2026? It’d also be great if you could share the certificate numbers and the links for the CMVP listings. Thanks! (csrc.nist.gov).
Post‑Quantum Readiness (must-answer)
Hey there! Just wanted to pick your brain about your plans for rolling out NIST’s PQC standards like ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). Any timeline you’re working with? Also, are you following along with the FN-DSA (FALCON) standardization news? It’d be great to hear about your crypto-agility strategy and how you plan to handle key rotations! Thanks! (csrc.nist.gov). Hey there! Quick question for you--do you happen to have a Cryptographic Bill of Materials (CBOM)? You know, that handy list that breaks down the algorithms, key sizes, and libraries that you're using in your apps, services, and HSMs? If you do, I'm curious about the format you've got it in. Is it CycloneDX v1, or something else? Thanks! 6+/v1. 7)? (cyclonedx.org).
Threshold Cryptography/MPC
Hey there! I’d love to know what schemes you’re supporting, like GG18/GG20 or FROST. If you're diving into Schnorr/Ed25519 or the secp256k1 variants, could you fill me in on the protocol details and any audits you might have? Oh, and just so you know, FROST got its official stamp of approval as RFC 9591 back in 2024!
(datatracker.ietf.org).
RNG and Entropy
So, how do you go about seeding entropy on mobile devices and servers? I'm curious if you rely on hardware-backed key generation for Android, such as TEE or StrongBox, and if you tie that to the Secure Enclave on iOS. Also, could you share your process for verifying that attestation? Thanks! (developer.android.com).
Data-in-Transit Security
Hey there! Quick question for you: Are you guys using modern TLS cipher suites and doing any certificate pinning? I’m really curious about how you handle certificate rollovers too. Also, when it comes to scoring, how do you calculate your CVSS v4 scores? And what’s your patch service level objective (SLO) for critical vulnerabilities?

By the way, just a heads up--NVD has been backing CVSS v4 since 2024, so definitely try to use CVSS-BTE whenever you can! Check it out here: nvd.nist.gov.

What Good Looks Like

Make sure you’ve got your FIPS 140-3 certificates ready, or at least a solid interim plan in place. Also, don’t forget to include the CMVP links! Hey there! Just a quick reminder: for every release, don't forget to include a CBOM or SBOM that’s formatted in CycloneDX 1. It’s super important! Thanks! 6+ or SPDX 3. 0. Make sure you've got a solid PQC migration plan in place that focuses on using ML-KEM and ML-DSA for your key exchange and signatures. It's important to keep these things documented!

So, let's wrap things up by putting a CVSS v4 policy into action and connecting it with CISA KEV. If you want to dive deeper into CycloneDX, you can find more info here. Happy reading!

2) Key management, backups, and recovery

These choices really influence how users feel about the experience and can also affect the level of risk they take on.

Wallet type coverage: We're diving into EOAs, smart contract accounts (shoutout to ERC-4337 for making that possible), and what we're calling "Smart EOAs" thanks to EIP-7702. Can the same user experience really work for all three? Check it out here: eips.ethereum.org.
Which recovery models do you support? (Feel free to check all that fit!) Also, include how you've used these models in real-world production settings. We've got a bunch of recovery models lined up for you. There's the social/guardians approach, time-lock recovery, hardware-bound passkeys, and then there's SLIP-39 that works with those Shamir mnemonic shares. Oh, and we can't forget BIP-85, which helps with deterministic entropy for sub-wallets. Pretty cool stuff! Hey, just a quick reminder to send over those audit reports for the recovery flow. Also, don’t forget to include your rate-limit and lockout details! You can find more info at slips.readthedocs.io. Thanks!
Bitcoin policy controls: Hey, just wanted to check if you're all set up to handle output descriptors and Miniscript for making secure spending policies like timelocks, multisig, and Taproot trees? If you are, I’d love to see some examples of those descriptors. Also, could you share some details about how your sign/verify processes work with BIP-380, 383, 387, 379, and 386? Thanks! (bips.dev).

What good looks like:

Important ceremonies that have been thoroughly documented.
Put the disaster recovery plans to the test, focusing on the recovery time objectives (RTO) and recovery point objectives (RPO).
Backups that show evidence of tampering. You can choose to use SLIP-39, which lets you set up group thresholds if you want.
Using Miniscript tools for Bitcoin safety with descriptor-driven approaches.

3) Account abstraction, UX, and programmability

The wallet should be able to sync up with users as they are right now (you know, their Externally Owned Accounts) while also being set to embrace what's coming next (like native Account Abstraction). It's all about striking that perfect balance!

ERC‑4337 Support: Hey! So, let’s break down the different versions of EntryPoint we’re chatting about. How do you handle validation--like with simulations? And what’s the deal with managing paymasters? Also, it’d be great if you could walk us through how bundler compatibility fits into all this. Oh, and don’t forget to touch on nonces (you know, the key and sequence stuff) and the tools you use for UserOperation receipts. Looking forward to your insights! You can find all the details over at eips.ethereum.org. Take a look!
EIP‑7702 (Pectra) Readiness:
Since May 7, 2025, the Ethereum mainnet has been buzzing with transaction type 0x04, known as the authorization list. It's pretty neat because it allows externally owned accounts (EOAs) to hand off tasks to contract logic. So, how do you actually turn batching, gas sponsorship, and least-privilege delegation into a reality? It’s all about getting the details right and ensuring a seamless revocation experience for users.

To start, think about crafting some solid test cases to make sure everything runs smoothly. It’ll help you see how these features work together in real-world scenarios. And don’t forget to keep a close eye on monitoring--watch for any shifts in authorization that might pop up, because you want to keep everything on track.

It's a bit of a juggling act, but with the right approach, you can definitely make it happen! If you want more details, check out their site at pectra.org.

Modular Smart Accounts: Hey there! Just curious, which modular standards are you considering? Are we talking about ERC‑7579 for the minimal modular interfaces, or are you leaning towards ERC‑6900? Also, any thoughts on bringing in module registries or attestations like ERC‑7484? It’d be super helpful if you could share a quick overview of your module audit inventory too. Thanks! For more info, check out the details over at eips.ethereum.org. It’s a great resource!

What good looks like:

We've got this awesome single codebase that effortlessly handles regular accounts (EOA), smart contract accounts (4337), and even delegated EOAs (7702). Plus, it makes sure that the user experience stays smooth and consistent throughout. This includes some cool features like queued actions, session keys, spending limits, and gas abstraction, all neatly packaged in a pluggable module system (7579 + registry attestations). Take a look at it here: (eips.ethereum.org). You might find it really interesting!

4) Mobile client security and passkeys

When you're putting together your RFP, make sure to really highlight the importance of platform-native security. Avoid those generic phrases like “we encrypt.” They don't tell you much and can leave you in the dark about how secure things actually are. It’s better to dig deeper and get specific about what security measures are in place. ”.

OWASP MASVS Conformance: Don't forget to include the newest MASVS v2 mapping and the MASTG tests. Just a heads up, think more about the profiles instead of just focusing on L1/L2. Make sure to include the results from your penetration tests and how effectively you manage jailbreak and root resilience. It'll really help paint a clearer picture! Feel free to take a look at the details over at mas.owasp.org. You'll find a ton of useful info there!
Keystores with Hardware Support and Attestation: Hey there! So, quick question--are you using StrongBox whenever it's an option? It's pretty handy! Also, do you make sure to check those attestation chains, like TrustedEnvironment and StrongBox? And one more thing--when you're signing, are you binding keys to user presence by using setUserPresenceRequired? If you want to dive deeper into this, check out the details on developer.android.com. Happy coding!
Apple: Have you linked signing to the Secure Enclave yet? And what about those “secure intent” confirmations, like the double-press flow for those extra sensitive tasks? You’ll want to dive into the details here: (support.apple.com).
Passkeys/WebAuthn: Hey there! Just checking in--do you have your device-bound or synced passkeys ready for things like unlocking your wallet and logging into your accounts? It’s super important to share how you manage FIDO2/WebAuthn interoperability and what steps you take to handle those anti-phishing origin checks. Learn more at (fidoalliance.org).

What good looks like:
We've got some cool controls in place that match up with MASVS v2. This includes hardware-backed keys that are double-checked, easy passkey logins, and biometric checks for those larger transactions. Plus, we make sure there are secure confirmation steps for important actions that you definitely don’t want to mess up.

5) Compliance, risk, and audits

Ask for Certificates and Reports--Not Just Promises

When you're diving into any kind of service or product, it's really crucial to make sure you're getting the genuine article. This means you should definitely ask for certificates and reports rather than just taking someone's word for it. Here’s why:.

Why Certificates & Reports Matter

1. Proof of Quality: Certificates are like a badge of honor, showing you that a service or product really measures up to specific standards. They're not just words that don't mean anything!

2. Accountability: Reports usually break down the methods and outcomes, making sure companies stay accountable for what they say.

3. Building Trust: When you ask for documents, it really signals that you care about getting things right. This helps create a sense of trust between you and the other person.

What to Request

When you're on the hunt for the info you need, think about asking for:

Quality Assurance Certificates: These certificates make sure that the product or service meets certain industry standards.
Compliance Reports: These are basically documents that show you're following all the necessary laws and regulations.
Performance Reports: Check out the data on how the product or service really performs in everyday situations.

How to Ask

When you get in touch, just keep it simple and to the point. You could say something like this:

Hey [Name], thanks for all the info you've sent my way! I really appreciate it. Could you do me a favor and send over those relevant certificates and reports? That would be super helpful for me to make a well-informed decision. Thanks! ".

Having the right paperwork in order can really save you a lot of trouble later on! Seriously, don't hesitate! Just go ahead and ask for what you need.

Information Security Programs: When you're diving into SOC 2, just remember to stick to the 2017 Trust Services Criteria and keep an eye on those updated focus points from 2022. It's important to stay on top of those changes! Oh, and make sure you keep ISO/IEC 27001:2022 in mind! It’s packed with 93 controls that cover everything from organizational stuff to people, physical security, and technology. It’s pretty comprehensive! Could you send me the latest reports and the Statement of Applicability (SoA) when you get a chance? Thanks! Feel free to take a look at it here: (aicpa-cima.com).
Payments: So, if you’re dealing with card payments--whether it’s for those on-ramps or fees--you’ll want to make sure you’re all good with PCI DSS v4 compliance. It’s super important to keep everything secure! Make sure you remember to factor in those upcoming requirements that everyone will need to meet by 2025. They’re pretty important! Could you send over the Attestation of Compliance (AoC), the Report on Compliance (ROC), and the worksheet for the compensating controls? Thanks a bunch! If you're looking for more details, just hop over to this link: (rsmus.com). It's packed with useful info!
Sanctions and AML:
EU Travel Rule: Just a heads up to stay compliant with Regulation (EU) 2023/1113 and the EBA guidelines. These will kick in on December 30, 2024, so it's a good idea to start getting things in order now! It’s really important to have a clear policy in place for dealing with incomplete data from originators or beneficiaries. Also, don’t forget about how you handle any interactions with unhosted wallets. Just make sure you have all that covered! If you’re looking for more info, check out this link: eur-lex.europa.eu. It’s got all the details you need!
**U.S. OFAC: Could you share some details about your sanctions compliance program? I’m particularly interested in things like how you handle screening, IP geo-controls, wallet checks, and chain analytics. Thanks! This should line up with the guidance from OFAC that came out in 2021, especially when it comes to virtual currency. If you want more details, just check out this link: ofac.treasury.gov. It’s all there!
**U.S. FinCEN: Just reach out and tell us if your business model fits the bill for a Money Services Business (MSB) or a money transmitter! Sure! When it comes to the FIN-2019-G001 guidance, we’ve put some solid controls in place to make sure we comply with the Travel Rule. This means we’ve established procedures for collecting and sharing necessary sender and receiver information when you're sending money, especially for transactions involving cryptocurrencies.

As for the CVC mixing Notice of Proposed Rulemaking from October 19, 2023, we have a pretty clear stance. We believe that transparency and accountability are crucial in the crypto space, so we’re all for measures that help keep things above board. We think the proposed rules could be an important step forward in ensuring everyone plays by the same set of rules. Overall, we're committed to adapting our strategies to align with these guidelines and to create a safer environment for users. Check out this link for more info: (fincen.gov). It really has some helpful details!

SBOMs and Supply Chain: So, let’s talk about Software Bill of Materials (SBOMs) and their role in supply chains. They’re super important for keeping everything organized and secure. An SBOM gives you a clear picture of all the components in your software, making it easier to identify any vulnerabilities. This transparency helps companies manage risks better and ensure they’re using safe and reliable software throughout their operations. Overall, SBOMs are becoming a must-have in today’s tech landscape, especially as supply chains get more complex. Could you send over the SBOMs that comply with SPDX 3? Thanks! Make sure you’re all set with the 0 and/or CycloneDX standards, and remember to throw in the Component Bill of Materials (CBOM) for your cryptography inventory. It’s super important! Don't forget to add those signed attestations and your vulnerability disclosure program. And when it comes to figuring out the severity, make sure you're using CVSS v4 for that! If you’re looking for more tips and information, check out this link: (linuxfoundation.org). It’s a great resource!

What good looks like: Make sure you have the latest SOC 2 and ISO 27001 certifications in your toolkit. If it’s relevant for you, don’t forget the PCI DSS v4 AoC as well. It’s also a good idea to have some playbooks ready for dealing with cross-jurisdiction transfers under the Travel Rule. Plus, having strong sanctions controls that align with OFAC is crucial. And let’s not overlook the importance of a machine-readable SBOM/CBOM and those signed attestations to round things out!

6) Privacy, telemetry, and data governance

Wallets should really aim to keep their data light and only store what's necessary. It’s all about proving what you have without overloading on information!

Data Minimization:
Alright, let's break down the personal info we're collecting so we have a good understanding of it all. So, we’re talking about stuff like device IDs, IP addresses, and crash logs. Could you give me the lowdown on the retention schedules and let me know where we're keeping this data on a regional level? Thanks!
Observability Without Deanonymization: Okay, so here’s the deal: how do we watch out for fraud and keep tabs on performance without tying on-chain identities to personal info unless it's really necessary? Are there any ways for people to opt out, and do we have any regional controls set up? It’s super important that we stay in line with GDPR and CCPA rules, right?
Incident Response: Could you send over the incident response plan? Also, I’d love to see the SLAs we have for breach notifications. And if you could share any examples of how we've dealt with incidents before, that would be super helpful! Thanks! Just to double-check, we’re using CVSS v4 and staying on top of CISA KEV tracking, right? (first.org).

7) Interoperability and developer UX

Reduce Integration Risk with Standards, Not Proprietary Glue

When you're thinking about integration, it's best to stick with the widely accepted standards. They just make life a lot easier! Sticking to proprietary solutions can really cause some major headaches later. You might find yourself dealing with vendor lock-in or running into compatibility problems that just don’t make life easy. Let me share why getting on board with standards really makes sense.

Why Standards Matter

Following established standards can really help reduce risks in a few key ways:

Interoperability: When systems use the same standards, they can easily talk to each other. This means less hassle for you and a lot of time saved!
Flexibility: Using common standards is a game changer! It lets you easily switch out parts or do upgrades without having to start all over again.
Future-Proofing: Standards change pretty often, which means you’ll have a better chance of staying relevant without having to do a ton of updates all the time.

Key Benefits

Check out some of the benefits of opting for standards instead of going with proprietary solutions:

1. Lower Costs: Say goodbye to those steep fees that usually come with proprietary tech! 2. Better Support: Thanks to a big community rallying around the popular standards, it’s way easier to track down answers and resources when you need them. 3. Lower Risk: The more people use a standard, the more likely it is to stick around and get the support it needs over time.

Conclusion

So, when you're dealing with integration challenges, it's a smart move to prioritize flexibility and durability by opting for established standards. Avoiding proprietary glue not only cuts down on your risks but also leads to smoother and more efficient integrations.

Connecting Ethereum in Your Browser: Hey, just checking in--are you using EIP‑6963 to tackle that multi-injected provider discovery? It's super important for avoiding those annoying "last-in wins" issues. Trust me, it makes a big difference! Check it out here.
Signing In and Delegated Features: Hey there! Just wondering if you support SIWE (EIP-4361) and ReCaps (EIP-5573)? They’re pretty crucial for scoped authorization flows, and I can’t stress enough how important it is to include anti-phishing domain binding as well. If you're looking for more details, check this out here. It's got everything you need!
Tooling: So, let's dive into the world of CLI and SDKs that offer type-safe APIs. These tools are super handy because they come with testnets and simulators specifically designed for 4337 and 7702 functionalities. It's all about making the development process smoother and more reliable! It would be awesome to have some sample apps for iOS, Android, and web! Hey, make sure you remember to include those observability hooks, error taxonomies, and don’t skip out on localization to tie everything together!

What good looks like: Alright, so we've got some well-structured SDKs that make things super easy to navigate. The SIWE and ReCaps flows are really seamless too! Plus, there's support for EIP‑6963, which is awesome. And if you need it, there are reference implementations for 4337 and 7702, all bundled up with great test suites to help you out. (docs.erc4337.io).

8) Platform‑specific hardening

Demand Concrete Platform Guarantees

When you're venturing into the realm of concrete platforms, it's super important to have some reliable guarantees supporting you. Here are a few things to keep an eye on:

1. Quality Assurance: It's really important that the platform has some solid quality checks in place to ensure everything runs smoothly. It's important to make sure that the materials and construction are up to par with industry standards.

2. Performance Metrics: Make sure you find some solid performance guarantees. These will give you a good idea of what to expect regarding load capacity and how well things will hold up over time.

3. Warranties: Make sure to check in on warranties! They're super important. A solid warranty can really help ease your mind because you know you're protected if anything goes south.

4. Customer Support: Make sure you’ve got a solid support team on standby to tackle any questions or issues that might come your way. They’re here to help!

5. Flexibility: Try to find platforms that can easily adjust to what you really need. When it comes to ramping up or adding new features, it’s all about having choices that can keep up with you as you grow.

6. Feedback and Reviews: Taking a peek at what other users are saying can really help you get a feel for how reliable a platform is and how well it performs overall. Feel free to dive into those reviews! They're super helpful!

Having the right guarantees can really change the game when it comes to making sure your concrete platform works the way you want it to. No rush! Just take your time, do some digging, and make sure to choose wisely!

Android: Hey, just a heads up--don't forget to double-check those StrongBox/TEE attestation roots! Also, it’s a good idea to take a look at the attestationSecurityLevel while you’re at it. Make sure you have a solid policy for devices that lack a hardware-backed keystore. It’s really important to address this upfront! If you want to dive deeper into this topic, feel free to check it out here. Happy reading!
Apple platforms: Hey there! Just take a moment to check out how you’re making use of the Secure Enclave, especially when it comes to secure intents and any Secure Element or NFC configurations for storing your credentials on iOS 18. It’s super important to keep everything secure! 1 and any version that comes after that, if it's relevant. If you want to dive deeper into this, you can check out more details here.
Desktop: Alright, let’s make sure we keep things secure by really honing in on key storage. We should definitely support hardware tokens like FIDO2, and let’s not forget to put some strong anti-tampering measures in place. That way, we can keep everything locked down tight!

9) Operational excellence

SRE and Change Management:
So, let's talk about Site Reliability Engineering (SRE) and how it fits into change management. SRE focuses on keeping systems reliable while embracing changes that enhance performance and user experience. It's all about finding that sweet spot between stability and innovation. When changes are managed properly, they can lead to better service delivery and satisfied users. Just remember, the key is to approach changes thoughtfully, using data and insights to guide your decisions. That way, you can minimize risks while still making those necessary updates that keep everything running smoothly. Let's chat about how we can keep everything running smoothly with some cool techniques like zero-downtime deployments, canary releases, and automated rollbacks for our wallet services. It's all about making sure our users have a seamless experience, right?
Vulnerability Management: Let’s lay down some ground rules here. First off, what’s our SLA for critical vulnerabilities? You know, the ones that hit that “Critical” level in the CVSS v4 and CVSS-BTE contexts. Also, how often are we pushing out those routine patches? And what’s our strategy for keeping our third-party libraries up to date? If you want to dive deeper into this, you can find more details over at first.org.
Responsible Disclosure: Let's take some time to lay out our public policy, explain how submissions will work, and talk about the different bounty ranges we’re offering. By the way, how quickly are we able to roll out advisories and hotfixes?

10) Evidence checklist (attach with proposal)

When you're responding to the RFP, make sure to ask for these artifacts. It'll help keep things clear and prevent any vague or “hand-wavy” responses.

Certifications/reports: Hey! Take a look at our FIPS 140‑3 certificate numbers. If you're interested in FIPS 140‑2, we've got that too, but it’s on a sunset plan that wraps up by September 22, 2026. We've got the newest SOC 2 reports on hand, along with the ISO 27001:2022 certificate and the Statement of Applicability. And if it matters to you, we've also got the PCI DSS v4 AoC ready to go! If you’re looking for more details, check this out: (csrc.nist.gov).
Compliance playbooks: Hey there! We've put together some really solid standard operating procedures for the EU Travel Rule and mapped out the guidelines from the EBA. You'll also get to see our processes for handling OFAC sanctions, figuring out FinCEN's MSB determinations, and keeping track of Travel Rule controls. Plus, we've got our policy on monitoring CVC mixing NPRM included, too! If you’re looking for more info, just check out this link: eba.europa.eu. There's a ton of details waiting for you there!
Security docs: Hey there! Just a heads up, we have some important documents, including SBOMs (that's the Software Bill of Materials) in SPDX 3 format. Okay, so we’ve got CycloneDX, the CBOM, and a roadmap that’s all about making cryptography more flexible, especially when it comes to ML-KEM, ML-DSA, and SLH-DSA. It's a lot to unpack, but basically, these things are super important for keeping our data safe and sound as technology keeps evolving. Hey, just a quick reminder about our mobile MASVS v2 mapping! Also, make sure to check out the pen test and code audit reports that go over the threshold/MPC protocols. You won’t want to miss those! Take a look at this link: linuxfoundation.org. It’s got some pretty interesting info!
Ethereum AA evidence: We've put together this pretty cool 4337 support matrix that covers everything from EntryPoint to bundlers and paymasters. Check it out! You’ll find all the details on EIP-7702 test coverage, the rise of the modular smart account standard (that’s ERC-7579/6900 for those in the know), and some info on module registry attestations right here: (eips.ethereum.org).
Bitcoin policy: Take a look at our example descriptors and Miniscript policies, plus some test transactions you can go over. If you want to dive deeper, check it out here: bips.dev. There's some great info waiting for you!

Example RFP questions (copy/paste)

Security and Crypto

Could you put together a list of all the cryptographic libraries you’re using, and be sure to include their versions too? Thanks! Hey there! If you have any links for CBOM or SBOM, feel free to share them. Also, I’d love to hear about your strategy for moving away from RSA/ECC and diving into NIST's post-quantum cryptography. Are you thinking of using stuff like ML-KEM, ML-DSA, or SLH-DSA? Let’s chat about your plans! Hey there! So, what's your game plan for rolling out hybrid key exchange? And how are you planning to keep things flexible with those signature algorithms? If you want to dive deeper into the latest updates, definitely take a look at this NIST page. It’s got some good info!

Hey, just a quick reminder! Make sure to include the CMVP certificate numbers for your HSMs and SDK crypto modules. Thanks! Hey there! Just a quick reminder to make sure you're all set for the FIPS 140‑2 sunset that’s happening in September 2026. It's always good to be prepared! If you're looking for more information, check out this NIST page. It's got all the details you need!

Let’s get into the nitty-gritty of your threshold/MPC design, like what you see with FROST or secp256k1. I’m really curious about how you manage the storage of those key shares. What approach do you take to keep everything secure and efficient? Don’t forget to chat about your rate-limit and tamper-evidence controls too! They're super important. If you're looking for some helpful guidelines, check out this IETF document. It's packed with useful info!

Account Abstraction and UX

So, let’s dive into ERC‑4337! We really need to chat about the UserOperation simulation strategy. Plus, don't forget the replay protection--shoutout to those nonce lanes for having our backs! And of course, we should definitely cover some solid paymaster risk controls to keep everything running smoothly. With EIP‑7702, it’s really important for users to have a straightforward way to check their delegations, set time limits, and, if needed, revoke them. Take a look at this link: (eips.ethereum.org). You might find it interesting!

Hey! So, about those modular smart account standards--I'm curious which ones you actually support. I'm particularly interested in ERC‑7579/6900. Do you have any insights on that? So, how do you actually validate those third-party modules using the ERC‑7484 registry attestations? If you’re looking for more details, check this out: (eips.ethereum.org).

Mobile and Passkeys

Let’s dive into how Android handles key generation and attestation with its hardware-backed features, like TEE and StrongBox. And while we’re at it, we’ll also explore how Apple’s Secure Enclave functions. It’s pretty fascinating stuff! Oh, and make sure to check out passkey/WebAuthn sign-in! It’s super important to have those phishing-resistant origin checks set up too. You definitely don’t want to skip that part! And hey, we've got a super useful MASVS v2 mapping ready for you! Learn more here!.

Compliance

Don't forget to grab the SOC 2 report, the ISO 27001:2022 certificate, and the PCI DSS v4 AoC if you're dealing with card transactions. It's important to have those documents handy! Oh, and make sure to share the Travel Rule gap analysis along with your OFAC and FinCEN policies. Don’t forget to include how you’re keeping an eye on that CVC mixing NPRM too! Hey, if you're looking for some good insights, take a peek at this link: bdo.com. It's got some valuable info you might find helpful!

Interoperability

Make sure to test EIP‑6963 with a bunch of different injected providers. Also, it’s important to check out support for Sign-In with Ethereum (EIP‑4361) and ReCaps (EIP‑5573) when it comes to delegated functions. And don’t forget to keep an eye out for some sample apps for 4337/7702. It’ll really help you get a feel for how everything works! (eip.info).

Bitcoin Controls

Alright, let’s jump into some example descriptors and Miniscript policies that lay out the spending conditions. We’re going to focus on Taproot multisig (BIP‑387) and chat about how you can give it a test run.

Example Descriptors

Single Key Spend
This is the most straightforward way to spend, where you just need one private key.
```
sh(wpkh(<your_public_key>))
```
Two-of-Three Multisig
To make a transaction here, you'll need at least two out of the three keys.
```
sh(multi(2,<pubkey1>,<pubkey2>,<pubkey3>))
```
Taproot Multisig
Mixing multisig with Taproot can really boost both privacy and efficiency.
```
tr(multi(2,<pubkey1>,<pubkey2>,<pubkey3>))
```

Miniscript Policies

Miniscript is really useful for laying out these conditions in a clearer way. So, here’s what the policies would look like:

1. Policy for Spending with a Single Key This is just a quick way to see if that one key can actually unlock the funds.

pk(<your_public_key>)

2. Policy for Two-of-Three Multisig. This checks to see if at least two out of the three keys are valid.

and_v(v:pk(<pubkey1>), v:pk(<pubkey2>), v:pk(<pubkey3>))

3. Policy for Taproot Multisig. Just a quick note to confirm that for a transaction to go through with Taproot, it needs approval from two keys.

and_v(v:pk(<pubkey1>), v:pk(<pubkey2>), v:pk(<pubkey3>))

Testing Methodology

To make sure everything runs smoothly, here's a simple approach you can follow:

1. Set Up Testnet: Dive into Bitcoin's test network! It’s a great way to experiment without the worry of losing any real money. 2. Create Transactions: Go ahead and set up your transactions using the descriptors and guidelines we talked about earlier. 3. Simulate Spending: Go ahead and play around with different key combinations to test out your multisig policies. It's a great way to see how everything works! 4. Analyze Results: Take a look at whether what you expected to happen lines up with what actually happened. This is a great way to spot any potential problems that might pop up.

If you're looking for more info, just check out the official BIP documentation over at bips.dev. It's got all the details you need!

Emerging best practices to require (2025 edition)

Think of PQC as a long-term program instead of just a one-off project. Alright, here's the deal: make sure you’re on top of that CBOM. Also, we need to get our plans rolling for ML-KEM, ML-DSA, and SLH-DSA. Let’s not forget to give those hybrid handshakes a good test run! And, of course, don’t forget to connect with CNSA 2. We've got a lot on our plate, but I know we can handle it! There are no timelines when it really makes sense. (csrc.nist.gov).

Embrace native AA: Let's design a user-friendly experience that seamlessly connects with regular EOAs, 4337 smart accounts, and EIP-7702 delegated EOAs. We can make gas transactions way more straightforward by incorporating paymasters. Plus, it’ll be great to implement session keys and set some rate limits using modular accounts to enhance the overall functionality. (eips.ethereum.org).
Send out the SBOM/CBOM with every release:
Use SPDX 3. 0 or CycloneDX 1. Make sure to include signed attestations for 6+ vulnerabilities. Also, link those vulnerabilities to CVSS v4 and CISA KEV. Oh, and remember to put out those timelines for remediation too! (linuxfoundation.org).
Travel Rule-ready infrastructure:
Get everything ready for data collection, validation, and exception handling, following the EBA guidelines. Just a heads-up: when you're checking for sanctions and looking into wallets, try to keep the collection of personal identifiable information (PII) to a minimum. We want to stay compliant and respect privacy! (eba.europa.eu).
Mobile hardening automatically included:
Make sure to stick to the MASVS v2 guidelines, use hardware-backed keys, double-check those secure intents for anything high-risk, and don’t forget to tackle any jailbreak or root risks. (mas.owasp.org).

Brief example: scoring a vendor answer

Getting pumped for PQC and making sure we stick to the best practices! ”. Hey there! Just wanted to share some exciting news - we’re about to launch a CBOM (CycloneDX 1.0). Stay tuned for more updates!

with every release. We've put together a 12-month migration plan for moving to ML-KEM and ML-DSA, and we're also making sure to keep a hybrid KEM in place so we can stay compatible with any existing systems. Oh, and just so you know, we update our server keys every three months. Hey, take a look at the attached CBOM, the PKI runbook, and the results from our test harness. Let me know what you think! ” (cyclonedx.org).

Final note

This RFP template really highlights how crucial it is to have solid proof. Don’t forget to ask for important documents like certificates, SBOM/CBOM, audits, test vectors, and maybe even a few production references. Those will really help you get a clearer picture! If a vendor can't deliver on these points, it’s probably a good idea to pass on the pilot, no matter how slick their demo is.