DxSxT Network White Paper

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.

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:

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.

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:

1. To the player, as Contracts, earned by playing.
2. To DxSxT, as the operating margin that funds game development, infrastructure and user acquisition.
3. 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.

Protocol Architecture (Solana)

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.

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.

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 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.

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.

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.

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.

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 DxSxT would need to know.

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

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.

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:

Supply, Distribution, and Release Token Information

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.

Public Offering and Reserve Funds (Vesting)

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.

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

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

Content Platform and Creator Economy

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.

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:

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.

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

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

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 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

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:

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

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:

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

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.

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.

Now — Operating

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.

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.