Article 2: Activation Strategy and Dependency Resolution – The Cold-Start Problem is a Structural Problem

Author: Alexandre Kotcherguine, Vision Officer & Investor

Contributors: Georgi Gitchev, Governance Officer & Organisation Domain Lead; Matt Jackson, Growth Officer

Executive Summary

Article 1 established that go-to-market for Web3 infrastructure is an activation graph – a dependency graph of multi-sided participants in which regulatory permission is a first-class node, with thresholds and a bounding constraint set. The article closed with a hard question, and this one answers it: given the graph, how do you actually switch the network on?

The default framing is that this is a distribution problem – a matter of reach, marketing, partnerships, and awareness. That framing is wrong, and the source of most early-stage failure in this category. Activation is dependency resolution under cold-start conditions, and the questions that matter are structural rather than narrative. Projects that answer them structurally have a materially higher probability of activating; projects that treat them as marketing questions, on the cohort evidence (Methodological Appendix V.3.7.0), rarely do.

1. 1. The Cold-Start Problem as a Binding Constraint
   2. Defining Minimum Viable Network State
   3. Three Bootstrapping Loop Archetypes
   4. Operator Tests

The activation graph defined in Article 1 is not, on its own, an activation plan. It is the minimum object from which one can be derived. Before turning to the cold-start problem proper, four uses of the graph are worth naming explicitly – each is a move that activation strategy depends on, and each is unavailable to a project that has not done the graph work.

It disciplines claims of progress. “We onboarded 500 wallets last month” is not progress if wallets are three edges downstream of the hard side and the hard side is still inactive. The graph tells the operator which numbers matter at which stage of the activation path.

It exposes optimistic sequencing. A plan that assumes Merchants activate before R_j is live in a target jurisdiction is not aggressive; in this category it is consistently observed to fail. The graph makes this visible before the capital is committed and the activation path begins.

It makes the cold-start problem diagnosable. When the network is not activating, the graph identifies where the blockage is – missing precondition, unmet threshold, or inactive R_j – rather than routing the team back to “we need more marketing”. This diagnostic content is the substantive payoff of the graph for an activation team.

It provides the input to the capital model. Once the graph is defined, the capital requirement is a function of activation costs along each path, weighted by timing and bounded by the constraints – the derivation Article 4 makes explicit, and the closed loop on which the corpus’s second novelty claim rests.

Every multi-sided network faces the same initial condition: no side has reason to join, because no other side is present. An exchange with no market-makers is not an exchange; an identity layer with no relying parties is not an identity layer. The value proposition to each participant class is a function of the presence of the other classes, and at launch that function evaluates to near zero.

This is the cold-start problem. Andrew Chen’s treatment of it in The Cold Start Problem (2021) is now the standard reference, and two of its ideas do particularly heavy lifting: the minimum viable network – the smallest configuration at which interactions self-sustain – and the hard side – the participant class whose acquisition is disproportionately costly and whose presence is disproportionately valuable. Both generalise cleanly to Web3 infrastructure.

What changes in Web3 is that the cold-start problem is not merely a growth challenge to be engineered around. It is the binding constraint on the capital requirement. Every day below MVNS is a day the treasury is paying to hold the network together with subsidies that must eventually be withdrawn. Misjudge MVNS, or choose the wrong bootstrapping loop, and the network burns through capital faster than utility can replace incentives.

For infrastructure – as opposed to consumer apps – this definition needs sharpening on three axes.

Completeness of the participant graph. MVNS is not “some users on each side”. It is the minimum number per class at which interactions between classes self-sustain. For a regulated on-chain financial network, a plausible MVNS specification might be: two Operators operating in at least two jurisdictions; five Providers with live customer flow; three Merchants covering at least one full product category; a Client base that transacts weekly, not one-off. These numbers are illustrative; the point is that the network is alive only when all thresholds are met. Article 5 gives a worked example with concrete per-class numbers.

Depth per participant, not just count. Ten Providers who each signed a memorandum of understanding and never went live is not ten Providers; it is zero.

Stability under subsidy withdrawal. MVNS is defined as the state in which the network continues to function if subsidies are paused. If pausing subsidies causes the network to unwind within weeks, the state below MVNS has been confused for MVNS itself.

