Spells v2: The Edge-Native Pivot

Moving from a brittle, centralized database architecture to a robust, highly-distributed "Actor Model" powered by Cloudflare Durable Objects.

The Executive Summary

Our initial v2 architecture relied heavily on a central database (Neon Postgres) to store every user's portfolio, triggers, and highly sensitive session keys. This forced our globally distributed edge workers to constantly sync back to a central point, creating latency, complex synchronization bugs (the "outbox" problem), and a massive single point of failure.

The Pivot: We are completely removing Neon from the user-data path. Instead, every user's Smart Account gets its own dedicated, isolated micro-server at the edge called a MetavaultDO. This "Edge Actor" acts as both the database and the execution engine for that specific user, unlocking unparalleled security, speed, and simplicity.

The Paradigm Shift

Frontend / Users

⬇️
Global Trigger Evaluator Worker (Sweeps all users)

⬇️ ⬆️
Central Database (Neon Postgres)

Stores EVERYTHING: Keys, Triggers, Positions for ALL users.

The Bottleneck

A single global "Trigger Evaluator" worker had to wake up every 60 seconds, query the central database for all active users, evaluate their triggers, and then push intents back to the database. As user count grows, this global sweep becomes slow, expensive, and fragile.

The Security Risk

All encrypted session keys for all users were stored in one central database. If the API layer connecting to the database was compromised, the attacker could theoretically access the execution material for the entire platform.

Frontend / User

⬇️
Stateless API Gateway

⬇️
User A's MetavaultDO
User B's MetavaultDO
User C's MetavaultDO

Isolated instances. Each contains its own internal SQLite database and evaluating loop.

The Actor Model

Instead of one worker sweeping all users, each user's MetavaultDO wakes itself up. It evaluates its own triggers using its own internal database. 10,000 users means 10,000 isolated execution environments running in parallel at the edge.

The "Fortress DO"

The central database no longer holds user keys. The MetavaultDO owns its keys, and it performs a strict internal identity check on every incoming request. It doesn't trust the API; it verifies the caller's identity against its own internal records.

Practical Business Benefits

🛡️

Massively Reduced Security Attack Surface

By implementing the "Fortress DO", a compromise of our main API no longer equates to a compromise of user funds. An attacker cannot bulk-dump user session keys from a central database because they aren't there. Each vault is an isolated vault. If an attacker tries to command a vault, the DO checks the cryptographic identity of the caller and rejects unauthorized requests natively.

🛠️

Developer Experience & Maintainability

We eliminated "hallucinated overengineering". Before, developers had to write complex code to handle race conditions, queue retries, and "outbox patterns" to keep the edge execution synced with the central database. Now, developers write code as if they are writing a program for a single user. The DO's internal SQLite provides immediate, strong consistency. This drastically reduces bug surface area and speeds up feature development.

Instant User Experience

Because the DO is both the database and the execution engine, when a user creates a trigger on the frontend, the response is immediate. There is no waiting for database replication lag. The user's dashboard reads directly from their personal DO, meaning the UI is always perfectly in sync with the execution reality.

💰

Cost Effectiveness at Scale

Relational databases charge heavily for high-frequency reads/writes. A global trigger evaluator polling a database every 60 seconds for thousands of users is incredibly expensive. Cloudflare Durable Objects charge fractions of a cent for compute, and their internal SQLite storage operations are free. We only use the expensive central database for things that actually need to be global (like World Monitor signals and analytics telemetry).

A Robust Foundation for the Web3 Future

This isn't just an optimization; it's a platform shift. By perfecting the "Edge Actor" model, we are building a generalized, hyper-scalable engine for Web3 automation and AI.