Download

Whitepaper

PFun Store White Paper

The architecture, token model, governance and roadmap of PFun Store.

本白皮書之中文版本僅供參考。中文版與英文版如有任何歧異或不一致之處，概以英文版為準。

DST token
01

PFun Store Vision and Declaration

Preface

Most people never enter Web3 because the first step asks too much of them: understand a wallet, hold a token, accept volatility — all before anything enjoyable happens. PFun Store starts from the other end. It starts with games people already want to play.

What PFun Store Is

PFun Store is a game-led digital ecosystem. It operates a portfolio of casual mobile games, an advertising-funded reward layer that pays users for verified engagement, and a set of on-chain components that give long-term participants a durable stake in what they helped build.

Three layers, in the order they matter:

Games. A growing portfolio of casual titles — puzzle, sorting, merge, hidden-object and similar — designed to be understood in seconds and played in short sessions. Each game is built to stand on its own as entertainment. A PFun Store game should still be worth playing with every reward removed.

Rewards, funded by advertising. Players earn Contracts by completing Quests: reaching a milestone in a partner app, watching an optional rewarded video, or returning across consecutive days. Advertisers pay for verified engagement; part of that payment reaches the player as Contracts, and PFun Store retains the margin.

Ecosystem. Contracts connect gameplay to progression, events, community standing and digital collectibles such as PFun Store Genesis. The on-chain layer exists to make participation portable and ownership real, not to be the reason someone opens the app.

Our Mission

To turn mainstream mobile players into long-term ecosystem participants — by earning their attention with games worth playing, rewarding them from real revenue rather than speculation, and giving the ones who stay a genuine stake.

Where This Goes Next

PFun Store is built in sequence, not all at once. Each phase has to work before the next one is worth attempting.

Now — Games. Build a portfolio of casual titles and an audience that returns for them.

Now — Rewards funded by advertising. Turn that attention into revenue, and share part of it back with players as Contracts.

Next — The Creator Platform. Open the ecosystem to creators, so that content and games are produced by the community as well as by PFun Store.

Next — Developer tools. A GameFi SDK allowing third-party developers to integrate PFun Store rewards into their own titles.

Next — DAO governance. Progressive transfer of decision-making to token holders, including the veDST weighting model described in the Tokenomics chapter.

Next — Cross-chain. PFun Store is deployed on Solana. Interoperability with other chains is planned, without a committed timeline.

Later — A PFun Store chain. The long-term intention is to operate a PFun Store chain of our own, with the Solana deployment as a starting point rather than the destination. This is a direction, not a schedule. It depends on the earlier phases succeeding at a scale that would justify it, and it will only be attempted if and when that becomes true.

The order is deliberate. A creator platform without an audience is an empty storefront; creators go where the players already are. Developer tools and community governance both assume something worth building on and worth governing. Games come first because they are what brings people in.

Items marked "Next" are plans, not commitments. Items marked "Later" are stated directions with no timeline attached. Both may change, be re-sequenced, or be dropped.

Who Decides Today

Because DAO governance is not yet operating, decisions that the Tokenomics and Governance chapters describe as subject to DAO approval — treasury allocation, community release schedules, the rate at which Contracts redeem for DST, and any change to the supply model — currently rest with the operator named below.

We state this plainly rather than leaving it implied. Until governance is live, "DAO determined" means determined by the operator, and the transfer of those powers is itself a future event, not a present condition.

What This Document Does Not Claim

The limits of what PFun Store does:

  • PFun Store does not operate a DePIN network.
  • PFun Store does not operate an on-chain AI model pool or AI model governance.
  • PFun Store does not rent or broker GPU compute.
  • PFun Store is not a general-purpose blockchain or infrastructure layer.
  • Rewards are not a yield product and carry no expectation of profit.

Anything not described in this document is not being built.

Who Operates PFun Store

PFun Store is operated by De Stijl Technology Network International Company Limited. This document is published by that entity. References to "we", "us" and "the team" throughout this Whitepaper refer to it.

Our Vision

An ecosystem people return to because they enjoy participating in it — not because they are waiting for a payout.

前言

多數人始終未能踏入 Web3，原因在於第一步的門檻過高：必先理解錢包、必先持有代幣、必先承受波動——而這一切，都發生在任何值得享受的事情出現之前。PFun Store 選擇從另一端開始：從人們原本就願意投入的遊戲開始。

PFun Store 的定位

PFun Store 是一個以遊戲為核心的數位生態，由三個部分構成：一組休閒手機遊戲；一個以廣告收入為基礎、按經核實的參與行為向用戶付酬的獎勵層；以及一組鏈上元件，使長期參與者對其共同建立的成果擁有實質份額。

三者按重要性排序如下。

遊戲。 持續擴充的休閒遊戲組合，涵蓋解謎、分類、合成、尋物等類型，設計原則是數秒內即可理解、於零碎時間內完成一局。每一款遊戲均須能作為娛樂產品獨立成立——即使移除全部獎勵機制，一款 PFun Store 遊戲仍應值得遊玩。

以廣告收入為基礎的獎勵層。 玩家透過完成任務取得 Contract：在合作應用中達成指定進度、觀看選擇性的獎勵影片，或於連續數日回訪。廣告商就經核實的參與行為付費，其中一部分以 Contract 形式歸於玩家，PFun Store 保留營運利潤。

生態層。 Contract 將遊玩行為連結至進度、活動、社群身份，以及如 PFun Store Genesis 一類的數位收藏品。鏈上層的作用，在於使參與具備可攜性、使擁有權具備實質意義，而非成為用戶開啟應用的理由。

使命

將主流手機遊戲玩家，轉化為長期的生態參與者：以值得遊玩的作品贏取其注意力，以真實收入而非投機回報其投入，並使選擇留下的人擁有實質份額。

發展次序

PFun Store 依次序建構，而非一次推出全部。每一階段均須先行證明可行，下一階段方值得展開。

現階段——遊戲。 建立休閒遊戲組合，並累積願意回訪的用戶群。

現階段——以廣告收入為基礎的獎勵。 將用戶注意力轉化為收入，並以 Contract 形式與玩家分享其中一部分。

下一階段——創作者平台。 向創作者開放生態，使內容與遊戲不僅由 PFun Store 生產，亦由社群生產。

下一階段——開發者工具。 推出 GameFi SDK，使第三方開發者得以將 PFun Store 獎勵機制整合至自身作品。

下一階段——DAO 治理。 逐步將決策權移轉予代幣持有人，包括代幣經濟章節所述之 veDST 權重模型。

更長遠——PFun Store 自有公鏈。 長遠目標為營運 PFun Store 自有公鏈；Solana 上的部署為起點，而非終點。此為方向，而非時程：只有當前述各階段的規模足以支撐時，才會啟動。

此一次序出於刻意安排。缺乏用戶基礎的創作者平台形同虛設，創作者只會前往玩家已然聚集之處；開發者工具與社群治理，亦同樣預設了已有值得建構其上、值得治理的標的。遊戲之所以排在最前，正因遊戲是把人帶進來的那一環。

標示為「下一階段」者為計劃，並非承諾；標示為「更長遠」者為已陳明之方向，不附帶任何時程。兩者均可能變更、重新排序，或予以放棄。

現階段的決策主體

由於 DAO 治理尚未運作，代幣經濟與治理章節中所述須經 DAO 批准之事項——包括資金庫配置、社群釋放時程、Contract 兌換 DST 之比率，以及供應模型之任何變更——現階段均由下述營運方決定。

本文件選擇直接載明此點，而非留待讀者自行推斷。在治理正式運作之前，「由 DAO 決定」在事實上即等同於由營運方決定；而該等權力之移轉，本身屬未來事件，並非現況。

本文件不予聲稱之事項

PFun Store 所不涉及之範圍：

  • PFun Store 不營運 DePIN 網絡。
  • PFun Store 不營運鏈上 AI 模型池，亦不從事 AI 模型治理。
  • PFun Store 不出租或轉介 GPU 算力。
  • PFun Store 並非通用區塊鏈或基礎設施層。
  • 獎勵並非收益型產品，不附帶任何獲利預期。

本文件未載明之功能，即尚未建置。

營運方

PFun Store 由 De Stijl Technology Network International Company Limited 營運。本文件由該實體發佈。本白皮書中「我們」之指稱，均指該實體。

願景

一個使人因享受參與而回訪的生態——而非一個使人等待兌現的生態。

03

How PFun Store Makes Money

The Short Version

Advertisers pay to reach engaged players. PFun Store earns that money by delivering genuine engagement, and passes part of it back to players as Contracts. Nothing in the reward layer depends on token appreciation, new user deposits, or future fundraising.

Where the Money Comes From

Rewarded advertising inside our games. A player chooses to watch a video in exchange for a benefit in the game. The advertiser pays for that view. This is standard mobile advertising, served through Google AdMob.

Quests — advertiser tasks. An advertiser wants players to try their app and keep using it. They pay for verified engagement: reaching a level, completing a tutorial, returning across several days. These tasks reach us through offerwall inventory supplied by our advertising partner — currently Unity LevelPlay — rather than being sourced by PFun Store directly. What a completed Quest gives the player is an accelerator, not a Contract; the section below explains the difference.

The important word is verified. Advertisers pay on confirmed outcomes, not on clicks or impressions alone, and rewards are released only after that confirmation. This is why a Quest reward is not instant.

