RFP Guide: 50 Questions to Ask Your Blockchain Development Partner

Your last RFP looked great at first glance--but then reality hit for 2025-2026.

Ethereum L2 fees took a nosedive after Dencun (EIP-4844 blobs), but it wasn't a uniform drop across all stacks. If you’re basing your budget on 2023-2024 calldata economics, you're way off--like, orders of magnitude off. Miscalculating blob-era data can really mess up your unit economics or lead to some unnecessary over-optimizing. Check it out here: (ethereum.org)
When it comes to optimistic-rollup withdrawals, there’s still a ~7-day challenge window for L1 exits. This is super important for managing treasury operations, getting on exchange listings, and processing user refunds. If you miss this in your SLAs, you could face some serious incident escalations and damage to your reputation. More details here: (ethereum.org)
The behavior of SELFDESTRUCT has changed with EIP-6780. This means those old “metamorphic” upgrade patterns are broken; if a vendor isn't in the loop, they could end up orphaning upgrade paths or ignoring your change-control policy. More info can be found here: (eips.ethereum.org)
The account user experience changed again post-Pectra. The ERC‑4337 setup has matured, and thanks to EIP‑7702, EOAs can temporarily function like smart accounts. If your partner isn’t able to utilize bundlers/paymasters safely, it could really harm your activation funnels and increase customer acquisition costs. Here’s the scoop: (ethereum.org)
We’re seeing an uptick in security loss events at the higher end of the scale. In 2025, we witnessed multi-billion dollar thefts led by DPRK-linked groups. An RFP that doesn’t enforce a measurable security posture (like SOC 2, SSDF, SLSA, or supply-chain attestations) is opening the door to board-level risk. Learn more here: (chainalysis.com)

What That Risk Means for Deadlines, Spend, and Compliance

Missed Milestones: If cost modeling isn’t fully done (like understanding the difference between blob and calldata), it tends to rear its head late during load tests and finance reviews. This can lead to scope changes and a whole lot of rework across multiple sprints. (ethereum.org)
Budget Bleed: When teams opt for storage flips and generic guards instead of using EIP‑1153 transient storage or MCOPY, they could be losing out on 10-100x gas savings on key paths. This can really inflate operational expenses. (eips.ethereum.org)
Compliance Gaps: These days, auditors are on the lookout for a secure SDLC that aligns with SSDF, SLSA build provenance, and SOC 2 Type II controls mapped to the Trust Services Criteria--especially when it comes to Availability and Security. Taking an “audit later” approach could lead to failed customer security reviews and hold up procurement processes. (csrc.nist.gov)
GTM Friction: If your team lacks the skills for 4337/7702 (like sponsored gas, session keys, and recovery), you’re likely to add unnecessary clicks, drop conversions, and see an uptick in support tickets. Plus, your treasury operations will have to deal with unexpected L2→L1 latency issues. (ethereum.org)

7Block Labs’ Technical-but-Pragmatic Delivery

From the get-go, we bring together procurement, engineering, and go-to-market (GTM) teams, all while keeping it real with today’s protocol realities.

