Exploring Protocol Revenue to Strengthen Polkadot’s Treasury

*This proposal aims to discuss the macro-level possibilities of this topic, while specific amounts, protocol revenue, and dividend details will be discussed through a separate proposal before executing the referendum.


Summary

While the Polkadot community has previously discussed diversifying BTC and ETH in the treasury reserves, a key argument remains: Can these assets bring consistent or sustainable income?

This proposal seeks to explore an alternative approach — allocating a portion of the treasury to participate as a stakeholder in mature DeFi protocols, particularly through holding parachain tokens that provide protocol revenue. Rather than replacing BTC or ETH as reserve assets, this strategy aims to complement them by introducing yield-generating components into the treasury portfolio, potentially enhancing the long-term financial sustainability of the network.

Community Concerns

Based on previous discussions, the community has raised several concerns that we should consider in advance:

Why Parachain Tokens? - Addressing Concerns

Can dividends be provided for the treasury?

If the invested parachain projects can offer stable income, the treasury can receive returns through dividends, forming a sustainable funding cycle. Compared to simply assets holding, continuous dividends are more beneficial for long-term development.

Currently, there are parachain projects that can provide dividends with growth potential, such as Hydration and Bifrost.

For instance, in Bifrost’s upcoming new economic model, holding bbBNC means participating in protocol revenue sharing. Although bbBNC is a non-transferable credential, the Polkadot treasury address can hold bbBNC on the Bifrost network and transfer dividends back through XCM calls.

In addition, the same logic can be leveraged on Hydration. Hydration continuously buys back HDX through their Treasury and distributes dividends to HDX stakers. The Treasury can act as a staker as well.

Revenue & Fee Metrics

Both projects have achieved stable revenue for at least six months to a year. As protocol operations expand and revenue increases, the Polkadot treasury will receive greater returns.

Fees on Hydration - revenue accruing since Mar, 2025

Fees on Bifrost - revenue accruing since Mar, 2024

Decentralization?

Investing in parachains can theoretically be fully implemented through Opengov execution, without requiring any third-party intervention. Whether staking HDX or holding bbBNC, on-chain execution can be completed through XCM calls to Hydration or Bifrost.

Community Confidence

  • The growth of parachain projects will greatly enhance Polkadot’s visibility, especially those projects that deeply integrate DOT at the product level. Additionally, increases in Parachain token prices will further boost treasury revenue.

  • Implementing on-chain governance, investment, and dividend distribution models will be completely transparent, which could be a groundbreaking application paradigm for other chains.

  • Parachain Token management by the Polkadot community can enhance user confidence.

Timing

Compared to the DOT/BTC price, DOT still maintains a certain advantage when exchanging for parachain tokens.

Risk

  • Parachain project tokens have higher volatility than BTC and ETH. Additionally, there are unpredictable risk factors such as protocol security issues, team stability, and development roadmap.

  • Protocol revenue is closely tied to business scale; if the business scale shrinks, treasury income will decrease accordingly.

1 Like

Typical incentive compatibility. I suggest conducting a certain proportion of token swaps through over - the - counter (OTC) transactions.

Sorry for the bad English earlier, I’m using Google Translate. Please stop using any mention of BTC reserve or ETH reserve or any reserve where you need to sell the DOT. This has a bad effect on the atmosphere and surroundings of polkadot. They’re already laughing at us-bloggers, people on Twitter, in chat rooms. Why would I keep a Dot if the management itself is selling to buy ETH?- Why should I keep a Dot? - if the management itself does not believe in dot? Do you understand what you are doing? Why do you want to sell DOT at the bottom in order to buy BTC at the top? Polkadot looks for opportunities for dot value and gets rid of it right away. I will agree to buy BTC ETH when polkadot breaks through the price of $ 20-30-40, after that polkadot waits for the price of bitcoin to be lower than the price of its own production, that is, 40-50-60-70K$. P.S.- All conversations from BTC negatively affect potential DOT ETF buyers. Why would I buy a DOT if they sell and buy ETH themselves?

1 Like

Hey, thanks to your advice,

If the contents aounrd BTC/ETH is too sensitive, we can avoid mentioning that. But this topic is about parachain token rather than BTC/ETH, which are not the angle of this discussion.

This is a discussion forum. People can discuss different opinions just fine.

This is not a feel-good-safespace. We can discuss issues even if they are sensitive :smile:

I think that from a financial perspective, it makes sense to diversify the treasury. Investment funds normally hedge against risks, so looking for anti-correlated assets to de-risk the Treasury seems smart.
But it is indeed a very difficult message to send. I can see how people would misunderstand this and indeed think that we lost hope in the DOT token itself. Not sure how to proceed, it would have to me a masterclass in marketing communications.

1 Like