How a Contract Is Earned

A Contract is not handed out for completing a task. It is produced by playing.

Each player has a progress meter. The meter advances on actual play — level progress, valid rounds, registered input — and not on elapsed time. A game left open on an idle device advances nothing. When the meter reaches 100%, the player receives one Contract and the meter resets.

Rewarded video and Quests produce accelerators, which raise the rate at which the meter advances. An accelerator is not a Contract and not a currency. It cannot be redeemed, transferred, or held for value, and it does nothing outside the game. Its only effect is that a player who watches an ad or completes a Quest reaches the same Contract sooner, by playing.

Two things follow from this design, and both are deliberate.

What the advertiser buys is real. A reward tied to play rather than to a claim means the engagement sold to advertisers is engagement that happened.

Farming is expensive. The common attack on reward applications is to automate the rewarded action. Where progress requires play rather than elapsed time, an idle session, an emulator left running, or a script that does not actually play the game produces nothing. The detection controls are addressed in the security chapter and are not published.

Daily cap. However many PFun Store games a player plays, a player earns at most ten Contracts a day across all of them. Accelerators change how quickly that cap is reached, not the cap itself. The accelerator rate and duration, and how the meter is defined in each game, will be published separately.

概要

廣告商付費以觸及具參與度的玩家。PFun Store 透過交付真實的參與行為取得此項收入，並將其中一部分以 Contract 形式回饋玩家。獎勵層之任何環節，均不依賴代幣升值、新用戶入金，或日後之融資。

收入來源

遊戲內獎勵式廣告。 玩家自行選擇觀看影片，以換取遊戲內的利益，廣告商就該次觀看付費。此為標準的行動廣告形式，由 Google AdMob 投放。

任務——廣告商指派之任務。 廣告商期望玩家試用其應用並持續使用，故就經核實的參與行為付費，例如達到指定關卡、完成新手教學、於連續數日回訪。此類任務來自廣告夥伴所提供之任務牆庫存，現為 Unity LevelPlay，而非由 PFun Store 直接接洽廣告商。玩家完成任務所得者為加速器，而非 Contract；兩者之分別見下節。

其中關鍵在於「經核實」三字。廣告商係按已確認之結果付費，而非僅憑點擊或曝光；獎勵亦須待確認完成後方予發放。任務獎勵並非即時到帳，原因即在於此。

Contract 之產生方式

Contract 並非因完成任務而發放，而係由遊玩本身產生。

每名玩家設有一條進度條。進度條只會因實際遊玩而上升——過關、完成有效回合、已記錄之操作——而非因時間經過而上升。遊戲若僅開啟而置於閒置裝置，進度條不會上升。進度條儲滿 100% 時，玩家獲得 Contract 一張，進度條隨即歸零。

獎勵式影片與任務所產生者為加速器，其作用為令進度條上升得更快。加速器並非 Contract，亦非任何形式之貨幣：不可兌換、不可轉讓、不具價值儲存功能，離開遊戲即無任何作用。其唯一效果，係使觀看廣告或完成任務之玩家，得以透過遊玩較快取得同一張 Contract。

此一設計有兩項作用，均屬刻意安排。

廣告商所購買者為真實之參與。 獎勵取決於實際遊玩，而非自行申報；因此售予廣告商之參與行為，均為確實發生過之參與。

刷取之成本因而提高。 針對獎勵型應用之常見攻擊，係將取得獎勵之行為自動化。當進度取決於遊玩而非時間，閒置之連線、持續運行之模擬器，或未實際遊玩之腳本，均無法產生任何獎勵。至於偵測層面之控制措施，載於安全章節，並不予公布。

每日上限。 無論遊玩多少款 PFun Store 遊戲，每名玩家每日合共最多取得 Contract 十張。加速器僅改變達到該上限之速度，不改變上限本身。加速器之倍率與時效，以及各款遊戲中進度條之定義，將另行公布。

Ecosystem reward pool1,800,000,000 DST · 30%
AdMobUnity LevelPlayAdvertisers · pay on verified outcomes
PFun Storeoperating revenue
Playlevels · rounds · input
Contractthe player's reward
0%

01 · THE POOL

1,800,000,000 DST

30% of total supply, held in the ecosystem reward pool. There is no emission schedule: DST leaves the pool only when a reward is paid.

02 · ADVERTISERS

Advertisers pay for verified outcomes

AdMob and LevelPlay pay PFun Store for verified advertising outcomes inside the games.

03 · REVENUE

Revenue funds the reward budget

Advertising revenue is PFun Store's operating revenue. It sets how fast rewards can be paid out.

04 · PLAY

Play fills the meter. 100% earns a Contract.

Levels, rounds and inputs move the meter; accelerators raise the rate. At 100% the player receives a Contract — the reward, funded by advertising.

05 · REDEEM

Contracts redeem into DST from the pool

Redemption is the only way DST leaves the pool. The pool sets how much can ever be paid out; advertising sets how fast.

Advertiser AdMob · LevelPlay PFun Store operating revenue pays on verified outcome funds the reward budget Play levels · rounds · input Progress meter raised by accelerators 100% Contract the player's reward funded by advertising redeem Ecosystem reward pool DST 1,800,000,000 DST · 30% of total supply No emission schedule Leaves the pool only when a reward is paid UPPER BOUND The pool sets how much can ever be paid out. Advertising revenue sets how fast.
Figure 1 — Flow of advertising revenue, Contracts and DST redemption from the ecosystem reward pool.

Where the Money Goes

Advertiser payment splits three ways:

  1. To the player, as Contracts, earned by playing.
  2. To PFun Store, as the operating margin that funds game development, infrastructure and user acquisition.
  3. To the advertising partner, as the intermediary fee. PFun Store currently works with Google AdMob for rewarded video and Unity LevelPlay for offerwall inventory. Partners may change.

The exact split varies by advertiser, country and campaign, and is set by market rates rather than by protocol.

Why This Matters

Reward ecosystems fail in a predictable way. Rewards are funded from token issuance or from new participants; the cost of rewards rises with user growth; the only way to keep paying is to issue more or recruit more. That is not a sustainable business model.

PFun Store's reward layer is funded by advertising revenue, which scales with engaged users rather than against them. More players who genuinely play are worth more to advertisers, which funds larger rewards, which is affordable precisely because the revenue exists first.

The Constraint We Accept

PFun Store does not pay out more than advertising revenue supports. Reward rates move with advertising economics — eCPM, fill rate, advertiser demand by country — and may go down as well as up. We would rather state this limit than let anyone infer a guarantee that does not exist.

Revenue Beyond Advertising

Advertising is the only revenue line operating today. The creator platform described in the previous chapter may introduce others in future. Nothing in this document should be read as assuming revenue that does not yet exist.

What This Is Not

  • Rewards are not interest, dividends, yield, or a return on investment.
  • Participation requires no purchase and no deposit.
  • No reward rate is guaranteed, and rates may change without notice.

Contracts are redeemable for DST. How that works, and what bounds it, is set out in the Tokenomics chapter.

收入分配

廣告商之付款分配如下：

  1. 玩家——以 Contract 形式，由遊玩產生。
  2. PFun Store——作為營運利潤，用於遊戲開發、基礎設施與用戶獲取。
  3. 廣告夥伴——作為中介費用。PFun Store 現以 Google AdMob 投放獎勵式影片，以 Unity LevelPlay 提供任務牆庫存。合作夥伴可能變更。

實際分配比例因廣告商、地區與投放活動而異，由市場價格決定，而非由協議規定。

此一結構的意義

獎勵型生態的失敗模式具有高度可預測性：獎勵由代幣增發或新參與者的資金支應；用戶規模擴大，獎勵成本隨之上升；欲維持支付，便只能繼續增發，或持續吸納新參與者。此非可持續之商業模式。

PFun Store 的獎勵層由廣告收入支應，而廣告收入隨活躍用戶同步增長，並非被用戶增長所拖累。真正投入遊玩的玩家愈多，對廣告商的價值愈高，因而得以支撐更大規模的獎勵；獎勵之所以負擔得起，正因收入先於獎勵存在。

我們自設的上限

PFun Store 所發放之獎勵，不會超出廣告收入所能支撐之水平。 獎勵比率將隨廣告經濟環境變動——包括 eCPM、填充率、各地區廣告商需求——可升亦可跌。與其任由讀者推斷出一項並不存在的保證，本文件寧可明確載明此一上限。

廣告以外之收入

廣告為現階段唯一運作中的收入來源。前章所述之創作者平台，日後或將帶來其他收入。本文件任何內容，均不應理解為已假設尚未存在之收入。

明確排除之事項

  • 獎勵並非利息、股息、收益，亦非投資回報。
  • 參與不涉及任何購買或入金。
  • 任何獎勵比率均不予保證，且可能未經通知而變更。
04

System Overview and Architecture

Protocol Architecture (Solana)

協議架構（Solana）

Client layermobile application · web dashboard · wallet connectionLIVE
Protocol and contract layerDST token · transaction engine · reward distribution · staking · DAO governance2 LIVE · 1 PARTLY2 NOT ACTIVE
Integration layerProtocol adapter · third-party applicationsPLANNED
FoundationSolana · SPL Token · SPL Governance
Client layer mobile application · web dashboard · wallet connection Protocol and contract layer DST token · transaction engine · reward distribution staking · DAO governance Integration layer Protocol adapter · third-party applications FOUNDATION Solana · SPL Token · SPL Governance LIVE 2 LIVE · 1 PARTLY 2 NOT ACTIVE PLANNED
Figure 2 — System architecture: the four layers and their current status.