Architecture & Economics Baseline
- We're diving into blob-era cost modeling with EIP‑4844 and EIP‑7516, plus a look at L2 fee sensitivity analysis; our approach integrates unit economics into our sprints and dashboards. Check it out here: (ethereum.org).
- We've got plans for exit latency strategies between Optimistic and ZK stacks, including options for quick exits when liquidity is available. More details can be found here: (docs.optimism.io).
- We're ensuring our upgradeability holds up against EIP‑6780 with UUPS and diamond patterns, along with clear governance and rollback procedures. Learn more about it here: (eips.ethereum.org).
Secure-by-default SDLC (SOC 2 + SSDF + SLSA)
- Align your build pipelines with SSDF tasks (check out NIST SP 800‑218 for details!) and make sure to provide SLSA provenance along with SBOMs for every release. You can find more info here.
- For continuous verification, use Slither and Echidna in your CI setup and add detectors for the latest features like 4337 and transient storage. Don’t forget to include coverage and invariant gates too! More on that can be found on GitHub.
- To boost trust in your supply chain, publish your source through Sourcify and Etherscan. It’s a great way to minimize assumptions about trust. Check out the details here.
Wallets and UX (Pectra/4337/7702-aware)
- Choosing the right bundler and paymaster while keeping an eye on quotas; budgeting for gas sponsorship; putting in place fraud and abuse controls; and making sure session key policies align with SOC 2 change management. (ethereum.org)
Cross-chain risk management
- It’s a good idea to use a defense-in-depth approach when it comes to messaging. Think about leveraging CCIP’s Risk Management Network or LayerZero DVNs where it makes sense. You might want to model X‑of‑Y‑of‑N verifier thresholds and develop operation runbooks. Check out this link for more details: (blog.chain.link)
Gas optimization that actually boosts ROI
- Check out EIP-1153 for transient storage. This helps with reentrancy guards and transaction-scoped flags. Plus, if you're using OpenZeppelin Contracts 5, you'll benefit from custom errors and those nifty reduced SLOAD patterns. Just make sure you're on Solidity version 0.8.26 or higher! (eips.ethereum.org)
- And don't forget about SSTORE2! It's a real game-changer for handling large, immutable data blobs--perfect for things like on-chain catalogs and Merkle proofs. It can save you from those hefty 20k-gas storage sets and helps keep your calldata lean. (github.com)
Delivery with clear SLAs
- We have SLOs in place for how quickly end-users get confirmation (L2), expectations on L1 finality (ZK), detailed on-call runbooks, plus our RTO/RPO targets and data residency controls.

Where it plugs into your procurement

If you're interested in build and integration, check out our custom blockchain development services and blockchain integration.
For protocol and dApp needs, take a look at our dApp development and smart contract development.
When it comes to DeFi rails, wallets, and cross-chain solutions, dive into our DeFi development services, DEX development, and cross-chain solutions.
And if you're looking to strengthen your project's security, don't miss our security audit services.

Proof: GTM and Engineering Metrics We Deliver in Pilots

Unit Economics After Dencun: So, we've seen some pretty impressive shifts lately with fee-per-action (like transfers, swaps, and mints) and blob sensitivity at the p50/p95 levels on selected L2s. We're talking about expected reductions of 90-98% compared to the pre-Dencun calldata for traffic classes that match up. We link all this back to our CAC/LTV models to help get those budget approvals sorted out. Check out more about it here.
Activation and Retention: Our metrics for the 4337/7702 funnel show some solid numbers--like the percentage of sponsored actions, recovery success rates, and the average time it takes to transact post-KYC.
Operational Reliability: We keep an eye on mean confirmation times that users can actually see compared to L1 finalization behind the scenes. We also look at withdrawal latency distributions for ORUs and how quickly we can handle incidents (MTTR).
Security Posture: Our coverage for SSDF tasks, the SLSA provenance rate, and the evidence for SOC 2 controls, all mapped out to TSC categories (like Security and Availability baseline). If you're curious to dive deeper, you can find more info here.

50 Must-Have RFP Questions

Here are 50 super handy RFP questions that you might want to copy and paste right into your procurement document.

The 50 questions (Technical but Pragmatic)

Strategy and ROI (5)

User Actions & Costs
Which user actions get us to Level 2? Let’s dig into their median (p50) and 95th percentile (p95) gas costs now that we’re in a post-Dencun world. Also, what assumptions are you making about blob prices (BLOBBASEFEE) in your cost model? Don't forget to put together a sensitivity table! Check this out for more info: eips.ethereum.org.
KPI Tree Mapping
What kind of KPI tree are you planning to set up? Think along the lines of cost per successful on-chain action, activation-to-transaction conversion rates, and on-chain churn. How does this tie back to the ROI for the executives?
Impact Validation
How will you confirm the effect of the 7-day L2→L1 challenge window on refunds, settlements, and treasury liquidity? Be sure to include any Service Level Agreements (SLAs) and workarounds, like LP-based fast exits. You can find more details here: docs.optimism.io.
Feature Flagging on-chain
What’s your game plan for feature flagging on-chain? I’m thinking about methods like using storage or version slots to A/B test economic parameters without having to redeploy everything.
12-Month TCO
Can you provide a 12-month Total Cost of Ownership (TCO)? Make sure it covers not only build hours but also audits, infrastructure, incident response, and compliance reporting.

Architecture and Chain Selection

6) Which rollup(s) match our workload profile?

