# Yield Intent Compute Network ## Submission Draft Yield Intent Compute Network is a Bittensor-based yield intent compute subnet. Users submit yield targets and risk constraints. The platform converts those intents into standardized compute tasks. Miners provide GPU/CPU compute to run the platform's unified model. Validators verify computation results, backtest performance, and risk metrics. The platform does not promise fixed returns. It provides verified strategy discovery, return simulation, and risk evaluation. **Selected design mode:** Platform-provided unified model; miners provide compute. **Core boundary:** No custody of user funds. No guaranteed returns. No direct miner access to user assets. --- ## 1. Project Vision Yield Intent Compute Network turns a user's vague yield goal into a computable, verifiable, and comparable strategy task. Users do not need to know which assets to buy, which strategy to use, how to backtest it, or how to maintain complex data and compute infrastructure. A user only needs to express a yield intent, for example: ```text Capital: 1,000,000 Period: 30 days Target return: 5% Maximum acceptable loss: 3% Risk preference: medium-low Asset universe: BTC, ETH, stablecoins, mainstream DeFi yield pools Leverage: not allowed ``` The platform converts this intent into a standardized compute task and dispatches it through a Bittensor subnet. Miners run the platform's unified model. Validators verify the results. The user receives a verified strategy report, not a guaranteed profit promise. **Important boundary:** The 5% return is a target constraint, not a guaranteed result. The platform provides computation, simulation, comparison, and risk evaluation. --- ## 2. Problem Background Retail users, active Web3 traders, and small institutions often do not lack information. They lack systematic computation and verification. Current pain points: - Users know their desired return but do not know how to translate it into an executable strategy. - Many strategies only show upside return and hide maximum drawdown, volatility, and tail risk. - Backtests can be over-packaged, and users cannot easily tell whether a model is overfitted. - Multi-asset, multi-period, multi-scenario simulations require persistent data engineering and compute capacity. - Centralized quant tools are often opaque; users cannot reproduce or audit model outputs. The core problem is not "how to guarantee profit." The core problem is how to make the computation behind a yield target standardized, verifiable, and continuously improvable. --- ## 3. Solution This project adopts **Mode 1: platform-provided unified model, miner-provided compute**. The platform provides: - Unified prediction model - Data processing pipeline - Backtesting framework - Risk metrics - Output schema - Miner client - Validator verification logic Miners provide: - GPU/CPU compute - Stable uptime - Correct execution of platform tasks - Timely submission of results This design is suitable for the early stage because it lowers cold-start complexity. Miners do not need to design financial strategies, and validators can more easily verify whether miners actually completed the required computation. The platform provides users with: - Recommended portfolio strategy - Expected return range - Maximum drawdown estimate - Volatility and risk level - Historical backtest results - Stress test results - Execution constraints and risk warnings - Post-period real performance review --- ## 4. Role Design | Role | Responsibility | Incentive | | --- | --- | --- | | User / Customer | Submit yield target, investment period, risk constraints, and asset universe. Purchase strategy reports, simulations, or API access. | Get more systematic strategy discovery, backtesting, and risk evaluation than manual research. | | Platform / Subnet Owner | Provide unified model, data interfaces, task format, miner client, validator logic, and commercial entry point. | Earn protocol fees, subscriptions, API revenue, and long-term ecosystem value. | | Miner | Deploy platform client, provide GPU/CPU compute, run prediction, backtesting, Monte Carlo simulation, and stress testing tasks. | Earn user-fee share and TAO incentives by completing computation correctly, quickly, and reliably. | | Validator | Re-run sampled tasks, validate hidden test data, check result hashes, compare multi-node outputs, and assign miner weights. | Earn validator rewards and TAO-related revenue by maintaining scoring credibility. | --- ## 5. Incentive and Mechanism Design Because the current version uses a platform-provided unified model, miner competition is not about who invents the most aggressive strategy. It is about who can complete computation more correctly, reproducibly, quickly, reliably, and cost-effectively. ```text Miner Score = Correctness × 40% + Reproducibility × 20% + Speed × 15% + Availability × 15% + Cost Efficiency × 10% ``` ### Correctness The miner's output must match the platform's standard model and data processing rules. Validators check whether the miner skipped, miscomputed, or modified required steps. ### Reproducibility When validators re-run sampled tasks, key metrics should be reproducible within an accepted error range. ### Speed The miner should finish assigned tasks within the required time window. ### Availability The miner should remain online and consistently accept computation tasks. ### Cost Efficiency For the same valid task output, miners that achieve lower resource cost can receive better scoring. --- ## 6. System Architecture and Workflows The system consists of a user entry layer, intent parser, platform-controlled unified model, miner compute network, validator verification network, and report layer. The core principle is: > The platform provides model and rules. Miners provide compute. Validators verify whether the computation is correct. Users receive verified strategy reports. ### 6.1 System Architecture ```mermaid flowchart TD U[User / Customer
Yield target + risk constraints] --> UI[Yield Intent App
Form / API / Dashboard] UI --> P[Intent Parser
Standard task JSON] P --> Q[Task Scheduler
Queue + dispatch] Q --> M1[Miner Node A
GPU / CPU] Q --> M2[Miner Node B
GPU / CPU] Q --> M3[Miner Node N
GPU / CPU] subgraph Platform[Platform-Controlled Layer] D[Market and On-chain Data] Model[Unified Yield Model] Schema[Output Schema] end D --> Model Model --> M1 Model --> M2 Model --> M3 Schema --> M1 Schema --> M2 Schema --> M3 M1 --> R[Submitted Results
Portfolio + metrics + hash] M2 --> R M3 --> R R --> V[Validator Network
Replay + hidden tests + comparison] V --> S[Score and Weight
Correctness + speed + availability] S --> Report[Verified Strategy Report
Return range + drawdown + risk score] Report --> U S --> Reward[Reward Distribution
Miner + Validator + Protocol] ``` ### 6.2 User-to-Report Workflow ```mermaid sequenceDiagram participant User as User participant App as Platform App participant Scheduler as Task Scheduler participant Miner as Miner GPU Node participant Validator as Validator participant Report as Report Layer User->>App: Submit yield intent: capital, target return, max drawdown App->>App: Convert intent into standard task JSON App->>Scheduler: Create compute task Scheduler->>Miner: Dispatch unified model task Miner->>Miner: Run prediction, backtest, Monte Carlo, stress test Miner->>Scheduler: Submit result + model/data hash Scheduler->>Validator: Send result for verification Validator->>Validator: Re-run sample tasks, check hidden tests, compare outputs Validator->>Report: Approve score and risk metrics Report->>User: Return verified strategy report ``` ### 6.3 Step-by-Step Workflow 1. **User submits yield intent** The user enters capital, target return, investment period, maximum acceptable loss, risk preference, asset universe, and leverage limits. 2. **Platform standardizes the task** The platform converts natural language or form input into a standard JSON task, defining data requirements, model version, risk constraints, and output metrics. 3. **Miner executes computation** Miners run the platform's unified model to complete prediction, backtesting, Monte Carlo simulation, stress testing, and portfolio optimization. 4. **Validator verifies results** Validators perform sampled re-runs, hidden test validation, cross-miner comparison, result hash checks, and anomaly audits. 5. **User receives verified report** The user receives portfolio strategy, expected return range, maximum drawdown, risk score, stress test results, execution constraints, and risk warnings. --- ## 7. Validation Mechanism The validation mechanism has two layers: 1. Verify that miners actually completed the platform-defined computation. 2. Verify that the strategy output has basic risk-return quality and is not merely overfitted to history. ### 7.1 Computation Correctness Verification Validators check: - Random task re-runs - Hidden test data - Output hash - Model version hash - Data version hash - Cross-miner output consistency - Anomaly-triggered audits ### 7.2 Strategy Quality Verification The strategy report is evaluated through: - Historical backtesting - Out-of-sample testing - Stress testing - Volatility and drawdown calculation - Post-period real performance review ```text Strategy Report = expected return range + max drawdown + volatility + risk score + stress-test loss + confidence + execution constraints ``` The validation goal is not to prove future profit. It is to prove that the computation process is credible, reproducible, and risk-aware. --- ## 8. Economic Model Users pay for strategy computation, return simulation, and risk evaluation. The network distributes revenue based on contribution. An early-stage fee split can be: | Revenue Allocation | Share | Description | | --- | ---: | --- | | Miner Reward | 50% | Rewards miners that complete computation and pass validation. | | Validator Reward | 20% | Rewards validators for re-computation, audit, and weight assignment. | | Protocol Fee | 20% | Funds platform, treasury, model development, product, and ecosystem operations. | | Data & Infrastructure | 10% | Covers market data, on-chain data, storage, execution infrastructure, and risk systems. | User-side monetization can include: - One-time strategy report - Monthly subscription - Institutional API access Bittensor-side incentives can use validator weights to distribute TAO emissions to miners that are correct, stable, fast, and cost-efficient over time. --- ## 9. Market Rationale The project targets three early customer groups. ### High-Net-Worth Retail Users They have capital and yield goals but lack systematic backtesting, risk simulation, and strategy comparison capabilities. ### Active Web3 Traders They are willing to pay for better portfolio suggestions, risk controls, and cross-platform yield opportunities. ### dApps and Institutional APIs They need to embed yield strategy, risk scoring, and simulation results into their own products without building a compute and validation network from scratch. Compared with centralized quant tools, the differentiation is not simply "we have a magic model." The differentiation is that open miner compute and reproducible validator checks make the strategy generation process, risk metrics, and reward distribution auditable. --- ## 10. MVP Plan The MVP does not touch real user funds. It does not provide automatic custody. It does not promise returns. The first phase validates three things: 1. Users are willing to submit yield intents. 2. Miners can reliably run the platform's unified model. 3. Validators can objectively verify results. ### Week 1: User Entry and Task Format Build the yield intent form, task JSON schema, and basic strategy report page. ### Week 2: Platform Unified Model Baseline Build baseline asset allocation, historical backtesting, basic prediction, risk metrics, and stress tests. ### Week 3: Miner Client Build task receiving, model execution, result submission, model version logging, and data version logging. ### Week 4: Validator and Scoreboard Build sampled re-computation, result comparison, scoring dashboard, and demo dataset. The first MVP success criterion is not proving that the model can always make money. It is proving that the full loop can run: ```text Yield intent → Standard task → Distributed computation → Reproducible validation → Strategy report ``` --- ## 11. Key Risks and Boundaries ### No Guaranteed Return The platform must not market the product as guaranteed yield or fixed-income wealth management. A target return is a user constraint, not a promise. ### No Miner Custody Miners should never directly access user funds, wallets, private keys, or execution authority. ### Backtest Overfitting Historical performance can be misleading. The system must include out-of-sample tests, stress tests, and post-period reviews. ### Compliance Risk Financial strategy products can trigger regulatory concerns. The MVP should start as strategy computation, simulation, and risk evaluation, not discretionary asset management. ### Data Quality Bad market data produces bad strategies. The platform must version, audit, and validate data sources. --- ## 12. Summary Yield Intent Compute Network is a Bittensor subnet for verified yield strategy computation. Users submit yield goals and risk constraints. The platform provides a unified model and task framework. Miners provide compute to run the model. Validators verify correctness and risk metrics. Users receive verified strategy reports. The early version focuses on computation and validation, not fund custody or guaranteed returns. This keeps the system easier to launch, easier to validate, and safer from both technical and regulatory risk.