> 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-06-enterprise-and-rwa-readiness-assessment.md). # RFP 06: Enterprise and RWA Readiness Assessment 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 Is Cardano ready for production-grade enterprise adoption, including real-world asset deployments; and which readiness gaps must close before enterprise pilots, RWA opportunities, and institutional use cases can convert into recurring usage, durable value, or scalable ecosystem adoption? ### Evidence gap Cardano has enterprise- and RWA-relevant infrastructure, live or emerging tokenisation activity, and a strategic interest in regulated and institutional adoption. However, Cardano stakeholders do not yet have a decision-ready assessment of whether the surrounding conditions for production deployment are in place. Enterprise and RWA adoption depends on more than protocol capability. Buyers, issuers, operators, custodians, delivery partners, and regulated-market participants may require clear ROI, compliance documentation, implementation ownership, integration support, custody and settlement pathways, reliability expectations, support models, procurement fit, and risk controls before they can move from interest or pilot activity into production use. The evidence gap is therefore not simply "which enterprise use cases are attractive?" The gap is whether Cardano is ready to support production deployment in priority enterprise and RWA contexts, which verticals are closest to readiness, which blockers are most material, and which actions should be taken before further pilots, funding, partner engagement, or product investment. ### Decision unlocked This research should enable Cardano stakeholders to decide: * which enterprise and RWA verticals should be prioritized first; * which opportunities are production-ready, pilot-ready, conditional, monitor-only, or not ready; * which readiness gaps block enterprise conversion; * which gaps require ecosystem investment, documentation, partner recruitment, product support, compliance diligence, or handoff to another workstream; * which pilots or opportunities justify further funding, partner engagement, or coordination; * what evidence should be required before Cardano stakeholders treat an enterprise or RWA opportunity as meaningful adoption. ### Expected outputs The selected vendor will produce an enterprise readiness scorecard, enterprise vertical prioritization matrix, RWA category assessment, buyer requirement map, pilot-to-production conversion framework, compliance-readiness and diligence map, infrastructure dependency assessment, delivery and support readiness assessment, gap closure plan, adoption signal framework, evidence register, research methodology appendix, executive decision memo, cross-RFP handoff memo, final research report, final presentation, and public summary. Vendors may combine deliverables where sensible, provided that every decision gate is answered and every required output is covered. ### Requirement priority The required core is to answer the decision gates with traceable evidence and produce the required decision outputs. Optional methods, templates, or extra category coverage should be separated from the core scope and budget. This RFP is not enterprise sales execution, legal advice, token promotion, implementation delivery, partner certification design, or a generic RWA market report. *** ## 2. Strategic Context The Cardano Product Committee has received funding to commission a portfolio of product research initiatives aligned with Cardano's long-term product direction and Strategy 2030 priorities. The purpose of the portfolio is to define the evidence Cardano needs before making product, adoption, funding, partnership, and strategic decisions. This RFP focuses on enterprise and RWA readiness. Its purpose is to assess whether Cardano can support production-grade enterprise adoption and to identify the specific gaps that must close before pilots, tokenisation opportunities, and institutional engagements can produce durable outcomes. Enterprise adoption requires more than interest from potential partners. It requires a credible pathway through procurement, risk review, integration, compliance review, implementation, support, monitoring, and ongoing operations. RWA adoption adds further complexity because asset type, issuer responsibility, custody, settlement, liquidity, regulatory treatment, data integrity, and investor or buyer requirements can vary materially by category. This RFP should treat RWA as a major enterprise vertical and category set, not as the whole scope. The broader question is production readiness: what must be true for Cardano-based enterprise deployments, including RWA deployments, to become operational, maintained, measurable, and valuable. The research should inform the Cardano Product Committee and the broader Cardano ecosystem, including enterprise adoption teams, RWA builders, infrastructure teams, delivery partners, grant allocators, compliance-facing contributors, business development teams, and future research vendors. *** ## 3. Research Problem Statement Cardano lacks a decision-ready enterprise and RWA production-readiness assessment. Current discussion can blur several different states of maturity: * technical capability; * proof of concept; * pilot; * announced partnership; * buyer interest; * production deployment; * recurring usage; * durable value locked; * retained institutional adoption. These are not interchangeable. A technically plausible enterprise or RWA use case may still fail to reach production if buyer ROI is unclear, compliance documentation is incomplete, custody or settlement pathways are weak, support expectations are not met, delivery ownership is missing, procurement cannot proceed, or the vertical lacks a credible adoption pathway. Cardano stakeholders need to know: * which enterprise verticals have credible production potential; * which RWA categories are ready, conditionally ready, or not ready; * what buyers, issuers, operators, and delivery partners actually require; * where support, SLA, integration, custody, compliance, settlement, and delivery gaps block adoption; * what current pilots or comparable deployments reveal about conversion barriers; * which gaps should be fixed first; * which opportunities should be pursued, monitored, deferred, or stopped. Without this evidence, Cardano risks: * funding pilots that cannot convert to production; * treating announcements or letters of intent as adoption; * over-indexing on broad RWA narratives; * pursuing enterprise opportunities without implementation ownership; * underestimating compliance, custody, support, or procurement requirements; * duplicating adjacent research on use-case positioning, delivery partner networks, stablecoin liquidity, government entry, or L2/interoperability; * missing the specific readiness investments that would unlock enterprise production usage. The selected vendor must close this evidence gap by producing a readiness assessment that connects enterprise and RWA opportunities to buyer requirements, production constraints, gap closure actions, and clear decision gates. *** ## 4. Definitions For this RFP: **Enterprise readiness** means the degree to which Cardano-related infrastructure, products, partners, documentation, support, and ecosystem capabilities can satisfy the requirements of enterprise or institutional buyers moving toward production use. **RWA** means real-world asset activity where off-chain assets, rights, claims, records, cash flows, commodities, financial instruments, or other real-world value representations are issued, tracked, transferred, financed, settled, verified, or otherwise supported using blockchain infrastructure. **RWA category** means a distinct asset or deployment category, such as tokenised funds, commodities, invoices or receivables, real estate, carbon or energy assets, supply-chain assets, identity-linked assets, institutional settlement assets, or applicant-justified alternatives. **Production deployment** means a live operational deployment integrated into a real business, institutional, or user workflow, with defined ownership, support, users or counterparties, operating requirements, and measurable activity. **Pilot** means a limited deployment or test with a defined owner, scope, success criteria, timeline, and conversion question. **Proof of concept** means a demonstration that a technical or workflow concept can function, but without sufficient evidence of buyer commitment, production integration, operational ownership, or recurring usage. **Compliance readiness** means evidence that relevant documentation needs, review questions, diligence triggers, regulatory uncertainty, and buyer-side compliance expectations are understood well enough to inform next steps. It is not legal advice. **Buyer requirement** means a condition that an enterprise or institutional buyer, issuer, operator, custodian, or procurement process may require before adoption, such as ROI evidence, risk controls, integration support, documentation, reporting, custody, settlement, privacy, security, uptime, or vendor accountability. **Delivery model** means the practical arrangement for who builds, integrates, operates, supports, maintains, and scales an enterprise deployment. **Support or SLA expectation** means an enterprise requirement for availability, response time, escalation, maintenance, monitoring, documentation, ownership, or service continuity. **Adoption signal** means evidence that an enterprise or RWA opportunity is producing meaningful usage, production deployment, retained users, recurring transactions, durable value locked, workflow integration, revenue pathway, or other measurable value. **Cosmetic activity** means engagement that appears useful but does not demonstrate adoption, such as vague partnership announcements, event participation, non-binding letters of intent, demos without implementation ownership, or unsupported claims of enterprise interest. The selected vendor may refine these definitions during the research design phase, but revised definitions must remain measurable and decision-useful. *** ## 5. Objectives The selected vendor will be expected to: 1. Assess Cardano's readiness for production-grade enterprise deployment across technical, commercial, compliance-readiness, support, integration, custody, delivery, and buyer-readiness dimensions. 2. Identify and prioritize enterprise verticals where Cardano has credible production potential. 3. Assess RWA opportunities by asset category or deployment model rather than treating RWA as a single market. 4. Map enterprise buyer, issuer, operator, and institutional requirements that determine whether a use case can move into production. 5. Identify blockers that prevent pilots, proofs of concept, or early engagements from converting into production deployments. 6. Map compliance-readiness needs, documentation gaps, uncertainty, and diligence triggers without presenting legal advice. 7. Assess delivery, support, SLA, integration, custody, settlement, and infrastructure dependencies for priority opportunities. 8. Distinguish meaningful enterprise/RWA adoption from cosmetic activity. 9. Recommend which opportunities Cardano stakeholders should pursue, fix prerequisites for, monitor, defer, or stop. 10. Produce a gap closure plan and cross-RFP handoff memo that route blockers to the right workstreams. *** ## 6. Decision Gates Applicants must design their methodology around the following decision gates. A proposal that does not map methods and deliverables to these gates will be considered weak fit for this RFP. | Decision Gate | Evidence Required | YES Means | NO Means | Action Unlocked | | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | Is Cardano ready for production-grade enterprise deployment in priority verticals? | Readiness assessment across technical reliability, integration requirements, support expectations, SLA needs, compliance documentation, custody, security, procurement, and delivery capacity | Cardano can identify where production deployment is plausible and what conditions must be met | Enterprise interest may exist, but production readiness is not yet credible | Decide whether to pursue enterprise production pathways, readiness investment, or defer | | Which enterprise verticals should be prioritized first? | Comparative vertical scoring across buyer demand, ROI logic, urgency, Cardano fit, implementation feasibility, ecosystem capability, regulatory/compliance burden, and evidence confidence | Cardano can focus enterprise effort on verticals with credible production potential | Vertical prioritization remains narrative-driven or opportunistic | Set enterprise vertical priorities for funding, BD, product support, and partner coordination | | Which RWA opportunities are production-ready, pilot-ready, or not ready? | RWA category assessment covering asset type, buyer need, regulatory/compliance dependencies, custody, settlement, liquidity, data integrity, issuer/operator readiness, and recurring usage pathway | RWA can be treated as concrete deployable opportunities with different readiness levels | RWA remains too broad to guide action or funding | Decide which RWA categories deserve deeper pursuit, conditional support, or no action | | What prevents enterprise pilots from converting to production? | Pilot-to-production gap analysis based on current or comparable deployments, buyer/operator interviews, implementation blockers, procurement constraints, support gaps, and dependency mapping | Conversion blockers can be named and sequenced | Cardano cannot distinguish promising pilots from stalled demonstrations | Fund or coordinate gap closure before scaling pilot activity | | What enterprise buyer requirements must Cardano satisfy? | Buyer requirement map covering ROI, risk, compliance review, procurement process, integration burden, uptime/support expectations, data handling, reporting, custody, and vendor accountability | Cardano stakeholders understand the buyer-side evidence required before adoption | Enterprise-facing work may continue optimizing for ecosystem assumptions rather than buyer requirements | Build buyer checklists, proof assets, readiness documentation, and product/partner requirements | | Which compliance and regulatory readiness gaps matter, without turning the RFP into legal advice? | Compliance-readiness mapping based on public sources, expert input, buyer expectations, and jurisdiction/vertical sensitivity, with uncertainty clearly labeled and legal-review needs identified | Cardano can identify compliance documentation and diligence needs without relying on vendor legal conclusions | Recommendations may overclaim legal feasibility or ignore compliance blockers | Decide where further legal review, documentation, policy work, or jurisdiction-specific diligence is required | | What delivery and support model is required for production enterprise adoption? | Assessment of implementation ownership, delivery partner capacity, maintenance responsibilities, support/SLA expectations, escalation paths, and post-deployment operating model | Production deployment requirements can be connected to delivery capacity | Enterprise opportunities may fail because no one can implement, operate, or support them | Hand off partner-network needs to RFP #8 and define interim delivery requirements | | Which infrastructure dependencies block enterprise or RWA deployment? | Dependency assessment covering stablecoins, fiat/off-ramp access, custody, identity, privacy, interoperability, oracle/data quality, integration APIs, wallets, and monitoring/reporting | Required dependencies can be sequenced and assigned to workstreams | Enterprise recommendations ignore blockers outside the immediate RFP | Coordinate with stablecoin, L2/interoperability, delivery partner, product, compliance, or ecosystem workstreams | | What counts as meaningful enterprise adoption rather than cosmetic activity? | Adoption signal framework defining production deployment, recurring usage, transaction activity, value locked, retained institutional users, revenue pathway, operational integration, and weak or misleading signals | Cardano can judge enterprise progress using evidence thresholds | Announcements, demos, or letters of intent may be mistaken for adoption | Set pilot KPIs, funding triggers, reporting requirements, and stop conditions | | Which gaps should Cardano stakeholders fund or coordinate first? | Gap closure plan ranking readiness gaps by impact, urgency, owner, dependency, cost driver, and decision value | Stakeholders can move from research to action | The research produces diagnosis without an implementation sequence | Prioritize readiness investments, documentation work, partner recruitment, pilot support, or no-go decisions | | Which findings should be handed to adjacent RFPs or workstreams? | Cross-RFP handoff memo mapping dependencies to customer segmentation, use-case landscape, stablecoin liquidity, government entry, L2/interoperability, delivery partners, brand, AI, or other workstreams | RFP #6 informs adjacent work without absorbing it | Scope expands into multiple other RFPs and becomes unmanageable | Keep enterprise readiness focused while preserving useful dependencies | *** ## 7. Scope of Work ### In scope The selected vendor should cover: * enterprise production-readiness assessment; * enterprise vertical prioritization; * RWA category assessment; * buyer, issuer, operator, custodian, and delivery requirement mapping; * pilot-to-production conversion analysis; * compliance-readiness and diligence mapping, without providing legal advice; * support, SLA, integration, custody, settlement, and delivery readiness assessment; * infrastructure dependency analysis; * primary research with external enterprise, institutional, operator, expert, or delivery stakeholders where feasible; * desk research and benchmarking where it clarifies production-readiness standards; * adoption signal framework; * gap closure plan; * public and confidential reporting. ### Enterprise scope guidance Applicants should propose a scope that can answer the decision gates within the project budget and timeline. The RFP does not require every possible enterprise vertical to receive equal research depth. Applicants should use a screening phase to identify which verticals or categories deserve deeper analysis. A narrower proposal with credible external evidence and clear decision value may be stronger than a broad proposal that covers many verticals superficially. Candidate enterprise areas may include: | Enterprise Area | Research Purpose | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | RWA and tokenisation | Assess asset-category readiness, issuer/operator requirements, custody, settlement, compliance-readiness, liquidity, and production pathway | | Supply chain and traceability | Assess workflow integration, data integrity, partner model, recurring usage, and buyer ROI | | Regulated financial services | Assess compliance review, institutional requirements, custody, settlement, reporting, and risk controls | | Identity and credentials | Assess buyer need, privacy, standards, integration, governance, and adoption pathway | | Enterprise infrastructure or data integrity | Assess whether Cardano can support auditable records, verification, automation, or trusted workflows in production settings | | Applicant-justified vertical | Include only where the applicant can show buyer demand, Cardano fit, evidence access, and decision value | ### RWA scope guidance Applicants should avoid treating RWA as one market. They should propose an RWA category design and explain which categories will be screened or deep-dived. Candidate RWA categories may include: | RWA Category | Research Purpose | | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Tokenised funds or financial instruments | Assess issuer/operator model, regulatory sensitivity, custody, investor requirements, settlement, reporting, and distribution pathway | | Commodities | Assess asset verification, custody, title, settlement, market access, liquidity, and data integrity | | Invoices or receivables | Assess underwriting, debtor/creditor workflow, compliance-readiness, liquidity, and buyer ROI | | Real estate or property-linked assets | Assess legal structure, title, registry, jurisdictional dependency, custody, liquidity, and operational feasibility | | Carbon, energy, or environmental assets | Assess verification, registry integration, buyer demand, data integrity, market credibility, and regulatory risk | | Supply-chain or product-linked assets | Assess traceability, financing, data source reliability, enterprise integration, and recurring usage | | Institutional settlement or cash-equivalent assets | Assess stablecoin, liquidity, custody, off-ramp, compliance, and settlement dependencies | Applicants may propose other categories if they justify the decision value. ### Out of scope and handoff boundaries This RFP should remain focused on enterprise and RWA production readiness. 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 | Enterprise buyer types and requirements where needed for readiness | Full segmentation, persona framework, or market sizing model | | Use-case landscape | Enterprise/RWA readiness and production feasibility for screened verticals | Full Cardano use-case audit or chain-by-chain competitive benchmark | | Stablecoin liquidity | Identify stablecoin, settlement, liquidity, or off-ramp dependencies | Stablecoin liquidity incentive design or market-maker strategy | | Brand perception | Enterprise trust or proof requirements where they affect readiness | Broad awareness, perception, or message testing | | Government and emerging markets | Public-sector or regional dependencies where they affect enterprise/RWA readiness | Country-level government entry strategy or regional playbooks | | Delivery partners | Assess whether delivery capacity blocks production deployment | Full certified partner network design or channel program | | L2 and interoperability | Identify scaling or interoperability dependencies that affect production readiness | Full L2 demand study, bridge strategy, or technical requirements register | | AI commercial positioning | Include AI only if it emerges as an enterprise vertical | Full AI positioning, narrative testing, or go/no-go AI strategy | | Legal advice | Identify documentation needs, uncertainty, and diligence triggers | Legal opinions, jurisdictional approvals, or formal compliance advice | Findings that materially affect another research initiative should be captured in the Cross-RFP Handoff Memo rather than expanded inside this RFP. *** ## 8. Required Methodology Applicants should propose a mixed-method research design. Desk research alone is unlikely to satisfy the evidence bar for this RFP. ### Core research hypotheses Applicants should test hypotheses such as: 1. Cardano's enterprise and RWA opportunity is constrained less by abstract technical capability than by production-readiness conditions. 2. RWA is not one market; asset categories have different buyer, issuer, custody, settlement, liquidity, and compliance-readiness needs. 3. Some enterprise opportunities may be commercially attractive but not currently production-ready. 4. Proof-of-concept or pilot activity may not reliably indicate production adoption. 5. Enterprise buyers require evidence that differs from crypto-native builders, including ROI, risk, procurement, support, documentation, and accountable delivery. 6. The highest-value output is a ranked readiness view showing where Cardano should act, wait, fix prerequisites, or stop pursuing. ### Required evidence types The selected vendor should combine: * enterprise buyer or buyer-adjacent interviews; * Cardano ecosystem operator interviews; * RWA issuer, tokenisation platform, custodian, compliance, infrastructure, or enterprise delivery interviews; * expert input from enterprise procurement, custody, tokenisation, institutional digital assets, regulated-market, or compliance-readiness practitioners; * desk research on enterprise blockchain adoption, RWA categories, peer ecosystem models, and buyer requirements; * review of Cardano-relevant infrastructure, tooling, documentation, support, and deployment examples; * evidence from current or prior pilots, enterprise sales conversations, or implementation attempts where available; * proprietary or paid data where access terms, limits, and confidence implications are disclosed. ### Primary research expectations Applicants should propose respondent categories, recruitment channels, and rationale. The RFP does not prescribe a fixed interview count, but proposals must explain why the sample is sufficient for the decision gates. Expected primary research may include: | Method | Purpose | Minimum Expectation | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Enterprise buyer interviews | Validate buyer requirements, ROI logic, procurement barriers, risk concerns, support expectations, and adoption conditions | Include target buyer categories and recruitment plan | | Enterprise/RWA operator interviews | Understand deployment blockers, integration needs, custody/settlement dependencies, and pilot-to-production barriers | Include Cardano and non-Cardano operators where useful | | Expert interviews | Validate compliance-readiness, custody, tokenisation, institutional settlement, procurement, or vertical-specific assumptions | Identify expert categories and limits | | Delivery/support interviews | Assess implementation ownership, support needs, SLA expectations, and delivery capacity | Keep scope to readiness assessment rather than partner-network design | | Confidential case review | Analyze current or comparable deployments without exposing sensitive details | State how evidence will be anonymized and verified | ### Desk research requirements Desk research should support, not replace, primary validation. It should cover: * enterprise blockchain and RWA adoption patterns; * priority RWA categories and operating models; * Cardano-relevant infrastructure and documentation; * enterprise procurement, support, integration, custody, settlement, and reporting expectations; * peer ecosystem approaches to enterprise/RWA readiness where relevant; * known constraints around tokenisation, digital assets, privacy, identity, data quality, or regulated workflows; * evidence of real deployments versus announcements; * public regulatory and compliance context where relevant, framed as readiness mapping rather than legal advice. ### Survey requirements A survey is optional. A survey may be useful if the vendor can reach a qualified enterprise, institutional, operator, or RWA respondent set. A broad crypto-community survey should not be treated as evidence of enterprise readiness. If a survey is proposed, applicants must explain respondent qualification criteria, recruitment source, sample limitations, decision-gate mapping, and how results will be weighted against interviews and documentary evidence. ### Benchmarking requirements Benchmarking should be used only where it clarifies Cardano's readiness standard. Relevant benchmark areas may include: * enterprise support and SLA expectations; * compliance documentation and due diligence packs; * tokenisation platform operating models; * custody and settlement integrations; * delivery partner ecosystems; * institutional buyer proof requirements; * production conversion from pilot to recurring use; * peer ecosystem enterprise/RWA adoption models. Benchmarking should not become a generic competitor narrative. Broader competitive positioning belongs primarily to the Use-Case Landscape and Competitive Positioning RFP. ### Evidence quality and confidence Applicants must explain how they will: * separate Cardano ecosystem claims from external buyer/operator evidence; * handle confidential or unattributable evidence; * mark proprietary, paid, incomplete, or uncertain sources; * assign confidence levels to major findings; * distinguish direct evidence from vendor judgment; * identify what their methods cannot prove. ### What should not count as evidence The following should be excluded or clearly discounted: * generic RWA market-size claims without Cardano-specific implications; * ecosystem enthusiasm without buyer validation; * proof-of-concept activity without production conversion path; * unverified announcements; * vague partnership claims; * legal or regulatory conclusions presented without qualification; * tokenisation narratives without issuer, buyer, custody, settlement, or liquidity evidence; * TVL or transaction spikes without durability or user explanation; * technical capability claims that ignore support, compliance, integration, or delivery requirements; * competitor comparisons based only on public reputation rather than deployability evidence. *** ## 9. Expected Deliverables The selected vendor is expected to produce the following outputs. Vendors may combine deliverables where sensible, provided all decision gates and acceptance criteria are covered. 1. **Enterprise readiness scorecard** - readiness assessment across technical, commercial, compliance-readiness, integration, support/SLA, custody, security, delivery, and buyer-readiness dimensions. 2. **Enterprise vertical prioritization matrix** - ranked view of enterprise verticals by buyer demand, ROI logic, Cardano fit, implementation feasibility, readiness, adoption pathway, and evidence confidence. 3. **RWA category assessment** - assessment of RWA opportunities by asset category or deployment model. 4. **Buyer requirement map** - map of enterprise buyer, issuer, operator, custodian, and institutional requirements. 5. **Pilot-to-production conversion framework** - framework for assessing whether pilots or proofs of concept can become production deployments. 6. **Compliance-readiness and diligence map** - non-legal mapping of documentation needs, uncertainty, diligence triggers, and further review requirements. 7. **Infrastructure dependency assessment** - dependency map covering stablecoins, custody, identity, privacy, interoperability, oracle/data quality, wallets, APIs, monitoring/reporting, and other relevant blockers. 8. **Delivery and support readiness assessment** - assessment of implementation ownership, support model, SLA expectations, escalation paths, and delivery capacity. 9. **Gap closure plan** - ranked plan for closing readiness gaps. 10. **Adoption signal framework** - thresholds for meaningful enterprise/RWA adoption versus cosmetic activity. 11. **Evidence register** - source-by-source record supporting major claims. 12. **Research methodology appendix** - explanation of methods, samples, recruitment, source limits, bias controls, and confidence approach. 13. **Executive decision memo** - concise recommendation for CPC and broader Cardano stakeholders. 14. **Cross-RFP handoff memo** - findings that should inform adjacent Product Research Initiative RFPs or ecosystem workstreams. 15. **Final research report** - complete research record. 16. **Final presentation** - presentation to CPC and relevant ecosystem stakeholders. 17. **Public summary** - non-confidential ecosystem-facing summary. *** ## 10. Acceptance Criteria Deliverables must connect directly to decision gates. A long report without decision-useful outputs will not satisfy this RFP. | Deliverable | Description | Format | Purpose | Acceptance Criteria | Decision Enabled | Failure Modes | | ----------------------------------------- | -------------------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Enterprise readiness scorecard | Assessment of production enterprise readiness | Table or spreadsheet plus narrative | Identify where Cardano is production-ready, conditionally ready, or not ready | Defines each readiness dimension; assigns score or classification; cites evidence; labels confidence and limitations | Enterprise readiness investment and pursuit decisions | Gives generic scores without evidence or treats technical capability as full readiness | | Enterprise vertical prioritization matrix | Comparative assessment of candidate enterprise verticals | Matrix or spreadsheet | Rank verticals by decision value | Includes criteria, scoring logic, source basis, confidence, and recommendation per vertical | Vertical prioritization | Produces attractive use-case list without decision consequence | | RWA category assessment | Breakdown of RWA opportunities by asset category | Matrix plus narrative | Prevent RWA from becoming an undifferentiated market claim | Separates asset categories; assesses buyer, issuer/operator, custody, settlement, liquidity, compliance-readiness, data integrity, and recurring usage pathway | RWA go/conditional-go/no-go decisions | Relies on generic RWA narratives without asset-specific evidence | | Buyer requirement map | Map of enterprise buyer requirements | Table plus narrative | Ground readiness in buyer-side conditions | Covers ROI, risk, procurement, compliance review, support, integration, custody, reporting, accountability, and proof requirements | Buyer-readiness and proof-asset decisions | Based mainly on ecosystem assumptions | | Pilot-to-production conversion framework | Framework for evaluating conversion | Framework plus applied examples | Identify why pilots stall and what evidence is needed before scaling | Defines production, pilot, proof of concept, blockers, evidence needed, owner, dependency, and next decision | Pilot funding and continuation decisions | Treats all pilots as progress | | Compliance-readiness and diligence map | Non-legal mapping of compliance needs | Table with caveats | Identify compliance blockers without legal advice | Labels source basis, uncertainty, documentation gaps, and where qualified legal review is required | Documentation and diligence decisions | Presents legal conclusions or ignores uncertainty | | Infrastructure dependency assessment | Map of dependencies affecting production adoption | Matrix | Assign blockers to the right workstream | Covers relevant stablecoin, custody, identity, privacy, interoperability, data/oracle, wallet, API, monitoring, and delivery dependencies | Cross-workstream sequencing | Ignores dependencies outside vendor's preferred scope | | Delivery and support readiness assessment | Assessment of implementation and support model | Table plus narrative | Determine whether deployment can be operated after launch | Distinguishes readiness assessment from full partner-network design; identifies delivery gaps and RFP #8 handoffs | Delivery and support decisions | Becomes a partner program design or ignores operations | | Gap closure plan | Ranked plan for closing readiness gaps | Roadmap or action table | Convert findings into sequenced action | Ranks gaps by impact, urgency, dependency, likely owner, cost driver, confidence, and decision value | Funding, coordination, documentation, partner, and product decisions | Lists gaps without sequence or action path | | Adoption signal framework | Evidence thresholds for meaningful adoption | Table plus guidance | Distinguish production signal from cosmetic activity | Defines strong, moderate, weak, and misleading signals with enterprise/RWA examples | KPI, funding trigger, and stop-condition design | Treats announcements, demos, or LOIs as adoption | | Evidence register | Source record supporting major claims | Spreadsheet/table | Preserve traceability | Maps major factual claims to source, interview category, dataset, document, or explicit vendor judgment; marks confidential/proprietary evidence | Reviewer confidence assessment | Makes unsupported claims or hides evidence basis | | Research methodology appendix | Full explanation of methods | Appendix | Make research auditable | Lists respondent categories, recruitment, sample limits, bias controls, data handling, and confidence approach | Method validation | Provides conclusions without method transparency | | Executive decision memo | Concise decision summary | Memo, suggested max \[5] pages | Support CPC and ecosystem decision-making | States recommendations, rationale, confidence, tradeoffs, and decisions required | Portfolio and funding decisions | Summarizes findings without decision implications | | Cross-RFP handoff memo | Dependencies and blockers for adjacent workstreams | Memo or table | Keep portfolio scope clean | Maps findings to specific adjacent RFPs/workstreams with requested action | Cross-portfolio coordination | Duplicates adjacent scopes or buries dependencies | | Final research report | Complete research report | PDF/doc/Markdown | Provide complete research record | Includes executive summary, methodology, decision-gate answers, readiness scorecard, vertical matrix, RWA assessment, gap plan, limitations, and appendices | Full evidence base | Long narrative without decision tables | | Final presentation | Presentation to CPC and ecosystem stakeholders | Slide deck plus live or recorded presentation | Communicate findings and decisions | Covers decision-gate answers, confidence, recommendations, tradeoffs, gaps, and next actions | Shared alignment | Promotional summary without decision implications | | Public summary | Non-confidential summary | Markdown or document | Share findings with ecosystem | Includes methodology, key findings, evidence caveats, and publishable recommendations; excludes sensitive details | Community transparency | Over-discloses sensitive data or publishes unsupported claims | *** ## 11. Vendor Eligibility Applicants may be research firms, consultancies, independent researchers, academic teams, ecosystem teams, or consortia. Subcontracting is allowed if roles, responsibilities, costs, and conflicts are clearly disclosed. A credible applicant should demonstrate capability in some combination of: * enterprise market research; * RWA, tokenisation, institutional digital assets, or regulated-market research; * production-readiness assessment; * enterprise buyer or operator research; * procurement, ROI, support, integration, custody, settlement, or compliance-readiness analysis; * structured decision-support deliverables; * confidential interview and data handling; * Cardano ecosystem context or a credible plan to obtain it. Cardano-specific experience is useful but not mandatory. A team with strong enterprise/RWA research capability and a credible Cardano learning plan may be competitive. Applicants should disclose whether they or their subcontractors are also vendors, issuers, tokenisation platforms, custodians, delivery partners, or ecosystem participants whose interests may be affected by the research. *** ## 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: * enterprise vertical and RWA category screening approach; * readiness scorecard design; * buyer/operator/stakeholder access plan; * pilot-to-production conversion analysis method; * compliance-readiness and legal-advice boundary; * handoff approach for partner-network issues that belong to RFP #8. Budgets should explain how cost relates to enterprise access, RWA expertise, compliance-readiness expertise, 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 distinguish technical capability, proof of concept, pilot, production deployment, recurring usage, and durable value. It should identify which enterprise and RWA opportunities are production-ready, pilot-ready, conditional, monitor-only, or not ready. A strong proposal should map buyer requirements, compliance-readiness needs, custody/settlement/support dependencies, delivery constraints, and pilot-to-production blockers. Delivery partner network design should be handed to RFP #8 rather than duplicated here. Proposals should score lower if they provide broad RWA narratives, treat announcements as adoption, ignore buyer requirements, overclaim legal feasibility, or duplicate adjacent RFP scopes. Cost should be judged against evidence value, not lowest price. Higher-cost proposals may be justified by stronger enterprise access, specialist compliance or RWA expertise, better external validation, or clearer readiness scoring. ## 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, scope, workplan, communication cadence, and confidentiality expectations | | Research design alignment | Applicant-proposed timing | Align on screening model, RWA category logic, respondent categories, evidence standards, and confidentiality boundaries before fieldwork | | Screening review | Applicant-proposed timing | Review initial enterprise vertical and RWA category screening and select priority deep dives | | Stakeholder access check | Applicant-proposed timing | Surface recruitment issues, weak access, confidentiality constraints, or substitutions needed | | Interim findings review | Applicant-proposed timing | Test whether evidence is answering decision gates and whether scope needs adjustment | | Draft deliverables review | Applicant-proposed timing | Review readiness scorecard, vertical matrix, RWA assessment, buyer requirements, gap plan, and handoffs | | Final report and presentation | Applicant-proposed timing | Present final findings, confidence levels, limitations, decisions enabled, and recommended actions | | Public summary review | Applicant-proposed timing | Confirm what can be published and what must remain confidential | | Public summary | Applicant-proposed timing | Publish non-confidential summary | Applicants should propose a timeline appropriate to their methodology. Unrealistic timelines should be avoided, especially where enterprise buyer access, confidential evidence, regulated-market review, or multi-category RWA analysis is required. *** ## 15. Governance, Reporting, and Communication The selected vendor will participate in structured checkpoints. The process should protect research quality without turning the work into committee-managed consulting. | Checkpoint | Purpose | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Kickoff | Confirm objectives, decision gates, scope, workplan, communication cadence, and confidentiality expectations | | Research Design Review | Align on screening model, RWA category logic, respondent categories, evidence standards, and confidentiality boundaries before fieldwork | | Screening Review | Review initial enterprise vertical and RWA category screening and select priority deep dives | | Stakeholder Access Check | Surface recruitment issues, weak access, confidentiality constraints, or substitutions needed | | Interim Findings Review | Test whether evidence is answering decision gates and whether scope needs adjustment | | Draft Deliverables Review | Review readiness scorecard, vertical matrix, RWA assessment, buyer requirements, gap closure plan, and handoffs | | Final Presentation | Present final findings, confidence levels, limitations, decisions enabled, and recommended actions | | Public Summary Review | Confirm what can be published and what must remain confidential | The vendor should not wait until the final report to disclose weak access, respondent recruitment issues, regulatory uncertainty, evidence gaps, conflicts, scope risks, or findings that show an opportunity should be deprioritized. *** ## 16. Risks, Bias Controls, and Safeguards Applicants must include a research integrity plan. | Risk | Required Control | | ------------------------------ | ----------------------------------------------------------------------------------------- | | Cardano insider bias | Separate ecosystem claims from external buyer/operator evidence | | RWA hype | Break RWA into categories and require asset-specific evidence | | Pilot inflation | Define proof of concept, pilot, production, and adoption signal thresholds | | Legal overclaiming | Label uncertainty and identify where qualified legal review is required | | Vendor self-promotion | Disclose conflicts and distinguish research from sales or implementation | | Confidential evidence risk | Provide traceability without exposing sensitive respondent data | | Weak access | Disclose recruitment limitations early and adjust confidence levels | | Enterprise self-selection bias | Identify when respondents are unusually crypto-friendly or commercially incentivized | | Generic market sizing | Tie market evidence to Cardano-specific readiness and adoption decisions | | Delivery blind spots | Assess implementation and support requirements without designing the full partner network | | Scope creep | Use cross-RFP handoff logic for adjacent topics | | Sensitive data exposure | Separate public findings, confidential findings, proprietary data, 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: * enterprise vertical scope; * RWA category logic; * production-readiness definitions; * buyer or operator access expectations; * treatment of confidential respondents; * compliance-readiness boundaries; * treatment of legal or regulatory uncertainty; * data sources and proprietary evidence; * 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 production-readiness thinking, buyer-access realism, caution around legal overclaiming, RWA category discipline, and understanding of what enterprise research can and cannot prove. *** ## 18. Data Handling, Confidentiality, and Public Summary The selected vendor must provide a data handling plan covering: * informed consent for interviews, expert calls, workshops, or surveys; * anonymization approach; * raw notes, recordings, or transcript treatment; * storage and access controls; * retention and deletion plan; * treatment of sensitive buyer, operator, issuer, custodian, delivery, or regulatory findings; * treatment of proprietary, paid, or respondent-provided data; * separation of public findings, confidential findings, and raw data; * publication boundaries. Research outputs should distinguish: * public findings suitable for community publication; * confidential findings suitable only for CPC/internal review; * sensitive respondent or counterparty information that should not be published; * raw data that should not be published; * proprietary data that CPC can inspect but may not publish; * vendor judgment where primary data cannot be disclosed. A public summary is expected unless specific findings cannot be published for justified confidentiality reasons. The public summary should include methodology overview, key findings, evidence caveats, and publishable recommendations. It should not expose respondent identities, sensitive buyer/operator information, confidential commercial details, legal/regulatory sensitivities, or proprietary data. If proprietary, paid, respondent-provided, or locally restricted 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 may require interviews, expert calls, workshops, or surveys with enterprise, institutional, regulated-market, or commercially sensitive stakeholders, 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 responses may be used; * ask whether comments are attributable, anonymized, or confidential; * obtain consent before recording; * avoid publishing sensitive respondent information without permission; * allow respondents to clarify attribution status; * avoid misleading respondents about the purpose or audience of the work; * avoid exposing respondents to employment, commercial, regulatory, or institutional risk. *** ## 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 enterprise buyers, RWA issuers, tokenisation platforms, custodians, delivery firms, compliance providers, or infrastructure vendors discussed in the research; * relationships with respondents, data providers, subcontractors, or expert networks; * ownership or commercial interest in a product, service, token, asset category, or platform that may be affected by the research; * 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 * [ ] Enterprise and RWA scope design * [ ] Production-readiness framework * [ ] Stakeholder access plan * [ ] Buyer and operator validation plan * [ ] Compliance-readiness approach * [ ] Data sources * [ ] Workplan * [ ] Deliverables plan * [ ] Team qualifications * [ ] Relevant experience * [ ] Risk and bias mitigation plan * [ ] Confidentiality and data handling approach * [ ] Ethics approach * [ ] Timeline * [ ] Budget breakdown * [ ] Conflicts declaration * [ ] Prior work examples, if applicable *** ## 23. Appendix B: Suggested Enterprise Readiness Scorecard Template | Dimension | Readiness Question | Evidence Source | Status | Confidence | Gap | Recommended Action | | -------------------- | ------------------------------------------------------------- | --------------- | -------------------------------------------- | ---------------------- | ------ | ------------------ | | Buyer ROI | \[What economic or operational value does the buyer receive?] | \[Source] | \[Ready / Conditional / Not ready / Unknown] | \[High / Medium / Low] | \[Gap] | \[Action] | | Procurement fit | \[Can the buyer procure and adopt this?] | \[Source] | \[Status] | \[Confidence] | \[Gap] | \[Action] | | Compliance readiness | \[What documentation, diligence, or review is needed?] | \[Source] | \[Status] | \[Confidence] | \[Gap] | \[Action] | | Integration | \[What systems or workflows must integrate?] | \[Source] | \[Status] | \[Confidence] | \[Gap] | \[Action] | | Support/SLA | \[What support expectations must be met?] | \[Source] | \[Status] | \[Confidence] | \[Gap] | \[Action] | | Custody/settlement | \[What custody or settlement path is required?] | \[Source] | \[Status] | \[Confidence] | \[Gap] | \[Action] | | Delivery capacity | \[Who can implement and maintain it?] | \[Source] | \[Status] | \[Confidence] | \[Gap] | \[Action] | | Adoption pathway | \[How does usage become recurring and measurable?] | \[Source] | \[Status] | \[Confidence] | \[Gap] | \[Action] | *** ## 24. Appendix C: Suggested RWA Category Assessment Template | RWA Category | Buyer / User | Issuer / Operator | Asset Verification | Custody | Settlement / Liquidity | Compliance-Readiness Need | Data Integrity Need | Production Pathway | Confidence | Recommendation | | ------------ | ------------- | ------------------ | ------------------ | ------- | ---------------------- | ------------------------- | ------------------- | ------------------ | ---------------------- | ------------------------------------- | | \[Category] | \[Buyer/user] | \[Issuer/operator] | \[Need] | \[Need] | \[Need] | \[Need] | \[Need] | \[Pathway] | \[High / Medium / Low] | \[Go / Conditional / Monitor / No-go] | *** ## 25. Appendix D: Suggested Pilot-to-Production Conversion Template | Opportunity / Pilot | Current Stage | Production Requirement | Blocker | Owner / Workstream | Evidence Needed | Dependency | Next Decision | Recommendation | | ------------------- | -------------------------------------------------- | ---------------------- | ---------- | ------------------ | --------------- | ------------- | ------------- | -------------- | | \[Opportunity] | \[Proof of concept / Pilot / Production / Unknown] | \[Requirement] | \[Blocker] | \[Owner] | \[Evidence] | \[Dependency] | \[Decision] | \[Action] | *** ## 26. Appendix E: Suggested Compliance-Readiness and Diligence Template This template is for readiness mapping only. It is not a legal opinion. | Vertical / RWA Category | Jurisdiction or Market Context | Compliance Topic | Known Documentation Need | Uncertainty | Source Basis | Further Review Needed | Confidence | | ----------------------- | ------------------------------ | ---------------- | ------------------------ | ---------------------- | ------------ | ------------------------------------------------------------------------- | ---------------------- | | \[Vertical/category] | \[Context] | \[Topic] | \[Need] | \[High / Medium / Low] | \[Source] | \[Legal review / local counsel / buyer diligence / policy review / other] | \[High / Medium / Low] | *** ## 27. Appendix F: Suggested Adoption Signal and Handoff Template | Opportunity | Signal Observed | Signal Strength | Why It Matters | What It Does Not Prove | Next Evidence Needed | Handoff / Owner | Recommended Action | | -------------- | --------------- | ---------------------------------------- | -------------- | ---------------------- | -------------------- | -------------------- | ------------------ | | \[Opportunity] | \[Signal] | \[Strong / Moderate / Weak / Misleading] | \[Implication] | \[Limitation] | \[Evidence] | \[RFP or workstream] | \[Action] | --- # 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-06-enterprise-and-rwa-readiness-assessment.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.