Let’s take a look at ZK rollups, which offer faster Layer 1 withdrawals, compared to Optimistic rollups that rely on fault proofs. It’s important to weigh the user and operational impact of each. Check out more details on ethereum.org.

7) Provide a Dencun-aware data strategy.

How can we keep calldata to a minimum, make the most of blobs upstream, and manage any potential data availability outages or price spikes? Dive into the specifics on ethereum.org.

8) How will you protect upgradeability after EIP‑6780 removed durable SELFDESTRUCT patterns?

We need to show how we’ll maintain upgradeability moving forward. Let's discuss UUPS or diamond governance diagrams to illustrate our approach. More on the EIP can be found on eips.ethereum.org.

9) What is your L2 fee backoff strategy under blob market congestion?

It’s crucial to have a solid plan in place for managing those L2 fees when the blob market gets congested.

10) Are we using ERC‑2535 (diamond) for modularity?

Absolutely! Let’s also clarify how we control DiamondCut access, whether that’s through multisig, Timelock, or Guardian setups. Check out the details at eips.ethereum.org.

11) How do you model bridge dependencies and choose between CCIP RMN vs LayerZero DVNs?

We need to carefully consider our bridge dependencies and decide which route to take, either CCIP RMN or LayerZero DVNs. This includes outlining verifier thresholds and potential failure modes. For more on this topic, see blog.chain.link.

12) Will we maintain read replicas and archival data for analytics without overpaying for L1 access (post‑Dencun)?

It’s definitely something we need to assess so we can keep our analytics running smoothly without breaking the bank.

13) What’s your approach for on-chain verification?

To avoid any lock-in with explorers, we should have a strategy in place for on-chain verification, utilizing Sourcify and Etherscan’s multi-verifier system. More info can be found at docs.sourcify.dev.

Solidity Engineering Depth (6)

14) Which compiler channel and flags (via‑IR, optimizer runs) are standard?

For Solidity, you'd typically want to stick with version ≥0.8.26, especially if you're using require() with custom errors. This version brings in some cool IR optimizer benefits that can save you some gas in your contracts. You can check out more about it here.

15) Where do you adopt EIP‑1153 transient storage (TSTORE/TLOAD) to replace hot SSTORE/SLOAD patterns?

When it comes to reentrancy locks and single-transaction approvals, switching to EIP-1153's transient storage (TSTORE/TLOAD) is a smarter move. It can really help cut down on gas costs compared to those old SSTORE/SLOAD patterns. If you're curious about the gas differences, you can dive into the details here.

16) How do you use MCOPY (EIP‑5656) for tight memory operations and calldata slicing?

Using MCOPY from EIP-5656 is a game changer for optimizing tight memory operations and slicing calldata. This feature allows for more efficient memory management in your contracts, which is always a plus. Want to learn how to implement it? Check it out here.

17) What’s your policy on custom errors vs revert strings?

When it comes to custom errors versus revert strings, it's important to weigh the trade-offs like bytecode size and deployment costs. Personally, I've found that using custom errors can be more efficient, especially when referring to libraries like OZ Contracts 5. They provide a lot of useful patterns to follow. More info can be found here.

18) When do you choose SSTORE2 for large immutable data?

For large immutable data, SSTORE2 is definitely the way to go. It helps you avoid the pitfalls of code-size and load-time constraints that come with regular storage methods. If you're looking for more insights into this, the details are available here.

19) Show your storage layout discipline.

Having a solid storage layout discipline is essential--think about packing, immutables, and constants. Plus, locking it down with automated diff checks ensures consistency and helps catch any potential issues early on.

Account Abstraction and Wallets (5)

Which bundlers or paymasters are you thinking of using, and how do you plan to prevent gas sponsorship abuse? It’d be great to see your approach to logs, alerts, and reimbursement rules. (alchemy.com)
How are you planning to leverage EIP‑7702 to integrate smart-account features into EOAs without the hassle of migrations? Please share how you’ll backtrack to the 4337 infrastructure. (ethereum.org)
What’s your strategy for session keys in terms of durations and scopes? Also, how does this tie into your SOC 2 CC6/CC7 auditing process? (cbh.com)
How do you approach recovery UX while keeping personal info to a minimum and still complying with our DPA/GDPR requirements?
Can you explain your methods for mitigating phishing and blind-signing risks? Things like human-readable transactions and metadata registries could be key. Also, don't forget to mention the verification UX through Sourcify/Verified Alliance. (docs.sourcify.dev)