Core Modules

PFun Store is modular: protocol functions are deployed, upgraded and extended independently. The table below states what each module does and whether it is live today.

Module Function Implementation Status
DST Token Contract Manages total supply, unlocking, distribution and user interaction, with built-in lock-up mechanisms. SPL Token + custom economic model Live
On-chain Transaction Engine NFT issuance and transfer. Token conversion and asset exchange are not yet available. Solana Program (Rust) + SPL Token Partly live
Reward Distribution Module Records completed Quests and allocates Contracts to users. Funded by advertising revenue, not by token issuance. Completing a designated Quest earns its Quest reward Live
Staking Module Lock-up and staking as described in the Tokenomics chapter, including the veDST weighting model. Smart contract + time-lock mechanism Not yet active
DAO Governance Module Community proposals, weighted voting, binding of contract execution. SPL Governance + custom voting weight Not yet active
Protocol Integration Module Plug-in integration of third-party applications, including the GameFi SDK described in the opening chapter. Standardised API + protocol adapter Planned

The transaction engine is marked "Partly live" because only part of what it is designed to do is in use: NFT issuance and transfer work today, and token conversion and asset exchange do not. A module is listed as live only for the functions actually running.

Modules marked "Not yet active" exist in the protocol design and are described in the Tokenomics and Governance chapters. They are not operating. Until they are, the decisions they would govern rest with the operator, as set out in the opening chapter.

Client and Wallet

核心模組

PFun Store 採模組化設計，各項協議功能可獨立部署、升級與擴充。下表載明各模組之功能，並標示其現階段是否已投入運作。

模組 功能 實作方式 狀態
DST Token 合約 管理總供應量、解鎖、分配與用戶互動，內建鎖倉機制。 SPL Token ＋ 自訂經濟模型 已運作
鏈上交易引擎 NFT 發行與轉移。代幣轉換與資產交換尚未提供。 Solana Program（Rust）＋ SPL Token 部分運作
獎勵分配模組 記錄已完成之任務，並向用戶分配 Contract。由廣告收入支應，而非由代幣增發支應。 達成指定任務會獲得任務獎勵 已運作
質押模組 代幣經濟章節所述之鎖倉與質押機制，包括 veDST 權重模型。 智能合約 ＋ 時間鎖機制 尚未啟用
DAO 治理模組 社群提案、加權投票、合約執行綁定。 SPL Governance ＋ 自訂投票權重 尚未啟用
協議整合模組 以外掛形式整合第三方應用，包括首章所述之 GameFi SDK。 標準化 API ＋ 協議轉接層 計劃中

交易引擎標示為「部分運作」，因其設計功能中僅有一部分正在使用：NFT 發行與轉移現已運作，而代幣轉換與資產交換則否。模組僅就其實際運行之功能標示為已運作。

標示為「尚未啟用」之模組，存在於協議設計之中，並於代幣經濟與治理章節中有所描述，惟現階段並未運作。在其啟用之前，該等模組原應治理之事項，均由營運方決定，詳見首章。

用戶端與錢包

Figure 3 — Wallet connection and signing on the client side: Phantom, Solflare and Backpack through the Solana Wallet Adapter standard.
  • Supported wallets: Phantom, Solflare, Backpack, via the Solana Wallet Adapter standard.
  • Login and signature: SIWS (Sign-in With Solana), message-signature anti-phishing verification, source domain binding.
  • Transaction experience: single and batch signing, priority fee suggestions, error classification (slippage, balance, permissions).
  • Key management: MPC and social recovery (non-custodial), multi-signature and whitelisted address management.
  • Caching and synchronisation: IndexedDB transaction and account snapshots, offline draft signatures, automatic synchronisation on recovery.
  • Development kits: Web SDK, React Native SDK, server-side signing tools.
Module Capability Security design
Wallet connection Connect and disconnect, network detection, account switching Minimal permissions, domain binding prompts
Transaction sending Single and batch, priority fees, retries Replay protection, nonce management, standardised error codes
Asset management SPL Token and NFT query and display Read-only RPC, rate limiting, phishing contract flagging
Signing and verification SIWS, message signing Fixed message templates, risk prompts, expiry times

Protocol and Contract Layer

  • Contract modules: transaction engine, reward distribution, staking, DAO governance, DST token, protocol adapters.
  • Account model: PDA (Program Derived Address) for state management; resource naming and permission domains standardised by seeds.
  • Events and logs: critical operations emit events for indexers and dashboards; error codes and event names are standardised.
  • Upgrade control: upgrades execute through a timelock with multi-signature approval. Governance of that process is intended to transfer to the DAO once it is active; until then it rests with the operator.
  • Compatibility: compliant with SPL Token and Metadata standards.
  • Security baseline: re-entrancy protection, arithmetic overflow checks, privilege separation, emergency pause.

Why Solana

Rewards in PFun Store are small and frequent. A user may earn Contracts several times in a single session. That pattern makes two properties decisive: the cost of settling a transaction, and the time it takes to settle. Solana was selected on those two grounds.

We do not reproduce network throughput figures here.

  • 支援錢包： Phantom、Solflare、Backpack，採 Solana Wallet Adapter 標準。
  • 登入與簽章： SIWS（Sign-in With Solana）、訊息簽章防釣魚驗證、來源網域綁定。
  • 交易體驗： 單筆與批次簽章、優先費用建議、錯誤分類（滑點、餘額、權限）。
  • 金鑰管理： MPC 與社交復原（非託管）、多重簽名與白名單地址管理。
  • 快取與同步： 以 IndexedDB 保存交易與帳戶快照、離線草稿簽章、復原後自動同步。
  • 開發套件： Web SDK、React Native SDK、伺服器端簽章工具。
模組 能力 安全設計
錢包連接 連接與中斷、網絡偵測、帳戶切換 最小權限、網域綁定提示
交易送出 單筆與批次、優先費用、重試 重放保護、Nonce 管理、標準化錯誤碼
資產管理 SPL Token 與 NFT 之查詢與顯示 唯讀 RPC、速率限制、釣魚合約標記
簽章與驗證 SIWS、訊息簽章 固定訊息範本、風險提示、有效期限

協議與合約層

  • 合約模組： 交易引擎、獎勵分配、質押、DAO 治理、DST Token、協議轉接層。
  • 帳戶模型： 以 PDA（Program Derived Address）管理狀態；資源命名與權限範圍以 seeds 標準化。
  • 事件與日誌： 關鍵操作發出事件供索引器與儀表板使用；錯誤碼與事件名稱均已標準化。
  • 升級控制： 升級須經時間鎖並取得多重簽名批准後執行。該流程之治理權，預定於 DAO 啟用後移轉；在此之前由營運方掌理。
  • 相容性： 符合 SPL Token 與 Metadata 標準。
  • 安全基線： 重入保護、算術溢位檢查、權限分離、緊急暫停。

選用 Solana 之考量

PFun Store 的獎勵金額細小而發放頻繁，一名用戶可能在單次使用中多次取得 Contract。此一模式使兩項特性成為決定性因素：單筆交易的結算成本，以及結算所需的時間。選用 Solana 即基於此二者。

本文件不引述網絡吞吐量數據。

05

Interoperability and Chain Strategy

Where PFun Store Runs Today

PFun Store's on-chain components are deployed on Solana. Solana was chosen for transaction cost and settlement speed, both of which matter when rewards are small and frequent.

Interoperability

Making DST and PFun Store assets usable on other chains is a planned direction, not a delivered feature. Any bridging would be implemented through established third-party protocols rather than built in-house.

We deliberately do not list target chains or named bridge providers in this document. Naming them before an integration exists creates the impression of a commitment that has not been made. Integrations will be announced when they are built, not before.

A PFun Store Chain

The long-term intention, stated in the opening chapter, is to operate a PFun Store chain of our own. The Solana deployment is the starting point rather than the destination.

This is a direction, not a schedule. Operating a chain is a substantially larger undertaking than operating an application, and it is only justified if the games, the reward economy and the ecosystem reach a scale that requires it. If that scale is not reached, it will not be pursued. We state this here so that it is not left unsaid later.

現階段之部署

PFun Store 之鏈上元件部署於 Solana。選用 Solana 之考量在於交易成本與結算速度——當獎勵金額細小而發放頻繁時，此二項屬決定性因素。

互通性

使 DST 與 PFun Store 資產得以於其他鏈上使用，屬計劃中之方向，並非已交付之功能。任何跨鏈橋接，均將透過成熟之第三方協議實現，而非自行開發。

本文件刻意不列出目標鏈或指名橋接服務商。在整合完成之前即點名，會令人誤以為已作出承諾。各項整合將於建置完成後公布，而非事前公布。

PFun Store 自有公鏈

如首章所述，長遠目標為營運 PFun Store 自有公鏈。Solana 上之部署為起點，而非終點。

此為方向，而非時程。營運一條公鏈，遠較營運一個應用龐大；只有當遊戲、獎勵經濟與生態的規模確實需要自有公鏈時，才會推進。若未達到該規模，則不會勉強推行。本文件於此明確載明，以免日後不了了之。

06

Smart Contracts and Developer Experience

This chapter sets out what a third-party developer can build on PFun Store, which standards apply, and — the part these documents usually omit — what is available today.

