CHAPTER 00

Dream Max Token

From Earth orbit to the lunar surface. Building the next step in space, together.

Dream Max Token (DMT) is a proposed project connecting organizations that plan space missions, companies and researchers that use experiments and data, and people contributing research proposals, data preparation and discussion. Starting with a two-satellite demonstration, the project aims to develop an orbital research network and a lunar observation base.

How to read this document

• Start with the vision for an introduction to the project.
• Individuals considering participation should read DMT and usage rights, participation and contributions and the development budget.
• Organizations seeking experiments or data should read the first mission and services.

Amounts are denominated in US dollars. Reference yen conversions use a fixed rate of JPY 150 per USD. The roadmap presents the objectives of each Stage.

CHAPTER 01

Vision and challenges

From a research idea to an experiment in space

Researchers need more than a launch reservation. An experiment requires accommodation, power, communications, thermal provisions, ground operations and a way to receive its results. A research plan cannot proceed if separately procured stages have incompatible requirements.

DMT aims to connect these stages within individual missions, giving researchers and companies access to shared infrastructure. Users focus on research, instrument development and subsequent analysis, while the operating organization coordinates integration, transport, operations and data delivery.

From Earth orbit to the Moon

The first mission will use two satellites for space-environment testing and Earth observation, demonstrating the complete process from accepting user experiments to delivering data. The next phase targets 12 satellite launches cumulatively and connected ground stations, supporting recurring experiment and observation services.

The lunar phase combines an environmental observation station, a small rover and procured lunar-orbit relay services. It extends the operational model developed in Earth orbit: operating instruments, returning results to Earth and delivering them to users.

Crewed bases, commercial mining and the development of proprietary rockets or landers are outside this project scope. Transport will be procured from specialist providers. DMT will plan, commission and operate missions and services.

Why include a token?

DMT is intended to provide a common participation framework across missions. The same participation unit can support votes on research topics and funding allocations, rewards for qualifying contributions, and payments for supported services.

A token does not automatically create transport contracts, research results or revenue. Commercial viability depends on delivering services that users need and are willing to pay for. Claims about shared-cost savings or superiority to alternatives must be assessed through demonstrations and comparisons.

→ Explore participant roles

CHAPTER 02

Ecosystem and participants

Clear roles

Transport and other providers are listed as required business roles. Specific counterparties have not been selected. The operating entity's name and team members' backgrounds are not presented as established credentials.

How a mission moves forward

The operating organization identifies research topics and user demand, then combines spacecraft, transport and communication requirements into a mission proposal. After technical and budget review, participants vote within the defined scope. Procurement starts when execution conditions are met.

Companies and universities prepare equipment to meet integration requirements, and the operator verifies acceptance. Results from orbital experiments are delivered to the users specified in each contract. Participants receive reports on shared funds, progress and material changes to the plan.

Public information and protected information

Public reporting focuses on mission achievements, aggregated use of funds and voting outcomes. Customer equipment details, personal information and customer-owned experimental data are not placed directly on a public ledger. Public evidence and materials provided under restricted contractual access are managed separately.

CHAPTER 03

First mission

Two satellites: from experiments to data delivery

The Dream Max First Mission plans to deploy two satellites of approximately 150 kg each into low Earth orbit. A sun-synchronous orbit is the initial option; final specifications will depend on transport opportunities and experiment requirements.

Mass figures are design targets, not guaranteed performance. In addition to the 30 kg for external experiments, operator-owned shared observation instruments occupy a separate design allocation. Using saleable capacity in revenue calculations does not remove the need for technical integration review.

Transport and payload integration

Generated concept illustration of transport architecture. It is not an engineering drawing of an actual vehicle, a DMT-owned rocket, or a finalized launch configuration. Scale and dimensions have not been validated.

The rocket transports satellites to their intended orbit. The illustration shows the relationship between the satellite payload and protective fairing, upper stage, interstage and lower propulsion stage. Actual integration, separation and testing must follow the launch provider's requirements.

Dream Max experiment services are different from a rocket's transport capacity. Experiment customers purchase an operational service: their instruments use satellite power and communications in orbit, and results are returned to the ground.

Delivery steps within Stage 1

Success includes deploying both satellites, establishing communications, performing contracted experiments, delivering data and recording usage history. Partial achievements and unmet objectives will be distinguished. A successful launch alone does not complete the entire mission.

CHAPTER 04

Experiment services and data

Experiment services

The service provides satellite accommodation and orbital operating conditions for customers' equipment and specimens.

The mass allocation is equivalent to 30 basic applications, but does not guarantee accommodation for 30 instruments. Actual acceptance depends on volume, power, thermal, communications and safety requirements. A 100 g unit represents contractual capacity; a single unit does not entitle its holder to fly a separate instrument.

Users submit research objectives, equipment specifications and requested operating conditions. The process proceeds through technical review, agreement on specific terms, contracting, design checks and equipment acceptance. If conditions are not met, the parties discuss design changes, another mission or cancellation under the contract.