Hi. I understand that this is a discussion forum and it’s just a conversation. But on Twitter, they laugh at this discussion, and bloggers do the same. It also repels potential buyers who are almost absent anyway. polkadot is trying to improve the value of the DOT by selling it to buy eth. I consider this nonsense and harm to polkadot and the project environment. Let’s now start Elon Musk on Twitter just talking about how cryptocurrency is harmful, Bitcoin is clogging up the environment, Tesla is selling his btc and cryptocurrency is a scam- let’s see what happens to cryptocurrency, but this is just a conversation.

Yes, it won’t be easy. Hopefully people can find out the hope should be built on projects who build in Polkadot and willing to grow with it. Constant revenue flows to Treasury is a key here for diversification and only ecosystem projects would do this.

Polkadot should support its ecosystem parachain that aligned with its vision. Defi is the liquidity lifeblood of the entire ecosystem. I see Hydration and Bifrost is the 2 matured Defi parachain with its own OpenGov. let’s show outsiders of our ecosystem that we actually have successful parachains with product marker fit. Without good products in the hands of end users we are nothing but good tech on paper. I would rather have Polkadot treasury liquid stake DOT into vDOT then DCA into Hydration and Bifrost tokens via Hydration platform because it actually helps the liquidity of the whole ecosystem instead of OTC.

1 Like

I was planning on making a business plan for each of these Ideas and put together an ecosystem-centric vision & plan but I don’t have the bandwidth. So I’ll just dump the ideas here.

## **Internal Services**

* **Polkadot Storage** *(CLASSES: NVMe, HDD, Memory)*

  * **CLASS: NVMe**

    * **User purchases:** Object/file storage (GB‑month), retrieval bandwidth (GB), redundancy/pinning tier, IOPS/throughput class.
    * **Provider offers:** Gen‑3 NVMe–backed Ceph BlueStore object store; PoSt/PDP optimized for Gen‑3 NVMe; availability/throughput SLAs; retention; metadata index mapping files → tenant “Cloud Store”.
    * **Dependencies:** Monitoring Network (availability/durability attestations), DID (provider onboarding/compliance), PoSt/PDP modules, on‑chain payments.
    * **Caveats/Notes:** Egress cost exposure; encryption/key custody; proof parameters/tuning **TBD**.
  * **CLASS: HDD**

    * **User purchases:** Cold object/file storage (GB‑month), retrieval bandwidth (GB), archival redundancy tier.
    * **Provider offers:** HDD‑backed Ceph BlueStore capacity; PoSt/PDP attestations (cold tier); large‑capacity retention; same metadata index → “Cloud Store”.
    * **Dependencies:** Monitoring Network, DID, PoSt/PDP tuned for HDD characteristics.
    * **Caveats/Notes:** Very slow retrieval; lowest cost; retrieval batching; hot‑tier promotion policies **TBD**.
  * **CLASS: Memory**

    * **User purchases:** Ultra‑low‑latency key/object storage (ops/sec, GB‑RAM), TTL policies, optional write‑through to NVMe tier.
    * **Provider offers:** Redis cluster as object store; high‑QPS/low‑latency SLAs; optional persistence/replication; metrics/export; metadata mapping to “Cloud Store”.
    * **Dependencies:** Monitoring Network (latency/availability), DID, optional NVMe backfill/snapshot.
    * **Caveats/Notes:** RAM cost premium; durability semantics (ephemeral vs AOF/RDB) explicit; eviction/TTL policy **TBD**.

* **Monitoring System & Network**

  * **User purchases:** Active probes (TCP/HTTPS/WSS/ETH‑RPC Revive), alerting, attested uptime/latency/error reports, vantage diversity.
  * **Provider offers:** Staked probe nodes, scheduled checks, signed attestations, SLA participation.
  * **Dependencies:** DID (operators), Polkadot Storage (logs/metrics), secure time sync, quorum/aggregation pallet.
  * **Caveats/Notes:** Oracle manipulation/false positives; slashing curves; regional vantage scarcity; probe‑data privacy.

* **Decentralized ID (DID)**

  * **User purchases:** KYC/KYB verification, verifiable credential issuance, status/revocation checks.
  * **Provider offers:** Attestations, local‑partner record‑keeping, verification APIs.
  * **Dependencies:** Jurisdictional partners, Polkadot Storage (claims metadata), Monitoring (service uptime).
  * **Caveats/Notes:** PII minimization/retention; cross‑border data rules; appeal/revocation flow; cost per verification.

---

## **IaaS Marketplace**

