Article 1: Regulation as a Graph Node — A Framework for Web3 Infrastructure Go-to-Market
Author: Alexandre Kotcherguine, Vision Officer & Investor
Contributors: Georgi Gitchev, Governance Officer & Organisation Domain Lead; Matt Jackson, Growth Officer
This article is written for operators, investors, and system designers working on regulated digital finance infrastructure. The category has been mis-modelled by reuse of frameworks built for consumer software and unregulated crypto, with the common consequence in the named cohort being capital exhaustion before network formation. — What this series does. Phase 1 of the Polity Thought Leadership Series sets out a structural framework for go-to-market, capital, and valuation in Web3 financial infrastructure; it provides the operational substrate the Disciplined Fundraising series (April 2026) treated as given. — What this article does. Article 1 establishes the primary abstraction (the activation graph, in which regulatory permission is a first-class node) and addresses the four rival explanations it must subsume or concede to. — What the remaining instalments do. Articles 2 through 4 complete the analytical core: activation strategy (Article 2), the substitution curve (Article 3), and the derivation of round size from the graph (Article 4); Article 5 walks one end-to-end worked operator example.
TL;DR. Go-to-market for Web3 infrastructure is best modelled as an activation graph: a dependency graph of multi-sided participants in which regulatory permission is promoted from constraint to first-class node. The architectures of the named cohort were not the failure mode; the activation order was. Drawing the graph — with named participant classes, named jurisdictions, regulatory-permission nodes, activation conditions, and thresholds — is the first work product of go-to-market planning, not a downstream artefact.
Most Web3 infrastructure projects that fail do not fail because the technology is wrong. They fail because the go-to-market model underneath was never a model — only a narrative about communities, flywheels, and adoption curves dressed up as a plan. Every downstream decision (round size, token design, runway, architectural trade-offs, partnership priorities) inherits that error.
Pattern recognition. In the named cohort — the fifteen regulated-finance Web3 infrastructure projects documented in the Polity Phase 1 Methodological Appendix V.3.7.0, with five additional projects flagged in the inclusion-exception list because they meet the inclusion criteria but their activation pattern is dominated by a structural factor outside the framework’s scope — Layer-1 and infrastructure networks launched into the 2020–22 cycle with a regulated-finance thesis show a consistent shape. Headline KPIs at twelve months read well — wallet counts in the low-to-mid six figures, peak TVL in the tens of millions, partnership announcements in the dozens. By eighteen to twenty-four months, supply-side activation had remained at pilot scale: regulated Service Providers live in zero or one jurisdictions, Merchants committing product at single-digit counts, weekly active wallets decayed materially from peak. Treasuries had commonly spent in the tens of millions of dollars, three-quarters on user-acquisition and incentive emissions. Bridge rounds at flat or down valuations, or functionally equivalent recapitalisation events, followed in a substantial share of the cohort within twelve months. The architectures were not the failure mode; the activation order was. Network value in this cohort is determined by the regulated supply-side classes — Operators, then Providers, then Merchants — and Clients had been activated three structural edges downstream of those classes, before any of the upstream nodes had reached the threshold needed to make Client activity useful. The resulting failure mode was the standard one: Client metrics ramped on subsidy, then collapsed when subsidy tapered, with no upstream depth to give Clients reason to stay.
The corpus’s structural claim. Go-to-market for Web3 infrastructure is an activation graph — a directed graph in which the nodes are participant classes and an edge from A to B reads “A must be present at a defined depth before B can meaningfully activate”. Regulatory permission is a first-class node alongside the participant classes, not a downstream constraint applied to them. The graph constrains outcomes; it does not determine them. The pattern observed above is what the graph produces when it is not drawn, not what an unfavourable graph produces. Projects that draw the graph and pace activation against it produce a different shape; projects that treat the graph as implicit produce this one.
The SaaS funnel — the standard B2B software model in which a single class of buyer is moved through awareness → trial → conversion → expansion — and the consumer-growth playbook are the default mental models founders and investors bring to Web3. In Polity’s primary-source review of fundraising materials across the named cohort, the funnel diagram and the single-class user-acquisition curve were the two most common GTM artefacts; multi-class dependency graphs were not observed. Neither default model survives contact with Web3 infrastructure, for four structural reasons.
1. Multi-sided, asymmetric participants. A Web3 infrastructure network is not a customer base. It is a system with distinct participant classes — operators, service providers, merchants, clients, capital contributors — each with distinct incentives, costs of participation, and reasons to stay or leave. Treating them as a single “user” flattens the problem.
2. Participant dependencies. In SaaS, a user does not need another user to exist. In a Web3 infrastructure network, almost every participant needs another to have arrived first. Providers will not bring service offerings to a network that has no Clients; Clients will not transact on a network that has no Providers or Merchants. This circularity is the reason SaaS tactics underperform so badly when transplanted.
3. Incentives as first-class infrastructure. In SaaS, incentives are a marketing lever. In Web3, they are part of the protocol. Token emissions, fee rebates, staking rewards, and points programmes are not campaigns; they are code that runs whether or not marketing is watching. Their cost is a continuous drain on the treasury that compounds with participation.
4. Regulatory surface as topology, not constraint. Moves that work in SaaS — aggressive user incentives, free credit for referrals, international rollouts from a single jurisdiction — land differently in Web3 because securities law, AML obligations, and jurisdictional licensing change what is even permissible, and where. The standard treatment in the platform-economics literature is to model regulation as a constraint on a feasible set. This series argues that for regulated-finance infrastructure that treatment is too weak: regulation is itself a participant in the activation graph, with its own activation threshold and its own activation cost. The §1.4 Constraint Taxonomy returns to this distinction.
Key Insight. User growth without supply-side activation is a false positive. The metric is real; the network it claims to evidence is not.
The SaaS funnel is rejected outright; the single-participant, distribution-efficiency-bounded model fails for the four structural reasons set out above. The remaining three frameworks readers will arrive with — Hagiu and Wright on multi-sided platforms, Chen on cold start, Dixon on single-player tools — are retained but extended. The boundary is as follows.
From Rochet and Tirole, and from Hagiu and Wright (multi-sided platforms): asymmetric participants, distinct costs of participation, the topology of multi-sided networks. Used here unchanged.
From Chen (network effects, cold start): the minimum viable network and the hard side. Used here in extended form — MVNS as a per-class vector, hard side as a constraint property of the dependency graph rather than a single class.
From Dixon (single-player tool to network): the demand-first activation pattern, named here as one of three bootstrapping-loop archetypes (Article 2). Used as a contrasting case rather than a recommendation.
What is genuinely new here: the principal theoretical contribution of this series is the promotion of regulatory permission from element of the constraint set to first-class node in the activation graph. The standard multi-sided-platform (MSP) treatment models regulation as exogenous: a permissioning condition that filters which moves on the platform are feasible. For regulated-finance Web3 infrastructure, that treatment is too weak. Regulatory permission has its own activation cost (12 to 24 months and low-six to seven figures of dollars per jurisdiction in the cohort, depending on regime), its own threshold (a binary live/not-live condition per jurisdiction), and its own dependency edges (it must be activated before the regulated supply-side classes can activate). It behaves, in every relevant respect, like a participant in the graph rather than a property of it. Treating it as such is the first move of this framework, and the move on which the rest depends. The closed loop from activation graph to derived capital requirement (Article 4) is the second.
Web3 founders also operate inside a more specific set of category-native playbooks — venture-firm heuristics, token-driven growth, and Layer-1/Layer-2 ecosystem strategies. Each addresses a real problem. Each, taken at its strongest version, fails on structural grounds when applied to regulated infrastructure.
Venture-driven heuristics. Steelman: the dominant venture playbook is the most empirically-tested system for allocating capital to early-stage technology that exists, and its core insight — that capital efficiency is the binding constraint and user acquisition the operative variable — is correct in the consumer-software domain that produced it. Why it fails here: for regulated financial infrastructure, neither half of the heuristic holds. The binding constraint is regulatory readiness on the supply side, and the operative variable is which class is activated in what order. Heuristics calibrated to the consumer-application domain produce capital plans that systematically under-provision the supply-side cold start and over-provision the demand-side ramp.
Token-driven growth. Steelman: where it works, token-incentive growth is genuinely magical — emissions can compress months of community-building into weeks, and the resulting network density (Compound, early Curve, the productive end of liquidity mining) demonstrably outpaces what cash incentives can buy at the same cost. Why it fails here: the playbook assumes that participation acquired through emissions can be retained by network effects once emissions taper. The failure pattern is well-rehearsed and treated formally as the substitution curve in Article 3 — the per-class participation decay observed when an incentive subsidy is withdrawn before utility has accumulated. The cohort shape is stylised: peak metrics within weeks, decay to baseline within months of tapering, with no participant class crossing the threshold at which utility substitutes for subsidy. The token is a coordination instrument; it is not a substitute for the dependency graph that determines whether such crossings can occur.
L1 / L2 ecosystem strategies. Steelman: ecosystem investment programmes are one of the few places where a chain operator can credibly subsidise the things that increase the network’s value (developer attention, integration counts, and application diversity — the breadth of distinct production use cases the network supports at the time of measurement), and the model has produced category leaders in domains where developer-mediated distribution dominates (Solana DePIN, Base consumer apps). Why it fails here: for regulated financial infrastructure the binding constraint is regulated-counterparty readiness, not developer attention, and grants do not retire compliance work. Ecosystems that have produced regulated financial usage have done so by directly underwriting the regulated supply side — Canton’s Foundation-as-bank-consortium model is the cleanest example.
The common failure is to treat one variable — capital, token, or ecosystem — as dispositive, when each is one input into a larger dependency structure. The activation-graph framing subsumes rather than replaces these tools by being explicit about which class each can move and at what cost.
Before drawing the activation graph, name the participants.
A generic Web3 financial infrastructure network has five participant classes that recur across the Operator’s activation graph, with varying names across projects. The class names below follow Polity’s working vocabulary because consistent naming is required for the formal definitions in §1.3 and the substitution-curve treatment in Article 3, but the structural distinctions are not Polity-specific: every cohort member documented in the Methodological Appendix V.3.7.0 instantiates the same five classes under different labels, which the cross-mapping table at the end of this section makes explicit.
· Network Operators (Operators) — independent firms that deploy and run a programme instance of the network: validators, node operators, and the operational entity that licenses substrate and stands behind the network commercially. They bear the highest technical and regulatory cost of participation and are, in most cases, the hard side of the network (a term from Chen’s network-effects literature, formally treated in Article 2). Without them, nothing else works.
· Service Providers (Providers) — the regulated and commercial firms that deliver services within an Operator-run programme instance: exchanges, custodians, payment processors, lenders, advisers, and other counterparties whose service offering is the substantive content of the network for end clients.
· Digital Product Merchants (Merchants) — the issuers and product originators who supply digital products into Operator-run programme instances: token issuers, structured-product originators, certificate issuers, and suppliers of any productised offering distinct from a service relationship.
· End Users (Clients) — the retail and institutional clients who transact with Providers and Merchants on the Operator’s programme instance. In SaaS terms this would be “the customer”; in network terms this is only one class of several, and contracts directly with Providers and Merchants rather than with the Operator or the substrate vendor.
· Capital Contributors — investors and treasury participants whose capital underwrites the Operator’s treasury and, where applicable, the liquidity of early markets on the programme instance. They sit alongside the activation chain rather than on it.
Two further roles exist in the wider ecosystem but sit outside the Operator’s activation graph: substrate-side contributors (“Builders”), who develop the underlying technology rather than the Operator’s network; and secondary-market participants in any associated token, whose activity is price formation rather than network activation. Both matter for other purposes; neither sits on the activation graph.
Cross-cohort vocabulary mapping. The five participant classes recur across the named cohort under different labels. The mapping below is illustrative rather than exhaustive; the per-row sources are listed in the Methodological Appendix V.3.7.0.
Mapping is illustrative; named projects each instantiate the five classes under different labels and with different governance overlays. The Hedera Council case is a fused-class structure (Operator and Capital Contributor are the same parties) that the framework does not fully cover at Phase 1 — see §4.6a.
The conventional MSP model would now draw the dependency graph using the five participant classes above. This series adds a sixth node — Regulatory Permission — to the graph itself, with its own dependency edges to the regulated participant classes and its own activation cost. §1.3 draws the graph with that node; §1.4 sets out its cost and threshold properties.
A note on the term. The phrase “activation graph” is used in this series in the specific sense defined immediately below, and is not to be confused with cognate uses in chemistry, neuroscience, or unrelated computing contexts. The choice of name makes the modelling object directly nameable in operator and investor conversations: the alternative (“multi-sided-platform dependency graph with a regulatory-permission node and per-edge activation thresholds”) is too long to be useful in practice, and prior phrases in circulation (“cold start”, “chicken-and-egg”, “launch sequence”) under-specify the structure. The graph is the diagram an operator draws once and refers back to throughout planning; giving it a name is a precondition of treating it that way.
Definition — Activation Graph (GTM Context).
A directed graph whose nodes are the participant classes of a Web3 infrastructure network (Operators, Providers, Merchants, Clients, Capital Contributors) together with the regulatory-permission node for each target jurisdiction, and whose edges encode activation preconditions. An edge from A to B reads: A must be present at a defined threshold before B can meaningfully activate. The regulatory-permission node has outgoing edges to the regulated participant classes (Providers, Merchants) and an incoming edge from the Operator’s compliance investment.
Formal Definition — Activation Graph G = (V, E, τ, C).
V (vertices): the finite set of participant classes {Operator, Provider, Merchant, Client, Capital Contributor} together with one regulatory-permission vertex R_j per target jurisdiction j.
E ⊆ V × V (edges): directed activation preconditions. Edge (a, b) reads: vertex a must reach the threshold defined on this edge before vertex b can meaningfully activate. R_j has outgoing edges to Provider and Merchant nodes operating in jurisdiction j.
τ : E → ℝ₊ (edge thresholds): the minimum measurable depth on the source vertex required to activate the target vertex. Each threshold is operationally approximated via observable proxies (per-class depth, count, volume) and refined post-launch through calibration; ex-ante point estimation is not claimed (see Article 2 §2.2). For R_j, the threshold collapses to a binary live/not-live indicator on the relevant regulatory permission.
C (constraint set): residual technical and economic predicates that may bind any edge or vertex once R_j is activated; constraint failure makes the dependent edge inactive regardless of upstream depth.
Properties: (i) the forward-edge subgraph is a DAG governing cold start; (ii) reverse edges form reinforcing loops that activate only after MVNS is reached; (iii) for any non-trivial regulated graph (≥2 jurisdictions, ≥1 regulated supply class per jurisdiction), no feasible activation order exists in which any regulated participant class is activated before the corresponding R_j — promoting R_j to the graph makes this constraint structural rather than a side condition; (iv) the graph is jurisdiction-additive: activating in jurisdiction j+1 adds vertices, edges and thresholds rather than re-using those of jurisdiction j.
Consider an illustrative graph for a generic Web3 financial infrastructure network. Capital Contributors sit outside the main activation chain. Within the chain, Operators are the root; Providers depend on them; Merchants depend on Providers; Clients depend on both Providers and Merchants. The regulatory-permission node R_j sits upstream of the regulated supply-side classes in each target jurisdiction, with its own activation cost and its own threshold.
Schematic 1 — Activation graph for a generic Web3 financial infrastructure network, with regulatory-permission node R_j shown as a first-class graph element rather than a constraint on adjacent edges.
Three features matter.
Thresholds, not binary presence. Each edge carries a minimum viable level, not a binary “exists / does not exist”. A Provider class is not usefully present once one Provider has signed a memorandum of understanding; it is usefully present when, say, ten Providers have gone live with real flow and three have survived past ninety days. Defining these thresholds explicitly is Article 2’s subject. The regulatory node is the one exception — it is binary, with the analogue activation cost paid before the binary state flips.
Activation conditions, not timing. The graph does not say when each class arrives; it says under what conditions each class can arrive. “Merchants activate once at least two regulated jurisdictions support the required payment rails” is an activation condition — a testable predicate, not a date.
Feedback edges. Real networks have reverse edges. Client volume reinforces Merchant supply; Merchant supply reinforces Provider commitment; Provider commitment reinforces Operator economics. The graph is a DAG in its forward structure and a set of reinforcing loops once the network is warm. The DAG governs cold start; the loops govern escape velocity. Conflating them is another common error. Note that R_j has no reverse edges — utility on the network does not relax regulatory permission, which is asymmetric to the rest of the topology and is one of the reasons it functions as a structural constraint.
The opening case illustrates the value of this lens. The L1 network lacked the upstream node on which all downstream activation depended; Clients were three structural edges from the class capable of producing the value the network was priced against, and the regulatory node had not been activated in any of the target jurisdictions. The graph does not predict the future; it makes the structure of the cold-start problem — which class must be present at what depth before which other class can activate — explicit and falsifiable.
Key Insight. If a team cannot draw its activation graph — with named participant classes, named jurisdictions, regulatory-permission nodes per jurisdiction, activation conditions, and thresholds — the GTM has not been defined; it has been described. Every downstream capital question is unanswerable until that drawing exists.
Drawing the graph is half the work. The other half is bounding it with constraints, because the feasible GTM space is always smaller than the graph alone suggests.
Three constraint families recur, but they bind in different ways. The first two — technical and economic — apply to edges and vertices in the conventional sense. The third — regulatory — is the constraint family this series promotes to graph topology.
What the architecture can actually do, at any given moment, determines which nodes can be activated. Throughput ceilings, finality times, cross-chain interoperability, SDK maturity, identity and key-management usability — each acts as a binding ceiling: classes for which the cost of serving them remains below the value those classes contribute to the network can be served, others cannot, and which class falls on which side of the line is set by the graph and the constraint set. A network that has not yet shipped a production-grade identity layer cannot seriously onboard regulated merchants, however elegant the incentive design.
Activation costs capital. Every activation condition in the graph implies a cost — subsidies to the hard side, onboarding incentives to early Clients, integration support and fee rebates for early Providers and Merchants, liquidity provision to early markets. The sum of these costs, discounted against a plausible time-to-critical-mass, is the capital requirement. Article 4 explains in detail how this derivation is made.
Two sub-constraints deserve naming.
Incentive decay — the rate at which token or cash incentives must be withdrawn to avoid permanent subsidy — bounds how long the treasury can sustain cold-start conditions. Unit economics by participant class — the ratio of lifetime value to acquisition cost, computed separately for each class, not in aggregate — determines which parts of the graph are self-funding once warm and which require continuous support.
In the standard multi-sided-platform treatment, regulation is a constraint on the feasible set: certain moves are permitted in certain jurisdictions, and the constraint set C (the residual technical and economic predicates defined in §1.3) bounds which activation paths are admissible. This series argues that for regulated-finance infrastructure that treatment is structurally insufficient, and that regulatory permission is more accurately modelled as a node in the activation graph with three properties that distinguish it from a constraint:
· It has its own activation cost. Compliance and licensing programmes commonly take 12 to 24 months per jurisdiction in the cohort, with single-jurisdiction costs ranging from low-six to seven-figure dollars depending on regime — lighter-touch authorisations (e.g. EMI passports, MAS PSA Major Payment Institution, lighter MiCA CASP categories) cluster at the low-six to mid-six end; heavyweight authorisations (CSD/MTF designations, full-stack tier-1 bank-adjacent licences, systemically-important payment-system designations) cluster at the high-six to mid-seven end and can extend higher for the heaviest cases. This is not a constraint to be satisfied — it is a node to be activated, with the cost recorded against the activation budget rather than written off as overhead.
· It has its own threshold. Unlike participant nodes, the threshold on R_j is binary — the regulatory permission is either live in jurisdiction j or it is not. Below the threshold, the entire downstream supply-side subgraph in that jurisdiction is inactive. The capital model must absorb the binary character of this node, which makes the regulatory line item the most leveraged single variable in the model (Article 4 §4.2).
· It has its own activation order. R_j must be activated before any regulated participant class operating in j can activate. This is the structural reason multi-jurisdictional launches consistently mis-pace in the cohort: treating R as a constraint to be satisfied alongside operational work invites parallel-tracking the regulatory programme against operational delivery, which compresses neither and stretches both. Treating R as a node to be activated forces sequencing.
Stylised illustration — regulatory mis-pacing. Across regulated-finance infrastructure projects observed in the cohort, projects pitching multi-jurisdictional launch (typically three to six jurisdictions) repeatedly underestimated the calendar time and capital to clear regulatory readiness. Projects launching in two to three jurisdictions on a 24-month plan typically cleared one within plan, slipped on the second by 6 to 12 months, and abandoned or deferred the third within 18 months. The pattern is not that regulation is hard; it is that regulation compounds with jurisdiction count, which the activation-graph view makes visible at planning time when each R_j is drawn explicitly with its own activation cost. Cohort referents documented in the Methodological Appendix V.3.7.0: Fnality’s four-year activation cycle and the staggered jurisdictional rollouts of Polymesh and SDX.
Constraint — Regulatory Primacy.
Where the regulatory-permission node R_j has not been activated in jurisdiction j, the downstream regulated supply-side subgraph in j is inactive regardless of any upstream depth on other vertices. Capital and activation planning SHALL treat R_j as a node to be activated rather than a constraint to be satisfied; the difference is operationally consequential and surfaces in capital sizing (Article 4).
Three categories of case sit outside the framework’s core scope.
Genuine single-player tools at the user surface. Single-player tools — wallets, self-custody managers, portfolio analytics — solve the user’s problem on their own, before any network forms around them. They earn distribution on product merit and can later feed users into a network the same product team or a third party assembles. While the tool stands alone, what binds is product quality and distribution, not graph completeness; the activation graph applies only once the tool starts feeding a multi-sided system. Article 2 develops this loop. Cases such as Phantom, MetaMask, and Zerion in their tool-only phases sit in this region. The framing is not wrong; it is dormant until the tool tries to become a network.
Incentive-driven niche or temporary networks. Some networks operate, by design, as continuous incentive vehicles — liquidity-mining venues, points programmes, or short-horizon attention markets — with no expectation that incentive participation transitions to utility participation. Where this is the explicit design, the substitution-curve framing is not a failure mode but a non-feature: the network is what it is, and judging it by a substitution curve it never intended to cross is a category mistake on the analyst’s side. The question to ask of such networks is not “has utility replaced incentive?” but “is the incentive flow itself sustainable, and is that what investors are pricing?”
Non-regulated infrastructure with weak or absent supply-side asymmetry. The framework draws much of its predictive force from the structural cost asymmetry between participant classes — regulated supply, in particular, being slow and expensive relative to retail demand. In categories where this asymmetry is weak (consumer NFT marketplaces in their original form, content-driven attention platforms, certain games), the graph collapses toward a one-or-two-class system and the bootstrapping-loop choice loses its sharpness. The framework still applies, but it is less informative than it is in regulated finance — and the regulatory-node move is dormant where R_j is trivial.
The framework above explains the cohort’s recurrent activation failures via mis-pacing of the activation graph, with the regulatory node treated as a constraint rather than as topology. A serious reader will hold one or more rival explanations for the same cohort behaviour. This section names the four rivals this auditor would put first, and addresses each — subsuming where the framework already accounts for the mechanism, conceding where it does not.
Most institutional crypto pilots in 2020–24 were platform-defensive procurement (banks not wanting to be left behind), not P&L-driven adoption. If demand was illusory, no activation graph could have produced activation regardless of sequencing. This is the view advanced in Bank for International Settlements and central-bank-research outputs from 2022–24 — that the cohort’s pilots were procurement-driven defensive optionality rather than P&L-driven adoption — and it is on the public record across multiple post-mortems.
Subsumption. Rival 1 is the activation-graph view of the Client and Merchant nodes when their utility ceiling Uᵢ(∞) is set at or near zero (Article 3 §3.1). The framework does not require strong demand for the structural claim to hold; it requires per-class utility curves to be specified. Where Uᵢ(∞) is near zero for one or more classes, the framework’s account is that the network cannot reach a self-sustaining state regardless of subsidy spend or activation order, which is precisely the outcome Rival 1 describes. The rival is the framework’s prediction in the limiting case, not a separate explanation.
MiCA, eIDAS2, DORA, and the SEC enforcement turn (2022–24) materially changed the feasible set after the cohort raised on the previous regime. The supply-side cost asymmetry the framework treats as structural was, in part, a regulatory regime change.
Subsumption. Rival 2 is the cohort-period instance of the framework’s general claim that the regulatory-permission node R_j is real, costly, and time-binding. The framework’s account anticipates exactly this kind of regime-shift cost as a structural property: when R_j changes, every downstream regulated edge re-enters its activation phase. Projects sized against the pre-regime R_j therefore under-provisioned for the post-regime R_j by a margin determined by the magnitude of the regime change. The mechanism is identical to the framework’s standard claim; the cohort period happens to be one in which R_j shifted unusually fast. Rival 2 is the framework, evaluated against a particular epoch.
For most cohort projects, the binding risk on the supply side was not regulatory readiness but the securities-law characterisation of the native token, which made institutional integration legally infeasible regardless of activation-graph hygiene. A bank’s general counsel will not approve integration with a network whose native token is exposed to securities-law re-characterisation, no matter how clean the dependency graph.
Concession. Rival 3 is a separate explanation that the activation-graph framework bounds rather than displaces. Where token-design legal risk is the binding cause, no amount of graph hygiene activates the regulated supply side, because the integration is blocked at the legal layer rather than the activation layer. The framework’s contribution in this case is to make the boundary visible: the framework’s account is that R_j cannot be activated where the Operator’s token design exposes regulated counterparties to securities-law risk, but the framework does not specify the token-design moves required to clear that boundary. Phase 2 of this series takes up token-design legal posture as a first-class subject; in Phase 1 it is conceded as outside scope.
Public commentary on Onyx, on the ASX-CHESS termination (a Digital Asset / DAML programme with VMware as infrastructure partner from 2019), and on the Fnality slow build has tended to converge on a similar reading — that the unit economics did not justify replacement of working RTGS / CSD infrastructure within the relevant window. This is a demand-side utility-ceiling reading on the public record: on that reading, the value proposition to the regulated counterparty was too thin to displace an incumbent system that already worked. Polity has no access to bank-internal post-mortem documents, and the framework treats this only as a structural reading of public-record commentary, not as a characterisation of any single bank’s internal conclusions.
Mechanism subsumed. Where Uᵢ(∞) for the regulated-counterparty class is bounded above by the cost-savings differential against the incumbent system, and the differential is small, the framework’s account is that the substitution curve cannot cross at any level of subsidy. This is the same mechanism Rival 4 describes, expressed in the framework’s vocabulary; it is not a separate explanation.
Quantification conceded. The activation-graph view does not specify the cost-savings analysis required to compute that differential in any given case. It makes the question askable but not, on its own, answerable. Where Rival 4 is the binding cause, the framework correctly identifies the failure shape (substitution cannot cross) but cannot, on its own, identify the magnitude of the gap against the incumbent. This is a real boundary of the framework, and one this series concedes — the cost-savings analysis is a first-class subject of Phase 2.
Closing observation on rivals. Rivals 1 and 2 are subsumed because the framework’s mechanisms explain them. Rival 3 is conceded as outside scope. Rival 4 is split: the mechanism is subsumed in the substitution-curve framing, but the quantification (the cost-savings differential against incumbents) is conceded. A framework that concedes its boundaries with this level of granularity earns the reader’s trust; one that ignores rivals or claims to subsume more than it can does not. The activation-graph view is offered with the boundaries explicit.
Three stylised cases illustrate the framework’s diagnostic content. Each is read as: a setup (context), what the project did (activation sequence), where the graph broke (graph failure point), what was observed (outcome), and how that maps back to the framework (mapping).
Case A — Demand-first L1, regulated-finance thesis.
Context: a Layer-1 network launched in 2021–22 with a regulated-finance thesis.
Activation sequence: substantial spend on Client wallet acquisition and consumer-facing campaigns; regulated Provider onboarding deferred behind.
Graph failure point: traversal of the Client ← Merchants edge before the Provider ← Operator and Merchant ← Provider edges had cleared, with R_j inactive in the target jurisdictions.
Observed outcome at month 18–24: weekly-active wallets decayed materially from peak; cumulative Provider count remained at single digits across zero or one jurisdictions; bridge round at flat or down valuation, or functionally equivalent recapitalisation.
Mapping: the “invalid path” edge in Schematic 1 — Clients activated three structural edges downstream of the class determining network value, with R_j inactive and KPIs measuring a node whose preconditions were unmet.
Cohort referent: see Methodological Appendix entries on L1-thesis cohort members with deferred regulated-supply onboarding.
Case B — Multi-jurisdictional regulatory mis-pacing.
Context: regulated-finance infrastructure project pitching launch across three to six jurisdictions on a 24-month plan.
Activation sequence: regulatory readiness work commenced in parallel across all target jurisdictions; capital allocation calibrated against the consolidated multi-jurisdictional addressable market.
Graph failure point: each R_j treated as a constraint to be satisfied alongside operational work rather than as a node to be activated, with single-jurisdiction clearance times of 12–24 months compounding against the plan.
Observed outcome: one jurisdiction cleared within plan; second slipped 6–12 months; third deferred or abandoned within 18 months; capital plan absorbed the slippage as discretionary spend rather than as the binding constraint it was.
Mapping: violation of Regulatory Primacy — R_j evaluated as constraint rather than activated as node.
Cohort referent: see Methodological Appendix on Fnality’s four-year activation cycle and the staggered rollouts of Polymesh and SDX.
Case C — Token-incentive substitution failure.
Context: protocol launching a token-incentive programme to bootstrap participation.
Activation sequence: aggressive emissions schedule pulled in two to six weeks of peak TVL or peak wallet count; emissions tapered on the protocol-defined schedule.
Graph failure point: no per-class substitution curve specified; incentive decay rate — set by protocol — outpaced utility accumulation rate, which depended on graph maturity that had not been achieved.
Observed outcome at month 3–9: 60–95% of incentive-acquired participation lost; per-class participation tracked emissions one-for-one.
Mapping: the Substitution Curve Collapse failure mode treated formally in Article 3 §3.1 — participation was incentive-driven from t=0 to t=end, and the curve was never crossed. Named referents on the public record include the 2020–22 yield-farming and points-programme cohort (Iron Finance’s June 2021 collapse, Wonderland’s January 2022 unwind, the SushiSwap-vs-Uniswap vampire-attack reversal of mid-2020), whose post-emission decay shape is consistent with the trajectory the framework formalises.
Each case is a graph-readable diagnosis. The framework does not predict that any specific project will follow these patterns; it argues that where a project’s graph and constraint set are not made explicit, these are the recurrent shapes the cohort has produced.
Defining the system is necessary but not sufficient. The graph does not tell the operator how to activate the network — only what must hold for activation to be possible. Article 2 takes up the harder question: given the graph, which side is activated first, at what minimum viable state, through which bootstrapping loop, and at what subsidy cost.
Consequence. In the named cohort, mis-sequencing activation has repeatedly been the difference between network formation and capital exhaustion. Promoting R_j from constraint to graph node makes the mis-sequencing diagnosable at planning time rather than at month 24.
Principle — Graph Before Plan.
A Web3 infrastructure project’s go-to-market plan SHALL be derived from an explicit activation graph with named participant classes, named jurisdictions, regulatory-permission nodes per jurisdiction, activation conditions, thresholds, and constraints. Plans that lack this artefact are unbounded and therefore not costable.
Principle — Model Credibility Integrity.
A system-level model SHALL be supported by calibrated claims, empirical anchoring, and explicit failure conditions. Models that are structurally correct but empirically ungrounded should be treated as incomplete. Each core abstraction in this series — the activation graph (with regulatory node), the bootstrapping-loop archetypes, the substitution curve, the burn profile, and the capital derivation chain — is supported in this corpus by at least one stylised case demonstrating the failure mode it predicts and by named cohort referents in the Methodological Appendix V.3.7.0; absence of such anchoring constitutes a credibility risk against external adoption.
Empirical illustrations are stylised and synthesised from publicly observable patterns; they describe no specific entity. Quantitative ranges are directional cohort-level observations, not firm-specific data. The cohort is documented in the Polity Phase 1 Methodological Appendix V.3.7.0 (companion artefact, published alongside this article on 5 May 2026); readers are invited to check the workings against the projects named there.
Next: Article 2 takes up activation strategy and dependency resolution — three bootstrapping-loop archetypes mapped to activation-graph topology.
The terms Activation Graph, Regulatory-Permission Node (R_j), Minimum Viable Network State (MVNS), Bootstrapping Loop, and Substitution Curve are used consistently throughout this series to describe the structural components of Web3 infrastructure activation and capital formation. Their formal definitions are given in §1.3 (graph and R_j), Article 2 §2.2 (MVNS), Article 2 §2.3 (loops), and Article 3 §3.1 (curve). Subsequent phases of the series will use these terms in the same defined sense without re-introduction.
The terms SHALL and SHALL NOT, where they appear in Principle and Constraint blocks throughout this series, signal a strong analytical commitment of the framework — a position the framework holds with high confidence and that any reader applying it should treat as binding for the framework’s own consistency. They do not constitute a Polity governance requirement; this corpus is published as non-normative thought leadership and is not a Polity Documentation Kernel (PDK) instrument. Where a Polity governance instrument is cited and uses the same words, the cited instrument prevails.
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.
(1) Chen, A. (2021). The Cold Start Problem: How to Start and Scale Network Effects. New York: HarperCollins. [Reference framing for the minimum viable network and the hard side, used in Article 2.] Available at: https://www.coldstart.com/
(2) Dixon, C. (2015). ‘Come For the Tool, Stay For the Network.’ cdixon.org. [Canonical formulation of the single-player-tool bootstrapping loop referenced in Article 2.] Available at: https://cdixon.org/2015/01/31/come-for-the-tool-stay-for-the-network/
(3) Hagiu, A. and Wright, J. (2015). ‘Multi-Sided Platforms.’ International Journal of Industrial Organization, 43, pp. 162–174. [Peer-reviewed framing of multi-sided platform economics, used in the participant-asymmetry and activation analyses.] Available at: https://doi.org/10.1016/j.ijindorg.2015.03.003
(4) Rochet, J.-C. and Tirole, J. (2003). ‘Platform Competition in Two-Sided Markets.’ Journal of the European Economic Association, 1(4), pp. 990–1029. [Foundational treatment of two-sided platform pricing and asymmetric participation; cited alongside Hagiu and Wright as the canonical academic anchor.] Available at: https://doi.org/10.1162/154247603322493212
(5) European Union (2023). Regulation (EU) 2023/1114 on Markets in Crypto-Assets (MiCA). Official Journal of the European Union. [Primary regulatory framework against which the regulatory-permission node is assessed.] Available at: https://eur-lex.europa.eu/eli/reg/2023/1114/oj
(6) Polity (2026). Phase 1 Methodological Appendix and Cohort Dataset, V.3.7.0. Polity Thought Leadership Series, Phase 1, companion artefact. [Empirical anchor for the cohort claims in this article.]