What Is Available Today

The contracts described in the previous chapter are deployed on Solana and can be read by anyone. What does not yet exist is a supported integration path.

Capability What it would let a developer do Status
On-chain contracts Read the token, transaction and reward contracts directly from Solana, as anyone can with any deployed program Deployed
Plug-in SDK Write an integration through a client library instead of against the chain by hand Not yet released
GameFi SDK Award PFun Store rewards inside a third-party game Planned
Module submission Propose a new module for the protocol and have the community vote on it Not available; DAO governance is not yet active

Everything below the first row describes design, not a service a developer can use today.

Architecture

Three layers, each described in the previous chapter:

  1. Client layer — mobile application, web dashboard, wallet connection and signing.
  2. Protocol and contract layer — Solana programs for the token, transaction engine, reward distribution, and the modules that are designed but not yet active.
  3. Integration layer — the protocol adapter through which third-party applications will connect. Planned.

Development Stack

The table below covers the parts a developer integrating with PFun Store would need to know.

Category Technology Note
Chain Solana Selected for settlement cost and settlement time; see the previous chapter
Contract language Rust Solana programs
Contract framework Anchor Account structures, IDL generation
Token standard SPL Token and Metaplex Metadata Tokens and NFTs
Interface definition IDL Standard for every protocol module
Wallet Solana Wallet Adapter; Mobile Wallet Adapter on device Phantom, Solflare, Backpack
Client Next.js (web), React Native and Expo (mobile)
Read API REST Account and transaction queries for applications that do not read the chain directly
Asset storage IPFS for on-chain asset metadata

We do not publish the operator's internal server, database, deployment or monitoring infrastructure. None of it is required in order to integrate with PFun Store.

Environments

Phase Network Purpose
Development Devnet Contract development and unit testing
Preview Testnet Module deployment and simulated user testing
Production Mainnet-Beta Live contracts

Planned Integration Model

When the SDK is released, the intended model is as follows. It is stated here so that the design can be assessed; none of it is in operation.

  • A Plug-in SDK in TypeScript and Rust, so that an integration can be written either against the chain directly or through a client library.
  • Every protocol module exposes an IDL, so integrations are written against a published interface rather than against an implementation.
  • An integrated module may define its own fee, verification and permission parameters within the limits the protocol sets.
  • Proposals for new modules will be submitted through community governance once governance is active. Until then, integration is by agreement with the operator.

Security

Contract security, upgrade control and treasury controls are set out in the Security chapter. Two points belong here because they affect anyone considering an integration:

  • Upgrade control. Contract upgrades execute through a timelock with multi-signature approval. Until DAO governance is active, that approval rests with the operator.
  • Independent review. PFun Store's contracts are to be independently reviewed by a third-party security firm, with the report published. This section will carry the firm, the date, the scope and a link to the report once a review is complete.

本章載明第三方開發者可於 PFun Store 之上建構何種應用、適用何種標準，以及現階段實際可用之範圍。

現階段可用範圍

前章所述之合約已部署於 Solana，任何人均可讀取。現階段尚未提供獲正式支援之整合途徑。

項目 開發者可藉此進行之事 狀態
鏈上合約 直接自 Solana 讀取代幣、交易及獎勵各合約，與讀取任何已部署程式無異 已部署
外掛 SDK 透過用戶端程式庫撰寫整合，而非逐項對鏈撰寫 尚未發布
GameFi SDK 於第三方遊戲內發放 PFun Store 獎勵 計劃中
提交模組 向協議提出新模組，並交由社群表決 不適用；DAO 治理尚未啟用

表中首行以外之各項，均屬設計，而非開發者現階段可以使用的服務。

架構分層

分為三層，各層於前章均有說明：

  1. 用戶端層 —— 流動應用程式、網頁儀表板、錢包連接與簽章。
  2. 協議與合約層 —— 代幣、交易引擎、獎勵分配之 Solana 程式，以及已完成設計但尚未啟用之各模組。
  3. 整合層 —— 第三方應用未來接入所經之協議轉接層。計劃中。

開發技術選型

下表所列，為開發者整合 PFun Store 時所需知悉之部分。

類別 技術 說明
公鏈 Solana 基於結算成本與結算時間而選用，詳見前章
合約語言 Rust Solana 程式
合約框架 Anchor 帳戶結構、IDL 生成
代幣標準 SPL Token 與 Metaplex Metadata 代幣與 NFT
介面定義 IDL 各協議模組之統一標準
錢包 Solana Wallet Adapter；流動裝置採 Mobile Wallet Adapter Phantom、Solflare、Backpack
用戶端 Next.js（網頁）、React Native 與 Expo（流動裝置）
讀取介面 REST 供不直接讀取鏈上資料之應用查詢帳戶與交易
資產儲存 鏈上資產之 metadata 採用 IPFS

本文件不公布營運方之內部伺服器、資料庫、部署及監控架構。該等內容並非整合 PFun Store 之所需。

環境

階段 網絡 用途
開發 Devnet 合約開發與單元測試
預覽 Testnet 模組部署與模擬用戶測試
正式 Mainnet-Beta 正式運作之合約

整合模式（計劃中）

以下為 SDK 發布後之預定模式。於此載明，以供評估；現階段並無任何一項正在運作。

  • 提供 TypeScript 與 Rust 兩種外掛 SDK，使整合方得以直接對鏈撰寫，或透過用戶端程式庫撰寫。
  • 各協議模組均提供 IDL，使整合對象為已公布之介面，而非某一特定實作。
  • 已整合之模組，得於協議所設限度內，自行定義其費用、驗證及權限參數。
  • 新模組之提案，將於治理啟用後經社群治理提交。在此之前，整合須與營運方另行協議。

安全

合約安全、升級控制及金庫控制，均載於安全章節。以下兩點與考慮整合者直接相關，故於此陳述：

  • 升級控制。 合約升級須經時間鎖並取得多重簽名批准後執行。在 DAO 治理啟用之前，該項批准權由營運方掌理。
  • 獨立審核。 PFun Store 之合約將交由第三方安全機構進行獨立審核，並公布報告。俟審核完成後，本節將載明機構名稱、日期、審核範圍，並附上報告連結。
07

Tokenomics and Fee Model

Changing the Token's Economic Model via DAO Voting Proposals

Token Functions and Use Cases

Token Utility

DST is the core token of PFun Store, designed for multi-functionality and ecosystem integration:

Token Use Case Corresponding Technical Module Specific Implementation Mechanism Description
Governance DAO Governance Module Implements proposal voting via SPL Governance Participates in DAO proposals, voting, and resource allocation decisions.
Staking Staking Module veDST model, lock-up duration determines weight Locking up DST earns rewards and governance weight (supports ve-model).
Reward Redemption Reward Distribution Module Contracts earned in the application are redeemed for DST from the redemption reserve Contracts are funded by advertising revenue; redemption is the point at which a player receives DST.
Ecosystem Payment On-chain Transaction Engine Pays transaction fees and resource purchases Pays on-chain transaction fees, purchases resources, module usage licenses, etc.
Functional Threshold Protocol Integration Module Staking DST to gain access to advanced features Proposing, deploying protocols, or gaining access to advanced features may require staking or holding DST.

Supply, Distribution, and Release Token Information

Item Information
Token Name DST Token
Protocol Code DST
Blockchain Platform Initially deployed on Solana Mainnet
Supply 6,000,000,000 DST (6 billion, initial total supply)
Supply Model Total supply ceiling is tentatively set at 6 billion, with no continuous inflation mechanism. Future adjustments, if needed, will be decided through DAO governance proposals and community voting, and publicly announced and executed upon approval.

Distribution Ratio

代幣經濟模型之變更，須經 DAO 投票提案處理。

代幣功能與應用場景

代幣效用

DST 為 PFun Store 之核心代幣，其設計兼顧多重功能與生態整合：

代幣用途 對應技術模組 具體實作機制 說明
治理 DAO 治理模組 經 SPL Governance 實現提案表決 參與 DAO 提案、表決及資源分配決策。
質押 質押模組 veDST 模型，鎖倉期間決定權重 鎖倉 DST 可取得獎勵及治理權重（支援 ve 模型）。
獎勵兌換 獎勵分配模組 於應用內取得之 Contract，可向兌換儲備池兌換 DST Contract 由廣告收入支應；兌換即玩家取得 DST 之環節。
生態支付 鏈上交易引擎 支付交易費用及資源購買 支付鏈上交易費用、購買資源、模組使用授權等。
功能門檻 協議整合模組 質押 DST 以取得進階功能之使用權 提案、部署協議或使用進階功能，可能須質押或持有 DST。

供應、分配與釋放

項目 內容
代幣名稱 DST Token
協議代號 DST
區塊鏈平台 初期部署於 Solana 主網
供應量 6,000,000,000 DST（60 億，初始總供應量）
供應模型 總供應量上限暫定為 60 億，並無持續通脹機制。日後如有調整需要，須經 DAO 治理提案及社群投票決定，通過後公告並執行。

分配比例

