I can’t recall any President in my lifetime doing this many projects in one year to make America great. Can you?

I can’t recall any President in my lifetime doing this many projects in one year to make America great. Can you?

A Chairman said to me years ago, that most people are just "visitors of their problems." They see the problems, but "visit them" periodically when frustrated, and never take care of them. "Visiting problems" (and not solving them) contributes to a lot of misery. Be a solver.

Dev Update: Minotaur SN112 This sprint was all about fairness, reliability, and transparency. We've been rebuilding the scoring mechanism as this is what determines which miner wins and gets rewarded. The scoring is what ultimately pushes the miners to improve the solver code. It's also the key milestone that moves Minotaur from development mode into miner mode, so we're taking the time to get it right. What We've Shipped So Far: ▫️ Validators now score every submission against identical on-chain state, ensuring reproducible results every time. ▫️ Champion selection is now quorum-based. Independent validators vote to confirm the best solver, eliminating any single point of decision-making. ▫️ The validator /health endpoint now exposes peers, pinned blocks, and vote tallies, providing complete visibility into network activity. ▫️ Submissions now run inside isolated sandboxes, protecting validators from malicious or faulty miner code. Orders persist in a durable store, ensuring the system never loses state. ▫️ Miners now receive per-case results through /status, making it clear exactly how each submission performed and allowing them to quickly iterate and improve. Everything was first deployed in shadow mode to observe logging, running live without affecting rewards until stability was fully validated. How Scoring Works: Minotaur isn't tied to a single use case. So scoring must be applicable to any intent, not only swaps. Apps define intents, which represent a user's desired outcome, and provide their own scoring rules. Miners then build solvers designed to fulfill those intents. Every submission goes through the same evaluation pipeline: ▫️ Screen & Build → the submission is validated, sealed, and fingerprinted into a container. Every validator executes the exact same code. ▫️ Benchmark→ the solver is tested against both synthetic scenarios and real historical intents. This ensures it handles edge cases while proving its effectiveness in real-world conditions. ▫️ Score x2 → each submission must pass both a JS score and an on-chain score. ▫️ Challenge Champion → to become the new champion, a challenger must outperform the current best solver across every supported apps and by a meaningful margin. Matching performance isn't enough, and improvements in one area cannot come at the expense of another. ▫️ Quorum Vote → independent validators review the results and must reach consensus before a winner is confirmed. ▫️ Go Live → once approved, the new champion is hot-swapped into production and begins earning rewards. Two scores are the heart of it: The JS score evaluates plan quality according to each application's own requirements. This includes factors such as efficiency, correctness, and how effectively the outcome exceeds the user's minimum expectations. The on-chain score goes a step further. The plan is executed on a forked chain and graded directly by the application's smart contract. This measures actual value delivered rather than theoretical correctness, making the evaluation resistant to manipulation. Guarantees this gives the community: ▫️No regressions → a challenger is re-tested on the champion's strong cases before it can win. The network never moves backward. ▫️The bar keeps rising → the champion is re-scored each round against the latest tests, so winning by cutting corners doesn't work, only genuinely better solutions do. ▫️Grows cleanly → new apps onboard with their own scenarios scoring; new chains plug in directly. Scoring picks them up automatically, and the champion must keep performing across all of them. Why This Matters: Scoring represents roughly 90% of the solver system, and the solver system accounts for roughly 90% of Minotaur's codebase. Once scoring is fully tested and battle-proven, the team's focus can shift toward tooling, usability, Finney compatibility, and cross-chain application support. That's when builders will be able to deploy applications that interact directly with Bittensor itself. Intents can move stake, optimize yield, route subnet fee flows, and coordinate execution across the ecosystem. Bittensor won't simply be connected to Minotaur. It becomes a native execution environment. Our end goal: Minotaur has the potential of becoming the ultimate gate for value moving in and out of Bittensor, allowing automated actions to be performed such as auto staking and advanced alphanomics for subnets. Subnet fee flows, user payments, trading activity, and future intent-driven applications can all be routed through the network. We're laying that foundation now. This sprint tackles the hardest part of the system, and we're making sure it's done right before moving on.

