DOT DAO Strategy Mandate

Proposer: PCF

PREAMBLE
This proposal aims to establish the binding strategic direction for DOT DAO. It constitutes a strategic mandate, not a technical specification. While the Fellowship and implementing entities retain autonomy over technical guidance and execution details, all work must ultimately align with the mandate provided by the overall DOT DAO if approved.

1. Strategic Priority: End-User Adoption & Usage

• DOT DAO shall, for the present time, prioritise user-acquisition over other KPIs (such as ecosystem size and locked-value).

• This indicates a strategic shift from "competition with other smart-contract platforms" to "competition with Web2/mobile". It is acknowledged that a strategy purely involving growth of the user-base indefinitely (rather than the growth of e.g. product-teams or integrations) is suboptimal: integrations and product-teams might reasonably attract users. However DOT DAO asserts that the presence of users should nonetheless be pursued prior: fewer products/integrations with more users is a more desirable position for Polkadot to be in than the converse.

2. Economic Infrastructure: dotStables

Acknowledging that general users have little interest in financial exposure to an abstract and untethered currency, DOT DAO will introduce "dotStables", permissionless stable-value DOT-backed derivatives (such as dotUSD), as a conduit between user-visible value and DOT.

• It shall be engineered such that demand for dotStables (created e.g. through the functionality and products deployed on the Polkadot Product Platform) translates ultimately into DOT demand.

• It shall be permissionless in its instancing, though DOT DAO may subsidise and support certain dotStable instances on the basis of matching reasonable user expectations.

Implementation Details

• A single native permissionless DOT-backed dotStables implementation will exist, helping avoid potential economic fragmentation and wasted development effort. It will be based on a model proven to be efficient and resilient, exemplified by Liquity, collateralised by DOT and improved by certain Polkadot-specific elements and professionally audited.
• Potential fragmentation coming from permissionless instancing of multiple discrete currencies targeting the same value is muted through explicit DOT DAO support and subsidy of one of them. Others are not disallowed, but those with the backing of DOT DAO will be treated with primacy.
• Native, seamless support for local currencies is considered likely-important platform functionality. However in the interests of maximising the efficiency of early capital and the performance of various systems which require liquidity, the platform will prioritise dotUSD in areas where a single primary currency would be advantageous.
• While DOT DAO sponsorship implies a degree of endorsement, it is itself permissionless and decentralised. This is in contrast to instruments involving not purely autonomous logic but rather a central third-party which holds, controls, and can potentially invest the underlying collateral.

3. User Acquisition Mechanism: The Polkadot Product Platform

User-acquisition shall be facilitated through the deployment of a Polkadot Product Platform and on it certain core product functionality. DOT DAO shall support efforts to popularise this platform and selected functionality or products deemed best placed to stimulate demand for dotStables.

• This may happen through incentives for users and the funding of targeted communications initiatives towards demographics directed specifically through published, reviewed research.

Platform Scope & Architecture

• Unlike for Polkadot's prior parachains platform, this shall be full-spectrum (including data storage and logistics, signalling, referencing, user-interfacing, and more) as well as being full-stack. This ensures that Polkadot directly hosts and connects users and products, transcending its traditional role as merely a security and connectivity layer for Substrate blockchains.
• The platform itself shall be entirely compatible with existing parachain infrastructure, both system and community. To the greatest extent possible in line with this strategic mandate, community services shall be integrated.

Incentive Distribution Model

• Incentive distributions from DOT DAO are differentiated from previous "marketing spends" through:
  a) being delegated only to on-chain logic and not third-party entities; and
  b) delivered ultimately into the hands of individual human users under some algorithmic per-person-limit rather than arbitrarily.

  (The specific algorithms are out of scope for a strategic mandate, but applicable ones shall be constrained and their success measured in this way.)

Communications Strategy

• The realm of communications remains a difficult task for a DAO to command. Lacking a specific Fellowship in this field, responsible ecosystem entities, ideally those with a track-record of quality, cost-sensitive execution, are sought after for this element of the mandate. It is noted that the Polkadot Community Foundation exists with a well-aligned mandate in this matter.
• This is a strategic mandate rather than a technical specification document. It is aspirational in nature and specific technical evaluation and execution is thus left to relevant entities such as the Fellowship and aligned ecosystem parties.

4. User Experience Standards: Web2 Compatibility

The Polkadot Product Platform shall be engineered on the basis that products deployed be at the same level of user-experience and economic-proposition established by, and expected of, Web2 and other modern platforms. This includes: Freemium models, named (non-cryptographic) references, mobile-first and ubiquitous Web access.

• Freemium Implementation: Freemium models imply a free tier for users. Under Web3 principles, this must be achieved in novel ways through strong proof-of-personhood and subsidised per-person usage. The latter is trivial up to a point as Polkadot presently is extremely under-utilised. The former is non-trivial, however a system "Individuality" underpinned by zk cryptography and with oraclisation of uniqueness based on evidenced co-attestation under global synchrony has been under development for multiple years and is ready for production deployment. Additional uniqueness mechanisms which may strengthen the system are under varying levels of design and development.

5. Web3 Integrity Standards

The Polkadot Product Platform shall ALSO be engineered to ensure that products deployed on it well-adhere to standards and expectations in line with Web3, cypherpunk and crypto including self-sovereignty, privacy and zero-logins.

• Engineering Challenge: Engineering to simultaneously achieve points 4 and 5 is extremely non-trivial and will require material levels of innovation and iteration. DOT DAO accepts that this may take some time and be an incremental affair, but establishes the requirement as an aspirational target since
  a) the combined properties are both extremely desirable and as-yet unmet and thus imply substantial untapped economic demand; and
  b) Polkadot as a leader in performant, scalable, genuinely decentralised systems is best able to deliver such a platform.
• Privacy Definition: Privacy shall be taken to mean sensitive to the personal preference for selective disclosure. In the digital realm where traceability is naturally extensive, privacy is generally at odds with performance or cost. DOT DAO does not hereby mandate any particular trade-off between these; rather it mandates that this trade-off be explicitly left to the user and that technology be built and deployed to ensure that this can happen.

6. Execution and Resource Allocation

DOT DAO, on the basis of continuing financial support, invites and requires entities which it funds including but not limited to the Fellowship, to support this mandate.

• This includes bringing selected and strategically central logic under existing support and maintenance provisions; together with judicious utilisation of governance tracks for deployment.

Workload Mitigation

• It is acknowledged that this mandate is in addition to that which presently exists and results in a greater workload; however, a number of mitigating factors exist which ought to limit the true amount of additional work: the code in question is extremely modular, limiting complexity which is the most dangerous aspect of codebase creep. Secondly, the nature of the code as relatively simple transactional logic largely removed from difficult-to-manage elements such as asynchrony, parallelism and complex data relations. Furthermore, advances in LLM tooling appear to be reducing many maintenance workloads, especially for small, well-specified, modular components.