Due diligence Eleven questions an investor asks, answered by the project A member put seven due-diligence questions to the project on 24 September 2026: what GD is for, what creates demand for it, what stops RM becoming sell pressure, what cash flows reach holders, where the moat is, what is verified on-chain, and how an AI agent's work is proved. Four follow-up questions were answered on 26 September: the same-rank bonus, the V12 stake, the energy multiple and whether the capital sits inside the cap. The answers came back whole and are reproduced here as supplied, with the numbering kept. Open a question for the full text; the short version is a card in the Knowledge section and the assistant reads both.
Received 26 September 2026 · four follow-up questions · reproduced as supplied · numbering kept
Question 1 of 4
What's the same-rank % reward? I am V8 and my team is V8? Open The same-rank reward is 10%–15%, calculated based on the earnings of the nearest same-rank position under your structure.
For example, if you are V5 and there are two V5 accounts below you—one in the first generation and another in the second generation—the same-rank reward is calculated from the nearest V5, which is the first-generation V5. You receive 10%–15% of that V5's applicable earnings.
You do not repeatedly receive the same-rank reward from every V5 below that position.
The override reward follows the same nearest-position principle.
Therefore, if you are V8 and there is a V8 under your team, you receive 10%–15% of the applicable earnings of the nearest qualifying V8 position.
Copy this answer The short version
1. What's the same-rank % reward? I am V8 and my team is V8?
The same-rank reward is 10%–15%, calculated based on the earnings of the nearest same-rank position under your structure.
For example, if you are V5 and there are two V5 accounts below you—one in the first generation and another in the second generation—the same-rank reward is calculated from the nearest V5, which is the first-generation V5. You receive 10%–15% of that V5's applicable earnings.
You do not repeatedly receive the same-rank reward from every V5 below that position.
The override reward follows the same nearest-position principle.
Therefore, if you are V8 and there is a V8 under your team, you receive 10%–15% of the applicable earnings of the nearest qualifying V8 position. Question 2 of 4
What is the governance weight for V12 — 25,000 or 50,000? Open According to the current Leader Edition rank table, V12 requires 50,000 USDT.
To be precise, the 50,000 USDT refers to the personal Stake requirement for V12, rather than a separate "governance weight" parameter.
So the current standard is:
V12 Personal Stake = 50,000 USDT.
The 25,000 figure should not be used as the current V12 personal Stake requirement.
Copy this answer The short version
2. What is the governance weight for V12 — 25,000 or 50,000?
According to the current Leader Edition rank table, V12 requires 50,000 USDT.
To be precise, the 50,000 USDT refers to the personal Stake requirement for V12, rather than a separate "governance weight" parameter.
So the current standard is:
V12 Personal Stake = 50,000 USDT.
The 25,000 figure should not be used as the current V12 personal Stake requirement. Question 3 of 4
The Energy multiple: the DApp shows 260% and 557%, the Economic Model Analysis says 150% and 200%, and tonight's answers say 2–6× on burn. Which one is correct? Open The current DApp display should be used as the final reference.
There are two different Energy mechanisms currently shown in the DApp:
Energy Staking = 260%
RM Burning for Energy = 557%
These are two separate mechanisms and should not be mixed together.
Most importantly, 260% and 557% are dynamic protocol parameters, not permanently fixed rates. The protocol can adjust these values, so the figures may change over time.
The 150%/200% figures in previous Economic Model Analysis materials, as well as previous explanations of a 2–6× burn range, should not override the current live DApp parameters.
Therefore, promoters should always use the latest values displayed in the DApp.
Currently: Staking = 260%, Burning = 557%. These values are dynamic and subject to protocol adjustment. The DApp is always the final reference.
Copy this answer The short version
3. The Energy multiple: the DApp shows 260% and 557%, the Economic Model Analysis says 150% and 200%, and tonight's answers say 2–6× on burn. Which one is correct?
The current DApp display should be used as the final reference.
There are two different Energy mechanisms currently shown in the DApp:
Energy Staking = 260%
RM Burning for Energy = 557%
These are two separate mechanisms and should not be mixed together.
Most importantly, 260% and 557% are dynamic protocol parameters, not permanently fixed rates. The protocol can adjust these values, so the figures may change over time.
The 150%/200% figures in previous Economic Model Analysis materials, as well as previous explanations of a 2–6× burn range, should not override the current live DApp parameters.
Therefore, promoters should always use the latest values displayed in the DApp.
Currently: Staking = 260%, Burning = 557%. These values are dynamic and subject to protocol adjustment. The DApp is always the final reference. Question 4 of 4
Does the initial capital from staking or bonds count inside the 4×/5×, or is the 4×/5× reward with the capital on top? Open The initial capital is included within the 4×/5× total release cap.
The mechanism releases principal + earnings together over time. The principal is not separately returned on top after the 4×/5× has been completed.
For example, if a position has a 5× total cap, both the principal and earnings released by the protocol are calculated within that 5× total.
So the correct explanation is:
Principal + earnings are released together, and both are included within the 4×/5× total release cap. The principal is not an additional payment on top of the 4×/5×.
Copy this answer The short version
4. Does the initial capital from staking or bonds count inside the 4×/5×, or is the 4×/5× reward with the capital on top?
The initial capital is included within the 4×/5× total release cap.
The mechanism releases principal + earnings together over time. The principal is not separately returned on top after the 4×/5× has been completed.
For example, if a position has a 5× total cap, both the principal and earnings released by the protocol are calculated within that 5× total.
So the correct explanation is:
Principal + earnings are released together, and both are included within the 4×/5× total release cap. The principal is not an additional payment on top of the 4×/5×. Spartan OS · Answers to four follow-up questions · received 26 September 2026
1. What's the same-rank % reward? I am V8 and my team is V8?
The same-rank reward is 10%–15%, calculated based on the earnings of the nearest same-rank position under your structure.
For example, if you are V5 and there are two V5 accounts below you—one in the first generation and another in the second generation—the same-rank reward is calculated from the nearest V5, which is the first-generation V5. You receive 10%–15% of that V5's applicable earnings.
You do not repeatedly receive the same-rank reward from every V5 below that position.
The override reward follows the same nearest-position principle.
Therefore, if you are V8 and there is a V8 under your team, you receive 10%–15% of the applicable earnings of the nearest qualifying V8 position.
2. What is the governance weight for V12 — 25,000 or 50,000?
According to the current Leader Edition rank table, V12 requires 50,000 USDT.
To be precise, the 50,000 USDT refers to the personal Stake requirement for V12, rather than a separate "governance weight" parameter.
So the current standard is:
V12 Personal Stake = 50,000 USDT.
The 25,000 figure should not be used as the current V12 personal Stake requirement.
3. The Energy multiple: the DApp shows 260% and 557%, the Economic Model Analysis says 150% and 200%, and tonight's answers say 2–6× on burn. Which one is correct?
The current DApp display should be used as the final reference.
There are two different Energy mechanisms currently shown in the DApp:
Energy Staking = 260%
RM Burning for Energy = 557%
These are two separate mechanisms and should not be mixed together.
Most importantly, 260% and 557% are dynamic protocol parameters, not permanently fixed rates. The protocol can adjust these values, so the figures may change over time.
The 150%/200% figures in previous Economic Model Analysis materials, as well as previous explanations of a 2–6× burn range, should not override the current live DApp parameters.
Therefore, promoters should always use the latest values displayed in the DApp.
Currently: Staking = 260%, Burning = 557%. These values are dynamic and subject to protocol adjustment. The DApp is always the final reference.
4. Does the initial capital from staking or bonds count inside the 4×/5×, or is the 4×/5× reward with the capital on top?
The initial capital is included within the 4×/5× total release cap.
The mechanism releases principal + earnings together over time. The principal is not separately returned on top after the 4×/5× has been completed.
For example, if a position has a 5× total cap, both the principal and earnings released by the protocol are calculated within that 5× total.
So the correct explanation is:
Principal + earnings are released together, and both are included within the 4×/5× total release cap. The principal is not an additional payment on top of the 4×/5×.
Received 24 September 2026 · seven questions · reproduced as supplied · numbering kept
Question 1 of 7
What specific economic purpose does GD serve that could not be achieved with a conventional governance token or stablecoin? Open GD serves as the scarce governance and long-term ecosystem-rights layer of SpartanOS. It is deliberately separated from both stablecoins and RM because these assets perform fundamentally different economic functions.
Stablecoins primarily provide pricing, capital entry, and settlement. RM is the higher-frequency economic asset used across incentives, staking, bonds, liquidity, compounding, burns, and application participation. GD, by contrast, is designed to represent scarce governance rights and longer-term ecosystem participation.
GD has a fixed maximum supply of 390,000 tokens. Its maximum supply does not expand simply because SpartanOS gains more users, TVL, or applications.
Access to GD is also constrained by the original tokenomics. Relevant channels include rights allocated to early NFT holders, predefined governance and ecosystem allocations, GD governance rights associated with the RM Stable Vault, and secondary-market circulation.
An important distinction concerns the GD associated with the RM Stable Vault. Those GD rights are released linearly over 30 weeks, but they are not newly minted because the Stable Vault exists. They come from GD that was already allocated under the original tokenomics, including the original 25% liquidity-incentive allocation. The original allocation structure also includes a 5% protocol-treasury risk reserve. Therefore, the Stable Vault does not change GD's 390,000 maximum-supply logic.
The reason SpartanOS does not use RM for everything is that RM itself is designed to circulate through a much higher-frequency economic cycle: incentives → staking → bonds → liquidity → applications → release → market demand → burn. Combining that role with the ecosystem's scarcest long-term governance rights would place two different economic objectives into the same asset.
Stablecoins cannot fully perform this role either. Their primary economic purpose is stable denomination and settlement, rather than representing a scarce governance asset whose supply remains fixed while the ecosystem around it expands.
This separation of economic roles is not unusual in crypto. Major protocols have similarly separated settlement or productive assets from governance and ecosystem-rights assets. The comparison does not mean GD is equivalent to those tokens; it illustrates a broader crypto-economic principle: high-frequency economic circulation and scarce governance rights do not necessarily need to be represented by the same asset.
A conventional governance token could theoretically be designed with similar characteristics. Therefore, GD's differentiation is not simply that it is called a governance token. Its long-term differentiation must come from whether SpartanOS can continuously attach meaningful governance rights, application utility, and ecosystem participation to a fixed supply of 390,000 GD. The ecosystem can expand. Applications can expand. The user base can expand. GD's maximum supply does not need to expand with them. That is the core economic purpose of GD.
Copy this answer The short version
1. What specific economic purpose does GD serve that could not be achieved with a conventional governance token or stablecoin?
GD serves as the scarce governance and long-term ecosystem-rights layer of SpartanOS. It is deliberately separated from both stablecoins and RM because these assets perform fundamentally different economic functions.
Stablecoins primarily provide pricing, capital entry, and settlement. RM is the higher-frequency economic asset used across incentives, staking, bonds, liquidity, compounding, burns, and application participation. GD, by contrast, is designed to represent scarce governance rights and longer-term ecosystem participation.
GD has a fixed maximum supply of 390,000 tokens. Its maximum supply does not expand simply because SpartanOS gains more users, TVL, or applications.
Access to GD is also constrained by the original tokenomics. Relevant channels include rights allocated to early NFT holders, predefined governance and ecosystem allocations, GD governance rights associated with the RM Stable Vault, and secondary-market circulation.
An important distinction concerns the GD associated with the RM Stable Vault. Those GD rights are released linearly over 30 weeks, but they are not newly minted because the Stable Vault exists. They come from GD that was already allocated under the original tokenomics, including the original 25% liquidity-incentive allocation. The original allocation structure also includes a 5% protocol-treasury risk reserve. Therefore, the Stable Vault does not change GD's 390,000 maximum-supply logic.
The reason SpartanOS does not use RM for everything is that RM itself is designed to circulate through a much higher-frequency economic cycle: incentives → staking → bonds → liquidity → applications → release → market demand → burn. Combining that role with the ecosystem's scarcest long-term governance rights would place two different economic objectives into the same asset.
Stablecoins cannot fully perform this role either. Their primary economic purpose is stable denomination and settlement, rather than representing a scarce governance asset whose supply remains fixed while the ecosystem around it expands.
This separation of economic roles is not unusual in crypto. Major protocols have similarly separated settlement or productive assets from governance and ecosystem-rights assets. The comparison does not mean GD is equivalent to those tokens; it illustrates a broader crypto-economic principle: high-frequency economic circulation and scarce governance rights do not necessarily need to be represented by the same asset.
A conventional governance token could theoretically be designed with similar characteristics. Therefore, GD's differentiation is not simply that it is called a governance token. Its long-term differentiation must come from whether SpartanOS can continuously attach meaningful governance rights, application utility, and ecosystem participation to a fixed supply of 390,000 GD. The ecosystem can expand. Applications can expand. The user base can expand. GD's maximum supply does not need to expand with them. That is the core economic purpose of GD. Question 2 of 7
What creates structural demand for GD through actual SpartanOS usage? Open Structural demand for GD cannot come from scarcity alone. Scarcity does not automatically create demand. Utility does.
The intended long-term demand structure for GD is: fixed supply + limited acquisition + governance demand + application utility + ecosystem expansion.
GD is beginning to move beyond being purely a governance asset and into actual application utility. For example, applications such as TempleRaid are bringing GD, RM, and other AnubisChain ecosystem assets into application-level use. This represents an important transition from simply holding a governance asset toward using that asset across both governance and applications.
As additional games, DeFi applications, RWA products, DID/NFT systems, trading infrastructure, and other DApps enter the ecosystem, GD can progressively support additional governance participation, application rights, ecosystem permissions, or other utility.
The economic relationship we want to establish is therefore straightforward: the number of applications can increase; the number of users can increase; the amount of utility attached to GD can increase; but the maximum GD supply remains 390,000. This is the important distinction between speculative demand and structural demand.
ETH provides a useful mainstream reference point for the principle, although its economic model is different. ETH demand is not based solely on people choosing to hold ETH; ETH is required for gas, participates in staking, and is used throughout the Ethereum ecosystem. GD must ultimately prove itself through the same broader economic principle: real utility must support long-term demand.
For that reason, GD should not be evaluated only by its market price. More meaningful metrics include the number of active GD addresses, ownership distribution, governance participation, number of applications using GD, application interactions, and actual on-chain usage. If the ecosystem expands while GD usage does not, then structural demand has not been proven. If more applications and users genuinely require GD while maximum supply remains fixed at 390,000, then GD is developing utility-driven structural demand.
Copy this answer The short version
2. What creates structural demand for GD through actual SpartanOS usage?
Structural demand for GD cannot come from scarcity alone. Scarcity does not automatically create demand. Utility does.
The intended long-term demand structure for GD is: fixed supply + limited acquisition + governance demand + application utility + ecosystem expansion.
GD is beginning to move beyond being purely a governance asset and into actual application utility. For example, applications such as TempleRaid are bringing GD, RM, and other AnubisChain ecosystem assets into application-level use. This represents an important transition from simply holding a governance asset toward using that asset across both governance and applications.
As additional games, DeFi applications, RWA products, DID/NFT systems, trading infrastructure, and other DApps enter the ecosystem, GD can progressively support additional governance participation, application rights, ecosystem permissions, or other utility.
The economic relationship we want to establish is therefore straightforward: the number of applications can increase; the number of users can increase; the amount of utility attached to GD can increase; but the maximum GD supply remains 390,000. This is the important distinction between speculative demand and structural demand.
ETH provides a useful mainstream reference point for the principle, although its economic model is different. ETH demand is not based solely on people choosing to hold ETH; ETH is required for gas, participates in staking, and is used throughout the Ethereum ecosystem. GD must ultimately prove itself through the same broader economic principle: real utility must support long-term demand.
For that reason, GD should not be evaluated only by its market price. More meaningful metrics include the number of active GD addresses, ownership distribution, governance participation, number of applications using GD, application interactions, and actual on-chain usage. If the ecosystem expands while GD usage does not, then structural demand has not been proven. If more applications and users genuinely require GD while maximum supply remains fixed at 390,000, then GD is developing utility-driven structural demand. Question 3 of 7
RM is designed to incentivize users, developers, and community participation. What prevents RM from becoming a pure emission-and-sell-pressure token over time? Open RM is not designed around emission control alone. SpartanOS attempts to manage both sides of the equation: how RM enters circulation and what creates demand for RM once it does. If a token's long-term economic path is simply mint → reward → sell, then increasing emission can eventually translate into persistent sell pressure. SpartanOS therefore combines controlled release, long-term locking, market-buy demand, burns, dynamic incentives, application demand, and liquidity balancing.
First, RM being generated does not mean that all RM immediately enters the open market. Long-term staking, 360/540-day long-term liquidity bonds, compounding, and the Energy system affect when and how much RM becomes actual circulating supply. The Energy system also creates an RM consumption path. RM can be burned to obtain 2–6× Energy value, while Energy staking itself follows a 360-day structure. RM therefore has a consumption mechanism in addition to its reward and trading functions.
Second, the 1:1 Turbo Engine introduces corresponding market-buy demand. Under the relevant reward mechanism, the system does not operate only on the reward side. Corresponding rewards require a 1:1 market purchase of RM, creating a demand side against token release. This is an important distinction. The objective is not to prohibit users from selling RM. The economic question is whether RM entering circulation is accompanied by sufficient real market demand. RM purchased through Turbo also enters a 24-hour silent period, while the baseline sell-side tax is 5%, reducing the possibility that the same purchase immediately becomes an equivalent short-term sell order.
Third, SpartanOS uses the O2 Adaptive Balancing Protocol. O2 operates on a three-hour cycle and incorporates TWAP while observing variables including buy/sell volume, average transaction size, buy/sell ratios, liquidity depth, and broader market conditions. When significant short-term supply-demand imbalance appears, sell-side protection can increase. When conditions normalize, the system re-evaluates conditions every three hours and progressively adjusts protection back toward the baseline 5%. The fastest return to baseline conditions within 24 hours still requires the relevant recovery conditions to remain satisfied continuously. O2 therefore addresses liquidity and supply-demand imbalance. It is not a mechanism that dictates what RM's market price should be, nor should it be interpreted as a price guarantee. The underlying principle is simple: price is the result; supply and demand are the cause. When imbalance occurs, protection increases. When balance returns, protection normalizes.
Fourth, SpartanOS uses AICS as a dynamic incentive layer. AICS operates on a rolling 30-day evaluation: Score = 0.2H + 0.4C + 0.2A + 0.2R. It evaluates network-health factors including referral structure, holder addresses, long-term participation, retention, activity, and contribution to the ecosystem. As a result, reaching the same nominal level does not necessarily mean receiving exactly the same incentives. Persistent heavy selling, weak retention, or declining long-term contribution can affect AICS evaluation. In simple terms: AICS evaluates network health; O2 manages market balance.
Long-term staking, 360/540-day bonds, compounding, locking, burns, and growing application demand then add further supply and demand components. The broader DeFi market has already demonstrated why this matters. High-emission liquidity-mining models without sufficient utility, locking, or real demand can eventually convert incentives into sell pressure. Other major crypto systems have responded to similar economic problems through combinations of locking, fee burns, buybacks, or utility demand.
SpartanOS combines: controlled release + 1:1 Turbo demand + long-term locking + burn + AICS + O2 adaptive balancing + application demand. The key long-term metrics are therefore not simply how much RM is generated. They are: new RM supply, actual circulating supply, 1:1 Turbo buy demand, application demand, long-term locked RM, burned RM, and liquidity depth. These mechanisms are designed to improve the supply-demand structure. They do not constitute a guarantee of RM's market price. Ultimately, sustainable demand must grow sufficiently to absorb sustainable supply.
Copy this answer The short version
3. RM is designed to incentivize users, developers, and community participation. What prevents RM from becoming a pure emission-and-sell-pressure token over time?
RM is not designed around emission control alone. SpartanOS attempts to manage both sides of the equation: how RM enters circulation and what creates demand for RM once it does. If a token's long-term economic path is simply mint → reward → sell, then increasing emission can eventually translate into persistent sell pressure. SpartanOS therefore combines controlled release, long-term locking, market-buy demand, burns, dynamic incentives, application demand, and liquidity balancing.
First, RM being generated does not mean that all RM immediately enters the open market. Long-term staking, 360/540-day long-term liquidity bonds, compounding, and the Energy system affect when and how much RM becomes actual circulating supply. The Energy system also creates an RM consumption path. RM can be burned to obtain 2–6× Energy value, while Energy staking itself follows a 360-day structure. RM therefore has a consumption mechanism in addition to its reward and trading functions.
Second, the 1:1 Turbo Engine introduces corresponding market-buy demand. Under the relevant reward mechanism, the system does not operate only on the reward side. Corresponding rewards require a 1:1 market purchase of RM, creating a demand side against token release. This is an important distinction. The objective is not to prohibit users from selling RM. The economic question is whether RM entering circulation is accompanied by sufficient real market demand. RM purchased through Turbo also enters a 24-hour silent period, while the baseline sell-side tax is 5%, reducing the possibility that the same purchase immediately becomes an equivalent short-term sell order.
Third, SpartanOS uses the O2 Adaptive Balancing Protocol. O2 operates on a three-hour cycle and incorporates TWAP while observing variables including buy/sell volume, average transaction size, buy/sell ratios, liquidity depth, and broader market conditions. When significant short-term supply-demand imbalance appears, sell-side protection can increase. When conditions normalize, the system re-evaluates conditions every three hours and progressively adjusts protection back toward the baseline 5%. The fastest return to baseline conditions within 24 hours still requires the relevant recovery conditions to remain satisfied continuously. O2 therefore addresses liquidity and supply-demand imbalance. It is not a mechanism that dictates what RM's market price should be, nor should it be interpreted as a price guarantee. The underlying principle is simple: price is the result; supply and demand are the cause. When imbalance occurs, protection increases. When balance returns, protection normalizes.
Fourth, SpartanOS uses AICS as a dynamic incentive layer. AICS operates on a rolling 30-day evaluation: Score = 0.2H + 0.4C + 0.2A + 0.2R. It evaluates network-health factors including referral structure, holder addresses, long-term participation, retention, activity, and contribution to the ecosystem. As a result, reaching the same nominal level does not necessarily mean receiving exactly the same incentives. Persistent heavy selling, weak retention, or declining long-term contribution can affect AICS evaluation. In simple terms: AICS evaluates network health; O2 manages market balance.
Long-term staking, 360/540-day bonds, compounding, locking, burns, and growing application demand then add further supply and demand components. The broader DeFi market has already demonstrated why this matters. High-emission liquidity-mining models without sufficient utility, locking, or real demand can eventually convert incentives into sell pressure. Other major crypto systems have responded to similar economic problems through combinations of locking, fee burns, buybacks, or utility demand.
SpartanOS combines: controlled release + 1:1 Turbo demand + long-term locking + burn + AICS + O2 adaptive balancing + application demand. The key long-term metrics are therefore not simply how much RM is generated. They are: new RM supply, actual circulating supply, 1:1 Turbo buy demand, application demand, long-term locked RM, burned RM, and liquidity depth. These mechanisms are designed to improve the supply-demand structure. They do not constitute a guarantee of RM's market price. Ultimately, sustainable demand must grow sufficiently to absorb sustainable supply. Question 4 of 7
What actual cash flows move through the ecosystem, and what percentage ultimately accrues to the protocol or token holders? Open SpartanOS separates three concepts that should not be confused: capital flow, protocol accrual, and token holder value accrual.
SpartanOS is not accurately described as a simple traditional fund-allocation model where, for example, a user deposits $100 and a fixed X% automatically becomes protocol revenue while Y% automatically becomes token-holder income. The more accurate approach is to analyze both the asset side and the RM supply side.
When capital enters SpartanOS, depending on the specific product and its economic rules, that capital contributes to the protocol asset structure, including functions such as liquidity, treasury, POL, and other protocol assets. Different products can have different asset paths. A specific product can therefore be analyzed in terms of how much capital contributes to LP, treasury/POL, or other protocol functions. However, a product-specific asset allocation should not be presented as a universal revenue-distribution percentage for the entire SpartanOS ecosystem.
At the same time, the protocol determines the corresponding RM minting, locking, and future release obligations according to the rules of that product. This means that when $100 enters the protocol, the relevant economic question is not only "Where was the $100 allocated?" It is also "What protocol asset value was created by that $100, and what corresponding future RM supply or token liability was created against it?" That RM does not necessarily enter the open market immediately. Its economic path can involve: locking → controlled release → 1:1 Turbo demand → buyback → burn → O2 adaptive balancing.
Therefore, what matters economically is not simply "How much of the $100 was distributed?" A more meaningful question is: "What protocol asset value was created by that $100, what future RM supply was created against it, how and when does that RM enter circulation, and how does the market absorb that supply?"
A simplified representation is: capital enters the protocol → protocol assets / treasury / POL / liquidity → RM minting according to protocol rules → RM locking and controlled release → secondary-market supply and demand → O2 monitors market conditions → buyback / burn / protection / liquidity mechanisms respond → the system moves toward a new supply-demand equilibrium. In simple terms: SpartanOS does not simply divide deposits; it manages a token economy.
The second part of the question, what ultimately accrues to token holders, is equally important. Assets accumulated in treasury/POL represent protocol accrual. Liquidity contributes to protocol economics and market depth. Neither should automatically be described as cash income paid directly to token holders. Therefore: treasury ≠ holder dividend; liquidity ≠ holder dividend; token price appreciation ≠ cash-flow distribution.
At present, RM and GD holder value capture should primarily be understood as indirect value accrual rather than a traditional fixed dividend model. For RM, value accrual can occur through 1:1 Turbo market-buy demand, locking, changes in circulating supply, burns, application utility, and application-revenue-linked buyback/burn mechanisms where applicable. For GD, value accrual is associated with its fixed 390,000 maximum supply, governance rights, and expanding application utility.
The next major economic layer is external application revenue. As GoPlay, TempleRaid, and future games, DEXs, cross-chain applications, RWA products, trading infrastructure, and other DApps generate genuine external economic activity, it becomes possible to track how much application revenue enters treasury, how much strengthens liquidity, how much is used for RM buyback/burn, and whether any portion is explicitly distributed to holders. Unless a smart contract or explicit protocol rule states that X% of protocol revenue is directly distributed to RM/GD holders, protocol assets should not be represented as direct holder cash flow.
Therefore, there is currently no accurate universal formula such as "$100 deposited = X% goes directly to RM/GD holders." A more meaningful due-diligence framework is: for every unit of capital entering SpartanOS, what protocol assets are created or acquired, what corresponding RM supply or future token liability is generated, how is that RM released into circulation, and what mechanisms balance that supply against real market demand and liquidity? And then: how much external application revenue is ultimately captured by treasury, liquidity, buyback/burn, or direct holder distribution?
These distinctions are essential: capital flow ≠ revenue; protocol assets ≠ holder dividend; buyback/burn ≠ direct cash distribution.
Copy this answer The short version
4. What actual cash flows move through the ecosystem, and what percentage ultimately accrues to the protocol or token holders?
SpartanOS separates three concepts that should not be confused: capital flow, protocol accrual, and token holder value accrual.
SpartanOS is not accurately described as a simple traditional fund-allocation model where, for example, a user deposits $100 and a fixed X% automatically becomes protocol revenue while Y% automatically becomes token-holder income. The more accurate approach is to analyze both the asset side and the RM supply side.
When capital enters SpartanOS, depending on the specific product and its economic rules, that capital contributes to the protocol asset structure, including functions such as liquidity, treasury, POL, and other protocol assets. Different products can have different asset paths. A specific product can therefore be analyzed in terms of how much capital contributes to LP, treasury/POL, or other protocol functions. However, a product-specific asset allocation should not be presented as a universal revenue-distribution percentage for the entire SpartanOS ecosystem.
At the same time, the protocol determines the corresponding RM minting, locking, and future release obligations according to the rules of that product. This means that when $100 enters the protocol, the relevant economic question is not only "Where was the $100 allocated?" It is also "What protocol asset value was created by that $100, and what corresponding future RM supply or token liability was created against it?" That RM does not necessarily enter the open market immediately. Its economic path can involve: locking → controlled release → 1:1 Turbo demand → buyback → burn → O2 adaptive balancing.
Therefore, what matters economically is not simply "How much of the $100 was distributed?" A more meaningful question is: "What protocol asset value was created by that $100, what future RM supply was created against it, how and when does that RM enter circulation, and how does the market absorb that supply?"
A simplified representation is: capital enters the protocol → protocol assets / treasury / POL / liquidity → RM minting according to protocol rules → RM locking and controlled release → secondary-market supply and demand → O2 monitors market conditions → buyback / burn / protection / liquidity mechanisms respond → the system moves toward a new supply-demand equilibrium. In simple terms: SpartanOS does not simply divide deposits; it manages a token economy.
The second part of the question, what ultimately accrues to token holders, is equally important. Assets accumulated in treasury/POL represent protocol accrual. Liquidity contributes to protocol economics and market depth. Neither should automatically be described as cash income paid directly to token holders. Therefore: treasury ≠ holder dividend; liquidity ≠ holder dividend; token price appreciation ≠ cash-flow distribution.
At present, RM and GD holder value capture should primarily be understood as indirect value accrual rather than a traditional fixed dividend model. For RM, value accrual can occur through 1:1 Turbo market-buy demand, locking, changes in circulating supply, burns, application utility, and application-revenue-linked buyback/burn mechanisms where applicable. For GD, value accrual is associated with its fixed 390,000 maximum supply, governance rights, and expanding application utility.
The next major economic layer is external application revenue. As GoPlay, TempleRaid, and future games, DEXs, cross-chain applications, RWA products, trading infrastructure, and other DApps generate genuine external economic activity, it becomes possible to track how much application revenue enters treasury, how much strengthens liquidity, how much is used for RM buyback/burn, and whether any portion is explicitly distributed to holders. Unless a smart contract or explicit protocol rule states that X% of protocol revenue is directly distributed to RM/GD holders, protocol assets should not be represented as direct holder cash flow.
Therefore, there is currently no accurate universal formula such as "$100 deposited = X% goes directly to RM/GD holders." A more meaningful due-diligence framework is: for every unit of capital entering SpartanOS, what protocol assets are created or acquired, what corresponding RM supply or future token liability is generated, how is that RM released into circulation, and what mechanisms balance that supply against real market demand and liquidity? And then: how much external application revenue is ultimately captured by treasury, liquidity, buyback/burn, or direct holder distribution?
These distinctions are essential: capital flow ≠ revenue; protocol assets ≠ holder dividend; buyback/burn ≠ direct cash distribution. Question 5 of 7
What is SpartanOS's crypto-native moat? Open SpartanOS's moat is not RM alone, GD alone, O2 alone, or a single smart contract. Tokens can be copied. Smart contracts can be forked. Tokenomic parameters can also be replicated. The potential moat comes from the network effect created when multiple economic, application, infrastructure, liquidity, developer, and community layers operate together.
The first layer is the economic layer: RM + GD + O2 + 1:1 Turbo + AICS + Stable Vault + long-term staking + long-term liquidity bonds + Energy + burn + compounding. These mechanisms address different parts of the economic system: supply, demand, liquidity, long-term participation, and network health.
The second layer is the application layer. GoPlay, TempleRaid, and future applications are intended to move RM and GD beyond an internal protocol economy and into real application utility. As applications generate users, transactions, and external revenue, the application economy can begin feeding economic activity back into the RM/GD ecosystem.
The third layer is the AI / intent / execution layer. Intent infrastructure such as dappOS represents an important direction here. Its significance is not simply attaching an "AI" label to Web3. The objective is to reduce the complexity of blockchain interaction. A user expresses an intent; the relevant infrastructure can assist with routing, execution, and DApp interaction, while final asset ownership and settlement return to the blockchain layer. In simple terms: AI handles intelligence and execution assistance; blockchain provides trusted state, assets, and value settlement.
The fourth layer is blockchain infrastructure. SpartanOS uses AnubisChain for smart-contract execution and asset settlement, while the broader ecosystem connects with infrastructure across wallets, bridges, DEXs, explorers, indexing/data infrastructure, and cross-chain systems including areas such as The Graph, Blockscout, and LayerZero.
The fifth layer is ecosystem expansion. From Q3 onward, the ecosystem roadmap includes progressive development across: LayerZero + OFT cross-chain infrastructure, explorer upgrades, RocketSwap V3, Guard multisig, NFT + DID, AI Meme / AI Agent, RWA tokenization, a decentralized contract-trading platform, and contract-trading insurance. These should not all be represented as already-live revenue-generating products. Live products should be evaluated through product usage and on-chain data. Integrations under development should be evaluated through technical progress and official announcements. Future products should be verified through contracts, transactions, users, and revenue once deployed.
Major crypto networks demonstrate why this distinction matters. Ethereum's moat is not simply the EVM source code. Its network effect comes from developers, liquidity, wallets, applications, infrastructure, standards, and users interacting with one another. Likewise, an AMM formula itself can be forked; recreating the liquidity, integrations, users, developer tooling, and network effects around a mature DEX is significantly harder.
The network SpartanOS is attempting to build is therefore: token economy + liquidity + AI/intent + applications + blockchain infrastructure + developers + users + global community. It would be premature to describe this as an absolute, uncopyable moat. A more accurate description is that SpartanOS is building a network moat, whose strength must ultimately be demonstrated through liquidity depth, active users, application adoption, developer activity, external revenue, and cross-ecosystem integrations.
Copy this answer The short version
5. What is SpartanOS's crypto-native moat?
SpartanOS's moat is not RM alone, GD alone, O2 alone, or a single smart contract. Tokens can be copied. Smart contracts can be forked. Tokenomic parameters can also be replicated. The potential moat comes from the network effect created when multiple economic, application, infrastructure, liquidity, developer, and community layers operate together.
The first layer is the economic layer: RM + GD + O2 + 1:1 Turbo + AICS + Stable Vault + long-term staking + long-term liquidity bonds + Energy + burn + compounding. These mechanisms address different parts of the economic system: supply, demand, liquidity, long-term participation, and network health.
The second layer is the application layer. GoPlay, TempleRaid, and future applications are intended to move RM and GD beyond an internal protocol economy and into real application utility. As applications generate users, transactions, and external revenue, the application economy can begin feeding economic activity back into the RM/GD ecosystem.
The third layer is the AI / intent / execution layer. Intent infrastructure such as dappOS represents an important direction here. Its significance is not simply attaching an "AI" label to Web3. The objective is to reduce the complexity of blockchain interaction. A user expresses an intent; the relevant infrastructure can assist with routing, execution, and DApp interaction, while final asset ownership and settlement return to the blockchain layer. In simple terms: AI handles intelligence and execution assistance; blockchain provides trusted state, assets, and value settlement.
The fourth layer is blockchain infrastructure. SpartanOS uses AnubisChain for smart-contract execution and asset settlement, while the broader ecosystem connects with infrastructure across wallets, bridges, DEXs, explorers, indexing/data infrastructure, and cross-chain systems including areas such as The Graph, Blockscout, and LayerZero.
The fifth layer is ecosystem expansion. From Q3 onward, the ecosystem roadmap includes progressive development across: LayerZero + OFT cross-chain infrastructure, explorer upgrades, RocketSwap V3, Guard multisig, NFT + DID, AI Meme / AI Agent, RWA tokenization, a decentralized contract-trading platform, and contract-trading insurance. These should not all be represented as already-live revenue-generating products. Live products should be evaluated through product usage and on-chain data. Integrations under development should be evaluated through technical progress and official announcements. Future products should be verified through contracts, transactions, users, and revenue once deployed.
Major crypto networks demonstrate why this distinction matters. Ethereum's moat is not simply the EVM source code. Its network effect comes from developers, liquidity, wallets, applications, infrastructure, standards, and users interacting with one another. Likewise, an AMM formula itself can be forked; recreating the liquidity, integrations, users, developer tooling, and network effects around a mature DEX is significantly harder.
The network SpartanOS is attempting to build is therefore: token economy + liquidity + AI/intent + applications + blockchain infrastructure + developers + users + global community. It would be premature to describe this as an absolute, uncopyable moat. A more accurate description is that SpartanOS is building a network moat, whose strength must ultimately be demonstrated through liquidity depth, active users, application adoption, developer activity, external revenue, and cross-ecosystem integrations. Question 6 of 7
What exactly is verified on-chain, and what is merely asserted by off-chain AI infrastructure? Open SpartanOS makes a clear distinction between on-chain state and off-chain computation.
Information that can be independently verified on-chain includes: wallet addresses, token contracts, RM/GD transfers, swaps, liquidity changes, burns, smart-contract interactions, transaction hashes, and final asset settlement. These facts do not require a user to trust what the SpartanOS frontend says. They can be independently checked against the relevant blockchain state through explorers and, where supported, third-party blockchain data/indexing infrastructure. That is one of the core properties of blockchain: users should be able to independently verify critical asset and transaction states rather than relying solely on the protocol's own interface.
However, not every component of the system is automatically on-chain. Elements such as portions of AICS scoring computation, intent interpretation, external-data analysis, API calls, agent decision-making, and other off-chain computation must be treated separately. If an off-chain system performs a calculation and then submits a transaction to the blockchain, the blockchain can prove that the final transaction occurred. It does not automatically prove that every preceding off-chain computation was correct. Therefore: result on-chain ≠ entire computation on-chain.
The trust boundary is more accurately described as: AI / off-chain infrastructure handles intelligence, analysis, and execution logic; blockchain verifies trusted state, assets, transactions, and final value settlement.
If off-chain computation itself needs to become cryptographically verifiable, additional technologies may be required, depending on the implementation, including public algorithms, oracles, TEEs, ZK proofs, cryptographic signatures, validator networks, or other verifiable-computation systems.
We therefore distinguish between on-chain facts, independently verifiable through blockchain state, and off-chain computation, requiring its own verification mechanism. A result being written to the blockchain should not be presented as proof that the entire off-chain computation was itself performed or verified on-chain.
Copy this answer The short version
6. What exactly is verified on-chain, and what is merely asserted by off-chain AI infrastructure?
SpartanOS makes a clear distinction between on-chain state and off-chain computation.
Information that can be independently verified on-chain includes: wallet addresses, token contracts, RM/GD transfers, swaps, liquidity changes, burns, smart-contract interactions, transaction hashes, and final asset settlement. These facts do not require a user to trust what the SpartanOS frontend says. They can be independently checked against the relevant blockchain state through explorers and, where supported, third-party blockchain data/indexing infrastructure. That is one of the core properties of blockchain: users should be able to independently verify critical asset and transaction states rather than relying solely on the protocol's own interface.
However, not every component of the system is automatically on-chain. Elements such as portions of AICS scoring computation, intent interpretation, external-data analysis, API calls, agent decision-making, and other off-chain computation must be treated separately. If an off-chain system performs a calculation and then submits a transaction to the blockchain, the blockchain can prove that the final transaction occurred. It does not automatically prove that every preceding off-chain computation was correct. Therefore: result on-chain ≠ entire computation on-chain.
The trust boundary is more accurately described as: AI / off-chain infrastructure handles intelligence, analysis, and execution logic; blockchain verifies trusted state, assets, transactions, and final value settlement.
If off-chain computation itself needs to become cryptographically verifiable, additional technologies may be required, depending on the implementation, including public algorithms, oracles, TEEs, ZK proofs, cryptographic signatures, validator networks, or other verifiable-computation systems.
We therefore distinguish between on-chain facts, independently verifiable through blockchain state, and off-chain computation, requiring its own verification mechanism. A result being written to the blockchain should not be presented as proof that the entire off-chain computation was itself performed or verified on-chain. Question 7 of 7
How does SpartanOS prove an AI agent actually performed the service it claims to have performed? Open There are two separate levels of proof: execution result verification and computation verification.
If an agent claims that it completed a transfer, swap, stake, or smart-contract interaction, the user should not have to trust a frontend message saying "Completed." The primary proof should be the blockchain. A user should be able to verify the transaction hash, contract call, input assets, output assets, wallet-state changes, and final settlement.
For example, if an agent claims "I swapped Asset A into Asset B for you," the relevant proof is not the agent's own statement. The user should be able to verify whether the transaction actually exists, which smart contract was called, how much Asset A left the wallet, how much Asset B was received, and whether the transaction successfully settled. That is execution result verification. Blockchain is particularly effective at proving that an asset-related action actually occurred.
However, a transaction hash does not automatically prove why the agent made a particular decision, whether every input was accurate, or whether every internal reasoning step was correct. That is a separate problem: computation verification. If the objective is to cryptographically verify the agent's internal computation, additional mechanisms may be required, such as TEEs, ZK proofs, oracle systems, validator networks, cryptographic signatures, or other forms of verifiable computation.
We therefore do not make the technically inaccurate claim that "because the transaction is on-chain, every AI computation behind it is automatically trustworthy." The more accurate model is: AI understands intent, performs analysis, and assists execution; blockchain verifies asset state and final execution.
Intent infrastructure such as dappOS illustrates the broader direction: users do not necessarily need to manually understand every blockchain operation involved in fulfilling an intent. The intent/execution layer can simplify routing and execution, while critical asset outcomes should still return to blockchain-verifiable settlement.
The principle is straightforward: do not rely only on an agent saying "I completed the task." Verify whether the blockchain proves that the task was actually completed. If the requirement goes further, to prove why the agent made the decision or that its internal computation was correct, then that requires a separate cryptographic or verifiable-computation layer, and should be evaluated according to the actual verification technology deployed.
Copy this answer The short version
7. How does SpartanOS prove an AI agent actually performed the service it claims to have performed?
There are two separate levels of proof: execution result verification and computation verification.
If an agent claims that it completed a transfer, swap, stake, or smart-contract interaction, the user should not have to trust a frontend message saying "Completed." The primary proof should be the blockchain. A user should be able to verify the transaction hash, contract call, input assets, output assets, wallet-state changes, and final settlement.
For example, if an agent claims "I swapped Asset A into Asset B for you," the relevant proof is not the agent's own statement. The user should be able to verify whether the transaction actually exists, which smart contract was called, how much Asset A left the wallet, how much Asset B was received, and whether the transaction successfully settled. That is execution result verification. Blockchain is particularly effective at proving that an asset-related action actually occurred.
However, a transaction hash does not automatically prove why the agent made a particular decision, whether every input was accurate, or whether every internal reasoning step was correct. That is a separate problem: computation verification. If the objective is to cryptographically verify the agent's internal computation, additional mechanisms may be required, such as TEEs, ZK proofs, oracle systems, validator networks, cryptographic signatures, or other forms of verifiable computation.
We therefore do not make the technically inaccurate claim that "because the transaction is on-chain, every AI computation behind it is automatically trustworthy." The more accurate model is: AI understands intent, performs analysis, and assists execution; blockchain verifies asset state and final execution.
Intent infrastructure such as dappOS illustrates the broader direction: users do not necessarily need to manually understand every blockchain operation involved in fulfilling an intent. The intent/execution layer can simplify routing and execution, while critical asset outcomes should still return to blockchain-verifiable settlement.
The principle is straightforward: do not rely only on an agent saying "I completed the task." Verify whether the blockchain proves that the task was actually completed. If the requirement goes further, to prove why the agent made the decision or that its internal computation was correct, then that requires a separate cryptographic or verifiable-computation layer, and should be evaluated according to the actual verification technology deployed. Spartan OS · Response to Seven Due Diligence Questions · received 24 September 2026
1. What specific economic purpose does GD serve that could not be achieved with a conventional governance token or stablecoin?
GD serves as the scarce governance and long-term ecosystem-rights layer of SpartanOS. It is deliberately separated from both stablecoins and RM because these assets perform fundamentally different economic functions.
Stablecoins primarily provide pricing, capital entry, and settlement. RM is the higher-frequency economic asset used across incentives, staking, bonds, liquidity, compounding, burns, and application participation. GD, by contrast, is designed to represent scarce governance rights and longer-term ecosystem participation.
GD has a fixed maximum supply of 390,000 tokens. Its maximum supply does not expand simply because SpartanOS gains more users, TVL, or applications.
Access to GD is also constrained by the original tokenomics. Relevant channels include rights allocated to early NFT holders, predefined governance and ecosystem allocations, GD governance rights associated with the RM Stable Vault, and secondary-market circulation.
An important distinction concerns the GD associated with the RM Stable Vault. Those GD rights are released linearly over 30 weeks, but they are not newly minted because the Stable Vault exists. They come from GD that was already allocated under the original tokenomics, including the original 25% liquidity-incentive allocation. The original allocation structure also includes a 5% protocol-treasury risk reserve. Therefore, the Stable Vault does not change GD's 390,000 maximum-supply logic.
The reason SpartanOS does not use RM for everything is that RM itself is designed to circulate through a much higher-frequency economic cycle: incentives → staking → bonds → liquidity → applications → release → market demand → burn. Combining that role with the ecosystem's scarcest long-term governance rights would place two different economic objectives into the same asset.
Stablecoins cannot fully perform this role either. Their primary economic purpose is stable denomination and settlement, rather than representing a scarce governance asset whose supply remains fixed while the ecosystem around it expands.
This separation of economic roles is not unusual in crypto. Major protocols have similarly separated settlement or productive assets from governance and ecosystem-rights assets. The comparison does not mean GD is equivalent to those tokens; it illustrates a broader crypto-economic principle: high-frequency economic circulation and scarce governance rights do not necessarily need to be represented by the same asset.
A conventional governance token could theoretically be designed with similar characteristics. Therefore, GD's differentiation is not simply that it is called a governance token. Its long-term differentiation must come from whether SpartanOS can continuously attach meaningful governance rights, application utility, and ecosystem participation to a fixed supply of 390,000 GD. The ecosystem can expand. Applications can expand. The user base can expand. GD's maximum supply does not need to expand with them. That is the core economic purpose of GD.
2. What creates structural demand for GD through actual SpartanOS usage?
Structural demand for GD cannot come from scarcity alone. Scarcity does not automatically create demand. Utility does.
The intended long-term demand structure for GD is: fixed supply + limited acquisition + governance demand + application utility + ecosystem expansion.
GD is beginning to move beyond being purely a governance asset and into actual application utility. For example, applications such as TempleRaid are bringing GD, RM, and other AnubisChain ecosystem assets into application-level use. This represents an important transition from simply holding a governance asset toward using that asset across both governance and applications.
As additional games, DeFi applications, RWA products, DID/NFT systems, trading infrastructure, and other DApps enter the ecosystem, GD can progressively support additional governance participation, application rights, ecosystem permissions, or other utility.
The economic relationship we want to establish is therefore straightforward: the number of applications can increase; the number of users can increase; the amount of utility attached to GD can increase; but the maximum GD supply remains 390,000. This is the important distinction between speculative demand and structural demand.
ETH provides a useful mainstream reference point for the principle, although its economic model is different. ETH demand is not based solely on people choosing to hold ETH; ETH is required for gas, participates in staking, and is used throughout the Ethereum ecosystem. GD must ultimately prove itself through the same broader economic principle: real utility must support long-term demand.
For that reason, GD should not be evaluated only by its market price. More meaningful metrics include the number of active GD addresses, ownership distribution, governance participation, number of applications using GD, application interactions, and actual on-chain usage. If the ecosystem expands while GD usage does not, then structural demand has not been proven. If more applications and users genuinely require GD while maximum supply remains fixed at 390,000, then GD is developing utility-driven structural demand.
3. RM is designed to incentivize users, developers, and community participation. What prevents RM from becoming a pure emission-and-sell-pressure token over time?
RM is not designed around emission control alone. SpartanOS attempts to manage both sides of the equation: how RM enters circulation and what creates demand for RM once it does. If a token's long-term economic path is simply mint → reward → sell, then increasing emission can eventually translate into persistent sell pressure. SpartanOS therefore combines controlled release, long-term locking, market-buy demand, burns, dynamic incentives, application demand, and liquidity balancing.
First, RM being generated does not mean that all RM immediately enters the open market. Long-term staking, 360/540-day long-term liquidity bonds, compounding, and the Energy system affect when and how much RM becomes actual circulating supply. The Energy system also creates an RM consumption path. RM can be burned to obtain 2–6× Energy value, while Energy staking itself follows a 360-day structure. RM therefore has a consumption mechanism in addition to its reward and trading functions.
Second, the 1:1 Turbo Engine introduces corresponding market-buy demand. Under the relevant reward mechanism, the system does not operate only on the reward side. Corresponding rewards require a 1:1 market purchase of RM, creating a demand side against token release. This is an important distinction. The objective is not to prohibit users from selling RM. The economic question is whether RM entering circulation is accompanied by sufficient real market demand. RM purchased through Turbo also enters a 24-hour silent period, while the baseline sell-side tax is 5%, reducing the possibility that the same purchase immediately becomes an equivalent short-term sell order.
Third, SpartanOS uses the O2 Adaptive Balancing Protocol. O2 operates on a three-hour cycle and incorporates TWAP while observing variables including buy/sell volume, average transaction size, buy/sell ratios, liquidity depth, and broader market conditions. When significant short-term supply-demand imbalance appears, sell-side protection can increase. When conditions normalize, the system re-evaluates conditions every three hours and progressively adjusts protection back toward the baseline 5%. The fastest return to baseline conditions within 24 hours still requires the relevant recovery conditions to remain satisfied continuously. O2 therefore addresses liquidity and supply-demand imbalance. It is not a mechanism that dictates what RM's market price should be, nor should it be interpreted as a price guarantee. The underlying principle is simple: price is the result; supply and demand are the cause. When imbalance occurs, protection increases. When balance returns, protection normalizes.
Fourth, SpartanOS uses AICS as a dynamic incentive layer. AICS operates on a rolling 30-day evaluation: Score = 0.2H + 0.4C + 0.2A + 0.2R. It evaluates network-health factors including referral structure, holder addresses, long-term participation, retention, activity, and contribution to the ecosystem. As a result, reaching the same nominal level does not necessarily mean receiving exactly the same incentives. Persistent heavy selling, weak retention, or declining long-term contribution can affect AICS evaluation. In simple terms: AICS evaluates network health; O2 manages market balance.
Long-term staking, 360/540-day bonds, compounding, locking, burns, and growing application demand then add further supply and demand components. The broader DeFi market has already demonstrated why this matters. High-emission liquidity-mining models without sufficient utility, locking, or real demand can eventually convert incentives into sell pressure. Other major crypto systems have responded to similar economic problems through combinations of locking, fee burns, buybacks, or utility demand.
SpartanOS combines: controlled release + 1:1 Turbo demand + long-term locking + burn + AICS + O2 adaptive balancing + application demand. The key long-term metrics are therefore not simply how much RM is generated. They are: new RM supply, actual circulating supply, 1:1 Turbo buy demand, application demand, long-term locked RM, burned RM, and liquidity depth. These mechanisms are designed to improve the supply-demand structure. They do not constitute a guarantee of RM's market price. Ultimately, sustainable demand must grow sufficiently to absorb sustainable supply.
4. What actual cash flows move through the ecosystem, and what percentage ultimately accrues to the protocol or token holders?
SpartanOS separates three concepts that should not be confused: capital flow, protocol accrual, and token holder value accrual.
SpartanOS is not accurately described as a simple traditional fund-allocation model where, for example, a user deposits $100 and a fixed X% automatically becomes protocol revenue while Y% automatically becomes token-holder income. The more accurate approach is to analyze both the asset side and the RM supply side.
When capital enters SpartanOS, depending on the specific product and its economic rules, that capital contributes to the protocol asset structure, including functions such as liquidity, treasury, POL, and other protocol assets. Different products can have different asset paths. A specific product can therefore be analyzed in terms of how much capital contributes to LP, treasury/POL, or other protocol functions. However, a product-specific asset allocation should not be presented as a universal revenue-distribution percentage for the entire SpartanOS ecosystem.
At the same time, the protocol determines the corresponding RM minting, locking, and future release obligations according to the rules of that product. This means that when $100 enters the protocol, the relevant economic question is not only "Where was the $100 allocated?" It is also "What protocol asset value was created by that $100, and what corresponding future RM supply or token liability was created against it?" That RM does not necessarily enter the open market immediately. Its economic path can involve: locking → controlled release → 1:1 Turbo demand → buyback → burn → O2 adaptive balancing.
Therefore, what matters economically is not simply "How much of the $100 was distributed?" A more meaningful question is: "What protocol asset value was created by that $100, what future RM supply was created against it, how and when does that RM enter circulation, and how does the market absorb that supply?"
A simplified representation is: capital enters the protocol → protocol assets / treasury / POL / liquidity → RM minting according to protocol rules → RM locking and controlled release → secondary-market supply and demand → O2 monitors market conditions → buyback / burn / protection / liquidity mechanisms respond → the system moves toward a new supply-demand equilibrium. In simple terms: SpartanOS does not simply divide deposits; it manages a token economy.
The second part of the question, what ultimately accrues to token holders, is equally important. Assets accumulated in treasury/POL represent protocol accrual. Liquidity contributes to protocol economics and market depth. Neither should automatically be described as cash income paid directly to token holders. Therefore: treasury ≠ holder dividend; liquidity ≠ holder dividend; token price appreciation ≠ cash-flow distribution.
At present, RM and GD holder value capture should primarily be understood as indirect value accrual rather than a traditional fixed dividend model. For RM, value accrual can occur through 1:1 Turbo market-buy demand, locking, changes in circulating supply, burns, application utility, and application-revenue-linked buyback/burn mechanisms where applicable. For GD, value accrual is associated with its fixed 390,000 maximum supply, governance rights, and expanding application utility.
The next major economic layer is external application revenue. As GoPlay, TempleRaid, and future games, DEXs, cross-chain applications, RWA products, trading infrastructure, and other DApps generate genuine external economic activity, it becomes possible to track how much application revenue enters treasury, how much strengthens liquidity, how much is used for RM buyback/burn, and whether any portion is explicitly distributed to holders. Unless a smart contract or explicit protocol rule states that X% of protocol revenue is directly distributed to RM/GD holders, protocol assets should not be represented as direct holder cash flow.
Therefore, there is currently no accurate universal formula such as "$100 deposited = X% goes directly to RM/GD holders." A more meaningful due-diligence framework is: for every unit of capital entering SpartanOS, what protocol assets are created or acquired, what corresponding RM supply or future token liability is generated, how is that RM released into circulation, and what mechanisms balance that supply against real market demand and liquidity? And then: how much external application revenue is ultimately captured by treasury, liquidity, buyback/burn, or direct holder distribution?
These distinctions are essential: capital flow ≠ revenue; protocol assets ≠ holder dividend; buyback/burn ≠ direct cash distribution.
5. What is SpartanOS's crypto-native moat?
SpartanOS's moat is not RM alone, GD alone, O2 alone, or a single smart contract. Tokens can be copied. Smart contracts can be forked. Tokenomic parameters can also be replicated. The potential moat comes from the network effect created when multiple economic, application, infrastructure, liquidity, developer, and community layers operate together.
The first layer is the economic layer: RM + GD + O2 + 1:1 Turbo + AICS + Stable Vault + long-term staking + long-term liquidity bonds + Energy + burn + compounding. These mechanisms address different parts of the economic system: supply, demand, liquidity, long-term participation, and network health.
The second layer is the application layer. GoPlay, TempleRaid, and future applications are intended to move RM and GD beyond an internal protocol economy and into real application utility. As applications generate users, transactions, and external revenue, the application economy can begin feeding economic activity back into the RM/GD ecosystem.
The third layer is the AI / intent / execution layer. Intent infrastructure such as dappOS represents an important direction here. Its significance is not simply attaching an "AI" label to Web3. The objective is to reduce the complexity of blockchain interaction. A user expresses an intent; the relevant infrastructure can assist with routing, execution, and DApp interaction, while final asset ownership and settlement return to the blockchain layer. In simple terms: AI handles intelligence and execution assistance; blockchain provides trusted state, assets, and value settlement.
The fourth layer is blockchain infrastructure. SpartanOS uses AnubisChain for smart-contract execution and asset settlement, while the broader ecosystem connects with infrastructure across wallets, bridges, DEXs, explorers, indexing/data infrastructure, and cross-chain systems including areas such as The Graph, Blockscout, and LayerZero.
The fifth layer is ecosystem expansion. From Q3 onward, the ecosystem roadmap includes progressive development across: LayerZero + OFT cross-chain infrastructure, explorer upgrades, RocketSwap V3, Guard multisig, NFT + DID, AI Meme / AI Agent, RWA tokenization, a decentralized contract-trading platform, and contract-trading insurance. These should not all be represented as already-live revenue-generating products. Live products should be evaluated through product usage and on-chain data. Integrations under development should be evaluated through technical progress and official announcements. Future products should be verified through contracts, transactions, users, and revenue once deployed.
Major crypto networks demonstrate why this distinction matters. Ethereum's moat is not simply the EVM source code. Its network effect comes from developers, liquidity, wallets, applications, infrastructure, standards, and users interacting with one another. Likewise, an AMM formula itself can be forked; recreating the liquidity, integrations, users, developer tooling, and network effects around a mature DEX is significantly harder.
The network SpartanOS is attempting to build is therefore: token economy + liquidity + AI/intent + applications + blockchain infrastructure + developers + users + global community. It would be premature to describe this as an absolute, uncopyable moat. A more accurate description is that SpartanOS is building a network moat, whose strength must ultimately be demonstrated through liquidity depth, active users, application adoption, developer activity, external revenue, and cross-ecosystem integrations.
6. What exactly is verified on-chain, and what is merely asserted by off-chain AI infrastructure?
SpartanOS makes a clear distinction between on-chain state and off-chain computation.
Information that can be independently verified on-chain includes: wallet addresses, token contracts, RM/GD transfers, swaps, liquidity changes, burns, smart-contract interactions, transaction hashes, and final asset settlement. These facts do not require a user to trust what the SpartanOS frontend says. They can be independently checked against the relevant blockchain state through explorers and, where supported, third-party blockchain data/indexing infrastructure. That is one of the core properties of blockchain: users should be able to independently verify critical asset and transaction states rather than relying solely on the protocol's own interface.
However, not every component of the system is automatically on-chain. Elements such as portions of AICS scoring computation, intent interpretation, external-data analysis, API calls, agent decision-making, and other off-chain computation must be treated separately. If an off-chain system performs a calculation and then submits a transaction to the blockchain, the blockchain can prove that the final transaction occurred. It does not automatically prove that every preceding off-chain computation was correct. Therefore: result on-chain ≠ entire computation on-chain.
The trust boundary is more accurately described as: AI / off-chain infrastructure handles intelligence, analysis, and execution logic; blockchain verifies trusted state, assets, transactions, and final value settlement.
If off-chain computation itself needs to become cryptographically verifiable, additional technologies may be required, depending on the implementation, including public algorithms, oracles, TEEs, ZK proofs, cryptographic signatures, validator networks, or other verifiable-computation systems.
We therefore distinguish between on-chain facts, independently verifiable through blockchain state, and off-chain computation, requiring its own verification mechanism. A result being written to the blockchain should not be presented as proof that the entire off-chain computation was itself performed or verified on-chain.
7. How does SpartanOS prove an AI agent actually performed the service it claims to have performed?
There are two separate levels of proof: execution result verification and computation verification.
If an agent claims that it completed a transfer, swap, stake, or smart-contract interaction, the user should not have to trust a frontend message saying "Completed." The primary proof should be the blockchain. A user should be able to verify the transaction hash, contract call, input assets, output assets, wallet-state changes, and final settlement.
For example, if an agent claims "I swapped Asset A into Asset B for you," the relevant proof is not the agent's own statement. The user should be able to verify whether the transaction actually exists, which smart contract was called, how much Asset A left the wallet, how much Asset B was received, and whether the transaction successfully settled. That is execution result verification. Blockchain is particularly effective at proving that an asset-related action actually occurred.
However, a transaction hash does not automatically prove why the agent made a particular decision, whether every input was accurate, or whether every internal reasoning step was correct. That is a separate problem: computation verification. If the objective is to cryptographically verify the agent's internal computation, additional mechanisms may be required, such as TEEs, ZK proofs, oracle systems, validator networks, cryptographic signatures, or other forms of verifiable computation.
We therefore do not make the technically inaccurate claim that "because the transaction is on-chain, every AI computation behind it is automatically trustworthy." The more accurate model is: AI understands intent, performs analysis, and assists execution; blockchain verifies asset state and final execution.
Intent infrastructure such as dappOS illustrates the broader direction: users do not necessarily need to manually understand every blockchain operation involved in fulfilling an intent. The intent/execution layer can simplify routing and execution, while critical asset outcomes should still return to blockchain-verifiable settlement.
The principle is straightforward: do not rely only on an agent saying "I completed the task." Verify whether the blockchain proves that the task was actually completed. If the requirement goes further, to prove why the agent made the decision or that its internal computation was correct, then that requires a separate cryptographic or verifiable-computation layer, and should be evaluated according to the actual verification technology deployed.
How to use these
Quote an answer whole, or send the link to this section, rather than a sentence from it. Each answer carries its own limits in its own words: the mechanisms guarantee no price, treasury is not a dividend, a transaction on the chain does not prove the computation behind it, roadmap items are not live products, and the energy multiples are dynamic parameters read from the dApp on the day. A promoter who leaves those limits out is no longer quoting the project.