Estimation in practice – the open research problem

MVNS estimation, as the framework currently specifies it, is a research problem the activation-graph view opens rather than solves. This is conceded explicitly because the alternative – describing estimation methods that do not in fact estimate – is the failure mode this series most wants to avoid.

Two estimation approaches are tractable in principle but each has a binding limitation in practice.

Forward (comparable-network) estimation. Map per-class self-sustaining depth observed in a comparable network onto the project’s own classes, with adjustments for graph-topology and constraint-set differences. The method requires a comparable to exist at sufficient depth, with per-class telemetry available, and with its own substitution curve crossed. The Methodological Appendix V.3.7.0 documents only one or two cohort members where these conditions plausibly hold (Canton Network at scale, Provenance for the single-counterparty subset of its activity), and even there the per-class depth data is partial. The method is the right one in principle; the data conditions for executing it cleanly are met for almost no project at the planning stage.

Backward (substitution-curve) estimation. Recover the per-class self-sustaining depth from the substitution curve (Article 3 §3.1) – the per-class participation depth implied at the latest crossover time tᵢ* given the project’s incentive schedule and projected utility-accumulation rate. The method requires the substitution curve to itself be specified, which requires an MVNS target to have been chosen. The estimation chain is therefore circular at the planning stage; backward estimation is recovered only after launch, when calibration data on the realised substitution curve becomes available, at which point the estimate is no longer ex-ante.

Neither approach produces a clean ex-ante point estimate. Both produce ranges, with the range width itself being a function of how much comparable data is available. Where the ranges are tight, the project is in a category with mature comparables and the activation-graph framework is operating in a calibrated regime; where the ranges are wide, the project is in a category where MVNS estimation is a research problem the operator cannot defer.

What this means for capital planning. The honest position is that MVNS enters the capital model as a range with a sensitivity attached, not as a point estimate. Article 4 §4.2 treats this explicitly: the capital requirement is sensitive to MVNS at a magnitude an operator can quantify, and the Operator’s choice is between a wider initial round (covering the upper end of the MVNS range) or a tighter round with milestone-tranched extensions (Article 4 §4.3) gated on observed MVNS calibration. Both are defensible; neither requires pretending that MVNS is point-estimable when it is not.

Given the graph and a defined MVNS target (or range), the next question is: which bootstrapping loop activates the network most efficiently? In Web3 infrastructure, three archetypes recur. Each has a distinct cost structure, risk profile, and fit with different graph topologies.

Schematic 2 – Three bootstrapping loop archetypes for a multi-sided Web3 infrastructure network.

Supply-side first

Activate Operators, Providers, and Merchants first. Subsidise them directly. Only open to Clients once the supply side is at MVNS threshold.

This is the right loop when the supply side is the hard side – which, for regulated financial infrastructure, it almost always is. Regulated Providers and Merchants are expensive to onboard, slow to commit, and essential to the value proposition. Activating Clients before the supply side has real depth produces a churn event when those Clients discover the network has nothing useful to offer them. The churn is not recoverable cheaply.

The cost structure favours this loop too. Supply-side participants, once activated, have much higher retention – their commitment is structural, not episodic – so the subsidy is capitalised over a long useful life. Clients, activated too early, churn and take the subsidy with them. For a regulated financial infrastructure network, supply-side-first is, in most topologies, the correct answer.

Demand-side first

Activate Clients first, using a single-player or consumer-grade surface that delivers value without requiring the full network. Chris Dixon’s well-known formulation – “come for the tool, stay for the network” – is the canonical example.

This loop is the right choice when a usable tool can be delivered without network effects – a genuine single-player utility at the surface layer. It is difficult in infrastructure, which by definition has no single-player mode. Where it can work in Web3 is through wallet experiences or self-custody tools that work standalone and only later reveal the network surface. The risk is that users acquired through the tool never convert into network participants; the transition rate is typically small, and acquisition cost on non-converters is wasted.

