Try games from our partners, reach the goal and collect Contracts.
01
Download
Pick a partner game from the Quest list and install it.
02
Complete
Reach the Quest goal, like finishing a level.
03
Collect
Get your Contracts once the mission is confirmed.
Daily check-inCheck in 7 days in a row.Check in once a day. Seven days in a row unlocks the Day 7 reward — miss a day and the streak starts again at Day 1.Day 7×2 on your main Contract for 8 hours.
Day 1Day 2Day 3Day 4Day 5Day 6Day 7
×2main Contract · 8 hours
Contracts unlock rewards, events and community status.Full details at launch.
Genesis NFT
Own it. Then use it.
Twenty Genesis cards. Each carries one skill that works inside the DxSxT app.
The architecture, token model, governance and roadmap of DxSxT Network.
The English text governs. Any translation is provided for reference only.
DxSxT Network 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. DxSxT starts from the other end. It starts with games people already want to play.
What DxSxT Is
DxSxT Network 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 DxSxT 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 DxSxT retains the margin.
Ecosystem. Contracts connect gameplay to progression, events, community standing and digital collectibles such as DxSxT 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
DxSxT 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 DxSxT.
Next — Developer tools. A GameFi SDK allowing third-party developers to integrate DxSxT 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. DxSxT is deployed on Solana. Interoperability with other chains is planned, without a committed timeline.
Later — A DxSxT chain. The long-term intention is to operate a DxSxT 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 DxSxT does:
DxSxT does not operate a DePIN network.
DxSxT does not operate an on-chain AI model pool or AI model governance.
DxSxT does not rent or broker GPU compute.
DxSxT 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 DxSxT
DxSxT Network 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.
Legal and Risk Disclaimer
Risk Disclaimer & Legal Notice
This document ("Whitepaper") serves solely to provide technical, visionary, and token economic model information pertaining to the DxSxT Network project. It does not constitute investment advice, a fundraising solicitation, a guarantee, a promise, or a legal contract in any form. Please carefully read the following risk disclaimer and legal terms before participating:
1. Information Purpose Statement
The content contained in this Whitepaper is for general informational purposes only. All data is based on the future development direction envisioned by the current project team.
This document shall not be considered a securities prospectus, investment advice, financial service solicitation, or offering document in any jurisdiction.
The content of this Whitepaper may be updated as the project progresses, through DAO resolutions, or due to technical adjustments. For the latest information, please refer to official communications.
2. Token Risk Statement
Holding or using DST Tokens involves the following significant risks:
Risk Type
Description
Price Volatility
DST Token is not a stablecoin; its price may fluctuate dramatically due to market supply and demand.
Regulatory Risk
Different countries have varying definitions of crypto assets, and policy changes may affect usage and trading.
Technical Risk
Protocol errors, smart contract vulnerabilities, or failure of third-party tools may lead to asset loss.
Hacker & Security
The system may be subject to hacker attacks, resulting in data leakage or asset theft.
Liquidity Risk
If there is a lack of trading counterparts, DST may experience insufficient liquidity.
Ecosystem Risk
Insufficient adoption of protocols or applications may lead to a decrease in token value and utility.
Important Reminder: Investors should prudently assess their own risk tolerance and bear any financial losses independently.
3. Legal Restrictions and Regional Exclusion Statement
This Whitepaper is not directed at or distributed to jurisdictions that prohibit, restrict, or regulate participation in crypto assets.
If you are a resident or legal entity in such a jurisdiction, please do not participate in activities related to DxSxT Network.
Users are obligated to confirm whether their participation complies with local laws and regulations.
4. Future Outlook and No Guarantee Statement
The descriptions regarding DxSxT Network's development plans in this Whitepaper are merely goal-oriented vision statements and do not constitute legally binding commitments.
No explicit or implied guarantees are made regarding project progress, token value, partnership advancements, listing progress, or other related content.
All participants should understand that blockchain project development carries a high degree of uncertainty and may deviate from original plans.
5. Disclaimer of Liability
The DxSxT Network team shall not be held liable for any direct or indirect losses that may arise from the use of the content in this Whitepaper or participation in this project.
Users should exercise their individual judgment, seek professional legal, financial, and tax advice, and bear all risks associated with participation.
6. Intellectual Property Rights Statement
Unless otherwise stated, all text, graphics, architecture, and technical designs within this Whitepaper are owned by or licensed to DxSxT Network.
No one may reproduce, distribute, or use them for commercial purposes without prior written consent.
How DxSxT Makes Money
The Short Version
Advertisers pay to reach engaged players. DxSxT 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 DxSxT 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 DxSxT 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.
Where the Money Goes
Advertiser payment splits three ways:
To the player, as Contracts, earned by playing.
To DxSxT, as the operating margin that funds game development, infrastructure and user acquisition.
To the advertising partner, as the intermediary fee. DxSxT 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.
DxSxT'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
DxSxT 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.
System Overview and Architecture
Protocol Architecture (Solana)
Diagram loads on dxsxt.network
Protocol Architecture and Technical Architecture (Solana Version)
Core Modules
DxSxT Network 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
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
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.
Rewards in DxSxT 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.
Interoperability and Chain Strategy
Where DxSxT Runs Today
DxSxT'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 DxSxT 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 DxSxT Chain
The long-term intention, stated in the opening chapter, is to operate a DxSxT 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.
Smart Contracts and Developer Experience
This chapter sets out what a third-party developer can build on DxSxT, which standards apply, and — the part these documents usually omit — what is available today.
Diagram loads on dxsxt.network
Core Architecture Design Diagram
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 DxSxT 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:
Client layer — mobile application, web dashboard, wallet connection and signing.
Protocol and contract layer — Solana programs for the token, transaction engine, reward distribution, and the modules that are designed but not yet active.
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 DxSxT 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 DxSxT.
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. DxSxT'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.
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 DxSxT Network, 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
Diagram loads on dxsxt.network
Distribution Ratio
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 DxSxT 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
DxSxT's own games
Players redeem Contracts they earned by playing
Live
Third-party GameFi titles
Rewards inside games built on the DxSxT 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, DxSxT 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. DxSxT does not purchase DST to refill it. DST that DxSxT 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
DxSxT Network 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)
DxSxT 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
DxSxT supports "content as an asset," allowing creators to put their works on-chain and customize NFT sales and licensing rules.
Value Flow Characteristics of DxSxT Network
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.
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 DxSxT 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.
Diagram loads on dxsxt.network
DAO Architecture Composition Diagram
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.
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.
Security Model and Risk Control
Security in DxSxT 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 DxSxT, 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 DxSxT 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.
Ecosystem and Contribution Model
How DxSxT 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.
DxSxT 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.
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.
Now — Operating
Item
Detail
Games
The DxSxT 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 DxSxT 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.
Diagram loads on dxsxt.network
DxSxT Network Roadmap
Notice
News & updates
Official product updates, community news and announcements from DxSxT Network.