6,000,000,000DST · TOTAL SUPPLY
12%Ecosystem developmentDAO treasury for proposal funding
5%Reserve fundSecurity incidents and market shocks
3%AdvisorsProfessional and strategic support
25%InvestorsPrivate and public rounds, unlocked in rounds
25%Team / founders4-year vesting, 12-month cliff; no voting rights while locked
30%Ecosystem reward poolPlayer rewards, GameFi titles and the creator platform1,800,000,000 DST
6,000,000,000 DST · TOTAL SUPPLY 25% Team / founders 4-year vesting, 12-month cliff; no voting rights while locked 30% Ecosystem reward pool Player rewards, GameFi titles and the creator platform 1,800,000,000 DST 3% Advisors Professional and strategic support 25% Investors Private and public rounds, unlocked in rounds 12% Ecosystem development DAO treasury for proposal funding 5% Reserve fund Security incidents and market shocks
Figure 4 — DST distribution by allocation.

Vesting and Unlocking Mechanism (Vesting)

Allocated tokens do not arrive at once. Each allocation has a cliff — a period at the start during which nothing at all unlocks — followed by a linear release period, over which the remainder unlocks gradually rather than in a single tranche. A 12-month cliff with a 36-month linear release means nothing for the first year, then a steady release across the three years that follow.

The purpose is to keep the people who built the project holding it long enough to be affected by how it turns out.

Category Cliff Linear Release Period Unlocking Method and Governance Restrictions
Team / Founders 12 months 36 months 4 years total, no voting rights for locked tokens
Private Investors 12–18 months 12–18 months Unlocked in rounds, progress announced periodically
Advisors 6 months 12–18 months Tied to task contributions and advisor contract terms
Community / DAO None DAO determined release Controlled by multi-signature + community governance voting

Public Offering and Reserve Funds (Vesting)

Category Total Share Release Plan Unlocking Method and Governance Restrictions
Public Offering (IDO) 0–20% TGE Remaining proportion (80–100%) linear release within 3-6 months Can set instant release cap + dynamic announcements
Reserve Fund Activated as needed Activated as needed Used for rapid response and repair funds in case of protocol security vulnerabilities, market shocks, or critical infrastructure failures.

Note: TGE (Token Generation Event) refers to the time point when tokens are first generated and can be distributed, typically the beginning of the project's official token issuance phase. TGE is not equivalent to exchange listing but often occurs close to or concurrently with it.

Staking and Slashing Mechanism

Adopts the veDST staking model:

  • The longer the lock-up period, the higher the governance weight and staking yield.
  • Supports dynamic lock-up extension and weight stacking.
  • No general slashing rules are set; governance-related restrictions are based on unlock status and task completion.

Contracts and the Ecosystem Reward Pool

Players earn Contracts, not DST. Contracts are funded by advertising revenue, as set out in the revenue chapter.

Contracts may be redeemed for DST. That DST comes from the ecosystem reward pool — the 30% allocation, 1,800,000,000 DST. The pool is the ceiling on everything PFun Store can ever pay out as rewards anywhere in the ecosystem. It is not an emission schedule: nothing is released on a calendar, and there is no halving mechanism. DST leaves the pool only when a product in the ecosystem pays a reward out of it.

The games are the pool's first draw, not its only one.

What draws on the pool What the reward is for Status
PFun Store's own games Players redeem Contracts they earned by playing Live
Third-party GameFi titles Rewards inside games built on the PFun Store SDK Planned
Creator platform Rewards for creators and for the audience they bring Planned

Two Separate Limits

Two limits govern rewards, and they constrain different things. Reading them as one is the easiest way to misunderstand the model.

The token limit. 1,800,000,000 DST is all there will ever be for rewards. Once the pool is spent, no more DST is created to refill it — doing so would be a change to the supply model, which the section above places under DAO governance.

The business limit. In any given period, PFun Store hands out only as many Contracts as that period's advertising revenue pays for. Earn more from advertisers and more Contracts can be issued; earn less and fewer are. Contracts are never issued against revenue that has not arrived.

The second limit is the one that does the work day to day. The pool sets how much can ever be paid out; advertising revenue sets how fast it is paid out. Token release cannot run ahead of the business.

The pool is not replenished. PFun Store does not purchase DST to refill it. DST that PFun Store buys back is burned; it does not return to the pool.

The conversion rate from Contracts to DST, the redemption minimum and fees, and how the pool is divided between the three products above will be published separately.

Earning Contracts requires no purchase and no deposit. Redemption converts a reward already earned; it is not a subscription, an investment, or a return on capital.

Governance of the Supply Model

  • The redemption reserve is a ceiling on what may be released for redemption, not a commitment to release it.
  • Any change to the total supply, the size of the reserve, or the conversion rate is a change to the token's economic model. The supply model section above states that such changes are subject to DAO governance. DAO governance is not yet active; until it is, these decisions rest with the operator, as set out in the opening chapter.
  • Changes to the conversion rate will be announced before they take effect.

Ecosystem Application Scenarios and Value Flow Path

PFun Store is not just a set of protocols and a token mechanism; it is an open and extensible on-chain value network. Through the design of the DST Token and its modular protocol architecture, various roles such as creators, players, protocol developers, and contributors can participate, forming a tangible flow of value.

The scenarios below describe how the token is designed to move between participants. Apart from players earning rewards, none of them is in operation today; the module status table in the architecture chapter states which components are live.

GameFi Application Scenarios

Participant Action DST Value Flow Corresponding Module
Players Play games; Quests and rewarded video yield accelerators Play produces Contracts, redeemable for DST from the redemption reserve Reward Distribution Module
Game Developers Deploy game protocols Require staking DST to use game modules and tools Protocol Integration Module
Guilds / Referrers Refer users to participate Earn DST based on the activity of referred users Referral Incentive Module (not yet active)

PFun Store will provide a GameFi SDK, enabling third-party developers to quickly integrate DST-driven reward and governance modules.

Content Platform and Creator Economy

Participant Action DST Value Flow Corresponding Module
Creators Publish creative content Can receive DST as support and transaction returns On-chain Transaction Engine / NFT Module
Supporters Tip / purchase creative content Pay DST to support creators Ecosystem Payment Module
Content Platform Providers Integrate creator protocols Require staking DST to qualify for module usage Protocol Integration Module

PFun Store supports "content as an asset," allowing creators to put their works on-chain and customize NFT sales and licensing rules.

Value Flow Characteristics of PFun Store

  • Multi-role Interaction Design: Creators, players and developers can all contribute and benefit.
  • Modules as Economic Interfaces: Each module serves as a value inflow point and exchange arena.
  • Token Flow Closed Loop: The acquisition, consumption, staking, and governance of DST form a positive cycle.
  • Contribution as Value: Creation, participation and time are all forms of contribution the protocol can recognise.

鎖倉與解鎖機制（Vesting）

已分配之代幣並非一次到手。各項配額均設有 Cliff（禁售期）——即起始一段期間內完全不解鎖——其後方進入線性釋放期，餘額於該期間內逐步解鎖，而非一次過釋出。所謂 12 個月 Cliff 加 36 個月線性釋放，即首年完全不解鎖，其後三年內平穩釋出。

此項安排之目的，是讓建設本項目之人長期持有代幣，與項目之成敗共同承擔。

類別 Cliff 線性釋放期 解鎖方式與治理限制
團隊／創辦人 12 個月 36 個月 合共 4 年；鎖倉期間之代幣無投票權
私募投資者 12–18 個月 12–18 個月 分輪解鎖，定期公布進度
顧問 6 個月 12–18 個月 與任務貢獻及顧問合約條款掛鈎
社群／DAO 無 由 DAO 決定釋放 由多重簽名 ＋ 社群治理投票控制

公開發售與儲備基金（Vesting）

類別 總份額 釋放計劃 解鎖方式與治理限制
公開發售（IDO） TGE 時 0–20% 餘下部分（80–100%）於 3–6 個月內線性釋放 可設即時釋放上限 ＋ 動態公告
儲備基金 按需啟動 按需啟動 用於協議安全漏洞、市場衝擊或關鍵基礎設施故障時之快速應對與修復資金。

註： TGE（Token Generation Event，代幣生成事件）指代幣首次生成並可供分配之時點，通常為項目正式進入代幣發行階段之始。TGE 並不等同於交易所上市，惟二者時間往往相近或同步發生。

質押與罰沒機制

採用 veDST 質押模型：

  • 鎖倉期間愈長，治理權重及質押收益愈高。
  • 支援動態延長鎖倉期及權重疊加。
  • 並未設定一般性之罰沒規則；與治理相關之限制，係以解鎖狀態及任務完成情況為依據。

Contract 與生態獎勵池

玩家所取得者為 Contract，而非 DST。Contract 由廣告收入支應，詳見收入章節。

Contract 可兌換為 DST。該等 DST 來自生態獎勵池——即 30% 配額，1,800,000,000 DST。該池為 PFun Store 於整個生態中所能發放之獎勵總量上限。此非增發時間表：不會有任何代幣按日曆釋出，亦無減半機制。DST 僅於生態中某一產品自該池支付獎勵時方會離開。

自家遊戲為該池之首個動用者，而非唯一動用者。

動用該池之項目 獎勵所對應之行為 狀態
PFun Store 自家遊戲 玩家兌換其因遊玩而取得之 Contract 已運作
第三方 GameFi 遊戲 於採用 PFun Store SDK 建構之遊戲內發放之獎勵 計劃中
創作者平台 向創作者及其所帶來之受眾發放之獎勵 計劃中

兩重各自獨立之上限

獎勵受兩重上限規範，二者所約束之事項並不相同，不宜混淆。

