> For the complete documentation index, see [llms.txt](https://productcommittee.docs.intersectmbo.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://productcommittee.docs.intersectmbo.org/committee-outcomes/product-research/product-research-grants/product-researches-initiatives-grants/rfp-02-use-case-landscape-and-competitive-positioning.md). # 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: 1. Create a use-case map classifying current and historical Cardano use cases by maturity and evidence quality. 2. Screen relevant verticals and select a justified subset for deeper analysis. 3. Benchmark Cardano against relevant peer ecosystems by vertical at the product and operator level. 4. Identify where Cardano wins, loses, is undifferentiated, or lacks sufficient evidence. 5. 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. 6. Distinguish real adoption signal from cosmetic activity by vertical. 7. Recommend where Cardano should attack, partner, wait, stop, or hand off. 8. Identify findings that should inform adjacent Product Research Initiative RFPs. 9. 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. | Decision Gate | Evidence Required | YES Means | NO Means | Action Unlocked | | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- | | 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. | Topic | In Scope for This RFP | Out of Scope for This RFP | | ------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | 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: | Hypothesis | What Must Be Tested | Decision Relevance | | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | 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 | Evidence Type | Required Use | Notes | | -------------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | | 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: | Interview Category | Indicative Range | Purpose | | ----------------------------------------------------------------- | ---------------: | ---------------------------------------------------------- | | 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 | Deliverable | Description | Format | Purpose | Acceptance Criteria | | ------------------------------ | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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 | Deliverable | Description | Format | Purpose | Acceptance Criteria | | ----------------------------- | ------------------------------------------------------------------------------ | -------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 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 | Deliverable | Description | Format | Purpose | Acceptance Criteria | | ----------------- | -------------------------------------------------------------- | ---------------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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. | Milestone | Target Date / Timing | Purpose | | ----------------------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | 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. | Checkpoint | Purpose | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | 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. | Risk | Required Control | | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | | 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: * [ ] Cover letter * [ ] Understanding of the brief * [ ] Proposed methodology * [ ] Decision gate mapping * [ ] Vertical screening plan * [ ] Operator access plan * [ ] Win/loss research plan * [ ] Competitive benchmark plan * [ ] Adoption-signal framework approach * [ ] Workplan * [ ] Team qualifications * [ ] Relevant experience * [ ] Data sources * [ ] Risk and bias mitigation plan * [ ] Confidentiality and data handling approach * [ ] Timeline * [ ] Budget breakdown * [ ] Conflicts declaration * [ ] Ethics approach * [ ] Prior work examples, if applicable *** ## 23. Appendix B: Suggested Vertical Screening Template | Vertical | Screen or Deep Dive | Current Cardano Signal | Peer-Chain Signal | Operator Access | Evidence Quality | Dependency / Handoff | Rationale | | ----------- | --------------------- | ---------------------- | ----------------- | ---------------- | ---------------------- | -------------------- | ------------ | | \[Vertical] | \[Screen / Deep Dive] | \[Signal] | \[Signal] | \[Access status] | \[High / Medium / Low] | \[Dependency] | \[Rationale] | *** ## 24. Appendix C: Suggested Operator Win/Loss Register Template | Decision | Operator | Public Attribution Status | Vertical | Chain / Ecosystem Chosen | Cardano Role | Attributed Reason | Evidence Source | Confidence | | ------------------------------------------------------------------------ | ----------------------------------------------------- | ------------------------------------- | ----------- | ------------------------ | -------------------------------------------------- | ----------------- | ------------------------------- | ---------------------- | | \[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 | Strong Signal | Medium Signal | Weak Signal | Excluded Signal | Measurement Notes | | ----------- | ------------- | ------------- | ------------- | ------------------------------- | ----------------- | | \[Vertical] | \[Definition] | \[Definition] | \[Definition] | \[Signal that should not count] | \[How to verify] | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://productcommittee.docs.intersectmbo.org/committee-outcomes/product-research/product-research-grants/product-researches-initiatives-grants/rfp-02-use-case-landscape-and-competitive-positioning.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.