Shared observation data

The proposed commercial model offers 12 months of non-exclusive access to data from the operator's shared instruments to ten companies at USD 300,000 each. Scheduled delivery, calibration information and inquiry support are included, for USD 3 million in advance-payment contracts.

Receiving data from a satellite does not by itself constitute delivery. Contracts specify the covered period, formats, quality requirements, treatment of missing data and acceptance procedures. Resolution and accuracy depend on instrument specifications; no figures are presented as demonstrated performance.

Distinguishing data rights

An NFT records rights and usage history. Holding an NFT does not automatically transfer all copyright or exclusive rights in the underlying data.

CHAPTER 05

Technical architecture and data management

Acquire in space, verify on the ground, deliver under agreed terms

Observation and experiment data are received by ground stations, then processed and calibrated in the data platform. Users access deliverables through accounts linked to their contracts. Satellite control and token or NFT processing are designed as separate systems.

Proposed chain and token structure

A single EVM-compatible chain is under consideration. DMT is being considered as an ERC-20 token, with individual usage rights represented primarily by ERC-721 NFTs. ERC-20 specifies interfaces including transfers of fungible tokens; ERC-721 specifies interfaces for tracking and transferring individually identifiable NFTs. See the ERC-20 specification and ERC-721 specification.

A usage-right NFT would link a contract identifier, mission and usage status. Experiment capacity is an attribute of the contract; this does not require issuing one NFT for every 100 g. Multiple units may be combined in one contract, with rights retired after verified use and the history retained.

The network, fees and contract addresses remain undecided. Cross-chain bridges are outside the initial architecture. Adopting a standard does not by itself ensure compliance with contracts or security; usage restrictions, grant approvals and record management require separate design.

Evidence and access control

Large observation datasets and personal information will remain in the data platform rather than being stored directly on-chain. Publishable identifiers, comparison hashes and delivery and acceptance records will be linked so that the relevant dataset can be identified. A matching hash does not independently prove the truth or quality of an observation.

Records reach the ledger after operational-log checks, quality assessment and contractual acceptance. Plaintext personal information and identifiers that could reveal confidential information will not be published. Backup restoration and revocation or modification of data-access rights will also be tested.

Funds and administrative authority

The proposed shared treasury requires three signatures from five people with distinct roles for significant on-chain actions. Bank accounts use separate approval and payment controls; on-chain signatures do not directly control bank funds.

Contract-code checks, independent review, and tests of grant, usage and recovery procedures are conditions for production operation. This document does not claim that audited code, certified facilities or an operational network already exist.

CHAPTER 06

DMT and usage rights in the ecosystem

Connecting research, services and participation

DMT is a proposed token for recognizing contributions, using supported services and participating in shared operations within Dream Max. Mission budgets and token operations are separate. DMT is designed around actual research activity and service use.

Reading public information and joining open discussions do not require DMT holdings. Experiment services and access to contracted datasets are governed by their respective agreements.

Uses of DMT

Contribution recognition: DMT may be granted for verified work such as research proposals, translation, public-data organization and preparation of validation materials. Activity records are linked to grants; self-reported activity alone is insufficient.

Service use: Supported analysis tools, research workshops and additional processing of public data may accept DMT consumption or credits. Providers, quantities, covered functions and cancellation rules are disclosed before use. This does not automatically provide payload capacity or access to confidential data.

Shared operations: Activity and eligibility records support research proposals and voting. Governance rules define the voting method; DMT balances are not treated directly as voting weight.

Usage rights and actual services

Transferring experiment capacity still requires checks of the contracting party, device and schedule. Transferring an NFT alone does not approve a payload. Exclusivity, redistribution and use of derived data follow the relevant license.

DMT does not represent ownership of a company, satellite or intellectual property. Its role depends on actual services, participation programs and accountable record management.

→ Participation and contributions

CHAPTER 07

Participation and contributions

Start with public information

Researchers, developers, translators, people working with data and anyone interested in space can contribute their experience. Reading public information and joining open discussions or proposals do not require DMT holdings. Activity launch dates and entry points will be announced as programs become ready.

Activity-program process

1. Choose an activity: Review its purpose, required skills, deliverables, deadline and responsible team.
2. Review the terms: Check confidentiality, permissions, ownership of results and whether the program includes DMT grants. Quantities and assessment rules are to be disclosed before work begins.
3. Submit and verify: Provide outputs and supporting evidence. Reviewers apply the published acceptance criteria and explain any corrections or reassessment required.
4. Share the result: Record publishable outputs, acceptance decisions and activity history. Eligible programs grant DMT after verification, linking participation to supported services and shared operations.

Example: organizing public observation data

An activity may standardize column names, units and missing values in a permitted observation dataset, then document quality checks and results. The team specifies the dataset and acceptance criteria in advance and checks that the submitted work is reproducible. Approved outputs can be shared and the contribution recorded. Any DMT grant follows that activity's terms.