代幣面之上限。 可用於獎勵者，最終以 1,800,000,000 DST 為限。該池用罄後，不會另行增發 DST 予以補充；如需補充，即屬變更供應模型，而上節已載明該等變更須經 DAO 治理。

營運面之上限。 於任一期間內，PFun Store 所發放之 Contract 數量，以該期間廣告收入所能支應者為限。廣告收入增加，可發行之 Contract 隨之增加；收入減少則相應減少。本協議不會以尚未取得之收入為基礎預先發行 Contract。

日常真正發揮作用者為第二項。該池決定最多可以發放多少，廣告收入則決定發放的速度。 代幣釋放不會快於業務本身之增長。

該池不予補充。 PFun Store 不會購入 DST 以補充該池；PFun Store 所回購之 DST 一律銷毀，不會回流該池。

Contract 兌換 DST 之比率、兌換門檻與手續費，以及該池於上述三個產品之間之分配，將另行公布。

取得 Contract 無須任何購買，亦無須任何入金。兌換僅係將已取得之獎勵予以轉換，並非訂閱、投資，亦非資本回報。

供應模型之治理

  • 兌換儲備池係可供兌換釋放之上限，而非釋放之承諾。
  • 總供應量、儲備池規模或兌換比率之任何變更，均屬代幣經濟模型之變更。上文供應模型一節載明，該等變更須經 DAO 治理。DAO 治理尚未啟用；在其啟用之前，上述決定由營運方掌理，詳見首章。
  • 兌換比率之變更，將於生效前予以公告。

生態應用場景與價值流動路徑

PFun Store 不僅為一組協議與代幣機制，更係一個開放而可擴展之鏈上價值網絡。透過 DST Token 之設計及其模組化協議架構，創作者、玩家、協議開發者及貢獻者等不同角色均可參與其中，形成具體之價值流動。

以下場景描述代幣在參與者之間的設計流向。除玩家取得獎勵外，現階段並無任何一項正在運作；各模組之運作狀態載於架構章節之模組表。

GameFi 應用場景

參與者 行為 DST 價值流向 對應模組
玩家 遊玩遊戲；任務與獎勵式影片產生加速器 遊玩產生 Contract，可向兌換儲備池兌換 DST 獎勵分配模組
遊戲開發者 部署遊戲協議 須質押 DST 方可使用遊戲模組及工具 協議整合模組
公會／推薦人 推薦用戶參與 按所推薦用戶之活躍度取得 DST 推薦獎勵模組（尚未啟用）

PFun Store 將提供 GameFi SDK，使第三方開發者得以快速整合以 DST 驅動之獎勵與治理模組。

內容平台與創作者經濟

參與者 行為 DST 價值流向 對應模組
創作者 發佈創作內容 可取得 DST 作為支持及交易收益 鏈上交易引擎／NFT 模組
支持者 打賞／購買創作內容 支付 DST 以支持創作者 生態支付模組
內容平台方 整合創作者協議 須質押 DST 方具備使用模組之資格 協議整合模組

PFun Store 支援「內容即資產」，使創作者得以將其作品上鏈，並自訂 NFT 之銷售與授權規則。

PFun Store 之價值流動特徵

  • 多角色互動設計： 創作者、玩家與開發者均可貢獻並從中受益。
  • 模組即經濟介面： 各模組均為價值流入之節點與交換之場域。
  • 代幣流動閉環： DST 之取得、消耗、質押與治理，構成一個正向循環。
  • 貢獻即價值： 創作、參與與時間，均屬協議可予識別之貢獻形式。
08

Governance and Forkless Upgrades

DAO governance is not operating. This chapter states who decides today, describes the governance model that has been designed, and explains how protocol upgrades are executed in the meantime.

Governance Today

All decisions that the designed model would place with the DAO currently rest with the operator. That includes treasury allocation, community release schedules, the rate at which Contracts redeem for DST, any change to the supply model, contract upgrades, and which modules are integrated.

There is no community vote at present, and no proposal may currently be submitted on-chain. The transfer of these powers is a future event, not a present condition.

Forkless Upgrades

Protocol changes on PFun Store do not require a chain fork. The contracts are Solana programs, and a program is changed by deploying a new version under the control of an upgrade authority; the chain itself is unaffected, and no user action is required.

This makes the upgrade authority the most consequential control in the system. Whoever holds it can replace the running code, and with it the rules that govern balances, rewards and lock-ups. It is held as follows:

Control What it allows Who holds it today Designed position
Upgrade authority Replacing the running contract code The operator, and only with several key-holders signing The DAO, executing an approved proposal
Timelock before execution A waiting period between approval and execution, during which the change is visible and can be reversed The operator A fixed delay, published in advance
Emergency pause Halting contract operations without waiting for a vote The operator The operator, with the DAO reviewing the decision afterwards

The ability to upgrade without a fork is both a convenience and a risk for users: the rules can change without their participation. This document therefore states who holds that authority today before describing the voting model that is not yet in force.

The Designed Model

Everything in this section is design. None of it is in operation.

Principles

  • Governance weight is earned by locking tokens for a period, not by holding a balance.
  • Treasury expenditure is proposed, voted on, and recorded on-chain.
  • No single address may control the outcome; weight is capped.
  • Proposals pass through review before reaching an on-chain vote.

veDST weight

Voting weight is not the number of tokens held. It is the number of tokens locked, multiplied by a coefficient set by how long they are locked for. Locking the same amount for longer produces more weight: 1,000 DST locked for 24 months carries six times the weight of 1,000 DST locked for one month.

The effect is that influence is bought with time rather than with size, and anyone voting on a decision is still holding tokens when its consequences arrive.

Lock-up period Weight per 1,000 DST locked What the holder may propose Cap on a single address
1 month 250 Nothing; may vote only 2% of total weight
3 months 500 Proposals limited in scope 3%
12 months 1,000 Proposals affecting the whole protocol 4%
24 months 1,500 Requests to spend from the treasury 5%

Two design decisions are worth stating explicitly. Governance participation earns no reward, so there is no incentive to vote purely to farm returns. And the cap applies to weight rather than to holdings, so accumulating tokens beyond the cap confers no additional control through this mechanism.

Proposal process

Phase Action
1. Draft Proposal published for discussion, stating objective, budget and expected impact
2. Review Filtering of duplicate and spam proposals before an on-chain vote is opened
3. Vote Proposal goes on-chain; passes on reaching both turnout and approval thresholds
4. Delay Approved proposals wait out a timelock before execution
5. Execution and tracking Execution recorded on-chain; a proposal may be amended or reversed by a subsequent vote

The review stage in phase 2 is a filter held by a review body, not an automatic process.

The turnout threshold, the approval ratio, the minimum weight to submit a proposal, and the length of the timelock will be published before DAO governance is activated.

Treasury

Item Position
Sources Unallocated DST, reclaimed allocations, and protocol fees once fee-bearing modules are active. Operating revenue from advertising is described in the revenue chapter and is not treasury income.
Uses Ecosystem grants, developer subsidies, events, liquidity provision
Control Multi-signature execution; DAO approval once governance is active, operator approval until then
Reporting Prepared by the operator; published by the DAO once governance is active

Tooling

The on-chain governance program is SPL Governance, the Solana standard for proposals and weighted voting. Front-end and discussion platforms will be selected at the time governance is launched; this document does not name vendors in advance.

What We Are Not Claiming

We do not list further governance features — sub-DAOs, reputation systems, cross-organisation alliances — while the first vote has not yet been held. Those belong in a document written after governance is running, not before it has started.

DAO 治理尚未運作。本章載明現階段之決策主體、已完成設計之治理模式，以及在治理啟用之前，協議升級如何執行。

現階段之治理

凡設計模式中原應由 DAO 決定之事項，現階段均由營運方決定，包括金庫分配、社群釋出時程、Contract 兌換 DST 之比率、供應模型之任何變更、合約升級，以及模組之整合取捨。

現階段並無社群投票，亦無任何提案可於鏈上提交。上述權力之移轉，屬未來事件，而非現時狀態。

無分叉升級

PFun Store 之協議變更無須進行鏈上分叉。各合約為 Solana 程式，程式之變更係由升級權限持有人部署新版本達成，公鏈本身不受影響，用戶亦無須採取任何行動。

正因如此，升級權限乃全系統中最具決定性之控制權。持有該權限者，可替換正在運行之程式碼，連帶替換規管餘額、獎勵與鎖倉之各項規則。其歸屬如下：

控制項 該權限可作之事 現由何方持有 設計目標
升級權限 替換正在運行之合約程式碼 營運方，且須多名金鑰持有人共同簽署 DAO，用以執行已通過之提案
執行前時間鎖 於批准與執行之間設置等候期，期內變更內容公開可見，並可予撤回 營運方 固定延遲時間，並事先公布
緊急暫停 無須等候表決即可中止合約運作 營運方 營運方執行，事後由 DAO 覆核該決定

無須分叉即可升級，對用戶既是便利，亦是風險：規則可在用戶未參與之情況下改變。因此本文件先載明該權限現由何人持有，再描述尚未啟用之投票模式。

已設計之治理模式

本節全部內容均屬設計，現階段並無任何一項正在運作。

原則

  • 治理權重取得自鎖倉期間，而非持幣餘額。
  • 金庫支出須經提案、表決，並於鏈上留存紀錄。
  • 任何單一地址均不得單獨左右表決結果，其權重設有上限。
  • 提案須先經覆核，方可進入鏈上表決。