Security Engineering and Audits (8)

Let's chat about how we can map the SSDF (SP 800‑218) to our project stages and outputs. We’ll need to cover things like threat models, STRIDE, and abuse cases. You can check out the details here.
What's the SLSA level we're aiming for with our builds? Also, how do you plan on delivering provenance attestations (think Sigstore) with every release? More info on that can be found here.
Can you list out the static and dynamic tools we’re using (like Slither 0.11 and Echidna ≥2.1)? Don’t forget to include the detectors we’ve got (4337/paymaster, transient storage) and the required thresholds (we want no high or critical issues). You can find some resources here.
How do you incorporate formal methods or invariant testing for those critical invariants? We’re talking about things like supply caps, accounting, and oracle bounds.
What’s your game plan for 3rd-party audits and public disclosures?
Could you share your strategy for SWC coverage and how you deal with patterns that SWC might not catch as effectively (like business logic and oracle manipulation)? You can check out a good reference here.
How are you managing key material (like admin, guardians, signers)? What's the deal with HSMs versus MPC, rotation schedules, and emergency revokes?
Please provide an incident response plan that aligns with our SLAs. It should include details on L2 halt and regen scenarios, along with playbooks for bridge exploits.

Compliance and Governance

33) Are you SOC 2 Type II?

If you’re not, how do you plan to work under our SOC 2 scope and show us evidence that aligns with the TSC Security + Availability? Check out more about it on AICPA-CIMA.

34) Mapping Roles and Responsibilities

Can you outline how roles and responsibilities line up with CC1-CC9 (Change Management, Logical Access, System Operations)? We’d love to see some sample evidence, like tickets or approvals. You can get some insights from this guide on CBH.

35) Implementing SSDF Practices

How do you plan to apply SSDF practices (PO/PS/PW/RV) and report coverage for each sprint? More info can be found at NIST.

36) Data Protection Agreements and Residency

Please provide us with your Data Protection Agreements (DPAs) and data residency statements for logs, analytics, and any off-chain services you use.

37) Vulnerability Disclosure and Patch SLA

What’s your plan for vulnerability disclosure and patch SLA under our Master Service Agreement (MSA)?

38) Governance for Upgrades

Can you explain how your governance for upgrades works? Specifically, we’d like to know about timelocks, multi-signatures, and emergency pauses, and how this aligns with our change windows.

DevEx, CI/CD, and Observability

39) What’s your Hardhat/Foundry workflow, gas-reporting practices, and pre-merge checks?

40) How do you incorporate continuous verification (Sourcify) and multi-explorer publishing in your CI? (docs.sourcify.dev)

41) What kind of runtime telemetry are we looking at (like Tx success, revert codes, gas trends) and how do we connect alerts to our SLOs?

42) What’s your approach to testing across different clients (Geth/Besu/Nethermind/Reth) and handling blob-fee fluctuations?

Delivery, SLAs, and SRE (4)

Environment Strategy: Set up ephemeral testnets like Holesky and Sepolia, and create L2 staging environments using pre-populated data sets.
Define SLOs: Establish the p95 user confirmation time for L2, decide on acceptable reorg depth, and outline withdrawal time distributions. Don’t forget to include on-call schedules!
Disaster Recovery: Determine RTO/RPO for indexers, RPC, and verifiers, plus have some backup plans in place for last-resort vendors.
Compliance Artifacts: How do you keep your compliance documents up to date? Think SOC 2 evidence locker and SLSA attestations--these are crucial for staying audit-ready!

Cross‑chain and Integrations (4)

So, which bridging stack works best for our risk appetite--are we leaning towards CCIP with RMN or LayerZero DVNs? And what kind of thresholding (like X‑of‑Y‑of‑N) are we thinking about enforcing? Check out this blog post for some insight.
What’s the game plan for keeping an eye on bridge health? How do we pause routes if needed and possibly execute clawbacks when we can?
How are we going to separate cross-domain admin privileges to steer clear of any trust escalations that might happen implicitly?
Can you whip up a test matrix covering message ordering, idempotency, replay protection, and payload size limits in those blob-era conditions?

