# GM FM
### 1. What We’re Building
We’re launching the first always-on, talk-only crypto radio stream. Every news bulletin, deep-dive segment, and ad read is generated in real time by a coordinated system of AI agents — with <2 minutes from signal to stream.
#### Core Features:
* Real-time response: Breaking news becomes audio within 2 minutes
* Synthetic voices only: No humans on-air
* 24/7 programming: Short bulletins, longer analytical shows, adaptive content
* No accounts, no tracking: Anonymous by design
* On-chain ad billing: Sponsors stay pseudonymous, all payments via Base L2
***
### 2. How It Works — The AI Agent Stack
Each core function is handled by an isolated AI-powered service. Together, they maintain the flow of live crypto coverage, entirely autonomously.
#### 🧠 News Agent
* Scrapes on-chain alerts, RSS feeds, X/Twitter firehose
* Filters sources and deduplicates events
* Converts stories into radio copy via GPT-4o
* Publishes news.item.created to the pipeline
* Latency target: first radio script within 30 seconds of signal
#### 🎬 Showrunner
* Manages the minute-by-minute program clock
* Chooses show format: short (90s), medium (15m), or long (60m)
* Picks synthetic hosts, places ads, and issues segment requests
* Writes schedule changes to programme\_history for auditability
* Reacts in real time to sentiment signals and breaking events
#### 🗣 Voice Synth Service
* Sends each script line to ElevenLabs, receives MP3 in <3s
* Stores audio in S3 and publishes audio.line.ready
* Falls back to cached lines if synthesis fails
* Streams content via HLS in 6-second chunks
#### 💬 Sentiment Agent
* Monitors live listener chat
* Scores messages for emotion, toxicity, and relevance
* Updates real-time popularity metrics per host and topic
* Feeds the Showrunner with swap signals for unpopular content
* Embedding rate capped at 100 msg/s
#### 💰 RTB Ad Engine
* Real-time bidding via WebSocket; CPM-based auctions
* On-chain escrow contract in USDC on Base L2
* GPT-4o writes 30s native ad reads, Voice Synth voices them
* On playback, a signed impression receipt is posted on-chain
* All ad reads audibly marked as “Sponsored”
#### ✅ Moderation & Compliance
* Runs all chat and script content through OpenAI Moderations + AWS Comprehend
* Blocks or delays toxic content
* Injects “Sponsored” tags automatically
* Logs every paid placement on-chain for full transparency
* Borderline content is quarantined in an SQS Dead Letter Queue
***
### 3. The Full Production Pipeline
| Stage | Time Budget |
| ---------------------------- | ------------- |
| News detection → script | ≤ 30 seconds |
| Segment creation & host pick | ≤ 500 ms |
| Voice generation per line | ≤ 3 seconds |
| First audio chunk available | ≤ 120 seconds |
| Long-form shows (full) | ≤ 4 minutes |
HLS streaming updates every 6 seconds with fresh audio segments.\
***
### 4. Sponsorship Workflow
#### 4.1 Campaign Setup
* Sponsor creates campaign via web portal: set CPM, daily cap, and prompt hints
* Portal returns a unique Base L2 deposit address
* USDC received → campaign funded → eligible to bid in real time
#### 4.2 Real-Time Bidding
* Each ad slot includes topic + CPM floor
* Sponsors submit bids via WebSocket (CPM + max impressions)
* Redis ZSET selects highest bidder; second-price logic optional
* GPT-4o writes native ad read → voiced and stitched into stream
#### 4.3 Proof & Escrow
* Each playback creates a SHA-256 hash (segment ID + timestamp)
* Hash is signed and posted on-chain via recordImpression()
* Contract debits escrow; emits ImpressionReceipt
* Gas too high? Queue for batch posting later (90% gas savings)
#### 4.4 Budget Monitoring
* Alerts when campaign drops below 10% remaining
* Auto-refund on campaign end if unused funds remain
* Withdrawals require 2-of-3 multisig (system key + ops hot-key)
#### 4.5 Reporting
* CPM is USD-pegged, converted via Chainlink
* GraphQL subgraph indexes all receipts
* Real-time dashboards + CSV export (with tx\_hash for self-audit)
***
### 5. Infrastructure Overview
Everything runs on AWS with automated deployment and scaling.
#### Compute & Orchestration
* Amazon EKS for container orchestration
* Spot instances for all agents except RTB Engine
* Karpenter + Cluster Autoscaler handle node scaling
#### Networking
* Istio service mesh: mTLS, retries, traffic mirroring
* API Gateway for WebSocket endpoints (chat + RTB)
* Layer-7 routing inside mesh
#### Storage & Messaging
* S3: MP3 storage, HLS segments, logs
* Redis: sentiment scores, RTB bids, deduplication filters
* Postgres: program clock, ad ledger
* OpenSearch: news embeddings + similarity search
* EventBridge: core pub/sub event bus
* SQS: queues for moderation, synthesis, encoding
#### Media Pipeline
* FFmpeg jobs generate audio chunks and write directly to S3
* CloudFront delivers HLS with adaptive caching (12h for .ts, 1m for playlists)
#### Observability
* Prometheus + Grafana: latency, token usage, queue depth
* AWS CloudWatch for logs + alerts
* AWS X-Ray: trace full pipeline from news trigger to audio stream
***
### 6. Performance Targets
| Metric | Goal |
| ------------------------------- | ------------------------------ |
| Headline → air (short) | ≤ 120s (P95) |
| Full show (long-form, 15–60min) | ≤ 4 min |
| Ad bid → playback | ≤ 3 seconds |
| Listener concurrency | 100,000+ |
| Stream availability | 99.9% monthly |
| Recovery time objective (RTO) | 30 minutes |
| Recovery point objective (RPO) | 1 hour (Postgres + S3 backups) |
***
### 7. Principles & Design Philosophy
* Real-time media: Crypto moves fast — the stream should too.
* Modular agents: Each component is containerized and hot-swappable.
* Anonymity-first: No cookies, no accounts, no personal data collected.
* On-chain accountability: Every ad logged immutably.
* Resilient by default: Multi-AZ, autoscaled, backed up.
***
For technical specs, developer docs, and deployment guides, see:
* Agent Architecture
* Ad System & Smart Contracts
* Deployment & Observability
* Stream Format & HLS Specs
End of section.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://gm-fm.gitbook.io/gm-fm/gm-fm.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.