veDST 權重

投票權重並非持幣數量，而係鎖倉數量乘以一個係數，該係數由鎖倉期間長短決定。同一數量鎖得愈久，所得權重愈高：1,000 DST 鎖倉 24 個月，其權重為同樣 1,000 DST 鎖倉 1 個月之六倍。

其效果是：影響力以鎖倉時間換取，而非以資金規模換取；參與表決者在決定產生後果時，仍然持有代幣。

鎖倉期間 每鎖倉 1,000 DST 所得權重 可提出之提案 單一地址權重上限
1 個月 250 不可提案，僅可投票 總權重之 2%
3 個月 500 範圍受限之提案 3%
12 個月 1,000 涉及整個協議之提案 4%
24 個月 1,500 動用金庫之支出申請 5%

其中兩項設計取向值得明白指出。其一，參與治理本身不產生獎勵，故不存在純為套取收益而投票之誘因。其二，上限係針對權重而非持幣量，故持幣超出上限並不因此機制而取得額外控制力。

提案流程

階段 內容
一、草擬 公布提案供討論，載明目標、預算及預期影響
二、覆核 於開啟鏈上表決前，過濾重複及濫發之提案
三、表決 提案上鏈；須同時達到投票率與贊成比例門檻方為通過
四、延遲 通過之提案須待時間鎖屆滿方可執行
五、執行與追蹤 執行結果於鏈上留存紀錄；提案得經其後之表決修訂或撤銷

第二階段之覆核由覆核主體人手進行，並非自動程序。

投票率門檻、贊成比例、提交提案所需之最低權重，以及時間鎖長度，將於 DAO 治理啟用前公布。

金庫

項目 內容
來源 未分配之 DST、回收之配額，以及收費模組啟用後所產生之協議費用。廣告所得之營運收入詳見收入章節，並不計入金庫收入。
用途 生態資助、開發者補貼、活動、流動性提供
控制 以多重簽名執行；治理啟用後須經 DAO 批准，在此之前由營運方批准
申報 由營運方編製；DAO 治理啟用後轉由 DAO 公布

工具

鏈上治理程式採用 SPL Governance，即 Solana 上提案與加權表決之標準。前端介面與討論平台，將於治理啟用時一併選定；本文件不預先指名服務商。

本章不作之聲稱

在首次表決舉行之前，本文件不列出其他治理功能（子 DAO、聲譽制度、跨組織聯盟等）。該等內容應於治理實際運作後方予載明。

09

Security Model and Risk Control

Security in PFun Store has three separate parts, and they fail in different ways.

The contracts can be attacked directly. The reward system can be farmed by users who never intended to play. And user data can be over-collected or mishandled. Documents of this kind usually cover only the first. For a product that pays people for their attention, the second is where the practical risk sits, and the third is where the regulatory risk sits.

1. Contract Security

Control Design Status
Upgrade control Upgrades execute through a timelock with multi-signature approval Active; authority held by the operator
Emergency pause Pause permissions restricted to multi-signature addresses Planned
Re-entrancy protection Program structure and state locking in the Solana program Active
Arithmetic overflow Rust checked arithmetic on all value operations Active
Privilege separation Administrator and user permissions separated; least privilege Active
Event logging Critical operations emit on-chain events for tracing Active
Independent review Third-party security review of the contracts, report published Planned

On the last row: contracts are to be reviewed by an independent third-party security firm, and the report published. This section will name the firm, the date and the scope of the review, and link the report, once one is complete.

2. Reward Abuse

Any system that pays users for actions will be attacked by people automating those actions. This is the most likely attack on PFun Store, and it is an economic attack rather than a technical one: it does not break anything, it simply drains the reward budget and degrades the quality of the traffic sold to advertisers.

The forms it takes:

Attack Effect
Multi-accounting One person operating many accounts to multiply rewards
Idle farming A session left open on an unattended device, or many emulator instances, accruing progress without play
Emulators and automation Scripted play and scripted Quest completion without a real user
Ad fraud Fabricated ad impressions or completions, which advertisers claw back
Referral farming Self-referral rings that generate rewards without new users
Reward arbitrage Extracting rewards at a rate the advertising revenue cannot fund

Two structural defences are worth stating, because they are design decisions rather than detection rules:

  • Rewards are funded by advertising revenue, not by token issuance. A farming attack therefore competes against a revenue-linked budget rather than an open faucet. This is described in the revenue chapter.
  • Advertiser verification is external. Where a Quest is supplied by an advertising partner, completion is confirmed by that partner before a reward is released, which places a second party between the user and the payout.
  • Progress requires play, not time. A Contract is produced by a progress meter that advances on level progress, valid rounds and registered input. Elapsed time alone advances nothing, so an idle session or an emulator left running produces no reward. See the revenue chapter.

We do not publish detection thresholds, device-signal logic or scoring rules. Once published, they would no longer work.

3. Client and Backend Security

Area Measure
Wallet Connection only through the Solana Wallet Adapter standard; fixed signature message templates; source domain binding
Signing Expiry times on signature requests, phishing-contract flagging, risk prompts on unusual requests
Administrative access Role-based access control and multi-party approval on privileged operations
Keys Non-custodial; multi-signature and whitelisted addresses for operator-held keys

The SDK described in the developer chapter has not been released. Statements about SDK security belong in this document once it exists.

4. Governance Risk

Governance is not active, so the governance attack surface is currently the operator's own controls, described in the governance chapter. The designed protections — a minimum weight to submit a proposal, a cap on single-address weight, a voting delay and a timelock before execution — take effect only when governance launches.

5. User Data

The authoritative statement of what PFun Store collects is the published Privacy Policy, not this document. This chapter does not restate it, and where the two differ the Privacy Policy governs.

6. Compliance

Risk disclosure, jurisdictional restrictions and the limits of this document are set out in the Legal and Risk Disclaimer chapter. Three positions belong here:

Area Position
Token character DST is a functional token. It does not represent equity, a yield entitlement, or an investment commitment.
KYC and AML Identity verification at redemption is carried out independently by a regulated third-party verification provider. The jurisdictions in scope and the applicable thresholds follow local law.
Jurisdictions Promotion and participation are restricted in jurisdictions that prohibit or restrict crypto assets. See the Legal and Risk Disclaimer chapter.

PFun Store 之安全可分為三個互不相同的部分，其失效方式亦各異。

合約可能遭受直接攻擊；獎勵機制可能遭無意遊玩者刷取；用戶資料則可能被過度收集或處理不當。同類文件通常只涵蓋第一項；但對於一項向用戶注意力付酬之產品，第二項才是實際之營運風險，第三項則是監管風險。

一、合約安全

控制項 設計 狀態
升級控制 升級須經時間鎖並取得多重簽名批准後執行 已運作；權限由營運方持有
緊急暫停 暫停權限僅限多重簽名地址 計劃中
重入保護 Solana 程式之結構設計與狀態鎖定 已運作
算術溢位 所有數值運算採用 Rust 之檢查型算術 已運作
權限分離 管理者與用戶權限分離，遵循最小權限原則 已運作
事件日誌 關鍵操作發出鏈上事件以供追溯 已運作
獨立審核 合約交由第三方安全機構審核，並公布報告 計劃中

就最後一行補充說明：合約將交由第三方安全機構進行獨立審核，並公布報告。俟審核完成後，本節將載明機構名稱、日期、審核範圍，並附上報告連結。

二、獎勵濫用

凡因用戶行為而發放獎勵之系統，必然遭到自動化該等行為者之攻擊。此為 PFun Store 最可能面對之攻擊，且屬經濟性攻擊而非技術性攻擊：其並未破壞任何事物，僅係耗盡獎勵預算，並使售予廣告商之流量質素下降。

其常見形態如下：

攻擊形態 影響
多重帳戶 一人操作多個帳戶以倍增獎勵
閒置刷取 於無人操作之裝置持續開啟連線，或同時運行多個模擬器實例，藉以累積進度
模擬器與自動化 以腳本代替真實用戶進行遊玩及完成任務
廣告作弊 偽造廣告展示或完成紀錄，其後遭廣告商追討
推薦刷量 以自我推薦鏈產生獎勵，而未帶來新用戶
獎勵套利 以廣告收入無法支應之速率提取獎勵

其中兩項結構性防線值得載明，因其屬設計取向，而非偵測規則：

  • 獎勵由廣告收入支應，而非由代幣增發支應。 故刷取行為所面對者，為一個與收入掛鈎的預算，而非一個無限制的發放來源。詳見收入章節。
  • 廣告任務之完成由外部核實。 凡由廣告夥伴提供之任務，須經該夥伴確認完成後方予發放獎勵，即在用戶與獎勵之間置入第二方。
  • 進度取決於遊玩，而非時間。 Contract 由進度條產生，而進度條只會因過關、完成有效回合及已記錄之操作而上升；單純經過時間不會令進度條上升，故閒置連線或持續運行之模擬器均無法取得獎勵。詳見收入章節。

本文件不公布偵測門檻、裝置訊號邏輯或評分規則。一經公布，該等措施即告失效。

三、用戶端與後端安全

範圍 措施
錢包 僅經 Solana Wallet Adapter 標準連接；固定簽章訊息範本；來源網域綁定
簽章 簽章請求設有效期限、釣魚合約標記、異常請求風險提示
管理權限 特權操作採角色權限控制及多方批准
金鑰 非託管；營運方持有之金鑰採多重簽名及白名單地址