Post‑Dencun Cost Model (Actionable)
- Reach out to the vendor and ask them to provide a before-and-after unit-economics table for your top 5 transactions (like register, mint, swap, claim, and withdraw) on the L2s you've selected. Make sure they include details about blob base-fee sensitivity and any traffic multipliers. You should expect that they’re familiar with EIP-4844 and can interpret BLOBBASEFEE when it comes to the rollup components. (ethereum.org)
A Safer Upgrade Path Post EIP‑6780
- It’s essential to have a diagram that outlines how your old upgrade method stacks up against UUPS or ERC‑2535 diamonds. Make sure to include things like admin key ceremonies, timelocks, and emergency pause workflows. This shift helps us steer clear of the now-defunct SELFDESTRUCT-based "metamorphic" patterns. Check it out here: (eips.ethereum.org)
Gas optimization that really makes a difference
- Suggest that the vendor swap out a traditional ReentrancyGuard (you know, those storage boolean toggles) for EIP‑1153 transient storage flags. Make sure to highlight the gas deltas in a micro-benchmark suite, along with the adoption of OZ Contracts 5 custom errors and via-IR compile settings. When you put together your RFP, ask for the specific compiler configs and gas reports. (eips.ethereum.org)
AA (4337/7702) conversion impact
- Request a pilot study that tracks the percentage of transactions executed with sponsored gas, along with failure rates broken down by bundler. Also, look into how EIP‑7702 directs legacy EOAs into a smart-account flow. This should be linked to decreased drop-offs and support tickets. (ethereum.org)
Cross‑chain defense in depth
- Take a look at how CCIP’s independent Risk Management Network stacks up against LayerZero DVNs when it comes to your message types (like idempotency and payload size). Make sure to consider X‑of‑Y‑of‑N verifier thresholds and operational controls. Check it out here: (blog.chain.link)
Verification and Supply Chain
- For demand verification, we need to publish multi-verifier data (Sourcify → Etherscan/Blockscout) in our CI, along with provenance attestations (SLSA). Plus, we should include an SSDF control map to cover audit requirements and customer questionnaires. Check out the details here: (docs.sourcify.dev)

Emerging best practices to insist on

Keep blob-awareness in mind for every estimate: after Dencun, most Layer 2 solutions saw jaw-dropping fee reductions of 90-99% for common transactions. So, let’s not rely on outdated calldata math from before 2024 in proposals. (thedefiant.io)
Go for ZK if L1 exit latency is a deal-breaker for your business (think exchanges and settlements); make sure to document fallback liquidity providers for Optimistic fast exits and incorporate them into your SLAs. (docs.optimism.io)
Treat EIP‑6780 like your non-negotiable guideline--no metamorphic patterns allowed. Stick with UUPS or diamond patterns that come with clear governance and audit trails. (eips.ethereum.org)
Use Solidity version 0.8.26 or higher, via-IR, custom errors, and modern libraries like OpenZeppelin 5 to cut down on bytecode and runtime expenses. (soliditylang.org)
Make sure to outline your SSDF tasks, SLSA provenance, and SOC 2 evidence right from the get-go; this has become a must-have for enterprise security reviews. (csrc.nist.gov)
When dealing with large immutable data on-chain, leverage SSTORE2 to keep those storage costs down; also, jot down any limits (like code-size) and retrieval paths for clarity. (github.com)

Where 7Block Fits In

End-to-end build and ROI linkage: We've got you covered with our web3 development services, blockchain development services, and smart contract development. We make sure everything ties together smoothly so you can see the returns on your investment.
DeFi rails and cross-chain solutions: Check out our DeFi development services, DEX development, cross-chain solutions development, and blockchain-bridge development. We're all about creating seamless experiences across different platforms!
Security and readiness: Your projects are in safe hands with our security audit services, plus we integrate governance and compliance right into our delivery. We're here to ensure you're always ready for whatever comes next!

Final note on risk posture

Losses really surged in 2025 towards the end of the “big game.” It’s crucial that your RFP emphasizes the need for architectural and process maturity--things like bridges, governance keys, and supply-chain attestations are absolutely non-negotiable. (chainalysis.com)