RFP 08: Enterprise Delivery Partner Network
Tender type: Request for Proposals
Issued by: Cardano Product Committee / Intersect
Research portfolio: Product Research Initiatives
Final publication date, submission deadline, clarification window, expected project period, submission method, and contact will be confirmed on the Product Research Initiatives - Grants page before the call opens.
1. Executive Summary
Strategic question
What enterprise delivery partner network, certification framework, and go-to-market model would enable Cardano stakeholders to convert enterprise interest into implemented, supported, and measurable deployments?
Evidence gap
Cardano has enterprise-relevant infrastructure, ecosystem teams, and emerging enterprise and RWA opportunities. However, enterprise adoption depends on more than protocol capability, product interest, or pilot announcements. External clients usually need accountable delivery partners who can scope, implement, integrate, operate, support, and maintain solutions through procurement and production use.
One of the most consistently cited barriers to Cardano enterprise adoption is the absence of a visible, trusted, and certified channel of delivery partners or system integrators. Cardano stakeholders do not yet have a decision-ready map of which firms can deliver Cardano solutions today, which sectors and regions they cover, what capabilities they can prove, what gaps prevent enterprise procurement confidence, and what type of certification or partner programme would attract and retain qualified delivery firms.
The evidence gap is not whether a partner network sounds useful. The gap is what type of partner network would be credible, which firms could participate, what support and incentives they would require, what governance would protect quality, and which peer ecosystem models Cardano can adapt rather than invent from scratch.
Decision unlocked
This research should enable Cardano stakeholders to decide:
whether to create, fund, coordinate, or pilot a certified enterprise delivery partner network;
which partner categories should be prioritized, including specialist delivery firms, system integrators, consultancies, implementation agencies, regional delivery partners, and vertical specialists;
what certification criteria, partner tiers, training pathways, governance model, and quality controls should be used;
which geographies and sectors require urgent partner development;
whether co-funded implementation structures should be tested, and under what guardrails;
what prevents larger consultancies and system integrators from building a Cardano practice;
which pilot engagements, recruitment actions, enablement assets, or support mechanisms should be funded first;
what evidence should be required before Cardano stakeholders treat a delivery partner as enterprise-ready.
Expected outputs
The selected vendor will produce a partner landscape map, enterprise delivery capability model, partner certification framework recommendation, peer ecosystem reference-model benchmark, co-funded implementation model assessment, partner recruitment and go-to-market model, geography and sector gap analysis, larger-consultancy barrier analysis, training and enablement requirements map, partner governance and quality-control model, pilot engagement pathway, evidence threshold framework, executive decision memo, final research report, final presentation, public summary, and cross-RFP handoff memo.
Vendors may combine deliverables where sensible, provided that every decision gate is answered and every required output is covered.
Requirement priority
The required core is to answer the decision gates with traceable evidence and produce the required decision outputs. Optional methods, templates, or stretch work should be separated from the core scope and budget. This RFP is not implementation delivery, enterprise sales execution, partner-program operations, legal advice, or generic partnership strategy.
2. Strategic Context
The Cardano Product Committee has received funding to commission a portfolio of product research initiatives aligned with Cardano's long-term product direction and Strategy 2030 priorities. The purpose of the portfolio is to define the evidence Cardano needs before making product, adoption, funding, partnership, and strategic decisions.
This RFP focuses on enterprise delivery partner capacity. Its purpose is to determine what kind of partner network Cardano would need in order to support external enterprise clients through scoping, procurement, implementation, integration, support, and production use.
Enterprise adoption often requires an implementation channel. Buyers may not want to coordinate directly with protocol contributors, fragmented ecosystem teams, or unsupported open-source tooling. They may expect a vendor or delivery partner who can translate business requirements into architecture, manage delivery risk, support integrations, provide documentation, maintain service continuity, and remain accountable after launch.
Cardano has some firms with relevant delivery experience, but the ecosystem does not yet have a clear global map of capability, sector coverage, regional coverage, procurement readiness, training needs, or certification standards. The research should determine whether Cardano can build a credible delivery channel from existing and recruitable firms, what partner categories are most realistic, and what investments would make the network useful rather than symbolic.
The research should inform the Cardano Product Committee and the broader Cardano ecosystem, including enterprise adoption teams, RWA and government-market contributors, business development teams, infrastructure providers, grant allocators, delivery firms, system integrators, certification designers, and future research vendors.
3. Research Problem Statement
Cardano lacks a decision-ready enterprise delivery partner network model.
Current enterprise and adoption discussions can blur several different needs:
identifying a promising enterprise use case;
proving buyer demand;
building or configuring a technical solution;
integrating that solution into enterprise systems;
operating and supporting the deployment;
carrying procurement, accountability, and delivery risk;
creating a repeatable partner channel that can scale beyond one-off relationships.
These are not interchangeable. A strong use case may fail if no delivery partner can implement it. A technically capable ecosystem team may not be suitable for enterprise procurement. A firm may claim Cardano familiarity but lack support capacity, integration experience, regulated-industry credibility, or geographic coverage. A certification badge may increase confidence only if it is tied to real delivery capability, governance, and customer outcomes.
Cardano stakeholders need to know:
which firms can credibly deliver Cardano solutions today;
which firms could become credible with training, incentives, technical support, or certification;
which partner capabilities matter for enterprise procurement and production deployment;
which sectors and geographies are under-served;
which peer ecosystem partner models are relevant, including certification, co-selling, co-funding, implementation pathways, and quality controls;
what prevents larger consultancies or system integrators from building Cardano practices;
what partner governance model would protect enterprise trust;
which pilots should test the model before broader rollout.
Without this evidence, Cardano risks:
pursuing enterprise opportunities without implementation ownership;
treating partnership announcements as delivery capacity;
creating certification that does not signal real readiness;
subsidizing consulting work without durable adoption outcomes;
relying on a small number of regionally concentrated firms;
losing enterprise opportunities because buyers cannot find qualified implementation partners;
duplicating adjacent research on enterprise readiness, government entry, use-case positioning, brand perception, or stablecoin/L2 dependencies;
failing to create a practical channel from enterprise demand to recurring on-chain usage.
The selected vendor must close this evidence gap by producing a partner-network blueprint grounded in delivery-market evidence, enterprise buyer requirements, partner incentives, peer benchmarks, and decision-ready pilot recommendations.
4. Definitions
For this RFP:
Enterprise delivery partner means a firm or team capable of helping external clients scope, design, implement, integrate, operate, support, or maintain Cardano-related solutions in business, institutional, public-sector, RWA, regulated, or other enterprise contexts.
System integrator or SI means a firm that integrates technology into enterprise systems, workflows, data environments, operational processes, or vendor stacks. For this RFP, SI includes global consultancies, regional integrators, specialist implementation firms, and applicant-justified alternatives.
Certified partner network means a structured programme through which qualified firms are assessed, trained, recognized, supported, governed, and potentially co-sold or co-funded as delivery partners for Cardano-related enterprise opportunities.
Certification framework means the criteria, tiers, evidence requirements, training requirements, renewal rules, governance controls, and quality standards used to determine whether a firm can be represented as Cardano enterprise delivery-ready.
Enterprise delivery readiness means the degree to which a firm can support enterprise implementation needs, including technical capability, delivery management, integration experience, documentation, security and risk awareness, support model, sector experience, references, procurement fit, and accountability.
Partner tier means a level or category within a partner programme, such as certified developer firm, implementation partner, enterprise delivery partner, regional partner, vertical specialist, or applicant-proposed alternatives.
Co-funded implementation means an implementation funding structure in which cost, risk, or effort is shared between the target enterprise, the network, ecosystem funding, partner firm, or another sponsor. The selected vendor must assess whether such models are appropriate for Cardano and under what controls.
Co-selling means a coordinated go-to-market motion where Cardano ecosystem actors and partner firms jointly identify, qualify, pursue, or support enterprise opportunities.
Training pathway means the technical, commercial, delivery, documentation, support, certification, or vertical education needed for firms to become credible delivery partners.
Quality governance means the mechanisms used to maintain partner credibility over time, including certification renewal, customer feedback, delivery reviews, conflict controls, complaint handling, suspension, escalation, and removal.
Delivery signal means evidence that a firm has the capability and incentive to deliver production or pilot work, such as relevant implementation references, technical staff, sector experience, procurement fit, named delivery roles, delivery methodology, support model, and willingness to invest in Cardano capability.
Cosmetic signal means activity that appears useful but does not demonstrate delivery readiness, such as generic partnership announcements, logos on a partner page, community presence, event sponsorship, non-binding interest, or unverifiable claims of enterprise access.
The selected vendor may refine these definitions during the research design phase, but revised definitions must remain measurable, decision-useful, and evidence-based.
5. Objectives
The selected vendor will be expected to:
Map the current and potential global landscape of firms capable of delivering Cardano enterprise solutions, by capability, sector, geography, team size, enterprise experience, and readiness level.
Define the enterprise delivery capabilities required for Cardano-related deployments to move through procurement, implementation, integration, support, and production use.
Determine what certification framework, partner tiers, training pathway, governance model, and quality controls would credibly signal delivery readiness.
Benchmark partner-network models from relevant peer ecosystems, including certification, enablement, co-selling, co-funded implementation, governance, and partner recruitment structures.
Assess whether co-funded implementation structures are suitable for Cardano, and define guardrails that prevent subsidy of weak demand or poor delivery.
Identify what prevents larger consultancies or system integrators from building a Cardano practice, and what interventions would change that.
Identify priority geographies and sectors where partner development is most urgent.
Define incentives, enablement assets, technical support, commercial support, and training pathways needed to recruit and retain delivery partners.
Recommend pilot engagements and partner recruitment actions that test the model with measurable adoption outcomes.
Produce evidence thresholds for future partner certification, partner funding, co-funding, co-selling, and pilot support decisions.
Identify dependencies and handoff findings for adjacent RFPs or workstreams.
6. Decision Gates
Applicants must design their methodology around the following decision gates. A proposal that does not map methods and deliverables to these gates will be considered weak fit for this RFP.
What does the current Cardano-capable delivery partner landscape look like?
Partner landscape map covering named or anonymized firms, capability, sector, geography, team size, Cardano experience, enterprise references where available, and confidence level
Cardano has a baseline map of immediate and near-term delivery capacity
Partner recruitment remains anecdotal or dependent on informal networks
Prioritize outreach, enablement, and gap closure by firm type and region
Which delivery capabilities must a credible enterprise partner demonstrate?
Enterprise buyer/operator input, delivery-firm interviews, procurement expectations, implementation lifecycle analysis, support requirements, and technical capability taxonomy
Certification can be tied to real enterprise delivery requirements
Certification risks becoming a symbolic badge without procurement value
Define capability requirements and readiness levels
Can 10-50 person specialist delivery teams be credibly recruited and retained?
Interviews with target firms, incentive tests, opportunity-cost analysis, training/support needs, and commercial model assessment
A specialist partner channel may be a practical near-term route
The target segment may be inaccessible, under-incentivized, or too thin
Decide whether to recruit now, build demand first, or target another partner archetype
What role should larger consultancies and system integrators play?
Interviews or expert input from consultancies/SIs, analysis of demand thresholds, practice economics, risk perception, internal enablement needs, and opportunity cost
Larger firms may be reachable with specific interventions or proof points
Major consultancy recruitment is not a practical near-term path
Decide whether to pursue global SI engagement, regional SI engagement, or specialist-first strategy
Which peer ecosystem partner models are relevant to Cardano?
Benchmark of comparable ecosystems covering certification, enablement, co-selling, co-funded implementation, quality governance, and partner incentives
Cardano can adapt proven components rather than design from scratch
Peer models are not transferable or lack sufficient evidence
Select reference-model components for further design
Would co-funded implementation structures work for Cardano?
Cost-sharing benchmark, enterprise willingness evidence, partner economics, funding governance, buyer contribution logic, KPIs, and stop conditions
Co-funding can be tested with guardrails tied to adoption outcomes
Co-funding may subsidize consulting activity without durable adoption
Define pilot co-funding rules, reject the mechanism, or defer pending stronger demand evidence
Which geographies and sectors have the most urgent delivery gaps?
Gap map linking partner coverage to enterprise/RWA/government/use-case opportunities, regional procurement needs, sector capability, and confidence levels
Partner recruitment can be sequenced around adoption opportunities
Geographic or sector priorities remain speculative
Prioritize partner development by region and vertical
What training, enablement, and support assets are required?
Delivery-firm needs assessment, technical documentation review, certification input, support expectations, and comparison with peer programmes
Cardano can define what partners need to become delivery-ready
Recruitment may fail because firms lack practical enablement
Fund or coordinate training, documentation, technical support, sandbox access, or partner toolkits
What governance model protects quality and enterprise trust?
Certification renewal criteria, customer feedback loops, complaint handling, delivery review process, conflict controls, escalation, suspension, and removal options
Certification can remain credible over time
Poor delivery could damage Cardano's enterprise reputation
Define partner governance, oversight, and quality-control requirements
Which pilot engagements should test the partner model first?
Candidate opportunity analysis, partner readiness, buyer access, implementation scope, co-funding fit, KPIs, risks, and decision value
Cardano can move from research to controlled pilots
The partner model remains theoretical
Select pilot pathways, funding triggers, and stop conditions
What evidence should be required before funding, certifying, or co-selling with a partner?
Evidence threshold framework covering delivery capability, references, training completion, technical readiness, support model, conflicts, customer outcomes, and adoption KPIs
Future partner decisions can be made against a reusable standard
Partner decisions may rely on reputation, relationships, or enthusiasm
Create decision criteria for partner certification, funding, co-selling, and renewal
Which findings should be handed to adjacent RFPs or workstreams?
Cross-RFP handoff memo mapping dependencies to enterprise/RWA readiness, government entry, customer segmentation, use-case positioning, brand perception, L2/interoperability, stablecoins, or AI
RFP #8 stays focused while routing demand, buyer, or product findings correctly
Scope expands into a general enterprise strategy study
Preserve useful dependencies without duplicating other RFPs
7. Scope of Work
In scope
The selected vendor should cover:
current and potential Cardano delivery partner landscape mapping;
enterprise delivery capability taxonomy;
certification framework and partner-tier recommendation;
peer ecosystem partner-network benchmarking;
co-funded implementation model assessment;
partner recruitment and go-to-market model;
larger-consultancy and system-integrator barrier analysis;
geography and sector gap analysis;
training, enablement, technical support, and documentation requirements;
partner governance and quality-control model;
pilot engagement pathway;
evidence thresholds for certification, partner funding, co-selling, co-funding, and renewal;
public and confidential reporting.
Screening-first scope
Applicants should propose a screening phase before deep-dive research. The screening phase should identify:
candidate partner categories;
regions and sectors where partner capacity is most needed;
peer ecosystems worth benchmarking;
candidate certification models;
possible co-funded implementation models;
firms or respondent categories available for primary validation.
A narrower proposal with credible access and strong decision value may be stronger than a broad proposal that attempts to map every possible delivery firm superficially.
Partner categories to consider
Applicants may propose their own categories, but should consider:
Cardano-native delivery firms
Determine current implementation capability, support model, enterprise readiness, and scalability
Specialist blockchain implementation firms
Assess whether non-Cardano firms can be recruited or trained into Cardano delivery
Regional system integrators
Evaluate geography-specific delivery capacity and buyer access
Vertical specialists
Assess capability in sectors such as RWA, government, supply chain, identity, financial services, or enterprise data
Larger consultancies and SIs
Determine barriers to creating a Cardano practice and realistic intervention points
Infrastructure and product vendors
Identify where product teams can support, train, or co-deliver with partner firms
Peer ecosystem programme operators
Benchmark partner-network, certification, co-selling, and co-funding models
Out of scope and handoff boundaries
This RFP is not:
a contract to run the partner programme;
a contract to certify firms;
a contract to implement enterprise deployments;
an enterprise sales campaign;
a legal review of partner liability or procurement terms;
a generic Cardano partnerships strategy;
a replacement for RFP #6 enterprise and RWA readiness work;
a replacement for RFP #5 government and emerging markets entry work;
a replacement for RFP #2 use-case and competitive positioning work;
a funding mechanism for delivery firms before evidence thresholds are defined.
The selected vendor is expected to recommend a partner-network model and evidence thresholds. The vendor is not being asked to operate the partner programme, certify firms, or become the default implementation provider.
Optional / nice-to-have stretch scope
Applicants may propose optional stretch work if clearly separated from core scope and budget:
draft certification tier names and criteria;
sample partner onboarding checklist;
sample partner scorecard;
sample co-funded implementation term-sheet outline;
sample partner training curriculum outline;
mock partner directory structure;
pilot governance template;
draft RACI for partner programme ownership.
Stretch scope should not replace the required research and decision outputs.
8. Required Methodology
Applicants should propose a methodology that can answer the decision gates and produce decision-ready outputs. The methodology should be proportionate to the proposed budget and timeline.
Core research hypotheses
Applicants should test, refine, or reject the following hypotheses:
Cardano enterprise adoption is constrained by insufficient delivery partner capacity and visibility.
Enterprise buyers require accountable delivery partners before they will move from interest or pilot to production deployment.
A certification framework would be useful only if it measures real delivery readiness and is governed over time.
Specialist 10-50 person delivery teams may be more reachable in the near term than large global consultancies.
Larger consultancies may require stronger demand evidence, partner economics, support infrastructure, or lower perceived risk before building a Cardano practice.
Peer ecosystems have partner-network and co-funded implementation models that Cardano can adapt, but only after validating fit and guardrails.
Co-funded implementation may help enterprise adoption if buyer contribution, partner accountability, and post-project adoption outcomes are required.
Regional and sector gaps are likely uneven, and partner development should be sequenced around validated enterprise, RWA, government, or vertical demand.
Required evidence types
The research should include:
partner landscape evidence;
delivery capability evidence;
delivery-firm interviews or equivalent primary validation;
enterprise buyer, operator, or procurement input where feasible;
peer ecosystem benchmark evidence;
certification and governance model evidence;
commercial incentive and recruitment evidence;
co-funding model evidence;
geography and sector gap evidence;
negative-case evidence from stalled, failed, or non-adopted partner models where available.
Primary research
Applicants should propose a respondent plan that may include:
Cardano-native delivery firms;
non-Cardano blockchain implementation firms;
regional system integrators;
larger consultancies or former consultancy/SI practitioners;
enterprise buyers, operators, or procurement stakeholders;
RWA, government, supply-chain, identity, or other vertical stakeholders where relevant;
Cardano infrastructure, wallet, tooling, or product teams that partners would depend on;
peer ecosystem programme operators or knowledgeable experts;
organizations with experience in co-funded technology implementation.
Applicants should state which respondent categories are confirmed, likely, speculative, or dependent on CPC/ecosystem introductions. If respondent access is uncertain, the proposal must explain fallback methods and the effect on confidence levels.
Desk research
Desk research should cover:
public information on Cardano delivery-capable firms;
public information on peer ecosystem partner programmes;
certification and partner-tier structures from comparable technology ecosystems;
case studies of delivery partner networks and implementation channels;
co-funding, co-selling, partner enablement, and customer-success models where available;
regional and sector signals relevant to enterprise delivery coverage;
public examples of successful and failed blockchain or enterprise partner-programme models.
Applicants should avoid relying only on public partner pages, logo lists, or announcements. Those may be starting points, but they do not prove delivery readiness.
Benchmarking requirements
The selected vendor should benchmark relevant peer ecosystems and technology partner programmes. Benchmarks should include, where evidence is available:
partner types and tiers;
certification criteria;
training and enablement;
technical support model;
co-selling structure;
implementation funding or co-funding structure;
governance and quality controls;
partner incentives;
renewal requirements;
customer feedback mechanisms;
evidence of adoption outcomes;
limitations or failure modes.
The RFP does not require any named peer ecosystem to be treated as a proven model. Applicants may include ecosystems mentioned by CPC stakeholders or other relevant peer ecosystems, but must validate each benchmark and explain transferability to Cardano.
Co-funded implementation assessment
If applicants propose assessing co-funded implementation models, they should examine:
who pays;
what the enterprise must contribute;
what the partner firm contributes;
what the ecosystem or network contributes;
what milestones trigger funding;
what evidence shows buyer commitment;
what delivery and adoption KPIs are required;
how conflicts and self-dealing are prevented;
how failed or stalled projects are handled;
when co-funding should not be used.
Data sources to validate
Potential data sources may include:
public firm websites and case studies;
partner programme pages from peer ecosystems;
enterprise procurement and implementation experts;
Cardano ecosystem directories and project lists;
grant, pilot, or enterprise engagement records where accessible;
public repositories, documentation, or tooling maturity evidence;
prior research from adjacent RFPs where available;
paid expert networks or proprietary databases, if justified and inspectable.
If a data source is proprietary, paid, confidential, or uncertain, the applicant must label it as such and explain whether CPC can inspect it, whether it can be cited publicly, and what limitations apply.
Minimum evidence expectations
Applicants should propose sample sizes and coverage appropriate to their method. The proposal should justify the number and type of interviews, benchmarks, and partner profiles needed to answer the decision gates.
At minimum, the research design should explain how it will cover:
current Cardano delivery-capable firms;
at least one non-Cardano delivery-firm category;
at least one larger-consultancy or SI perspective, if feasible;
enterprise buyer/operator or procurement expectations;
peer ecosystem partner models;
regional or sector gap logic;
negative cases or reasons firms would not participate.
If any of these categories cannot be covered, the applicant must explain the limitation and its effect on decision confidence.
Avoiding Cardano insider bias
Applicants must separate:
Cardano ecosystem claims;
evidence from delivery firms seeking future funding or certification;
evidence from independent enterprise buyers or operators;
evidence from non-Cardano delivery firms;
evidence from peer ecosystem benchmarks;
vendor interpretation.
The final report must label confidence levels and source basis for important findings.
Distinguishing real adoption signal from cosmetic activity
The research should distinguish delivery readiness from:
informal partnership language;
event participation;
advisory relationships;
logo placement;
community reputation;
non-binding interest;
theoretical implementation capability;
vendor self-promotion;
one-off proof-of-concept activity without support obligations.
Real delivery signal should be tied to capability, references, technical readiness, delivery management, support model, procurement fit, customer outcomes, or willingness to invest in Cardano practice development.
9. Expected Deliverables
The selected vendor should produce the following deliverables. Vendors may combine deliverables where sensible, provided that each required output remains identifiable.
Partner Landscape Map
Map current and potential delivery firms by capability, sector, geography, team size, Cardano experience, enterprise readiness, and confidence level
Spreadsheet or table plus narrative summary
Establish baseline delivery capacity
Includes classification criteria, source basis, readiness levels, and confidence notes; does not rely only on logos or claims
Prioritize partner recruitment and gap closure
Becomes a directory without readiness evidence
Enterprise Delivery Capability Model
Define capabilities required for enterprise-grade Cardano implementation and support
Framework and scoring model
Anchor certification in real delivery requirements
Covers technical, integration, delivery management, support, procurement, security/risk, documentation, and sector experience
Define readiness levels and certification criteria
Uses vague terms such as "experienced" without testable evidence
Certification Framework Recommendation
Recommend partner tiers, criteria, evidence requirements, training, renewal, and governance
Framework document
Decide whether and how to certify partners
Ties every criterion to delivery readiness or procurement trust; includes renewal and removal logic
Launch or defer certification design
Creates a badge without quality controls
Peer Ecosystem Reference-Model Benchmark
Compare relevant partner, certification, co-selling, and co-funding models from peer ecosystems or technology markets
Benchmark report and comparison table
Adapt proven models where transferable
Includes source basis, transferability assessment, limitations, and relevance to Cardano
Select model components to adapt
Copies a model without proving fit
Co-Funded Implementation Model Assessment
Assess if and how shared-cost implementation structures could work for Cardano
Options analysis and guardrail framework
Decide whether to test co-funded pilots
Defines payer roles, buyer contribution, milestone triggers, KPIs, conflicts, stop conditions, and misuse risks
Approve, reject, or pilot co-funding
Subsidizes consulting without buyer commitment or adoption outcomes
Partner Recruitment and Go-to-Market Model
Define target partner archetypes, incentives, outreach sequence, co-selling model, and retention logic
GTM model and action plan
Recruit and retain qualified firms
Identifies target firm types, value proposition, required support, incentive logic, and adoption link
Launch recruitment pathway
Assumes firms will join without evidence
Geography and Sector Gap Analysis
Identify priority regions and sectors where delivery capacity is missing or urgent
Gap map and prioritization table
Sequence partner development
Links gaps to enterprise/RWA/government/use-case opportunities and confidence levels
Prioritize regional and vertical partner development
Treats all regions or sectors as equally important
Larger-Consultancy Barrier Analysis
Explain what prevents larger consultancies/SIs from building a Cardano practice
Findings memo
Decide whether major-SI engagement is realistic
Includes demand, economics, risk, support, training, brand/perception, and opportunity-cost factors
Choose global SI, regional SI, or specialist-first route
Reduces barrier to lack of awareness
Training and Enablement Requirements Map
Identify assets partners need to become delivery-ready
Requirements register
Fund or coordinate enablement
Covers technical documentation, reference architectures, training, sandbox access, support escalation, sales collateral, and vertical materials
Define enablement workstream
Produces generic training ideas not tied to partner gaps
Partner Governance and Quality-Control Model
Define oversight, renewal, feedback, conflict, complaint, escalation, and removal mechanisms
Governance model
Protect enterprise trust
Includes accountability roles, evidence checks, renewal criteria, customer feedback, and handling of poor delivery
Govern certification and partner quality
Fails to manage low-quality or conflicted partners
Pilot Engagement Pathway
Recommend pilot partner engagements, co-funding tests, KPIs, and stop conditions
Pilot roadmap
Move from research to controlled action
Identifies candidate pilot types, partner criteria, buyer contribution, delivery milestones, adoption KPIs, and risks
Launch pilot(s) or defer
Recommends pilots without measurable outcomes
Evidence Threshold Framework
Define minimum evidence before funding, certifying, co-selling, co-funding, or renewing partners
Decision framework
Standardize future partner decisions
Provides testable thresholds and confidence levels for each decision type
Create reusable partner decision criteria
Leaves future decisions relationship-driven
Executive Decision Memo
Summarize findings, confidence, options, recommended actions, and no-go areas
Short memo
Support CPC and ecosystem decision-making
States what to do, what not to do, what to test, and why
Decide next actions
Avoids hard recommendations
Final Research Report
Full evidence base, methodology, findings, limitations, recommendations, and appendices
Markdown/PDF/report format
Preserve traceable research record
Answers every decision gate and includes limitations and source confidence
Publication and internal reference
Long report without decision utility
Final Presentation
Present findings and recommended actions to CPC/designated reviewers
Slide deck or presentation
Enable review and discussion
Clear summary of decision gates, evidence, recommendations, and limitations
Approval or revision of next steps
Promotional deck lacking evidence
Public Summary
Non-confidential summary for the Cardano ecosystem
Markdown/web-ready summary
Share useful findings while protecting sensitive data
Includes methodology overview, high-level findings, recommendations where publishable, and limitations
Ecosystem learning and transparency
Reveals sensitive data or says too little to be useful
Cross-RFP Handoff Memo
Route findings to adjacent RFPs and workstreams
Memo or appendix
Prevent duplication and preserve dependencies
Identifies handoffs to enterprise/RWA readiness, government, use-case, brand, L2/interoperability, stablecoins, AI, or other workstreams
Coordinate action beyond RFP #8
Expands scope instead of handing off
10. Acceptance Criteria
The final work will be considered acceptable only if it answers the decision gates with traceable evidence and decision-ready recommendations.
At minimum, the final outputs must:
map current and potential delivery partners using explicit readiness criteria;
distinguish delivery capability from reputation, relationship, or announcement activity;
define enterprise delivery capability requirements in testable terms;
recommend or reject a certification framework with clear reasoning;
benchmark relevant peer models and assess transferability to Cardano;
assess co-funded implementation models with guardrails, KPIs, and stop conditions;
identify what would attract or deter specialist firms and larger consultancies;
identify priority geography and sector gaps;
define training, enablement, and technical support requirements;
define governance and quality controls for certification and partner management;
recommend pilot pathways or explain why pilots should be deferred;
include evidence thresholds for future funding, certification, co-selling, co-funding, and renewal decisions;
label confidence levels and limitations;
include public-summary and confidential-findings boundaries;
disclose conflicts and manage conflicted evidence;
include cross-RFP handoff logic.
Decision linkage
Each deliverable must state which decision gate it supports and what decision it enables. Deliverables that diagnose a problem without enabling a decision should be revised.
Evidence quality
Evidence should be source-labeled and classified by confidence level. Where evidence depends on confidential respondents, proprietary data, or vendor judgment, the final report must explain how reviewers can assess reliability without exposing sensitive information.
Unacceptable outputs
Outputs may be considered unacceptable if they:
provide only a generic partner-program recommendation;
list firms without readiness evidence;
assume certification is the correct answer without testing alternatives;
recommend co-funding without buyer contribution, delivery KPIs, conflict controls, or stop conditions;
rely mainly on Cardano insider opinion;
do not include non-Cardano or enterprise buyer/operator evidence where feasible;
present the vendor's own delivery services as the implied solution;
fail to disclose conflicts;
avoid negative findings;
cannot explain what Cardano stakeholders should do differently.
11. Vendor Eligibility
Applicants may be research firms, strategy consultancies, ecosystem research teams, enterprise technology analysts, delivery-channel specialists, market research firms, or qualified consortia.
Applicants should demonstrate capability in at least several of the following areas:
enterprise technology delivery or system integrator channel research;
partner programme, certification, or channel strategy design;
blockchain ecosystem, Web3, or open-source ecosystem research;
enterprise buyer, procurement, or implementation research;
partner recruitment and go-to-market analysis;
benchmarking of technology partner programmes;
qualitative interviews with senior commercial, delivery, or procurement stakeholders;
data handling for commercially sensitive respondents;
decision-oriented research for grant, product, or ecosystem strategy contexts.
Subcontracting is allowed if roles, responsibilities, costs, and conflicts are clearly disclosed. Applicants should identify which team members will conduct research, interviews, analysis, benchmarking, and writing.
Applicants that are themselves delivery firms, system integrators, consultancies, certification candidates, or potential beneficiaries of future partner funding may apply, but must disclose conflicts and explain how they will preserve research independence.
12. Proposal Submission Requirements
Applicants must follow the shared Submission Pack and include the common documents: cover letter, technical proposal, budget proposal, team credentials, evidence access plan, ethics/data handling statement, and conflicts declaration.
Applicants bidding on multiple Product Research Initiative RFPs must disclose shared staffing, shared respondent recruitment, shared evidence collection, and any assumptions that could create respondent fatigue or duplicated outreach.
For this RFP, the technical proposal must also include:
partner category and screening approach;
delivery capability model approach;
firm, buyer, SI, or consultancy access plan;
peer ecosystem partner-model benchmark approach;
certification, governance, and quality-control design logic;
co-funded implementation assessment and guardrail approach.
Budgets should explain how cost relates to delivery-firm access, peer benchmark depth, enterprise buyer input, sector/geography coverage, and decision value.
13. Evaluation Guidance
Proposals will be assessed using the CPC standard research grant evaluation framework: Fit to Grant Objectives, Team Capability, Proposal Quality and Execution Plan, and Cost Efficiency. The full scoring framework is maintained on the shared evaluation page.
For this RFP, strong fit means the proposal can define the delivery capabilities enterprise buyers need, map current and recruitable partner capacity, benchmark relevant peer models, and recommend a certification and partner-network model tied to real delivery outcomes.
A strong proposal should test whether specialist delivery firms, regional integrators, larger consultancies, and vertical specialists can be recruited or enabled. It should define co-funded implementation guardrails and quality governance without becoming partner-program operations.
Proposals should score lower if they rely on generic partnership strategy, symbolic certification, weak firm access, unverifiable delivery claims, or subsidy models without adoption thresholds.
Cost should be judged against evidence value, not lowest price. Higher-cost proposals may be justified by stronger delivery-firm access, peer benchmark depth, enterprise buyer input, or more useful pilot and governance design.
14. Timeline and Milestones
Final calendar dates will be confirmed on the Product Research Initiatives - Grants page before the call opens.
RFP publication
Confirmed on grants page
Open call for proposals
Clarification window opens
Confirmed on grants page
Applicants may submit questions
Clarification window closes
Confirmed on grants page
Final clarification responses issued
Proposal deadline
Confirmed on grants page
Applicant submissions due
Award notification
Confirmed on grants page
Selected vendor notified
Kickoff
Project week 1
Confirm objectives, decision gates, scope, workplan, communication cadence, confidentiality expectations, and public-summary expectations
Research design alignment
Applicant-proposed timing
Align on respondent categories, partner taxonomy, benchmark plan, evidence standards, certification assumptions, co-funding assessment, and data handling before fieldwork
Screening review
Applicant-proposed timing
Review initial partner categories, peer models, candidate regions/sectors, and deep-dive selection
Stakeholder access check
Applicant-proposed timing
Surface recruitment issues, weak access, missing respondent categories, confidentiality constraints, or substitutions needed
Early findings review
Applicant-proposed timing
Review initial partner landscape signals, certification requirements, peer benchmark lessons, and possible false positives
Interim findings review
Applicant-proposed timing
Test whether evidence is answering decision gates and whether scope needs adjustment
Draft deliverables review
Applicant-proposed timing
Review partner landscape, capability model, certification framework, peer benchmark, co-funding assessment, GTM model, and pilot pathway
Final report and presentation
Applicant-proposed timing
Present final findings, confidence levels, limitations, decisions enabled, and recommended actions
Public summary review
Applicant-proposed timing
Confirm what can be published and what should remain confidential
Public summary
Applicant-proposed timing
Publish non-confidential summary
Applicants should propose a timeline appropriate to their methodology. Unrealistic timelines should be avoided, especially where primary external validation, larger-consultancy access, peer benchmark research, or commercially sensitive partner interviews are proposed.
15. Governance, Reporting, and Communication
The selected vendor will participate in structured checkpoints. The process should protect research quality without turning the work into committee-managed consulting.
Kickoff
Confirm objectives, decision gates, scope, workplan, communication cadence, confidentiality expectations, and public-summary expectations
Research Design Review
Align on respondent categories, partner taxonomy, benchmark plan, certification assumptions, co-funding assessment, evidence standards, and data handling before fieldwork
Screening Review
Review initial partner categories, peer models, candidate regions/sectors, and deep-dive selection
Stakeholder Access Check
Surface recruitment issues, weak access, missing respondent categories, confidentiality constraints, or substitutions needed
Early Findings Review
Review initial partner landscape signals, certification requirements, peer benchmark lessons, and possible false positives
Interim Findings Review
Test whether evidence is answering decision gates and whether scope needs adjustment
Draft Deliverables Review
Review partner landscape, capability model, certification framework, peer benchmark, co-funding assessment, GTM model, governance model, and pilot pathway
Final Presentation
Present final findings, confidence levels, limitations, decisions enabled, and recommended actions
Public Summary Review
Confirm what can be published and what should remain confidential
Before primary fieldwork begins, the vendor should align with CPC or a designated review group on:
respondent categories;
recruitment strategy;
partner landscape taxonomy;
delivery readiness criteria;
peer benchmark selection;
certification framework assumptions;
co-funding assessment criteria;
minimum evidence standard;
data handling and confidentiality approach;
treatment of commercially sensitive partner or buyer evidence;
public-summary boundaries.
This review should protect research quality without directing the findings. The vendor should retain methodological independence and should be expected to report inconvenient or negative findings.
The vendor should not wait until the final report to disclose:
weak respondent access;
unsupported partner capability claims;
evidence that certification would not be credible;
evidence that co-funding would create poor incentives;
evidence that larger consultancies are not reachable in the near term;
major regional or sector coverage gaps;
conflicts of interest;
scope creep into adjacent RFPs.
16. Risks, Bias Controls, and Safeguards
Applicants must include a research integrity plan.
Cardano insider bias
Separate ecosystem claims from independent delivery-firm, enterprise buyer/operator, and peer benchmark evidence
Vendor self-interest
Disclose whether applicant or subcontractors may seek certification, delivery work, co-funding, or partner status
Cosmetic partnership signal
Require delivery capability, references, support model, training needs, and procurement fit evidence
Certification theater
Tie certification criteria to measurable delivery readiness and governance controls
Co-funding misuse
Require buyer contribution, delivery milestones, adoption KPIs, conflict controls, and stop conditions
Large consultancy overfocus
Test major-SI feasibility against demand, economics, risk, support needs, and opportunity cost
Partner directory trap
Use readiness scoring and confidence levels rather than simple firm lists
Peer model overcopying
Assess transferability, context, limitations, and failure modes before recommending adaptation
Weak access
Disclose recruitment limitations early and adjust confidence levels
Conflicted respondents
Label evidence from firms seeking future funding, certification, or commercial advantage
Regional blind spots
Identify geographic coverage limitations and confidence levels
Scope creep
Use cross-RFP handoff logic for enterprise demand, government entry, use-case positioning, brand perception, stablecoins, L2/interoperability, or AI
Confidentiality reducing public usefulness
Produce confidential full evidence plus publishable anonymized findings
The final report must include a limitations section explaining what the research can and cannot support.
17. Clarification Process
Applicants may submit clarification questions during the clarification window.
Questions may address:
partner categories;
certification scope and assumptions;
expected respondent categories;
treatment of named versus anonymized partner firms;
larger-consultancy or SI access expectations;
peer ecosystem benchmark scope;
co-funded implementation model boundaries;
treatment of confidential partner, buyer, or procurement evidence;
public versus confidential outputs;
overlap with enterprise/RWA readiness or government entry work;
budget format;
optional stretch scope.
Responses should be maintained in a rolling Q&A log where practical so applicants receive consistent information. If a clarification materially changes scope, deadline, eligibility, or deliverables, the RFP timeline may be adjusted.
The clarification process also helps assess applicant judgment. Strong questions may demonstrate understanding of delivery-channel economics, certification credibility, enterprise procurement, partner governance, co-funding risks, and methodological tradeoffs.
18. Data Handling, Confidentiality, and Public Summary
The selected vendor must provide a data handling plan covering:
informed consent for interviews, expert calls, workshops, or surveys;
recording and transcription policy;
anonymization approach;
raw notes and transcript handling;
storage and access controls;
retention and deletion plan;
treatment of sensitive partner, buyer, procurement, commercial, or delivery information;
treatment of proprietary, paid, or respondent-provided data;
separation of public findings, confidential findings, and raw data;
publication boundaries.
Research outputs should distinguish:
public findings suitable for ecosystem publication;
confidential findings suitable only for CPC or approved reviewers;
sensitive respondent or firm information that should not be published;
raw data that should not be published;
proprietary data that CPC can inspect but may not publish;
vendor judgment where primary data cannot be disclosed.
A public summary is expected unless specific findings cannot be published for justified confidentiality reasons.