Demand-side-first works where two conditions hold simultaneously: a usable single-player tool at the user surface, and credible conversion from tool-user to network-participant. Neither holds for regulated financial infrastructure: supply is itself regulated (R_j must be active before regulated counterparties can transact), the bottleneck is supply rather than user acquisition, and user-surface tooling does not substitute for the regulated merchants and providers who deliver the value. The pattern is included for completeness, and because its failure mode – mass user acquisition followed by zero merchant integration – is one of the most expensive mistakes in the category.

Stylised illustration – demand-first vs supply-first cohorts. Across regulated-finance-adjacent infrastructure projects launched in the early 2020s and documented in the Methodological Appendix V.3.7.0, the bootstrapping-loop choice has separated outcomes more cleanly than thesis quality or team pedigree. Demand-first projects – polished consumer wallets, large airdrops, viral referral programmes – commonly reached mid-six-figure user counts within six months, then stalled on regulated Provider onboarding because compliance teams read them as consumer crypto rather than professional infrastructure. Supply-first projects – nine to twelve months on Provider onboarding (legal, integration, custody clearance) before Client surface opened – reached comparable end-state Provider counts six to twelve months earlier and on materially less capital. At month eighteen, demand-first projects repeatedly raised bridge rounds at flat or down valuations or recapitalised through token-economic restructuring; supply-first projects more commonly held organic Client growth against a working supply graph. The architectures were broadly similar; the bootstrapping loop was the substantive difference. Cohort referents: see Appendix entries on Polymesh (supply-first; 14 regulated launch operators) versus the L1-thesis Layer-1s with deferred regulated-supply onboarding.

Simultaneous (constrained-surface)

Activate multiple sides in parallel, but within a deliberately narrow initial surface – a specific geography, a specific asset class, a specific use case – where the graph can be saturated before broadening. This is the “atomic network” approach, adapted to infrastructure.

Simultaneous activation is the right loop when no side can be activated alone but all sides can be activated together within a constrained surface. The cost is higher up-front – more participant classes to subsidise in parallel – but time-to-critical-mass is compressed, and the resulting MVNS is more stable because all participant classes have arrived with comparable commitment.

For an Operator operating a multi-sided programme instance – the role typically taken by a Polity operator-customer rather than by Polity itself – with a model that depends on aggregating supply-side (Providers, Merchants) and demand-side (Clients) participants simultaneously, the simultaneous loop has strong structural fit, provided the initial surface is constrained tightly enough. “Launching globally” is the opposite: it is an expensive way to dilute capital across a surface larger than any plausible treasury can saturate.

Choosing between the three

The choice is not primarily a matter of preference. It is structurally derivable, under stated assumptions, from the graph and the constraint set. A crude but usable decision rule is:

• If a single participant class is overwhelmingly the hard side, and the rest of the graph activates cheaply once the hard side is present: supply-side first.
• If a genuine single-player tool exists at the user surface and can carry initial acquisition: demand-side first.
• If the graph has multiple comparably-hard sides and no single-player tool exists, but the graph can be saturated within a constrained surface: simultaneous.

Article 5 walks through this decision rule for one worked operator example – a hypothetical European tokenisation operator across two MiCA jurisdictions – including the explicit rejection of the alternative loops with reasoning.

Three diagnostic tests follow directly from the graph framing of Article 1 and the activation framing of this article. Each is answerable in a single working session, and each surfaces a structural failure the cohort consistently fails to surface in time.

Test 1 – the graph test. If the team cannot draw the activation graph on a single page, with named participant classes, named jurisdictions, regulatory-permission nodes per jurisdiction, activation conditions, and thresholds, the GTM has not yet been defined – only described. Drawing it is the first work product of activation planning, not a downstream artefact.

Test 2 – the sequence test. If Clients are being acquired before the upstream classes (Operators, Providers, Merchants) have cleared their activation thresholds, or before R_j is live in the relevant jurisdictions, the project is on an invalid path. The Client growth metric is real; the network it claims to evidence is not. The diagnostic is per class, not aggregate: a network can be on an invalid path even where headline metrics are rising.

Test 3 – the MVNS test. If the MVNS cannot be stated as a vector with concrete per-class thresholds (or per-class ranges, given §2.2) and a defined stability period under subsidy withdrawal, the capital requirement (Article 4) cannot be derived. Any number presented as a capital requirement in the absence of an MVNS specification is a comparable-based estimate in disguise.

