A blockchain development RFP should tell a vendor what you need to launch, who can move assets or change the system, which existing tools it must connect to, and how you will accept the finished work. Include your budget range, delivery constraints and ownership requirements. Mark unresolved decisions clearly.
That is enough to start a useful conversation about price. A long feature list without those decisions leaves too much room for interpretation.
This blockchain development RFP checklist is for founders, product owners and procurement teams comparing proposals for a production build. You can use it before approaching a custom blockchain development company, even if you have not chosen the network yet.
Give vendors the same starting point
Imagine asking two teams to quote a tokenization platform. One includes token issuance and a dashboard. The other includes investor onboarding, transfer restrictions, document storage, redemption and operational support.
Their prices describe different products. Comparing the totals will not tell you which proposal offers better value.
An RFP, or request for proposal, asks vendors to explain their approach, delivery plan and price. An RFQ, or request for quotation, works better once the scope is sufficiently settled. If you still need to establish whether the product is feasible, ask for discovery before requesting a fixed build price.
Use the same brief and response format for everyone you shortlist.
Define the first release before listing future features
Start with the business workflow. Explain what happens today, where it breaks down and what the first release must change. Name the people who will use it and the person who will approve delivery.
Your opening brief should answer these questions:
RFP field | What to send |
|---|---|
Business outcome | The process you want to improve and the measure you will use to judge it |
Users and organisations | User roles, participating businesses and who operates the service |
Launch scope | Required workflows, supported assets, interfaces and networks |
Expected activity | Estimated users, transaction types, average volume and peak load |
Existing systems | API documentation, authentication methods and access dependencies |
Budget and schedule | Budget range, preferred currency, target date and genuine external deadlines |
Open decisions | Questions that need discovery, with an owner for each answer |
Separate launch requirements from later additions. A second blockchain, mobile app or trading marketplace can change the work substantially. State whether each belongs in the quoted release.
Include exclusions too. If the project covers software development but excludes legal structuring, custody operations or independent security review, put that in writing. Otherwise, those costs may surface after you have selected a vendor.
Explain why the workflow needs a blockchain
Identify who needs to verify the record and whether those parties trust one organisation to control it. If a single business owns the process and every participant accepts its database, ask vendors to compare a conventional architecture with the proposed blockchain design.
For a public network, describe wallet access, transaction fees and the information that may be visible publicly. For a permissioned network, specify who can join, operate nodes and approve changes.
Privacy needs more detail than the word "private." Hyperledger Fabric, for example, supports private data collections that restrict the underlying data to authorised organisations while recording its hash on the channel ledger. The data and evidence of that data have different visibility.
If you are considering private blockchain development, list which organisation may see each category of information. Include commercially sensitive documents, personal information and records shared with auditors.
You can leave the network undecided. Ask bidders to recommend an architecture and explain its operating costs, restrictions and failure conditions. A reasoned recommendation is more useful than a chain name without assumptions.
Put custody and contract permissions into words
"Wallet integration" can mean connecting an existing wallet, building a wallet application or operating infrastructure that controls customer assets. Tell the vendor which responsibility you expect it to take.
Specify who creates keys, where signing happens and how recovery works. Include what should happen when a user loses access, a staff member leaves or an administrator account is compromised. If the scope includes crypto wallet development, identify the custody model before requesting a final estimate.
For smart contracts, write a permissions list. Who may mint, pause, transfer administrative rights or change an allowlist? Which actions require more than one approval? Who receives control at handover?
Upgradeable contracts need a separate decision. Proxy designs can allow application logic to change, but access to upgrades and compatibility of stored data need explicit controls. An upgrade that mishandles storage can corrupt application state.
Ask the smart contract development team to price the selected upgrade approach, tests and operational procedures. If contracts will be immutable, document how you would replace them and migrate users if a change becomes necessary.
For an asset tokenization platform, attach the rules for issuance, eligible holders, transfers and redemption. Describe the records that connect the token to the underlying asset. The developer should implement approved business rules rather than infer them from a token standard.
Describe the systems around the chain
A working contract still needs an application around it. Your blockchain project requirements should cover the interface, backend services and the tools your operations team will use.
List each integration separately. For every payment, identity, ERP or data provider, include the API version, sandbox availability, access owner and expected behaviour during an outage.
If a contract depends on external information through an oracle, explain who supplies that information and what the application should do when it is late or unavailable. A signed transaction cannot establish whether an external business claim was accurate when someone entered it.
Also define the status users see. Submitted, included in a block and finalised describe different stages. The application needs a stated policy for when it treats a transaction as settled and how it handles a reorganisation where the selected network permits one.
Keep sensitive documents outside a public ledger unless the design has a specific, reviewed reason to place them there. Name the system responsible for storing, updating and deleting the original records.
Replace broad promises with acceptance tests
"Secure, fast and scalable" gives a procurement team little to approve. Write observable results and ask vendors to identify the evidence they will deliver.
These are example acceptance criteria to adapt to your application:
Requirement | Evidence to request |
|---|---|
Administrative permissions | An unauthorised account cannot execute restricted contract functions |
Duplicate processing | Replaying the same business event does not issue a second asset or credit |
Asset accounting | Issuance, transfers and redemption preserve the balances and supply rules in the specification |
Integration recovery | A provider outage produces a visible pending or failed state and a documented recovery path |
Upgrade safety | The permitted upgrade preserves the agreed state and rejects unauthorised changes |
Operational handover | Your team deploys the agreed release using the supplied instructions and access |
Set performance targets against a named workflow and environment. Measure response time separately from blockchain confirmation time. Specify the test duration, concurrent users and transaction mix. A result for a simple transfer says little about a workflow that calls several contracts and external services.
For independent security testing, ask who selects the reviewer, what code version the review covers, who pays for remediation and whether retesting is included. Record how unresolved findings affect launch approval.
Ask for build costs and operating costs separately
Require a breakdown for discovery, design, contract development, application development, integrations, testing, deployment and support. Ask bidders to identify reused components and any recurring licence fees.
Then request operating estimates using your expected activity. Include RPC or node services, indexing, storage, monitoring and transaction fees where applicable.
On Ethereum, a basic ETH transfer uses 21,000 gas. Contract interactions can consume more, so a vendor should estimate the actual operations your product performs rather than price everything as a simple transfer.
Consider this illustrative calculation: a contract operation using 150,000 gas at an effective gas price of 20 gwei costs 0.003 ETH in execution fees. Ten thousand identical operations at that assumed price would cost 30 ETH. These are calculation inputs, not a forecast or a benchmark for your application. Other network charges may apply, including separate data costs on some rollups.
Ask who pays those fees, how the estimate changes with usage and what happens when a transaction becomes too expensive to submit. Keep a fiat conversion separate and state its exchange rate and date.
Make the proposal include an exit plan
The contract should identify ownership of new code and the licence terms for existing components. Ask for repositories, deployment scripts, API documentation, contract addresses and the configuration needed to operate the system.
Agree how administrative authority will move to your organisation. Listing an address in a handover document is insufficient if the vendor still controls the account that can upgrade a contract or move assets.
Request support hours with a time zone, incident response targets, escalation contacts and a distinction between defect fixes and chargeable changes. A US buyer may need operational cover outside an India based development team's working day. Put the required overlap into the brief.
For projects involving US, UK or UAE entities, name the contracting entity, intended users and countries of operation. Give the development team the requirements your legal and compliance advisers have approved, along with any hosting or access restrictions that affect delivery.
Require a response against every requirement
Number your requirements. Ask each bidder to mark them as included, excluded, optional or awaiting discovery. Every optional item should have its own price or estimation method.
Use this response clause in your RFP:
Respond against each requirement ID. State assumptions, dependencies, exclusions, deliverables and acceptance evidence. Separate fixed fees, estimated effort, optional work and recurring charges. Identify any decision that must be resolved before a firm price or delivery date is possible.
Send the same clarification answers to all shortlisted vendors. Otherwise, their revised proposals will drift apart again.
Ready to request a scoped proposal? Send Alpharive your blockchain project brief with the launch workflows, custody requirements and open decisions attached.
Questions before sending your RFP
Can I request a quote without choosing a blockchain
Yes. Provide the business workflow, privacy requirements, expected activity and ownership model. Ask vendors to recommend a network and identify which assumptions affect price. You may need a discovery phase before committing to a fixed build fee.
Should an MVP include a security review
If the MVP will hold assets, process live funds or exercise privileged contract permissions, include a security review appropriate to that exposure. Define its scope and remediation process. A prototype using test assets has different release conditions from a product accepting customer funds.
What should remain outside a fixed price
Keep genuinely unresolved work visible. Examples include an integration without accessible documentation, an undecided custody model or business rules awaiting approval. Request a separate discovery price or an explicit allowance rather than treating those items as settled scope.