* **DNS Marketplace**

  * **User purchases:** Domain registration/transfer, authoritative DNS hosting, record management, DNSSEC, GeoDNS/Anycast add‑ons, query capacity.
  * **Provider offers:** Authoritative DNS service with defined QPS/SLA, zone propagation, DNSSEC signing, health reporting.
  * **Dependencies:** Monitoring (uptime/QPS attestations), Polkadot Storage (zone files/backups via NVMe/HDD), DID (registrant/provider), ICANN/registrar integration via PCF entity/reseller **TBD**.
  * **Caveats/Notes:** Per‑M query billing; DDoS shielding; proofs of hosting; TTL/cache behavior; ICANN policy compliance.

* **Virtual Machine (VM) Marketplace**

  * **User purchases:** vCPU‑hours, RAM‑hours, block/local storage (GB‑month on NVMe/HDD), GPU time, public IPv4/IPv6, intra/inter‑DC bandwidth; optional snapshots/backups.
  * **Provider offers:** VM images/instances, compute/network capacity, uptime/SLA, support, optional hardware attestation.
  * **Dependencies:** Monitoring (availability/perf), DID (tenants/providers), Polkadot Storage (images/snapshots), bandwidth metering.
  * **Caveats/Notes:** Noisy‑neighbor isolation; bandwidth fraud; IP reputation/abuse handling; hardware heterogeneity; side‑channel risk.

* **Kubernetes Marketplace**

  * **User purchases:** Managed clusters/namespaces, node/pod hours, storage classes (NVMe/HDD), ingress/LB, autoscaling, optional GPU nodes.
  * **Provider offers:** Control‑plane management, worker nodes, upgrades/patching, cluster SLOs, support/runbooks.
  * **Dependencies:** Monitoring (cluster/node/pod), DID, Polkadot Storage (backups/artifacts), container registry integration.
  * **Caveats/Notes:** Multi‑tenant security, version drift, workload isolation, egress cost from clusters.

* **Edge (CDN‑like) Marketplace**

  * **User purchases:** Edge object placement, request serving (requests/month), egress GB, cache TTL/invalidation, optional edge functions/WAF, TLS termination.
  * **Provider offers:** POP storage/bandwidth/compute, caching, TLS, request processing, logs/analytics.
  * **Dependencies:** DNS (routing/GeoDNS), Monitoring (POP health/perf), Polkadot Storage (origin/backfill; hot objects optionally Memory tier), certificate management.
  * **Caveats/Notes:** Egress cost volatility; content moderation/DMCA; cache‑purge costs; POP density; TLS key custody.

* **Carrier‑Grade Onion Routing Network**

  * **User purchases:** Transit capacity (GB), optional QoS classes, circuit/hop selection, anycast ingress/egress.
  * **Provider offers:** Forwarding nodes in private mesh, per‑hop processing/settlement, route announcements/peering, QoS enforcement.
  * **Dependencies:** DID (operators/tenants), Monitoring (path performance/availability), IBP hardware footprint, PCF‑owned IPv4/IPv6 blocks, PKI/micropayments, private interconnects (VXC/MPLS/ETC).
  * **Caveats/Notes:** Regulatory/exit‑node liability; lawful‑request handling; path‑length overhead vs latency; DoS/misrouting defenses; abuse mitigation.

* **Web Application Firewall (WAF) Marketplace**

  * **User purchases:** Managed WAF service (L7 filtering, bot mitigation, rate limiting), optional caching/optimization, TLS termination, per‑request analytics.
  * **Provider offers:** WAF clusters (reverse proxy), policy/rule management APIs, dedicated anycast/IP endpoints, logs.
  * **Dependencies:** **DID (mandatory)** for buyers/providers (CSAM/abuse gating), DNS Marketplace (CNAME/Apex), Monitoring (request/latency/error probes), Polkadot Storage (logs/config), certificate management; optional Edge Marketplace interop.
  * **Caveats/Notes:** False‑positive tuning; privacy/legal compliance; DDoS absorption disclosure; multi‑provider chaining; evidence preservation for abuse reports.

* **Mining Hashrate Marketplace**

  * **User purchases:** Leased hashrate directed to buyer‑specified pool(s); time‑boxed or hashrate‑target contracts; managed proxying.
  * **Provider offers:** Mining hardware capacity; configurable pool targets; telemetry; fallback to seller’s pool when idle.
  * **Dependencies:** WAF Marketplace (proxy/reverse‑proxy routing to pools), Polkadot Storage (buyer/seller configs, pool creds), Monitoring (delivery verification, shares/accepted rate), on‑chain escrow/deposits.
  * **Caveats/Notes:** Hashrate measurement/audit; pool misreporting risk; payout disputes; regional regulatory exposure; deposit drain/auto‑settlement logic.