The three tests are deliberately blunt. They are intended to be answerable on a Friday afternoon, not after a six-week diligence process, and to surface the cohort’s failure shapes early enough that capital can be redirected. A project that fails any one of them is not necessarily wrong; it is, however, not yet ready to make the bootstrapping-loop choice this article specifies.

Towards the Substitution Curve

The activation graph (Article 1) and the bootstrapping-loop archetype (this article) together specify how the network is supposed to activate. They do not, on their own, guarantee activation will hold. The next question is the binding one: when the protocol-scheduled incentives that drove early participation begin to taper, does utility take their place – on time, per class, before the treasury runs out?

Article 3 makes that question precise. It defines the substitution curve as a per-class trajectory, derives the crossover times that mark the transition from incentive-driven to utility-driven participation, and identifies the post-decay failure region in which most Web3 networks of the cohort have collapsed. Without crossing the substitution curve, the loop chosen here does not produce a network; it produces a subsidy schedule with a network-shaped marketing programme attached.

Methodological note

Empirical illustrations are stylised and synthesised from publicly observable patterns across the named cohort (Methodological Appendix V.3.7.0); they describe no specific entity. Quantitative ranges are directional cohort-level observations, not firm-specific data.

Disclaimer

This article is published for informational and educational purposes only. It does not constitute investment, legal, tax, or financial advice, an endorsement of any product or security, or any offer or solicitation. References to named projects in the cohort and to named public events (token launches, recapitalisations, discontinuations, regulatory milestones) are factual public-record observations recorded for analytical purposes; they are not assessments of those projects’ merits or prospects, and the framework expresses no view on the future trajectory of any individual project. Readers should conduct their own due diligence and consult qualified professionals before acting on any of its content.

Polity is a B2B technology vendor that develops substrate infrastructure for the operators of regulated digital finance networks. Polity does not provide investment advice, custody, crypto-asset services under Regulation (EU) 2023/1114 (MiCA), or any other regulated activity; operator-customers are the regulated entities for any service delivered on Polity substrate. Polity has a commercial interest in the adoption of this framework (operator-customers typically build on Polity substrate); this conflict of interest is disclosed for transparency and is not cured by it.

Forward-looking statements in this corpus – including the §4.6b research hypotheses – are based on current expectations and may prove materially incorrect. Past cohort patterns are not a guarantee of future outcomes. The §4.6b hypotheses are stated for falsification, not as investment recommendations, financial promotions, or solicitations within any applicable regulatory regime.

Published from the European Economic Area; not directed at any person in a jurisdiction where its publication would be contrary to local law. This corpus is not a marketing communication relating to any specific crypto-asset within the meaning of Article 27 of Regulation (EU) 2023/1114 (MiCA); it is a category-level analytical framework. Personal data of natural persons (typically corporate officers of named cohort projects) is processed under legitimate-interest grounds (GDPR Article 6(1)(f)) and confined to the public commercial record.

Third-party names and sources are public-record events; their inclusion implies no commercial relationship, endorsement, partnership, or affiliation. Characterisations of causes, mechanisms, or outcomes of named cohort projects are this framework’s analytical interpretation of the public record, not statements of fact about any entity’s strategy or condition. Inclusion in the companion Methodological Appendix implies no commercial relationship.

References

• Chen, A. (2021). The Cold Start Problem: How to Start and Scale Network Effects. New York: HarperCollins. Available at: https://www.coldstart.com/
• Dixon, C. (2015). ‘Come For the Tool, Stay For the Network.’ cdixon.org. [Canonical formulation of the single-player-tool bootstrapping loop referenced in this article.] Available at: https://cdixon.org/2015/01/31/come-for-the-tool-stay-for-the-network/
• Hagiu, A. and Wright, J. (2015). ‘Multi-Sided Platforms.’ International Journal of Industrial Organization, 43, pp. 162–174. Available at: https://doi.org/10.1016/j.ijindorg.2015.03.003
• Polity (2026). Phase 1 Methodological Appendix and Cohort Dataset, V.3.7.0. Polity Thought Leadership Series, Phase 1, companion artefact.