Why We Rejected the Training Layer

Training Layer was one of the most internally coherent ideas in the entire process. We still rejected it as the primary direction.

The reason was simple: people who want to complete an action do not necessarily want to train for it first.

A new name did not create new value

We had improved paper trading by connecting simulation to real intent. “Shadow Actions,” “Activation Sandbox,” and “Training Layer” described the mechanism more accurately. They did not prove that rehearsal was valuable enough to become a habit or a budget line.

For a user, a good wallet flow, clear explanation, small initial amount, and safe execution may be preferable to a separate practice stage. For a protocol, the primary goal is usually real activation and retained liquidity—not activity inside a simulator.

The engineering burden was too high for the evidence

To provide meaningful rehearsal, the product needed current protocol integrations, transaction simulation, wallet-like approvals, state updates, failure handling, and credible outcome tracking. That approached wallet and execution-infrastructure complexity.

The cost might have been justified if strong demand existed. We had no such evidence. Building expensive realism before validating the desire to rehearse repeated the same mistake as Strategy League: solving the mechanism in detail before proving motivation.

This was not evidence that training products can never work. It was a decision under uncertainty: given our resources and the current evidence, Training Layer was not the best primary bet.

What survived

Several components remained valuable:

• transaction simulation before execution;
• human-readable previews of permissions and asset changes;
• structured action definitions;
• bounded environments for agents;
• real-time logs that make behavior understandable;
• the ability to test policies with small amounts.

These features did not require training to be the product. They could become controls around real execution.

That changed the central question:

Are users willing to practice an action first?

became:

Are users willing to grant an agent narrow, revocable authority to complete a real, recurring DeFi task?

The second question carried much higher security and engineering costs. It also connected directly to a result the user already wanted.