開發者章節所述之 SDK 尚未發布。有關 SDK 安全性之陳述，應待其存在之後方載入本文件。

四、治理風險

治理尚未啟用，故現階段之治理攻擊面即為營運方自身之控制措施，詳見治理章節。已設計之各項防護——提交提案所需之最低權重、單一地址權重上限、投票延遲，以及執行前之時間鎖——均須待治理正式啟用後方始生效。

五、用戶資料

有關 PFun Store 收集何種資料，以已公布之《私隱政策》為準，而非本文件。 本章不予複述；二者如有歧異，概以《私隱政策》為準。

六、合規

風險披露、司法管轄區限制及本文件之效力範圍，均載於法律與風險聲明章節。以下三項應於此陳述：

範圍 立場
代幣性質 DST 為功能型代幣，不代表股權、收益權，亦不構成任何投資承諾。
KYC 與 AML 兌換時之身分核實，交由受監管之第三方核實機構獨立執行。適用之司法管轄區及門檻，依所在地法律而定。
司法管轄區 於禁止或限制加密資產之司法管轄區，推廣與參與均受限制。詳見法律與風險聲明章節。
10

Ecosystem and Contribution Model

How PFun Store recognises the different ways people contribute, and which of those mechanisms are operating today.

The commercial model — where the money comes from and how it is shared — is set out in the revenue chapter and is not repeated here.

Participant Roles

Role What they do What they receive Status
Players Play the games, complete Quests, refer others Contracts, funded by advertising revenue Live
Stakers Lock DST for a fixed period Governance weight under the veDST model Not yet active
Developers Build modules and integrations on the protocol Grants from the DAO treasury Not available; the SDK has not been released
Contributors Translation, documentation, community operations Grants from the DAO treasury Not available; DAO governance not yet active

Only the first row is in operation. The rest describe roles the protocol is designed to support once the corresponding modules are active.

PFun Store does not operate a node network, and no role in this ecosystem involves contributing hardware, bandwidth, storage or compute.

Staking and Governance Weight

DST locked for a fixed period produces veDST, which determines governance weight. The lock-up periods, coefficients and limits are set out in the governance chapter and are not repeated here.

Beyond voting, veDST is designed to influence priority of access to protocol modules and weighting in periodic distributions. veDST is non-transferable during the lock-up period.

The staking module is not yet active.

Builder Grants

The DAO treasury is intended to reserve a share of DST for grants to those building on the protocol, in three categories:

  • Module development — for developers deploying modules and integrations, assessed on usage.
  • Documentation and educational content — for those producing written material, translations and video.
  • Regional community programmes — for organisers running localised community and educational activity.

Until DAO governance is active, allocation decisions rest with the operator, as set out in the governance chapter. No grant programme is currently open for applications.

本章載明 PFun Store 如何看待各類參與者的貢獻，以及其中哪些機制已實際運作。

至於商業模式——收入來源及其分配方式——已載於收入章節，本章不予複述。

參與者角色

角色 行為 所得 狀態
玩家 遊玩遊戲、完成任務、推薦他人 Contract，由廣告收入支應 已運作
質押者 將 DST 鎖倉一定期間 veDST 模型下之治理權重 尚未啟用
開發者 於協議之上建構模組與整合 來自 DAO 金庫之資助 不適用；SDK 尚未發布
貢獻者 翻譯、文件、社群營運 來自 DAO 金庫之資助 不適用；DAO 治理尚未啟用

現階段僅首行處於運作狀態。其餘各項所描述者，為協議於相應模組啟用後所設計支援之角色。

PFun Store 並不營運節點網絡，本生態中亦無任何角色涉及提供硬件、頻寬、儲存空間或運算資源。

質押與治理權重

鎖倉一定期間之 DST 可產生 veDST，並據以決定治理權重。鎖倉期間、係數及各項上限均載於治理章節，本章不予複述。

除投票之外，veDST 於設計上亦影響協議模組之優先使用權，以及定期發放之加權比重。veDST 於鎖倉期間內不可轉讓。

質押模組尚未啟用。

建設者資助

DAO 金庫擬預留一定比例之 DST，用以資助於協議之上進行建設者，分為三類：

  • 模組開發 —— 供部署模組及整合之開發者申請，按使用情況評估。
  • 文件與教育內容 —— 供製作文字材料、翻譯及影片者申請。
  • 地區社群計劃 —— 供籌辦本地化社群及教育活動之組織者申請。

在 DAO 治理啟用之前，分配決定權由營運方掌理，詳見治理章節。現階段並無任何資助計劃開放申請。

11

Roadmap and Milestones

How to Read This

This roadmap states what is running, what is being built next, and what is a direction rather than a plan. It does not attach dates to items that do not yet exist.

An item moves from one column to the next only when it is live; the module status table in the architecture chapter is updated at the same time.

本章閱讀方式

本路線圖載明何者已在運作、何者為下一步建設、何者僅屬方向而非計劃。本文件不為尚未存在之項目標註日期。

項目須待實際運作，方由一欄移至另一欄；架構章節之模組狀態表亦會同時更新。

Games
Contracts
Rewarded video
Quests
On-chain
Mobile app
Creator platform
GameFi SDK
Staking · veDST
DAO governance
Cross-chain
PFun Store chain
PFun Store CHAINA CHAIN OF OUR OWN · DIRECTION
DSTthe ecosystem token

01 · NOW

Operating today

Games, Contracts, rewarded video, Quests, and the on-chain contracts on Solana are live. The inner orbit is what a player can use today.

02 · NEXT

In progress, in parallel

Mobile application, creator platform, GameFi SDK, staking, DAO governance and cross-chain interoperability. No fixed order; no dates until an item is live.

03 · LATER

A chain of our own

Solana is the starting point, not the destination. A PFun Store chain is a stated long-term direction with no timeline. It will be pursued only when the scale of the ecosystem requires it.

04 · THE SYSTEM

Three orbits, one rule

Inner orbit: live today. Middle orbit: in progress. Outer orbit: long-term direction. An item moves to the inner orbit only after it is live. No dates are set.

NOW NEXT LATER 01 · NOW Operating today Games · Contracts Rewarded video · Quests On-chain (Solana) 01 02 · NEXT In progress Mobile app · Creator platform GameFi SDK · Staking · veDST DAO governance · Cross-chain 02 03 · LATER Direction A PFun Store chain of our own Solana is the starting point No timeline attached 03 AN ITEM MOVES TO THE NEXT STATION ONLY WHEN IT IS LIVE · NO DATES ARE ATTACHED TO ITEMS THAT ARE NOT LIVE

Now — Operating

Item Detail
Games The PFun Store game portfolio, playable without any account linkage or task completion
Contracts Earned through play, funded by advertising revenue
Rewarded video Served through Google AdMob
Quests Advertiser tasks supplied through Unity LevelPlay offerwall inventory
On-chain DST token contract, reward distribution, and NFT issuance through the transaction engine, all deployed on Solana

Next — In Progress

Work on the items below is under way in parallel. They are listed without a fixed order, and no dates are attached until an item is live.

Item What it requires
Mobile application In development for iOS and Android in parallel; neither platform is sequenced ahead of the other
Creator platform An audience large enough that creators have a reason to publish into it
Developer tooling — GameFi SDK Published module interfaces and a supported integration path (see the contracts chapter)
Staking — veDST The staking module activated; parameters as set out in the tokenomics chapter
DAO governance Governance thresholds decided and the governance module activated
Interoperability with other chains Mature third-party bridging; no target chains are named in advance

Later — Direction

A PFun Store chain of our own. The Solana deployment is a starting point rather than a destination. This is a direction with no timeline attached: operating a chain is a far larger undertaking than operating an application, and it is only justified if the games, the reward economy and the ecosystem reach a scale that requires it.

Items marked Next are in progress; items marked Later are stated directions. Both may change, be re-sequenced, or be dropped.

現階段——運作中

項目 內容
遊戲 PFun Store 遊戲組合，無須綁定任何帳戶或完成任何任務即可遊玩
Contract 由遊玩產生，並由廣告收入支應
獎勵式影片 經 Google AdMob 投放
任務 廣告商任務，來自 Unity LevelPlay 之任務牆庫存
鏈上部分 DST Token 合約、獎勵分配，以及經交易引擎進行之 NFT 發行，均已部署於 Solana

下一步——進行中

以下各項均已同步進行，排列不代表先後次序；項目正式運作前不標註日期。

項目 前提條件
流動應用 iOS 與 Android 同步開發中，不設先後次序
創作者平台 用戶規模足以使創作者有發布之誘因
開發者工具——GameFi SDK 已公布之模組介面，以及一條獲支援之整合途徑（見合約章節）
質押——veDST 質押模組啟用；參數依代幣經濟章節所載
DAO 治理 治理門檻參數確定，並啟用治理模組
與其他鏈之互通 成熟之第三方橋接方案；本文件不預先指名目標鏈

長遠——方向

營運 PFun Store 自有公鏈。 Solana 上之部署為起點，而非終點。此為方向，並無時程：營運一條公鏈，遠較營運一個應用龐大；只有當遊戲、獎勵經濟與生態之規模確實需要自有公鏈時，才會推進。

標示為「下一步」者為進行中之項目，標示為「長遠」者屬已表明之方向。二者均可能變更、重新排序或取消。