PRD
Product semantics
Owns user journeys, entities, surfaces, risk framing, and the mental model for spells, positions, triggers, and automation.
System Thesis
Bounded automation for live market conviction.
Spells v2 is an event-driven DeFi system that lets users express a market view, route that view through a curated Spell, and execute or automate the result through a user-controlled Metavault. The key promise is not generic automation. It is legible automation with explicit limits, visible risk, and durable safety paths when infrastructure degrades.
Core Loop
4
Discovery, execution, monitoring, automation.
Canonical Factors
5
Growth, liquidity, risk, regulation, shock.
Execution Layers
2
Durable orchestration plus per-vault transaction control.
Safety Default
Fail Closed
Protective actions continue; stale or unsafe execution does not.
What the team is actually building
Users discover a signal, choose a bounded strategy, route it through a user-owned account, and keep visibility after entry. The product is not a generic terminal. It is an opinionated loop with explicit ownership and risk framing at every handoff.
How the product turns intent into on-chain state
Edge workers own the contract surface, workflows own durable business sequencing, and the TLM owns ambiguous transaction state. This separation is what lets the system keep user requests fast while still treating blockchain execution as a durable actor problem.
Why degraded modes are a first-class part of the design
Spells assumes infrastructure failures will happen. Position monitoring, alerting, trigger continuity, and emergency close each have a minimum dependency set so safety-critical behavior survives the loss of a single component.
Panorama
From market intent to bounded action, the product loop and runtime path stay separate on purpose.
Spec ownership
Product ownership
PRD and spec are complementary, not redundant.
The docs deliberately split into two lenses. The PRD defines what the user experience must mean. The spec defines how the system enforces those promises in runtime, storage, resilience, and security. This walkthrough keeps that line visible so alignment conversations stay grounded.
SPEC
Implementation semantics
Owns topology, orchestration, storage authority, service boundaries, failure modes, observability, and testing gates.
RULE
Conflict resolution
If a topic appears in both places, PRD owns product meaning and spec owns runtime behavior. This site mirrors that rule instead of flattening it away.
Spec runtime
The operating model is built around four principles.
Spells v2 is not an incremental patch on the prototype. It is a clean reimplementation optimized around durable orchestration, serialized execution, compute-near-data, and a single relational authority with explicit degraded paths.
Clean reimplementation
The architecture resets around v2 constraints instead of carrying prototype seams forward into launch-critical systems.
Two-layer execution
Workflows own business sequencing. The TLM owns blockchain ambiguity per Metavault, including nonce serialization and recovery.
Compute near data
Edge handles user-facing latency; regional workflows stay close to Neon for high-frequency monitoring and enrichment loops.
| Surface | Why it exists | What it must not do |
|---|---|---|
| Next.js / Vercel | User-facing UI, wallet flows, dashboards. | It is not trusted for autonomous trading or safety-critical automation. |
| Cloudflare Worker | Owns the public contract surface, auth, reads, and emergency entrypoints. | It does not become a hidden second frontend or bypass scoped access rules. |
| Cloudflare Workflows | Owns durable monitoring, trigger evaluation, and refresh pipelines. | It does not own transaction ambiguity or serialized nonce control. |
| Durable Objects | Own per-vault transaction lifecycle, session mirror use, and finality. | They are not a second general-purpose database. |
PRD + Spec
There are three flows the whole system bends around.
Most documents in the set either define one of these flows directly or define the controls that keep them safe. If the team stays aligned on these three, the rest of the spec reads as reinforcement rather than complexity.
Discover → trigger → automate
Prediction markets and WorldMonitor factors feed into bounded Triggers, which can dispatch a spell or a GMX trade when a condition is met.
Cast → TLM → chain confirmation
User-facing execution hands off to durable backend logic, then to a per-vault actor that handles gas estimation, submission, verification, and recovery.
Open exposure → monitor → alert or act
Positions stay observable after entry. Monitoring is continuous, alert thresholds are explicit, and degraded automation is surfaced as attention state instead of being hidden in backend logs.
Spec map
Read it in layers, not in file order.
This microsite rearranges the Markdown set into an alignment narrative. The original docs still matter when the team needs detail, but the fastest path to shared context is to move from product meaning to system shape to execution risk to launch sequencing.
For broad team alignment
- Product overview and pillars.
- User journeys and account model.
- Runtime topology and source-of-truth boundaries.
- Execution + security + degraded behavior.
For implementation planning
- Execution engine and GMX integration.
- Market intelligence, monitoring, and resilience.
- Observability, testing, and constants.
- Roadmap, deferred questions, and launch guardrails.