> 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-05-government-and-emerging-markets-entry-strategy.md). # RFP 05: Government and Emerging Markets Entry Strategy 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 How should Cardano sequence government and emerging-market entry by region, use case, partner model, and regulatory pathway; and what concrete regional playbooks would let Cardano stakeholders move from general interest to measurable pilots, usage, or partner action? ### Evidence gap Cardano has directional evidence that government and emerging-market adoption cannot be approached as a single global opportunity. LATAM, Africa, East Asia, and other candidate regions have different adoption conditions, use cases, regulatory dependencies, languages, infrastructure constraints, and counterparty pathways. Existing evidence points to practical infrastructure needs in developing markets, including land registry, supply chain, remittances, payments, humanitarian use cases, identity, privacy, mobile-first access, and stable-value settlement. It also indicates that regulatory uncertainty, trust, local delivery capacity, language access, and stablecoin readiness may determine whether a regional opportunity is actionable. What Cardano stakeholders do not yet have is a decision-ready view of which regions and use cases should be prioritized first, which counterparties are reachable within a realistic 12-24 month horizon, what each playbook requires, and how to distinguish meaningful adoption from cosmetic engagement. ### Decision unlocked This research should enable Cardano stakeholders to decide: * which government and emerging-market opportunities should be prioritized first; * which regions should be deprioritized or monitored until prerequisites improve; * which use cases should lead in each priority region; * which partner archetypes, regulatory dependencies, and delivery capabilities are required; * which opportunities justify pilots, funding, ecosystem coordination, or partner engagement; * which dependencies should be handed to stablecoin liquidity, enterprise/RWA readiness, delivery partner, interoperability, brand, or customer segmentation workstreams. ### Expected outputs The selected vendor will produce a market prioritization matrix, regional entry strategy playbooks, regulatory landscape summaries, counterparty and partner access map, use-case viability assessment, infrastructure prerequisite assessment, adoption signal framework, research-to-action roadmap, 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. This RFP is not lobbying, government affairs execution, market-entry delivery, grant distribution, event sponsorship, public-sector business development, or legal advice. Regulatory work should be decision-oriented landscape mapping with uncertainty clearly labeled. *** ## 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 government and emerging-market entry strategy. Its purpose is to determine where Cardano has credible regional entry opportunities, what those opportunities require, and how Cardano stakeholders should sequence action. Government and emerging-market adoption is not a single market. Public-sector agencies, regulators, humanitarian organizations, multilaterals, universities, local implementation partners, mobile-money operators, financial institutions, agricultural networks, supply-chain operators, and community organizations may each play different roles. Some may be direct users, some may be distribution partners, some may provide legitimacy or access, and some may only be relevant after technical or regulatory prerequisites are in place. Prior evidence indicates that developing markets may prioritize practical infrastructure over speculative DeFi; high-inflation markets may require stablecoin access before payment or settlement use cases are credible; regulatory uncertainty can block enterprise and public-sector adoption; language exclusion and local trust conditions affect participation; and delivery capacity may determine whether a pilot can become production usage. The research should inform the Cardano Product Committee and the broader Cardano ecosystem, including regional ecosystem teams, business development teams, public-sector and humanitarian partners, builders, grant allocators, delivery partners, policy-facing contributors, and future research vendors. *** ## 3. Research Problem Statement Cardano lacks a decision-ready government and emerging-market entry strategy. Current discussion often treats "emerging markets" or "government adoption" as broad strategic priorities. That framing is too general to support resource allocation. Cardano stakeholders need to know where the ecosystem should act first and what must be true before action is justified. The selected vendor must answer questions such as: * Which regions present the strongest near-term opportunity, and why? * Which use cases are credible in each region, and which are only aspirational? * Which public-sector, humanitarian, multilateral, commercial, academic, or local partners are reachable? * What regulatory approvals, licenses, policy constraints, procurement rules, data requirements, or compliance conditions shape each opportunity? * Which opportunities depend on stablecoin liquidity, off-ramp access, privacy infrastructure, identity infrastructure, mobile-first UX, offline capability, delivery partners, or local language support? * What evidence should be required before Cardano stakeholders fund a pilot, pursue a partner, or invest in a local ecosystem initiative? * How should success be measured after entry begins? Without this evidence, Cardano risks: * pursuing region lists instead of viable entry plays; * mistaking memoranda, event attendance, or informal enthusiasm for adoption signal; * funding pilots that cannot progress because regulatory, delivery, or infrastructure prerequisites are missing; * treating LATAM, Africa, East Asia, and other regions as interchangeable; * overloading government outreach with questions that belong to stablecoin, enterprise readiness, delivery partner, interoperability, or brand workstreams; * missing opportunities where Cardano already has relevant public-sector, humanitarian, agricultural, identity, or supply-chain signals. The selected vendor must close this evidence gap by producing region-specific, use-case-specific, and partner-specific entry guidance tied to clear decision gates. *** ## 4. Definitions For this RFP: **Government entry** means a credible pathway for Cardano-related infrastructure, applications, standards, partners, or ecosystem actors to be evaluated, piloted, adopted, or supported by public-sector entities or public-sector-adjacent institutions. **Emerging-market entry** means a credible pathway for adoption in markets where infrastructure gaps, high inflation, remittances, mobile access, identity needs, supply-chain visibility, public-service delivery, or financial inclusion may create practical demand for blockchain-enabled solutions. **Region** means a country, country cluster, or sub-region with enough shared regulatory, market, language, infrastructure, and partner conditions to support a coherent playbook. Applicants should avoid treating continents as single markets. **Use case** means a specific adoption pathway such as remittances, stablecoin payments, agricultural supply-chain verification, land registry, identity, humanitarian payment rails, public records, product traceability, education credentials, microfinance, or public procurement transparency. **Entry play** means a combination of region, use case, partner archetype, regulatory pathway, infrastructure prerequisites, delivery model, and milestone sequence. **Counterparty** means an entity whose cooperation or validation materially affects market entry, such as a ministry, regulator, local agency, university, humanitarian organization, multilateral, bank, payment provider, mobile-money operator, implementation partner, civic organization, or enterprise anchor. **Partner archetype** means a category of partner needed for execution, such as government sponsor, regulator, humanitarian implementer, local systems integrator, university hub, bank, mobile-money operator, agricultural cooperative, enterprise anchor, NGO, or community distribution partner. **Regulatory dependency** means a law, rule, license, supervisory posture, procurement process, data protection requirement, currency control, identity rule, tax treatment, or public-sector approval that affects whether a use case can proceed. **Adoption signal** means evidence that a regional opportunity may produce meaningful usage, deployment, recurring transactions, local partner activity, funded pilots, retained users, or durable value for the Cardano ecosystem. **Cosmetic activity** means engagement that appears strategically useful but does not create measurable adoption, such as event attendance, vague letters of intent, broad ecosystem praise, unqualified partner announcements, or unsupported claims of government 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. Identify and prioritize government and emerging-market entry opportunities by region, use case, partner pathway, regulatory readiness, infrastructure fit, and counterparty access. 2. Produce a market prioritization matrix that explains where Cardano stakeholders should act first, wait, monitor, or avoid. 3. Develop regional entry playbooks for priority markets, each with a named use-case thesis, partner archetype, regulatory pathway, infrastructure prerequisites, milestone sequence, risks, and adoption metrics. 4. Map the regulatory landscape for priority regions at a level sufficient to support go/no-go, pilot, partner, or further diligence decisions. 5. Identify reachable government, humanitarian, multilateral, commercial, academic, and local delivery counterparties relevant to each priority play. 6. Assess which use cases are credible in each region and which require dependencies such as stablecoin liquidity, off-ramp access, privacy, identity, interoperability, mobile-first access, offline capability, compliance artifacts, or delivery partners. 7. Distinguish real adoption signal from cosmetic activity. 8. Recommend research-to-action pathways, including pilots, partner engagement, ecosystem funding, local capability building, or no-action recommendations. 9. Define metrics and evidence thresholds for evaluating whether regional entry is working. 10. Identify findings that should be handed to adjacent Product Research Initiative RFPs or ecosystem 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 | | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | Which regions should Cardano prioritize first for government and emerging-market entry? | Comparative market prioritization across candidate regions, including use-case fit, regulatory readiness, infrastructure fit, counterparty access, local delivery capacity, and evidence confidence | Cardano can sequence regional attention and funding based on decision criteria | Regional prioritization remains anecdotal or politically driven | Decide which regions to pursue, monitor, or deprioritize | | Which use cases are credible entry plays in each priority region? | Use-case viability assessment by region, including problem severity, stakeholder demand, current alternatives, Cardano fit, dependencies, and measurable adoption pathway | Priority regions have specific entry plays rather than generic market narratives | The opportunity is too broad to support action | Select leading use cases per region and avoid unsupported vertical claims | | Which counterparties are reachable on a 12-24 month horizon? | Counterparty map and engagement evidence covering public-sector, humanitarian, multilateral, commercial, academic, local delivery, and ecosystem actors | There are identifiable routes to decision-makers or implementation partners | Opportunity depends on inaccessible or speculative stakeholders | Decide whether to pursue partner engagement, intermediary strategy, or no-action | | What regulatory conditions shape each priority play? | Regulatory landscape summaries with cited sources, named dependencies, data/privacy constraints, licensing considerations, procurement constraints, and uncertainty levels | Regulatory pathway and blockers are clear enough to inform next steps | The legal or procurement pathway is too uncertain for near-term action | Define regulatory diligence, local counsel needs, policy engagement, or go/no-go conditions | | What infrastructure prerequisites must be in place for each play? | Assessment of stablecoin liquidity, off-ramp access, privacy, identity, wallet UX, mobile/offline access, interoperability, compliance artifacts, delivery partners, and support/SLA needs | Required prerequisites can be named and sequenced | Entry strategy ignores the conditions that determine whether adoption can happen | Coordinate with stablecoin, enterprise/RWA, delivery partner, interoperability, or product workstreams | | What partner and delivery model is required in each region? | Partner archetype analysis, local delivery capacity review, implementation role map, and evidence of who can operate or maintain the solution | Cardano can identify how execution would happen beyond initial outreach | Opportunity cannot move beyond concept because delivery ownership is unclear | Define partner recruitment, local capability building, pilot ownership, or handoff requirements | | What would count as meaningful adoption rather than cosmetic activity? | Adoption signal framework with metrics by use case, evidence thresholds, monitoring method, and examples of weak or misleading signals | Cardano can evaluate whether regional entry is producing real outcomes | Engagement may be overvalued without usage, retention, or partner action | Set pilot KPIs, funding triggers, and stop conditions | | Which regional plays justify pilots, funding, or ecosystem coordination? | Ranked action roadmap with go/conditional-go/no-go recommendations, costs or cost drivers where available, dependencies, milestones, and risk levels | Cardano stakeholders can decide what to fund or coordinate next | The study produces analysis without a clear action path | Approve pilots, fund readiness work, engage partners, or defer | | Which findings should be handed to adjacent RFPs or workstreams? | Cross-RFP handoff memo mapping dependencies and blockers to customer segmentation, use-case landscape, stablecoin liquidity, enterprise/RWA, delivery partners, L2/interoperability, brand, or other workstreams | Government and emerging-market research informs adjacent work without absorbing it | This RFP duplicates other research or hides blockers inside regional recommendations | Keep scope clean and route non-regional issues to the right decision owners | *** ## 7. Scope of Work ### In scope The selected vendor should cover: * regional market prioritization for government and emerging-market entry; * at minimum, consideration of LATAM, Africa, and East Asia as candidate region categories, with applicants free to propose a narrower or more specific country-cluster design if justified; * use-case prioritization by region; * public-sector, humanitarian, multilateral, commercial, academic, and local partner pathway assessment; * regulatory landscape summaries per priority region; * infrastructure prerequisite assessment, including stablecoin, off-ramp, privacy, identity, mobile/offline access, interoperability, compliance, and delivery capacity where relevant; * stakeholder interviews or equivalent primary research with regional experts, counterparties, intermediaries, and implementation actors; * analysis of existing Cardano signals relevant to government and emerging-market adoption; * competitor or peer ecosystem comparison where it helps explain market entry standards or regional expectations; * adoption signal framework and cosmetic-activity filter; * regional strategy playbooks; * research-to-action roadmap; * public and confidential reporting. ### Regional scope guidance Applicants should propose the region design that best answers the decision gates. The RFP does not require every region to receive equal research depth. Applicants should avoid treating broad labels such as "Africa," "LATAM," or "East Asia" as single markets. Where broad regions are used, they should be broken into country clusters or priority countries with clear selection logic. Minimum regional consideration should include: | Region Category | Research Purpose | | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | | LATAM or high-inflation markets | Evaluate payment, remittance, stable-value settlement, merchant, and community adoption conditions | | Africa or practical infrastructure markets | Evaluate public-service, agricultural, identity, supply-chain, humanitarian, mobile-first, language, and infrastructure sovereignty conditions | | East Asia or regulatory-pilot markets | Evaluate government, enterprise, standards, local partner, payment, and regulatory pathways | | Applicant-justified additional region | Include only where the applicant can show strategic fit, counterparty access, or evidence value | Applicants may recommend a phased approach where the full candidate set is screened first and deeper primary research is concentrated on the highest-value regions. ### Use-case scope guidance Applicants should assess candidate use cases by region and avoid assuming that the same use case should lead everywhere. Candidate use cases may include: | Use Case | Research Purpose | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------- | | Stablecoin payments and settlement | Determine where stable-value instruments, liquidity, off-ramps, and regulation support credible usage | | Remittances | Assess corridor relevance, compliance constraints, user need, partner availability, and off-ramp requirements | | Humanitarian payment rails | Assess NGO, multilateral, beneficiary, compliance, privacy, and delivery requirements | | Agricultural supply chain | Assess traceability, financing, farmer identity, market access, and local implementation pathways | | Land registry or public records | Assess government readiness, procurement pathway, legal enforceability, and data governance requirements | | Identity or credentials | Assess user need, public-sector acceptance, privacy, standards, and wallet/user experience requirements | | Product or supply-chain verification | Assess enterprise/public-sector demand, data quality, partner model, and recurring transaction pathway | | Public procurement or transparency | Assess political feasibility, safety risk, governance context, and public-sector willingness | Applicants may add or remove use cases if they explain how the change improves decision value. ### Out of scope and handoff boundaries This RFP should remain focused on regional entry strategy, government and emerging-market pathways, use-case sequencing, regulatory landscape, partner archetypes, 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 | Identify regional stakeholder groups and partner/user archetypes needed for entry strategy | Full customer segmentation and persona model | | Use-case landscape | Assess use-case viability inside priority regions | Full global Cardano use-case audit or competitive positioning map | | Stablecoin liquidity | Identify where stablecoin liquidity, off-ramps, or local settlement are prerequisites | Full stablecoin liquidity diagnostic, incentive design, or market-maker strategy | | Enterprise and RWA | Identify enterprise or public-sector readiness requirements where they affect regional entry | Full enterprise/RWA readiness assessment, SLA framework, or compliance artifact production | | Delivery partners | Identify local partner archetypes and delivery capacity constraints | Full certified delivery partner network design | | L2 and interoperability | Identify infrastructure dependencies that affect regional entry | Full L2 adoption or interoperability demand study | | Brand awareness | Identify trust or credibility issues that affect government or regional adoption | Full brand awareness, perception, or message testing study | | Government affairs | Define evidence, pathways, and decision requirements | Lobbying, public affairs execution, campaign management, or direct government representation | | Pilot execution | Recommend pilot concepts, requirements, KPIs, and next steps | Running pilots unless separately commissioned | 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 country-level diligence for one or two high-priority markets; * local-language primary research; * field visits or in-person workshops; * local counsel review of regulatory findings; * deeper peer ecosystem benchmarking in priority regions; * pilot design templates for top-ranked plays; * partner recruitment or warm-introduction support after the research phase; * a monitoring dashboard specification for ongoing regional entry tracking. *** ## 8. Required Methodology Applicants should propose the methodology they believe will best answer the decision gates. The final research design will be confirmed during the research design review before fieldwork begins. The methodology should combine regional market analysis, desk research, primary stakeholder research, regulatory mapping, and decision-oriented synthesis. A desk-only proposal will be considered weak unless the applicant can justify why primary access is not required for the specific scope proposed. ### Core research hypotheses Applicants should test, refine, or reject hypotheses such as: 1. Government and emerging-market adoption opportunities differ materially by region and cannot be addressed through a single global playbook. 2. Some regional opportunities are blocked less by technology than by regulatory pathway, procurement model, trust, local delivery capacity, or stable-value settlement. 3. Stablecoin liquidity and off-ramp access are prerequisites for payment, remittance, and settlement use cases in some markets, but not necessarily for all public-sector or infrastructure use cases. 4. Public-sector entities may not be direct high-volume users at first, but can act as legitimacy, distribution, procurement, or coordination partners. 5. The strongest entry plays will combine a concrete use case, reachable counterparty, local delivery model, and measurable adoption signal. 6. Some government or emerging-market activity that appears promising will prove cosmetic when tested against adoption, procurement, usage, or implementation thresholds. 7. Regional partner and implementation capacity may be as important as protocol fit. Applicants may add hypotheses if they remain testable and relevant to decision-making. ### Required evidence types The research should include: * regional market indicators relevant to selected use cases; * regulatory and policy-source evidence; * counterparty access evidence; * stakeholder interview or expert-call evidence; * local partner and delivery-capacity evidence; * use-case-specific demand evidence; * infrastructure prerequisite evidence; * peer or competitor evidence where relevant; * existing Cardano signal review; * adoption metric and monitoring evidence; * limitations and confidence scoring. ### Primary research expectations Applicants should conduct primary research sufficient to validate or challenge the regional playbooks. Primary research may include: * interviews with public-sector stakeholders or former public-sector officials; * interviews with regulators, policy experts, local counsel, or compliance professionals; * interviews with humanitarian organizations, multilaterals, NGOs, or implementation intermediaries; * interviews with local technology providers, systems integrators, wallet/payment providers, banks, mobile-money operators, agricultural networks, universities, or civic organizations; * interviews with Cardano ecosystem actors already active in candidate regions; * expert panels or structured workshops where direct government access is not feasible. Applicants must state: * which respondent types are required; * which access is already secured, likely, uncertain, or unavailable; * how they will handle regions where direct government access is not feasible; * how they will avoid over-weighting Cardano insiders; * how they will document limits on confidence. ### Regional market analysis Applicants should build a comparable regional screening model. The model should include criteria such as: * use-case fit; * severity of problem or unmet need; * regulatory readiness; * policy or procurement feasibility; * stablecoin, payment, or off-ramp readiness where relevant; * mobile and digital infrastructure fit; * local delivery capacity; * language and cultural access; * counterparty reachability; * ecosystem presence; * likely time to pilot; * measurable adoption pathway; * risk and sensitivity; * confidence level. The model should be transparent enough that Cardano stakeholders can understand why a region was prioritized, deferred, or rejected. ### Regulatory mapping requirements Regulatory mapping should be proportionate and decision-oriented. It is not expected to replace formal legal advice. For each priority region, the vendor should identify: * relevant policy or regulatory bodies; * public-sector procurement considerations; * cryptoasset, stablecoin, payment, data protection, privacy, identity, and financial-services considerations where relevant; * restrictions, licenses, or permissions that may affect the entry play; * treatment of public-chain transparency where relevant; * local data residency or hosting considerations where relevant; * regulatory uncertainty and open questions; * whether local counsel or specialist review is required before action. If a finding depends on uncertain, proprietary, paid, or non-public data, it must be marked as requiring validation. ### Counterparty and partner mapping Applicants should identify the roles required for each regional play, not just list possible partners. The counterparty and partner map should distinguish: * decision sponsors; * regulators or policy gatekeepers; * procurement owners; * local delivery partners; * distribution partners; * technical implementers; * compliance or legal enablers; * payment, banking, or off-ramp partners; * humanitarian or multilateral intermediaries; * universities or talent/community hubs; * ecosystem actors; * beneficiaries or end users where relevant. Where named counterparties are included, the vendor should state whether the counterparty was interviewed, already known, desk-identified, referred by another stakeholder, or hypothetical. ### Infrastructure prerequisite assessment Each playbook should state which prerequisites must be in place before action is credible. These may include: * stablecoin availability and liquidity depth; * local off-ramp access; * wallet UX and account abstraction needs; * mobile-first or offline-capable design requirements; * privacy or selective disclosure requirements; * identity, credential, or KYC requirements; * interoperability or bridge requirements; * predictable fees or cost model; * compliance artifacts; * delivery partner capacity; * post-deployment support or SLA expectations; * local-language support; * data hosting or sovereignty requirements. Prerequisites should be classified as already met, partially met, unmet, unknown, or dependent on another workstream. ### Benchmarking requirements Applicants should benchmark against peer ecosystems only where it improves decision value. Useful benchmarking may include: * how other blockchain ecosystems have entered similar regions; * which public-sector or humanitarian pilots progressed to production and why; * which regional entry models failed or remained symbolic; * what partner, funding, regulatory, or delivery structures were used; * whether the benchmark is transferable to Cardano. Benchmarking should not become a general competitor positioning study. ### Adoption signal standard The selected vendor must define what should count as meaningful adoption for each recommended play. Potential signals may include: * signed pilot agreement with a clear implementation owner; * funded implementation plan; * regulator or procurement pathway identified; * active local delivery partner; * recurring transactions or usage after deployment; * retained users or institutional users; * measurable cost, trust, transparency, settlement, or operational benefit; * documented integration into an existing public-sector, humanitarian, or commercial workflow; * ecosystem actors required to execute are identified and reachable; * clear stop/go criteria for next funding. The vendor should also identify weak signals that should not trigger major spend. ### Bias controls Applicants must explain how they will control for: * Cardano insider optimism; * local elite or capital-city bias; * English-language bias; * event and conference sample bias; * government-access bias; * partner self-promotion; * NGO or multilateral overgeneralization; * crypto-native respondent bias; * unsupported regulatory interpretation; * overclaiming from small samples; * treating intent as adoption; * geopolitical, political-safety, or public-sector sensitivity. ### What should not count as evidence The following should not be treated as sufficient evidence by themselves: * broad claims that a region is "strategic" without use-case and counterparty evidence; * population size or macro-growth statistics without a Cardano-specific entry pathway; * letters of intent without implementation owner, timeline, or adoption metrics; * event attendance, panel invitations, or informal government meetings; * generic statements that blockchain can help land registries, remittances, identity, or transparency; * Cardano community enthusiasm inside a region without external stakeholder validation; * regulatory summaries copied from public sources without interpretation for the specific use case; * competitor announcements without evidence of production usage; * pilot ideas that ignore local delivery capacity; * payment or remittance recommendations that ignore stablecoin, liquidity, off-ramp, compliance, and user trust conditions. *** ## 9. Expected Deliverables ### Core decision outputs The selected vendor must provide: 1. **Market prioritization matrix** - candidate regions scored by use-case fit, regulatory readiness, infrastructure prerequisites, counterparty access, delivery capacity, adoption potential, risk, and confidence. 2. **Regional entry playbooks** - one playbook per approved priority region, covering leading use case, partner archetype, regulatory pathway, infrastructure prerequisites, milestone sequence, risks, metrics, and action recommendation. 3. **Use-case viability assessment** - comparison of candidate use cases by region, including why each should lead, wait, or be rejected. 4. **Regulatory landscape summaries** - concise, citable, decision-oriented summaries for each priority region. 5. **Counterparty and partner access map** - roles, named or archetypal counterparties, access status, relationship path, confidence level, and follow-on potential. 6. **Infrastructure prerequisite assessment** - dependency map for stablecoins, off-ramps, privacy, identity, mobile/offline access, interoperability, compliance, delivery partners, and support/SLA needs. 7. **Adoption signal framework** - metrics and evidence thresholds for distinguishing meaningful adoption from cosmetic activity. 8. **Research-to-action roadmap** - recommended next steps, including pilots, partner engagement, funding, readiness work, no-action decisions, dependencies, and sequencing. 9. **Executive decision memo** - concise recommendation for Cardano stakeholders, including go/conditional-go/no-go calls and immediate decisions required. 10. **Cross-RFP handoff memo** - findings that should inform customer segmentation, use-case landscape, stablecoin liquidity, enterprise/RWA readiness, delivery partner, L2/interoperability, brand, or other workstreams. ### Supporting research outputs The selected vendor should also provide: * methodology appendix; * interview guide and respondent screener; * anonymized interview notes or summaries where permitted; * regional evidence workbook; * regulatory citation appendix; * benchmark appendix where relevant; * confidence and limitations register; * risk register; * data-source inventory; * glossary of key regulatory, regional, and partner terms where useful. ### Public and community-facing outputs The selected vendor must provide: * public summary suitable for publication, excluding confidential or sensitive findings; * publishable market prioritization overview where confidentiality permits; * publishable explanation of methodology, confidence levels, and limitations; * public recommendations that do not expose sensitive government, respondent, or partner information. *** ## 10. Acceptance Criteria Deliverables must meet the following acceptance criteria. | Deliverable | Description | Format | Purpose | Acceptance Criteria | Decision Enabled | Failure Modes | | -------------------------------------- | -------------------------------------------------------- | ------------------------------------ | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------- | ---------------------------------------------------------------------------- | | Market prioritization matrix | Comparative screening of candidate regions and use cases | Spreadsheet plus narrative summary | Decide which regions to pursue, monitor, or deprioritize | Includes criteria, scoring logic, evidence source, confidence level, and recommendation for each candidate region | Regional sequencing | Scores are unexplained, subjective, or based mainly on macro statistics | | Regional entry playbooks | Actionable playbooks for priority regions | Slide or document section per region | Define what each regional entry play requires | Each playbook includes use case, partner archetype, regulatory pathway, infrastructure prerequisites, milestones, risks, metrics, and go/conditional-go/no-go call | Pilot and partner decisions | Playbooks are generic, interchangeable, or missing dependencies | | Use-case viability assessment | Region-by-use-case comparison | Table plus analysis | Select leading use cases by region | Assesses problem severity, Cardano fit, alternatives, stakeholder demand, dependencies, and measurable adoption pathway | Use-case prioritization | Treats all use cases as equally plausible or ignores local conditions | | Regulatory landscape summaries | Decision-oriented regulatory view per priority region | Narrative plus source appendix | Identify blockers, permissions, and open questions | Names relevant regulatory bodies, constraints, permissions, uncertainty, and where local counsel is required | Regulatory diligence and go/no-go decisions | Provides generic legal summaries without use-case implications | | Counterparty and partner access map | Map of stakeholders needed for each play | Table or CRM-style register | Identify who must act and how reachable they are | Distinguishes interviewed, referred, desk-identified, hypothetical, and inaccessible counterparties; includes role and confidence | Partner engagement decisions | Lists organizations without access status or role clarity | | Infrastructure prerequisite assessment | Dependency analysis by play | Matrix | Coordinate prerequisites before action | Classifies each prerequisite as met, partial, unmet, unknown, or dependent on another workstream | Dependency sequencing | Ignores stablecoin, off-ramp, privacy, identity, delivery, or UX constraints | | Adoption signal framework | Metrics and evidence thresholds | Table plus guidance | Avoid cosmetic engagement | Defines strong, moderate, weak, and misleading signals by use case | Funding triggers and stop conditions | Treats announcements or meetings as adoption | | Research-to-action roadmap | Recommended next steps and sequencing | Roadmap plus memo | Move from research to action | Includes go/conditional-go/no-go recommendations, dependencies, owners or owner archetypes, milestones, and risk levels | Pilot, funding, and coordination decisions | Recommends action without evidence thresholds or ownership | | Executive decision memo | Concise decision summary | Short memo | Support CPC and ecosystem decision-making | States top 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 or workstreams with requested action | Cross-portfolio coordination | Duplicates adjacent scopes or buries dependencies | | Public summary | Non-confidential public-facing 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 counterparty data or publishes unsupported claims | Final deliverables must include a limitations section stating what the research can and cannot support. *** ## 11. Vendor Eligibility This RFP is open to qualified research teams, consultancies, academic groups, policy researchers, market-entry specialists, ecosystem research organizations, and multidisciplinary teams that can credibly deliver the required evidence. Strong applicants may include teams with demonstrated experience in: * emerging-market strategy; * government or public-sector market entry; * regulatory and policy research; * humanitarian, multilateral, or NGO research; * financial inclusion, payments, remittances, identity, agriculture, or supply-chain research; * Web3, blockchain, digital assets, or digital public infrastructure; * primary stakeholder interviews in sensitive or institutional contexts; * cross-regional market prioritization; * partner and delivery model assessment; * translating research into go/no-go decisions and implementation roadmaps. Applicants do not need to be Cardano-native, but they must show that they can understand Cardano's ecosystem, technical constraints, governance context, and adjacent Product Research Initiative scopes. Applicants should disclose whether they have: * existing government, humanitarian, multilateral, regulatory, or regional networks; * local-language research capability; * local partners or subcontractors; * access to region-specific paid or proprietary datasets; * experience with sensitive respondent confidentiality; * prior work in Cardano, peer-chain ecosystems, or public-sector blockchain projects. Subcontracting is allowed if roles, responsibilities, costs, access, and conflicts are clearly disclosed. *** ## 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: * regional screening and country-cluster selection logic; * use-case selection logic by region; * counterparty and partner access plan; * regulatory landscape approach and legal-advice boundary; * infrastructure prerequisite assessment approach; * adoption-signal and cosmetic-activity filter. Budgets should explain how cost relates to regional expertise, local-language needs, counterparty access, regulatory research, travel if any, 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 move from broad regional narratives to specific entry plays with reachable counterparties, clear regulatory and infrastructure dependencies, realistic partner models, and measurable adoption signals. A strong proposal should use screening before deep dives; avoid treating broad regions as single markets; include local or regional expertise; distinguish regulatory landscape from legal advice; and explain what would justify pilots, partner action, funding, monitoring, or no action. Proposals should score lower if they list countries without selection logic, treat events or letters of intent as adoption, overclaim regulatory feasibility, or cannot show realistic counterparty access. Cost should be judged against evidence value, not lowest price. Higher-cost proposals may be justified by regional expert access, local language coverage, counterparty research, or stronger regulatory and partner-pathway evidence. ## 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, region scope, workplan, communication cadence, and confidentiality expectations | | Research design alignment | Applicant-proposed timing | Align on region-screening model, candidate use cases, stakeholder targets, regulatory mapping method, and bias controls before fieldwork | | Regional screening review | Applicant-proposed timing | Review initial candidate region screening and select priority deep dives | | Stakeholder access check | Applicant-proposed timing | Surface recruitment issues, access constraints, region limitations, or substitutions needed | | Regulatory and infrastructure review | Applicant-proposed timing | Review early regulatory findings and infrastructure prerequisite analysis | | Interim findings review | Applicant-proposed timing | Test whether evidence is answering the decision gates and whether regional playbooks need adjustment | | Draft deliverables review | Applicant-proposed timing | Review market prioritization matrix, playbooks, regulatory summaries, access map, and roadmap | | 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 multi-region primary research, local-language work, public-sector access, or regulatory mapping is required. *** ## 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, region scope, use-case scope, stakeholder access, regulatory mapping, confidentiality expectations, and publication boundaries, while leaving room for the vendor to adapt methods as evidence and access constraints emerge. | Checkpoint | Purpose | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | Kickoff | Confirm objectives, decision gates, region scope, workplan, communication cadence, and confidentiality expectations | | Research Design Review | Align on region-screening model, candidate use cases, stakeholder targets, regulatory mapping method, and bias controls before fieldwork | | Regional Screening Review | Review initial candidate region screening and select priority deep dives | | Stakeholder Access Check | Surface recruitment issues, access constraints, region limitations, or substitutions needed | | Regulatory and Infrastructure Review | Review early regulatory findings and infrastructure prerequisite analysis | | Interim Findings Review | Test whether evidence is answering the decision gates and whether regional playbooks need adjustment | | Draft Deliverables Review | Review market prioritization matrix, playbooks, regulatory summaries, access map, adoption signal framework, and roadmap | | 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 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 disclose weak counterparty access, regulatory ambiguity, country-selection problems, local-language limitations, region-specific safety concerns, or findings that show a region or use case should be deprioritized. *** ## 16. Risks, Bias Controls, and Safeguards Applicants must include a research integrity plan. | Risk | Required Control | | -------------------------------------- | --------------------------------------------------------------------------------------------- | | Cardano insider bias | Separate ecosystem views from external stakeholder evidence | | Region generalization | Use country or country-cluster logic rather than broad continental claims | | Local elite bias | Include implementation and beneficiary-side evidence where relevant | | Language bias | Disclose language coverage and where translation or local-language research is needed | | Government-access bias | State when direct access is unavailable and how intermediary evidence is weighted | | Regulatory overclaiming | Label uncertainty and identify where local counsel or further diligence is required | | Partner self-promotion | Corroborate partner claims with independent evidence where possible | | Cosmetic engagement | Apply adoption signal thresholds before recommending action | | Stablecoin and off-ramp assumptions | Explicitly classify payment and settlement dependencies | | Political or public-sector sensitivity | Protect respondents and avoid exposing sensitive institutional views | | Scope creep | Use cross-RFP handoff logic for adjacent product, liquidity, enterprise, or delivery blockers | | Conflicted recommendations | Require conflict declarations and mitigation plans | | Sensitive counterparty findings | 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: * regional scope; * country-cluster logic; * use-case scope; * stakeholder access expectations; * government or regulatory interview constraints; * treatment of inaccessible counterparties; * stablecoin, off-ramp, privacy, identity, or delivery dependencies; * regulatory mapping depth; * 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, regional awareness, regulatory caution, counterparty-access discipline, and realistic thinking about what market-entry 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 government, regulatory, humanitarian, or partner findings; * treatment of proprietary, paid, or locally sourced 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 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 government or regulatory views, confidential partner information, security-sensitive details, or commercially sensitive information. 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 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 political, employment, regulatory, or institutional risk; * apply extra care when working with public-sector, humanitarian, or vulnerable-population contexts. *** ## 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 governments, regulators, NGOs, multilaterals, local partners, delivery firms, or commercial entities discussed in the research; * relationships with respondents, regional intermediaries, local counsel, or subcontractors; * political affiliations or advocacy roles relevant to the target regions; * 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 * [ ] Regional scope and prioritization plan * [ ] Use-case assessment plan * [ ] Stakeholder access plan * [ ] Regulatory mapping plan * [ ] Infrastructure prerequisite plan * [ ] Adoption signal plan * [ ] Workplan * [ ] Team qualifications * [ ] Relevant experience * [ ] Data sources * [ ] 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 Market Prioritization Template | Region / Country Cluster | Candidate Use Case | Problem Severity | Cardano Fit | Regulatory Readiness | Counterparty Access | Infrastructure Readiness | Delivery Capacity | Adoption Pathway | Risk | Confidence | Recommendation | | ------------------------ | ------------------ | ---------------------- | ---------------------- | ---------------------- | ---------------------- | ---------------------------------- | ---------------------- | ---------------- | ------- | ---------------------- | ------------------------------------- | | \[Region] | \[Use case] | \[High / Medium / Low] | \[High / Medium / Low] | \[High / Medium / Low] | \[High / Medium / Low] | \[Met / Partial / Unmet / Unknown] | \[High / Medium / Low] | \[Pathway] | \[Risk] | \[High / Medium / Low] | \[Go / Conditional / Monitor / No-go] | *** ## 24. Appendix C: Suggested Regional Playbook Template | Field | Content | | ---------------------------- | ------------------------------------------------------------------------------------------------ | | Priority region | \[Region or country cluster] | | Leading entry use case | \[Use case] | | Strategic rationale | \[Why this play matters] | | Target stakeholders | \[Users, beneficiaries, partners, decision-makers] | | Partner archetype | \[Government sponsor / regulator / NGO / bank / mobile-money operator / SI / university / other] | | Regulatory pathway | \[Known pathway, dependencies, uncertainty] | | Infrastructure prerequisites | \[Stablecoin / off-ramp / privacy / identity / UX / interoperability / delivery / support] | | Delivery model | \[Who builds, operates, supports, and scales] | | Milestone sequence | \[Discovery / pilot / production / scale] | | Adoption metrics | \[Usage, transactions, retained users, institutional adoption, workflow integration, other] | | Key risks | \[Risks] | | Confidence level | \[High / Medium / Low] | | Recommendation | \[Go / conditional-go / monitor / no-go] | *** ## 25. Appendix D: Suggested Regulatory Landscape Template | Region | Use Case | Relevant Authorities | Key Rules / Constraints | License or Approval Need | Data / Privacy Considerations | Procurement Considerations | Stablecoin / Payment Considerations | Uncertainty | Further Diligence Needed | | --------- | ----------- | -------------------- | ----------------------- | ------------------------ | ----------------------------- | -------------------------- | ----------------------------------- | ---------------------- | ------------------------ | | \[Region] | \[Use case] | \[Authorities] | \[Constraints] | \[Need] | \[Considerations] | \[Considerations] | \[Considerations] | \[High / Medium / Low] | \[Action] | *** ## 26. Appendix E: Suggested Counterparty and Partner Access Register | Region | Counterparty / Archetype | Role in Entry Play | Access Status | Evidence Source | Interest / Posture | Dependency | Follow-On Action | Confidentiality | | --------- | ------------------------ | ------------------ | --------------------------------------------------------------------------------------- | --------------- | ------------------ | ------------- | ---------------- | ------------------------ | | \[Region] | \[Entity or archetype] | \[Role] | \[Interviewed / warm access / referred / desk-identified / hypothetical / inaccessible] | \[Source] | \[Posture] | \[Dependency] | \[Action] | \[Public / confidential] | *** ## 27. Appendix F: Suggested Adoption Signal and Handoff Template | Region | Use Case | Signal Observed | Signal Strength | Why It Matters | What It Does Not Prove | Next Evidence Needed | Handoff / Owner | Recommended Action | | --------- | ----------- | --------------- | ---------------------------------------- | -------------- | ---------------------- | -------------------- | -------------------- | ------------------ | | \[Region] | \[Use case] | \[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-05-government-and-emerging-markets-entry-strategy.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.