RFP 02: Use Case Landscape and Competitive Positioning
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
Where do Cardano's use cases actually stand today, where does Cardano win or lose against peer blockchain ecosystems, and which verticals should Cardano prioritize, partner into, wait on, or deprioritize over the next 24 months?
Evidence gap
Cardano has visible projects, promising vertical narratives, and partial evidence of activity, but it does not yet have an operator-grounded, vertical-by-vertical view of current use-case traction, competitive position, and the reasons operators choose, reject, pause, leave, or ignore Cardano.
Without this evidence, Cardano stakeholders risk making vertical investment, funding, partnership, and positioning decisions based on aspiration, visibility, or isolated examples rather than durable adoption signal and practical competitive advantage.
Decision unlocked
This research should enable Cardano stakeholders to decide which verticals deserve investment, which require partner or ecosystem intervention, which should be watched but not prioritized yet, and which should not be emphasized without stronger evidence.
Expected outputs
The selected vendor will produce a Cardano use-case map, vertical screening matrix, competitive benchmark, operator win/loss register, vertical wedge analysis, real adoption signal framework, executive decision memo, final research report, public summary, and cross-RFP handoff memo.
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.
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 combines use-case landscape and competitive positioning because the same operator evidence can answer both questions. A use-case map without competitive context may overstate Cardano's position. A competitive benchmark without grounding in actual verticals may become a generic positioning exercise.
The work should identify where Cardano has defensible traction, where it is undifferentiated, where it is losing, and where it may be wasting effort. It should also distinguish real adoption from cosmetic activity such as announcements, one-off pilots, social attention, or speculative volume that does not lead to recurring use.
The research should inform the Cardano Product Committee and the broader Cardano ecosystem, including grant allocators, product contributors, business development teams, partner teams, builders, and future research vendors.
3. Research Problem Statement
Cardano lacks a systematic, decision-ready map of which use cases are live and growing, live but flat, dormant, failed, or unproven.
Cardano also lacks a product-level competitive benchmark showing where it wins and loses against relevant peer ecosystems by vertical. Broad claims about security, decentralization, cost, performance, reliability, governance, or ecosystem maturity are not sufficient unless they are tied to operator decisions and observable adoption conditions.
This creates a strategic problem:
vertical investment decisions may be based on narratives rather than evidence;
funding may continue flowing to use cases with weak adoption signal;
strong verticals may be under-supported because their competitive edge has not been documented;
Cardano may continue competing in areas where it lacks credible differentiation or meaningful pull;
partner and go-to-market efforts may lack a clear view of where the ecosystem should attack, partner, wait, stop, or hand off to another initiative;
future RFPs may duplicate operator research unless this study produces clear handoff findings.
The selected vendor must close this evidence gap by combining use-case audit, vertical screening, competitive benchmarking, operator win/loss research, and adoption-signal assessment.
4. Definitions
For this RFP:
Use case means a recurring application of Cardano infrastructure by users, builders, operators, institutions, partners, or applications.
Vertical means a market or problem domain where blockchain infrastructure may support adoption, usage, settlement, verification, identity, coordination, compliance, privacy, or value transfer.
Operator means a builder, application team, enterprise, institution, integrator, infrastructure provider, liquidity provider, or other actor making practical chain-selection, deployment, integration, or adoption decisions.
Operator decision means a documented choice to build on, deploy on, integrate with, reject, leave, pause, migrate from, avoid, or not shortlist Cardano or a peer blockchain ecosystem.
Real adoption signal means evidence of recurring usage, retained value, transactions with an identifiable purpose, production deployment, revenue relevance, signed implementation, operational dependency, durable user behavior, or another vertical-specific indicator of meaningful adoption.
Cosmetic activity means attention, announcements, one-off pilots, social engagement, token-price movement, isolated demos, stated interest, or short-lived incentive-driven activity without evidence of recurring use or commitment.
The selected vendor may refine these definitions during the research design phase, but revised definitions must remain decision-useful and evidence-based.
5. Objectives
The selected vendor will be expected to:
Create a use-case map classifying current and historical Cardano use cases by maturity and evidence quality.
Screen relevant verticals and select a justified subset for deeper analysis.
Benchmark Cardano against relevant peer ecosystems by vertical at the product and operator level.
Identify where Cardano wins, loses, is undifferentiated, or lacks sufficient evidence.
Produce a win/loss register targeting at least 15 operator decisions, confidentially named to CPC where necessary. A narrower register may be acceptable only if the applicant justifies why fewer high-quality decisions produce stronger evidence than broader shallow coverage.
Distinguish real adoption signal from cosmetic activity by vertical.
Recommend where Cardano should attack, partner, wait, stop, or hand off.
Identify findings that should inform adjacent Product Research Initiative RFPs.
Produce a reusable scoring and evidence framework that Cardano stakeholders can refresh in future planning cycles.
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.
Which Cardano use cases are actually live, growing, flat, dormant, failed, or unproven?
Use-case inventory, operator interviews, observable usage signals, on-chain or product data where available, clear status taxonomy
Cardano has a factual baseline of current use-case maturity by vertical
Current use-case claims remain anecdotal or promotional
Establish the use-case map and stop treating visibility as adoption
Which verticals show real adoption signal rather than cosmetic activity?
Evidence of recurring usage, meaningful transactions, retained liquidity/value, revenue relevance, pilots moving toward production, or operator commitment
Some verticals have measurable adoption potential
Visible activity does not yet show durable usage or economic relevance
Prioritize verticals with stronger impact signal and define adoption tiers
Where does Cardano win or lose against peer ecosystems by vertical?
Competitive benchmark against relevant peers per vertical, including Solana, Ethereum L2s, and others where justified
Cardano's advantages and weaknesses differ by vertical and can be stated with evidence
Cardano has no clear advantage in the tested vertical, or evidence is too weak
Decide where to attack, partner, wait, or stop competing
Why do operators choose, reject, leave, pause, or ignore Cardano?
Win/loss register targeting at least 15 operator decisions, confidentially named if needed, with attributed reasons and evidence confidence
Cardano understands the actual decision criteria behind wins and losses
Operator decisions cannot be explained beyond speculation or narrative
Target product, partner, funding, or positioning fixes against real blockers
Which verticals deserve deep analysis versus light screening?
Vendor-justified vertical selection model, screening criteria, evidence availability assessment, and rationale for exclusions
The study focuses effort where evidence value and strategic relevance are highest
Scope becomes too broad, shallow, or arbitrary
Approve a focused research design while preserving a light scan of adjacent opportunities
Which verticals should Cardano prioritize over the next 24 months?
Comparative vertical scoring across traction, competitive position, ecosystem fit, market pull, operator access, dependency burden, and evidence confidence
Cardano can rank verticals and explain tradeoffs
Findings do not support a defensible priority order
Set vertical investment priorities for funding, partner engagement, and product strategy
What action should be taken for each priority vertical?
Vertical wedge analysis: attack, partner, wait, stop, or hand off, with rationale and required next evidence
Each vertical maps to a concrete strategic posture
Recommendations stay generic or all-positive
Convert research into portfolio decisions, pilots, partner work, or deprioritization
Which findings should be handed to other RFPs?
Boundary analysis across stablecoins, enterprise/RWA, government/emerging markets, L2/interoperability, brand, AI, and partner networks
RFP 2 informs adjacent work without trying to answer everything itself
Scope overlaps duplicate other RFPs or misses dependencies
Produce clean cross-RFP handoffs and reduce repeated operator asks
7. Scope of Work
In scope
The selected vendor should cover:
Cardano use-case audit;
vertical screening and justified deep-dive selection;
competitive benchmarking by selected vertical;
operator win/loss research;
adoption-signal framework;
vertical wedge analysis;
cross-RFP handoff notes;
public and confidential reporting.
Vertical screening guidance
Applicants should propose their own vertical taxonomy and explain how it supports the RFP decision gates.
The RFP does not require a full deep dive across every possible vertical. Applicants should provide a useful overview of the broader use-case landscape, then focus deeper research where their evidence access, methodology, and strategic rationale are strongest. A proposal that attempts to deeply analyze too many verticals without sufficient evidence access may be considered weak.
Applicants should explain whether and how they will screen verticals such as:
RWA/tokenisation;
humanitarian or public-good infrastructure;
IoT/machine identity;
digital product passports;
stablecoin infrastructure;
DeFi;
institutional DeFi;
privacy solution applications;
supply-chain traceability;
agritech;
other applicant-justified verticals.
This list is guidance, not a fixed required list. Applicants may combine, rename, add, or exclude verticals if they explain the rationale and decision value. Some minimum vertical coverage is expected, but applicants are not required to force specific verticals into scope where they lack evidence access or where another vertical would better answer the RFP.
For each screened vertical, the vendor should assess:
evidence of current Cardano activity;
evidence of peer-chain activity;
operator availability;
availability and relevance of on-chain or product usage evidence;
relevance to Cardano 2030 adoption goals;
dependency on adjacent constraints such as stablecoins, L2/interoperability, compliance, delivery partners, or brand perception;
expected decision value of deeper research.
Out of scope and handoff boundaries
This RFP should remain focused on use-case maturity, competitive positioning, operator decisions, vertical prioritization, and adoption signal. It may identify findings relevant to other Product Research Initiatives, but it should not attempt to fully answer those initiatives.
Customer segmentation
Operator types, decision criteria, and segment references where they explain vertical choice
Full customer segmentation and persona framework
Stablecoins
Stablecoin infrastructure as a screened or deep-dive vertical where justified
Liquidity incentive design, market-maker strategy, or venue-level activation plan
Enterprise and RWA
Enterprise or RWA use-case maturity and competitive position
Full enterprise readiness, SLA, compliance, or production-conversion assessment
Government and emerging markets
Vertical evidence where public-sector or emerging-market use cases appear
Country-level strategy, regional regulatory playbooks, or government entry plans
L2 and interoperability
Interoperability or scaling as operator-attributed win/loss factors
Full L2 demand study, bridge strategy, or technical requirements register
Brand perception
Brand or trust concerns only where operators cite them as decision factors
Full awareness baseline, perception study, or messaging research
AI
AI as a screened vertical if the applicant can justify evidence value
Full AI commercial positioning strategy
Delivery partners
Partner or integrator availability as a competitive-positioning factor
Full delivery partner network design or certification model
Findings that materially affect another research initiative should be captured in the Cross-RFP Handoff Memo rather than expanded inside this RFP.
Optional / nice-to-have stretch scope
Applicants may propose optional stretch scope, priced separately, such as:
deeper negative-case research with operators who considered Cardano but selected another chain;
additional deep-dive verticals beyond the core proposed scope;
more extensive public-source triangulation or analytics work;
a reusable annual refresh model;
additional public-facing artifacts or community workshops;
deeper cross-RFP handoff analysis.
8. Required Methodology
The selected vendor must use a mixed-method research design. Desk research alone is not sufficient.
The methodology should include:
existing evidence review;
use-case inventory;
vertical screening;
operator interviews;
non-Cardano and negative-case respondent coverage;
competitive benchmarking;
on-chain or product usage validation where available and meaningful;
adoption-signal assessment;
evidence confidence ratings;
decision-gate mapping.
Core research hypotheses
Applicants should test, refine, or reject hypotheses such as:
Cardano has identifiable use cases that can be classified by maturity
Whether use cases can be placed into live and growing, flat, dormant, failed, or unproven categories using evidence rather than promotion
Creates the baseline use-case map
Cardano's competitive position differs by vertical
Whether Cardano wins, loses, or is undifferentiated depending on operator needs, product requirements, ecosystem maturity, and peer alternatives
Prevents generic conclusions
Some verticals have stronger real adoption signal than others
Whether verticals show recurring usage, production dependency, retained value, meaningful transaction activity, revenue relevance, or durable operator commitment
Guides vertical prioritization
Operators can explain Cardano wins and losses
Whether chain-selection, rejection, pause, or migration decisions have attributable reasons
Directs product, partner, funding, BD, and positioning interventions
Some visible Cardano activity is cosmetic rather than durable
Whether announcements, pilots, social attention, or one-off experiments translate into sustained usage or operational commitment
Prevents investment based on weak impact signals
Cardano should not compete equally in every vertical
Whether evidence supports attack, partner, wait, stop, or handoff recommendations per vertical
Produces actionable portfolio choices
Required evidence types
Operator interviews
Explain why operators choose, reject, pause, leave, or ignore Cardano or peer chains
Required
Cardano use-case inventory
Identify current and historical use cases and classify maturity
Required
Competitive benchmark
Compare Cardano with relevant peer ecosystems by vertical
Required
On-chain or product usage data
Validate adoption signal where data is available and meaningful
Required where available; limitations must be stated
Desk research
Establish vertical context, peer activity, public evidence, and candidate use cases
Required
Negative-case evidence
Capture losses, rejected hypotheses, stalled projects, and competitor wins
Required
Expert or stakeholder interviews
Validate vertical definitions, competitor context, and evidence interpretation
Recommended
Public-source triangulation
Check operator claims against public data, documentation, product status, or transaction evidence
Required where possible
Primary research expectations
Applicants must include primary validation. The proposal should explain:
who will be interviewed;
why those respondents are relevant;
how respondents map to proposed verticals;
how non-Cardano and negative-case respondents will be reached;
how insider bias will be controlled;
how confidential operator decisions will be handled.
Indicative interview expectations:
Cardano operators/builders across candidate verticals
[15-25]
Classify use cases and explain current traction
Peer-chain or non-Cardano operators
[10-20]
Compare why operators select alternatives
Negative-case operators
[5-10]
Understand rejection, pause, migration, or failure reasons
Cross-ecosystem experts, integrators, or infrastructure providers
[5-10]
Validate competitive and vertical context
Total suggested range
[35-65]
To be justified by applicant scope and budget
Applicants may propose a different sample, but they must explain why it is sufficient to answer the decision gates.
The final win/loss register should target at least 15 operator decisions. Operator identities may be confidentially disclosed to CPC if public naming is not possible, but the vendor should maximize permissioned public attribution where operators consent. Applicants proposing fewer decisions must justify why the narrower sample still answers the decision gates.
Benchmarking requirements
The competitive benchmark should compare Cardano with relevant peer ecosystems by vertical. Peers may include Solana, Ethereum L2s, Ethereum mainnet, Avalanche, Polkadot, Cosmos chains, Bitcoin L2s or sidechains, or other ecosystems where justified by the vertical.
Applicants must explain:
why each peer was selected;
what is being compared;
what evidence supports each score;
where the benchmark relies on public evidence versus operator evidence;
what confidence level should be attached to each score;
what limitations apply.
Benchmark dimensions may include:
operator adoption;
product maturity;
integration friction;
transaction cost and performance fit;
liquidity or capital availability;
developer/tooling ecosystem;
compliance and enterprise readiness;
partner/integrator availability;
user distribution;
brand or trust perception when operator-attributed;
security, reliability, or technical differentiation;
ecosystem incentives and support;
ability to produce durable on-chain activity.
The benchmark must compare practical adoption conditions, not just protocol features or public narratives. Benchmark scores must include evidence notes and confidence labels to avoid false precision.
Adoption signal standard
The research must distinguish real adoption from cosmetic activity.
Examples of stronger adoption signals include:
recurring production usage;
transactions tied to an identifiable use case;
retained liquidity or value over a meaningful period;
active users or customers using the application repeatedly;
revenue, fees, or treasury-relevant value flows;
signed pilots that progress toward production;
third-party operators depending on Cardano infrastructure;
migration from another chain with stated rationale;
measurable reduction in cost, risk, latency, fraud, verification burden, or coordination cost for an operator;
ongoing partner or integrator activity with committed resources.
Examples of weak or cosmetic signals include:
announcements without implementation;
one-off demos;
social-media attention;
token-price movement;
short-lived incentive-driven volume without retention;
stated interest without budget, users, or deployment plan;
pilots with no path to repeated use;
isolated transactions that do not represent a durable workflow;
unverifiable claims of partnerships or traction.
The vendor must define adoption signal thresholds per vertical. A public-sector pilot, DeFi protocol, privacy application, supply-chain traceability deployment, and institutional DeFi deployment may require different evidence standards.
Data sources
Applicants should identify data sources and their access status. Potential sources may include:
on-chain analytics platforms;
dApp dashboards;
protocol analytics;
ecosystem project data;
public project documentation;
grants and funding records;
GitHub or developer activity where relevant;
interviews and survey instruments;
public competitor ecosystem reports;
transaction, TVL, liquidity, usage, or retention datasets;
enterprise or operator-provided evidence under confidentiality.
Any source that is proprietary, paid, incomplete, or uncertain must be marked "requires validation."
Vendors must not invent Cardano ecosystem statistics. Every statistic must include source, date, methodology, and limitations.
Bias controls
Applicants must describe controls for:
Cardano insider bias;
survivorship bias from only studying active projects;
availability bias from only researching visible projects;
positive-case bias from avoiding losses;
respondent conflict of interest;
competitor narrative bias;
overclaiming from thin on-chain data;
treating correlation as adoption proof;
cherry-picking verticals that flatter Cardano.
Required controls should include:
separate Cardano and non-Cardano respondent categories;
inclusion of negative cases;
evidence confidence ratings;
source traceability;
limitations section;
clear distinction between public evidence, confidential evidence, and vendor judgment.
What should not count as evidence
The following should not be treated as sufficient evidence:
generic blockchain market reports without vertical-specific Cardano relevance;
public narratives about Cardano's strengths without operator validation;
competitor comparisons based only on technical white papers;
Cardano community sentiment presented as market demand;
project lists without status, usage, or operator attribution;
announcements presented as adoption;
use-case claims without dates or evidence;
TVL, transaction count, or wallet count used without explaining what behavior it represents;
interviews with only Cardano advocates;
all-positive findings that do not identify losses, failures, or weak verticals;
market sizing without assumptions and source traceability.
9. Expected Deliverables
Deliverables are grouped into core decision outputs, supporting research outputs, and public/community-facing outputs.
Core decision outputs
Executive Decision Memo
Short synthesis of what Cardano should do differently based on the findings
PDF/doc, max [8] pages
Give CPC and ecosystem stakeholders the decision answer without requiring them to read the full report
States priority verticals, deprioritized verticals, attack/partner/wait/stop recommendations, evidence confidence, and next actions
Cardano Use-Case Map
Classification of current and historical Cardano use cases by maturity
Table/database plus narrative
Establish the factual baseline of Cardano use-case traction
Each use case is classified as live and growing, live but flat, dormant, failed, or unproven; each classification includes evidence source, date, operator attribution where available, and confidence level
Vertical Screening Matrix
Light screening of candidate verticals and rationale for deep-dive selection
Matrix/table
Decide which verticals deserve deeper analysis and which should be deferred or excluded
Screens applicant-defined vertical universe; explains inclusion/exclusion logic; covers relevant verticals where justified without treating the guidance list as mandatory
Competitive Benchmark
Vertical-by-vertical comparison of Cardano against relevant peer ecosystems
Scored benchmark table plus methodology note
Show where Cardano wins, loses, or lacks differentiation by vertical
Defines peer set per vertical; explains scoring dimensions; cites evidence for each score; separates operator evidence from desk research; includes limitations and confidence labels
Operator Win/Loss Register
Record targeting at least 15 operator decisions involving Cardano or relevant peer ecosystems
Confidential CPC register plus publishable anonymized version
Identify why operators choose, reject, pause, leave, or ignore Cardano
Records decision type, vertical, operator identity confidentially to CPC where needed, public/anonymized summary, attributed reason, evidence source, confidence level, and rationale if fewer than 15 decisions are used
Vertical Wedge Analysis
Recommendation for each priority vertical: attack, partner, wait, stop, or hand off
Table plus narrative
Convert evidence into strategic action
Each vertical includes recommended posture, rationale, required next action, dependency, evidence confidence, and what would change the recommendation
Real Adoption Signal Framework
Criteria for distinguishing durable adoption from cosmetic activity by vertical
Framework/table
Prevent future funding and strategy decisions from relying on vanity signals
Defines strong, medium, weak, and excluded signals per vertical; includes examples; explains how evidence should be measured or verified
Supporting research outputs
Research Methodology Appendix
Full explanation of methods, samples, sources, and limitations
Appendix
Make findings auditable
Lists interview categories, sample counts, recruitment channels, data sources, source limitations, bias controls, and analysis method
Evidence Register
Source-by-source record supporting major claims
Spreadsheet/table
Preserve traceability
Every major factual claim in core outputs maps to a source, interview, dataset, or explicit vendor judgment
Cross-RFP Handoff Memo
Findings that should inform other Product Research Initiative RFPs
Memo, max [5] pages
Keep RFP 2 focused while preserving useful dependencies
Maps findings to stablecoins, enterprise/RWA, government/emerging markets, L2/interoperability, brand, AI, partner networks, or customer segmentation; explains why the issue is a handoff
Final Research Report
Full research report covering methods, findings, evidence, and recommendations
PDF/doc
Provide the complete research record
Includes executive summary, methodology, use-case map, vertical screening, benchmark, win/loss synthesis, adoption signal framework, limitations, and recommendations
Public and community-facing outputs
Presentation Deck
Decision-ready presentation for CPC and ecosystem stakeholders
Slide deck
Support review, discussion, and communication
Covers strategic question, method, vertical priorities, competitive wins/losses, adoption signals, limitations, and recommended actions
Public Summary
Non-confidential version suitable for publication
Markdown/PDF, max [5] pages
Share useful findings while protecting sensitive operator data
Includes key findings, methodology overview, publishable vertical recommendations, evidence caveats, named examples where operators consent, and anonymized win/loss themes where needed
10. Acceptance Criteria
Each deliverable must be decision-useful, evidence-based, and traceable.
All deliverables must meet the following standards:
every factual claim must be traceable to a source, interview, dataset, or explicit vendor judgment;
Cardano evidence must be separated from peer-chain evidence;
public evidence, confidential evidence, and vendor interpretation must be clearly distinguished;
the win/loss register should target at least 15 operator decisions or justify a narrower high-quality sample;
operator identities may be confidentially named to CPC where required, with a publishable anonymized version where public naming is not possible;
named public examples should be included where operators consent;
deep-dive verticals must be justified through the screening process;
light-screened verticals must still receive enough treatment to justify deferral, handoff, or exclusion;
adoption signal standards must be defined by vertical;
benchmark scores must include evidence notes and confidence labels;
recommendations must include evidence confidence and what would change the recommendation;
weak, failed, dormant, unsupported, or deprioritized verticals must be explicitly identified.
A submission should fail acceptance review if it:
produces only a list of Cardano projects;
provides a generic blockchain market landscape;
avoids negative cases or competitor wins;
treats announcements as adoption;
uses on-chain metrics without explaining what behavior they represent;
includes too few operator decisions to support the recommendation and does not justify the limitation;
refuses to disclose operator identities even confidentially to CPC without a strong reason;
makes every vertical sound attractive;
does not map findings to decision gates;
duplicates adjacent RFP scopes without handoff boundaries.
CPC may reject final deliverables if the vendor cannot show sufficient negative-case evidence, unless the absence of such evidence is itself well explained and documented.
11. Vendor Eligibility
Applicants may be research firms, consultancies, ecosystem analysts, academic teams, independent researchers, or consortia. Subcontracting is permitted where responsibilities are clearly defined.
Applicants should demonstrate:
Web3 market and ecosystem research capability;
operator interview access;
competitive benchmarking experience;
ability to analyze product adoption and use-case maturity;
ability to handle confidential commercial information;
ability to communicate findings for both CPC and public ecosystem audiences;
ability to translate research into product, funding, partnership, or go-to-market decisions.
Cardano ecosystem familiarity is useful but not sufficient. Teams must also show external market access and willingness to test Cardano against alternatives.
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:
vertical screening plan and deep-dive selection logic;
operator access plan covering Cardano, non-Cardano, and negative-case respondents;
win/loss research plan for documenting enough operator decisions to answer the decision gates, targeting at least 15 where feasible;
competitive benchmark approach by vertical;
adoption-signal framework approach;
confidentiality plan for operator identity and commercially sensitive evidence.
Budgets should explain how cost relates to operator access, vertical coverage, benchmark depth, data sources, 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 credibly answer where Cardano has real use-case traction, where it wins and loses against peer ecosystems, why operators make those decisions, and which verticals should be prioritized, partnered into, waited on, deprioritized, or handed off.
A strong proposal should combine use-case audit, competitive benchmarking, and operator win/loss research; include Cardano, non-Cardano, and negative-case operators; explain how enough operator decisions will be documented, targeting at least 15 where feasible; and distinguish real adoption signal from cosmetic activity.
Proposals should score lower if they rely mainly on desk research, use Cardano insider interviews as the primary evidence base, avoid negative cases, produce a generic blockchain use-case landscape, or provide all-positive recommendations not tied to evidence.
Cost should be judged against evidence value, not lowest price. Higher-cost proposals may be justified by stronger operator access, better peer-chain comparison, deeper vertical analysis, or clearer decision value.
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, workplan, communication cadence, and confidentiality expectations
Research design alignment
Applicant-proposed timing
Align on sample plan, instruments, vertical screening criteria, benchmark approach, and data handling before fieldwork
Vertical screening review
Applicant-proposed timing
Confirm which verticals receive deep analysis and which receive light screening
Early signal check
Applicant-proposed timing
Review recruitment progress, early evidence gaps, negative-case access, and data limitations
Interim findings review
Applicant-proposed timing
Test whether evidence is answering the decision gates and whether scope needs adjustment
Draft deliverables review
Applicant-proposed timing
Review use-case map, benchmark, win/loss register, adoption signal framework, and wedge analysis
Final report and presentation
Applicant-proposed timing
Present final findings, confidence levels, limitations, decisions enabled, and recommended actions
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 and negative-case research are proposed.
15. Governance, Reporting, and Communication
The selected vendor will participate in structured checkpoints. The process should support research quality without becoming unnecessarily restrictive. CPC or a designated review group will align with the vendor on research design, vertical selection, and confidentiality expectations, while leaving room for the vendor to adapt methods as evidence and access constraints emerge.
Kickoff
Confirm objectives, decision gates, workplan, communication cadence, and confidentiality expectations
Research Design Review
Align on sample plan, instruments, vertical screening criteria, benchmark approach, and data handling before fieldwork
Vertical Screening Review
Confirm which verticals receive deep analysis and which receive light screening
Early Signal Check
Surface recruitment issues, weak data sources, negative-case access challenges, and scope risks
Interim Findings Review
Test whether evidence is answering the decision gates
Draft Deliverables Review
Review use-case map, benchmark, win/loss register, adoption signal framework, and wedge analysis
Final Presentation
Present final findings, confidence levels, limitations, decisions enabled, and recommended next actions
Public Summary Review
Confirm what can be published and what must remain confidential
The reporting cadence should be proportionate to project length, but at least one interim findings review and one draft deliverables review are required.
The vendor should not wait until the final report to reveal weak access, thin evidence, or vertical-selection problems.
16. Risks, Bias Controls, and Safeguards
Applicants must include a research integrity plan.
Cardano insider bias
Separate Cardano, non-Cardano, and negative-case respondent categories
Operator recruitment failure
State access status and fallback plans for each respondent category
All-positive findings
Include losses, pauses, rejections, competitor selections, and unsupported verticals
Overbroad vertical scope
Use light screening and justified deep-dive selection
False precision in benchmark scoring
Include evidence notes, confidence labels, and limitations for each benchmark score
Weak on-chain evidence
Explain what each metric represents and where on-chain data is unavailable or not meaningful
Competitor narrative bias
Use operator evidence and product-level evidence, not only public narratives
Confidentiality reducing public usefulness
Produce confidential CPC register plus publishable anonymized themes and named examples where operators consent
Scope creep
Use cross-RFP handoff logic for adjacent research areas
Conflicted recommendations
Require conflict declarations and mitigation plans
Sensitive data exposure
Separate public findings, confidential findings, and raw data
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:
vertical screening scope;
deep-dive selection expectations;
operator confidentiality;
minimum evidence standards;
peer-chain selection;
interview access;
win/loss register requirements;
data access and limitations;
public versus confidential outputs;
budget format;
overlap with other Product Research Initiative RFPs.
Responses should be maintained in a rolling Q&A log where practical so applicants receive consistent information. If a response materially changes scope, deadline, or eligibility, the RFP timeline may be adjusted.
The clarification process also helps assess applicant judgment. Strong questions may demonstrate specificity, methodological awareness, and realistic tradeoff thinking.
18. Data Handling, Confidentiality, and Public Summary
The selected vendor must provide a data handling plan covering:
informed consent process;
interview recording and transcript handling;
anonymization approach;
storage and access controls;
retention and deletion plan;
treatment of commercially sensitive information;
treatment of raw interview notes;
treatment of operator identities;
separation of public and confidential findings;
process for seeking permissioned public naming.
The operator win/loss register should target at least 15 operator decisions. Operator identities may be disclosed confidentially to CPC where public attribution is not possible. The vendor should maximize permissioned public attribution where operators consent, while also producing an anonymized public version. If fewer decisions are included, the vendor must explain the limitation and why the evidence remains sufficient.
Research outputs should distinguish:
public findings suitable for community publication;
confidential findings suitable only for CPC/internal review;
raw data that should not be published.
A public summary is expected unless specific findings cannot be published for confidentiality reasons. The public summary should include named examples where operators consent and anonymized win/loss themes where naming is not possible.
The public summary should not expose confidential operator identities, commercially sensitive information, or strategic details that could harm respondent trust.
If proprietary, paid, or operator-provided data is used, the vendor must state:
source;
access conditions;
whether CPC can inspect it;
whether it can be cited publicly;
what limitations apply;
whether the data can be retained after project completion.
If a finding depends heavily on data CPC cannot inspect, the vendor must label the confidence level accordingly.
19. Human Subject Research Ethics
Because this RFP requires interviews, the selected vendor must apply basic human-subject research safeguards.
At minimum, the vendor should:
tell respondents the purpose of the research;
explain who the research is for;
state how information may be used;
ask whether comments are attributable, anonymized, or confidential;
obtain consent before recording;
avoid publishing commercially sensitive information without permission;
allow respondents to clarify attribution status;
avoid misleading respondents about the purpose or audience of the work.
20. Conflicts of Interest
Applicants must disclose any actual, potential, or perceived conflicts of interest, including:
paid work for Cardano ecosystem entities;
paid work for peer-chain ecosystems;
advisory roles;
governance roles;
financial exposure to Cardano or competitor ecosystem assets;
relationships with operators included in the research;
relationships with projects that may benefit from vertical prioritization;
subcontractor conflicts.
Declared conflicts do not automatically disqualify an applicant, but they must be managed. Undisclosed conflicts may be grounds for rejection, non-award, payment holdback, or termination.
21. Terms and Conditions
Standard terms and conditions will be provided through the shared tender process before award. Applicants should assume that final award terms will cover ownership and permitted publication of deliverables, confidentiality, payment milestones, termination, data protection, subcontractor approval, warranties or disclaimers, and the governing process.
22. Appendix A: Proposal Checklist
Applicants should confirm that their proposal includes:
23. Appendix B: Suggested Vertical Screening Template
[Vertical]
[Screen / Deep Dive]
[Signal]
[Signal]
[Access status]
[High / Medium / Low]
[Dependency]
[Rationale]
24. Appendix C: Suggested Operator Win/Loss Register Template
[Win / Loss / Pause / Migration / Rejection / Not shortlisted / Parked]
[Named confidentially to CPC or public if consented]
[Public / Confidential / Anonymized]
[Vertical]
[Chain]
[Chosen / Rejected / Considered / Not considered]
[Reason]
[Interview / Source / Dataset]
[High / Medium / Low]
25. Appendix D: Suggested Adoption Signal Classification Template
[Vertical]
[Definition]
[Definition]