* **Price Oracle Marketplace** *(moved from dAPP Services)*

  * **User purchases:** Price feeds (pull/push) with freshness/SLA; aggregation policies; historical snapshots; retrieval from storage (pay‑per‑GB/object).
  * **Provider offers:** Bonded oracle nodes sourcing declared exchanges/APIs; periodic writes to **Polkadot Storage (Memory)**; misbehavior slashing; governance approval of sources/policies.
  * **Dependencies:** Polkadot Storage (Memory for hot writes; NVMe/HDD for history), DID (operators), Monitoring (outlier detection/availability), bonding/slashing pallet; consumer adapters (parachain runtime/EVM).
  * **Caveats/Notes:** Buyers pay retrieval/storage; source/API outages; collusion/outliers; **bootstrap subsidy:** Treasury top‑up ≥ staking reward + **TBD**% until organic demand.

---

## **dAPP Services**

* **On‑Chain Casino (all games on‑chain)**

  * **User purchases:** Wagers/game credits; table seats/tournaments; premium skins/namespaces.
  * **Provider offers:** Fully on‑chain games (slots/dice/roulette/blackjack/poker); on‑chain RNG (VRF/commit‑reveal/threshold VRF); transparent house edge & payout tables; on‑chain bankroll/solvency proofs; UI gateways.
  * **Dependencies:** Polkadot Storage (Memory for hot state; NVMe/HDD for history/logs), Monitoring (liveness/latency), DID (KYC/age geofencing per jurisdiction), IaaS (RPC/UI hosting), Price Oracle Marketplace (token valuations), settlement/escrow pallets.
  * **Caveats/Notes:** Target \~500 ms tick (multi‑core scheduling); fairness/anti‑front‑running; responsible‑gaming controls; licensing/geofencing; bankroll risk rules.

* **Discord/Element/Matrix‑Style Chat**

  * **User purchases:** Workspace/server creation, user seats/tiers (free + paid upgrades), storage/retention, voice/video minutes, API/integration quotas.
  * **Provider offers:** Wallet‑auth chat; per‑server Redis DB isolation; Voice/Video SFU; scalable messaging/search; upgrade APIs for server owners/managers/members.
  * **Dependencies:** Polkadot Storage (Memory hot state; NVMe/HDD persistence); IaaS (VM/Kubernetes); DID where required; components: Elixir, ScyllaDB, Elasticsearch, SFU.
  * **Caveats/Notes:** Jurisdictional DID gating; free‑tier abuse controls; blockchain‑aware component patches; media/storage costs.

* **Email Service / Account Messaging**

  * **User purchases:** Encrypted mailbox tied to wallet; message delivery; storage (GB); notification rules; spam‑deposit thresholds.
  * **Provider offers:** HPKE+x25519 or (double) ratchet; inbox deposit gates; “reap” to seize sender’s storage deposit on rejection; delivery receipts; wallet‑address routing.
  * **Dependencies:** Polkadot Storage (NVMe/HDD/Memory per sender choice); DID optional by jurisdiction; Monitoring; on‑chain escrow for deposits.
  * **Caveats/Notes:** Metadata/privacy leakage; key rotation/recovery; UX for deposits/reaping; legal retention; anti‑spam economics.

* **Logging Provider / Log Stash**

  * **User purchases:** Encrypted log ingestion endpoints, storage tier (NVMe or HDD), retention, viewing/streaming UI, optional search/indexing.
  * **Provider offers:** Blockchain‑aware receiver validating address↔store; encrypted write; chunked/multipart tailing UI; optional Elasticsearch search with customer‑key decryption.
  * **Dependencies:** Polkadot Storage (NVMe/HDD), Monitoring, IaaS (VM/Kubernetes); optional Elastic/Logstash.
  * **Caveats/Notes:** Search vs encryption trade‑off; cost of hot retention; multi‑tenant isolation.

* **On‑Chain Password Manager**

  * **User purchases:** Encrypted vault storage, client apps/extensions, team/shared vaults, 2FA secret management.
  * **Provider offers:** Encrypted blob storage; client for download/decrypt/edit; versioning/audit trails; optional write‑through to NVMe tier.
  * **Dependencies:** Polkadot Storage (NVMe/HDD; optional Memory cache), Monitoring; strong crypto libs; secure client distribution.
  * **Caveats/Notes:** Key loss/recovery; side‑channel risks; offline access; org policy controls.

* **On‑Chain Reputation Registry**

  * **User purchases:** Write/read of reputation artifacts; API access; dispute/arbitration flows.
  * **Provider offers:** Primitives for: (1) Attestation, (2) Categorical feedback/association, (3) Direct feedback (rare/vote), (4) Start/End dispute, (5) Structured feedback, (6) Free‑text note, (7) Pairwise rank, (8) Proposal reviews/audits.
  * **Dependencies:** DID (identity & issuer roles), Polkadot Storage (artifact blobs/indices), Monitoring; governance hooks for disputes.
  * **Caveats/Notes:** Sybil/brigading resistance; appeal windows; schema/versioning.
1 Like