Dev Update: Minotaur SN112 This sprint was all about fairness, reliability, and transparency. We've been rebuilding the scoring mechanism as this is what determines which miner wins and gets rewarded. The scoring is what ultimately pushes the miners to improve the solver code. It's also the key milestone that moves Minotaur from development mode into miner mode, so we're taking the time to get it right. What We've Shipped So Far: ▫️ Validators now score every submission against identical on-chain state, ensuring reproducible results every time. ▫️ Champion selection is now quorum-based. Independent validators vote to confirm the best solver, eliminating any single point of decision-making. ▫️ The validator /health endpoint now exposes peers, pinned blocks, and vote tallies, providing complete visibility into network activity. ▫️ Submissions now run inside isolated sandboxes, protecting validators from malicious or faulty miner code. Orders persist in a durable store, ensuring the system never loses state. ▫️ Miners now receive per-case results through /status, making it clear exactly how each submission performed and allowing them to quickly iterate and improve. Everything was first deployed in shadow mode to observe logging, running live without affecting rewards until stability was fully validated. How Scoring Works: Minotaur isn't tied to a single use case. So scoring must be applicable to any intent, not only swaps. Apps define intents, which represent a user's desired outcome, and provide their own scoring rules. Miners then build solvers designed to fulfill those intents. Every submission goes through the same evaluation pipeline: ▫️ Screen & Build → the submission is validated, sealed, and fingerprinted into a container. Every validator executes the exact same code. ▫️ Benchmark→ the solver is tested against both synthetic scenarios and real historical intents. This ensures it handles edge cases while proving its effectiveness in real-world conditions. ▫️ Score x2 → each submission must pass both a JS score and an on-chain score. ▫️ Challenge Champion → to become the new champion, a challenger must outperform the current best solver across every supported apps and by a meaningful margin. Matching performance isn't enough, and improvements in one area cannot come at the expense of another. ▫️ Quorum Vote → independent validators review the results and must reach consensus before a winner is confirmed. ▫️ Go Live → once approved, the new champion is hot-swapped into production and begins earning rewards. Two scores are the heart of it: The JS score evaluates plan quality according to each application's own requirements. This includes factors such as efficiency, correctness, and how effectively the outcome exceeds the user's minimum expectations. The on-chain score goes a step further. The plan is executed on a forked chain and graded directly by the application's smart contract. This measures actual value delivered rather than theoretical correctness, making the evaluation resistant to manipulation. Guarantees this gives the community: ▫️No regressions → a challenger is re-tested on the champion's strong cases before it can win. The network never moves backward. ▫️The bar keeps rising → the champion is re-scored each round against the latest tests, so winning by cutting corners doesn't work, only genuinely better solutions do. ▫️Grows cleanly → new apps onboard with their own scenarios scoring; new chains plug in directly. Scoring picks them up automatically, and the champion must keep performing across all of them. Why This Matters: Scoring represents roughly 90% of the solver system, and the solver system accounts for roughly 90% of Minotaur's codebase. Once scoring is fully tested and battle-proven, the team's focus can shift toward tooling, usability, Finney compatibility, and cross-chain application support. That's when builders will be able to deploy applications that interact directly with Bittensor itself. Intents can move stake, optimize yield, route subnet fee flows, and coordinate execution across the ecosystem. Bittensor won't simply be connected to Minotaur. It becomes a native execution environment. Our end goal: Minotaur has the potential of becoming the ultimate gate for value moving in and out of Bittensor, allowing automated actions to be performed such as auto staking and advanced alphanomics for subnets. Subnet fee flows, user payments, trading activity, and future intent-driven applications can all be routed through the network. We're laying that foundation now. This sprint tackles the hardest part of the system, and we're making sure it's done right before moving on.