Assessment emphasizes useful, verifiable work rather than post counts or referral totals.

DMT use and records

Functions using DMT will explain the supported network, available quantities, fees, actions and failure handling. Users will not be asked to send private keys or recovery phrases to the team.

A proposed activity view includes current programs, submissions, review status, grant and usage history, and eligible discussions. Research votes follow the eligibility and method defined in the governance rules.

Before programs begin

Responsible teams, assessment criteria, grant and usage rules, and contact channels must be established before operation. This page does not provide activity registration or wallet-connection functionality.

CHAPTER 08

DMT operating design

Design around activity and use

DMT operations are tied to ecosystem activity. Grant quantities must be designed alongside usable services, participation rules and verification methods. Supply limits, initial issuance and activity-specific grant quantities remain decisions to be made after demand assessment and operational testing.

Managing grants and use

Program acceptance, deliverable review, DMT grants and service use are recorded separately. Controls cover duplicate claims, self-approval and abusive use of multiple accounts. Corrections retain an explanation in the history.

Shared balances require approved actions; staff cannot freely grant them to individuals. Public reports distinguish issuance, grants, use and unused quantities while excluding personal and confidential information.

Conditions for introducing functions

Programs and supported services must be available, and the full grant-to-use process must be tested. Suspending DMT functions does not remove obligations relating to accepted work or service contracts. Rule changes disclose their reasons, scope and effective dates.

CHAPTER 09

Business model and development budget

First-mission budget

The USD 15 million budget covers development of two satellites through initial operations. These are planning allocations, not supplier quotations.

Each category includes its own personnel costs, which are not added again as a separate project-wide payroll. Customer instrument development is an additional customer expense. This budget does not guarantee coverage of all post-initial-operation costs or replacement of both spacecraft.

A service-based business model

Revenue-generating activities comprise experiment integration and operation, observation-data licensing, analysis support and ground-station services. Agreements define deliverables, fees and acceptance conditions, connecting revenue to actual service delivery.

DMT supports participation and use within these activities. DMT quantities are not recorded as cash budgets or business revenue. Compensation for researchers and contributors is managed according to approved work and agreements.

Budget and contract controls

The USD 15 million figure is a planned cost envelope, not secured cash. Before each stage starts, the team verifies available budget, agreements and payment timing. Stages without the necessary support are not ordered or started; plans are adjusted. Sources of operating budget and actual receipt schedules remain separate business-execution decisions.

Service fees are consideration for actual use. Any prepayment terms must specify delivery obligations, timing and cancellation or delay handling. Unsigned agreements and amounts not received are not described as secured resources.

Stage 2 expands the orbital research network, and Stage 3 extends it to lunar observation. See the roadmap for the objectives of each Stage.

CHAPTER 10

Operations and governance

From proposal to execution

Research and budget proposals move through public discussion, technical and financial review, voting, execution approval and reporting. Funding requests must state their purpose, deliverables, cost, deadline, responsible party and treatment of failure.

Eligible participants are verified through activity records and participation criteria. DMT can support eligibility checks, but balances do not determine vote counts. Duplicate accounts are checked and eligibility is fixed before voting begins. Direct conflicts of interest must be disclosed; affected participants are excluded from the proposal and its quorum base.

Responsibility for execution

A vote does not replace technical safety checks or contracts. If conditions are not met, execution is held and the reasons and requirements for a revised proposal are reported. Routine contractual payments follow approved budgets and milestones; individual votes are not required for every invoice.

The shared on-chain treasury would require three of five signatures. Roles are business operations, engineering, finance, community and independent review, with no individual occupying multiple signature positions. Signatories and appointments will be finalized during implementation.

Emergencies and reporting

The proposed emergency control allows two of five signatories to pause fund transfers for up to 72 hours. It only pauses transfers; it does not authorize payments or transfers of other parties' assets. An initial report is due within 24 hours and a review within 72 hours. Extensions require at least three approvals and publication of the reason and expiry. Resumption requires at least three approvals after the cause and impact are assessed.

Satellite safety follows separate mission-control procedures. Emergency spacecraft actions do not wait for participant voting.

Use of funds and progress would be reported monthly, with quarterly reviews of budgets and milestones. Reports include actual performance, deviations from plan, remaining funds and upcoming payment obligations.

CHAPTER 11

Roadmap and uncertainty

Objectives by Stage

Results from each Stage support the next. The 12-satellite figure is a cumulative launch target.

Responding to plan changes

Reporting to users and participants

Contracted services, accepted outputs and activities not yet started require distinct responses. Report impacts, reasons and revised plans where publishable, and communicate confidential terms directly to affected parties.

Mission stages and DMT functionality are managed separately. Public information and research discussions should remain accessible while DMT functions are unavailable. Grant and usage functions do not begin before verification is complete.

CHAPTER 12

Glossary

Terms