Sovereign

Inspiration

Digital creators hold billions of dollars in value locked in digital products from software repositories and newsletters to YouTube channels and Notion templates. Yet, they have zero access to liquid equity markets. Traditional solutions require complex legal setups or centralized platforms that introduce counterparty risk and lack transactional transparency.

We built Sovereign to show how a modern Creator Liquidity Exchange can enable instant, fractional asset trading with a mathematically airtight ledger one where the supply of creator shares is guaranteed 100% consistent with zero phantom shares, even when hundreds of buyers compete for the exact same order book in a global active-active database setup.

What it Does

Sovereign is a high-throughput, real-time creator asset exchange.

• Fractional Share Trading: Browse creator assets ($PRAGMATIC, $FIRESHIP, $SHADCN) and place limit buy or sell orders with real-time execution.
• Real Creator Metrics: Asset cards show live data - shadcn/ui (117.7k GitHub stars), Fireship (2.8M YouTube subscribers), The Pragmatic Engineer (580,000+ newsletter subscribers).
• TradingView Candlestick Charts: Full OHLC price history with 10S/30S/1M/5M/1H intervals.
• Live DynamoDB Activity Feed: Every trade, OCC collision, and stampede event streams into a DynamoDB firehose and appears in the market home activity feed in real time.
• Developer Telemetry Console: A live SSE terminal logs backend transactions, latency percentiles (p50/p95/p99), and OCC collision rates.
• The Stampede Simulator: Click "Run Stampede" to fire 60 concurrent trades at once. This forces OCC collisions, rollbacks, and jittered retries, finishing with a database audit proving Zero Over-Allocation (Balance Delta: 0).
• Price Alerts: Set target price alerts on any asset toast notifications fire when your price is crossed.

How We Built It

Dual-Database Architecture

The most important architectural decision: two databases, each doing what it's best at.

Aurora DSQL (Stockholm, eu-north-1) owns all consistency-critical state: orders, trades, ownership ledger, assets. Every trade executes under SERIALIZABLE isolation. OCC collision resolution (SQLSTATE 40001) is the core product mechanic not error handling.

Amazon DynamoDB owns the high-throughput activity firehose: trade events, OCC collision logs, stampede telemetry. Single-table design with 3 GSIs and 30-day TTL auto-expiry. No transactions needed here just sub-millisecond append-only writes at infinite throughput.

Design principle: DSQL for correctness. DynamoDB for throughput.

Core Stack

• Next.js 15 & TypeScript: App Router, Server Actions, API Routes
• AWS Aurora DSQL: Primary transactional DB in eu-north-1, IAM token signing via @aws-sdk/dsql-signer
• Amazon DynamoDB: Activity firehose, single-table design, 3 GSIs
• Drizzle ORM: Schema modeling and query layer
• TradingView lightweight-charts: OHLC candlestick charts
• Clerk: Authentication with one-click demo login
• SSE: Real-time telemetry streaming to judge console
• Three.js / React Three Fiber: WebGL fluid landing page

Challenges We Faced

1. Distributed DDL Limitations Aurora DSQL does not support standard PostgreSQL SERIAL datatypes or synchronous index creation. Drizzle's built-in migrator hardcodes SERIAL and synchronous USING btree indexes. We built a custom programmatic migration runner that pre-creates metadata tables using standard integers and issues CREATE INDEX ASYNC and CREATE UNIQUE INDEX ASYNC statements.

2. Saturating Connection Pools Network saturation from local nodes to Stockholm DSQL caused transaction timeouts during concurrency stress. We decoupled telemetry logging, optimized pool to max: 80 with 15000ms timeout, and batched dashboard queries to reduce round-trips.

3. Vercel Serverless Timeout Vercel functions time out at 60 seconds. 300 concurrent orders against Stockholm DSQL exceeded this. We restructured the UI stampede into 3 batches of 20 with 200ms gaps and a 45-second escape hatch returning partial results.

4. DynamoDB Scan Paging DynamoDB scans are physically paged newly written events were being masked by page boundaries. We expanded scan limit to 1000 and sort in memory to surface the full recent log.

5. OCC Error Wrapping Drizzle wraps native Postgres errors in DrizzleQueryError, placing the real DB error in err.cause instead of err directly. Our retry loop initially missed 40001 codes. Fixed by inspecting err.cause?.code to correctly catch and retry serialization failures.

Accomplishments We're Proud Of

• Perfect Supply Integrity: Stampede consistently audits to Balance Delta: 0 mathematically proving zero phantom shares under maximum concurrency.
• 60x Performance Gain: Optimized stampede from 197,850ms to ~3,200ms through pool tuning and transaction batching.
• Dual-DB Architecture: Justified, clean split between DSQL transactional core and DynamoDB throughput firehose each database doing exactly what it's designed for.
• Real Creator Data: Live GitHub stars and YouTube subscriber counts on asset cards make the market feel real.

What We Learned

• How to design schemas without referential foreign keys (which DSQL restricts for active-active scalability).
• How to handle 40001 serialization failures gracefully with jittered exponential backoff retry loops.
• The architectural difference between consistency-critical state (needs DSQL) and throughput-critical telemetry (needs DynamoDB).
• Aurora DSQL's globally-replicated, lock-free concurrency model and how OCC can be the product mechanic, not just infrastructure.

What's Next for Sovereign

• AMM liquidity pools for automated market making on creator assets
• Creator Analytics API integration for real-time valuation signals
• Multi-region DSQL deployment to demonstrate active-active consistency across us-east-1 and eu-north-1 simultaneously

Built With

• amazon-dynamodb
• aws-aurora-dsql
• clerk-auth
• drizzle-orm
• lenis-scroll
• lightweight-charts
• next.js
• react-three-fiber
• recharts
• server-sent-events
• tailwindcss
• three.js
• typescript