Evaluating Rythm: A Security & Architecture Guide for IT Teams

Rythm can provide immense risk reduction at an extremely low cost for organizations.

This guide is written for the person who has to answer: does adding this tool increase our risk, and is the benefit worth it?

The one-paragraph frame for the security team. Rythm is an email paywall for Gmail and Outlook. The decision model is binary and rules-based: if the sender is on the user’s automatically-built guest list (contacts, sent folder, inbox activity), the message is delivered; if not, the sender is asked to pay a small cover charge that settles directly to the user’s personal wallet. Rythm does not scan content to make filtering decisions, does not store email bodies or attachments, and is never in the flow of funds.

We are going to walk through that question honestly. Not with marketing language or product screenshots, but with the architecture, the security controls, the data handling, and the vendor risk profile. By the end, you should have what you need to make an informed decision or to tell us exactly what is missing.

---

Part 1: What Rythm Is and Where It Fits

The 60-Second Version

Rythm is a supplementary email filtering layer that sits downstream of your existing email security stack. It connects to Gmail or Outlook via OAuth and adds a single deterministic check: is this sender known to the user, or not?

• Known senders (a user-controlled approved list, built automatically from contacts and email activity) pass through untouched.
• Unknown senders are filed into a separate folder the user can review at any time. Nothing is deleted. Users can rescue any email from this folder, and that sender is approved going forward.
• Unknown senders who include a micropayment proof (the amount is set by the user, typically a few cents) are delivered to the inbox marked with a PAID label, and the payment settles directly to the user’s personal wallet.

Rythm does not replace Gmail’s spam filter, Proofpoint, Mimecast, or any other email security tool in your stack. It processes email after those tools have already done their work.

Even the best probabilistic filters operate in an inherently adversarial loop: attackers study how filters work and adapt. Novel phishing, well-crafted BEC, and AI-generated social engineering continue to get through because they are structurally indistinguishable from legitimate email. This is not a failure of your current tools. It is a fundamental limitation of any system that relies on content analysis alone. Rythm addresses this gap. It acts as a final deterministic layer that separates unknown senders from known ones, giving users clear signal about which messages warrant caution, and moving those messages out of the inbox where they could be accidentally engaged with during a busy day.

Where Rythm Sits in the Email Flow

Inbound Email
    │
    ▼
┌─────────────────────────┐
│  MX / Gateway (yours)   │  SPF, DKIM, DMARC checks
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│  Native Spam Filter     │  Gmail / Outlook / Proofpoint / Mimecast
│  (AI, heuristic, rules) │  Probabilistic scoring, known threats
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│ Email delivered to      │  Message lands in user's inbox
│ user's mailbox          │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│  Rythm (post-delivery)  │  Deterministic: known sender → pass
│                         │  Unknown sender → filter to review folder
│                         │  Payment proof → deliver + settle payment
└─────────────────────────┘

Key architectural point: Rythm processes email post-delivery via webhook notifications from Gmail Pub/Sub or Microsoft Graph. It is not in the SMTP delivery path. Processing typically completes within seconds of an email arriving. Because Rythm operates post-delivery, your email infrastructure has zero dependency on Rythm’s availability. Even in the unlikely event of a full infrastructure outage, email delivers to users’ inboxes exactly as it would without Rythm. We call this fail-open design, and it is the single most important architectural decision in the product.

How It Differs From What You Already Have

Your existing email security tools (whether native Gmail/Outlook filters or enterprise solutions like Proofpoint or Mimecast) are probabilistic. They use machine learning, heuristics, threat intelligence feeds, and content analysis to score incoming email and make a best guess about whether it is malicious or legitimate. They are good at catching known threats. They struggle with novel phishing, well-crafted BEC, and legitimate-looking cold outreach.

Rythm is deterministic. It does not analyze email content. It does not score messages. It asks one question: is this sender on the user’s approved list? If yes, deliver. If no, filter to a separate folder. There is no probability involved, which means there are no false negatives for unknown senders. Every email from someone not on the user’s list is separated for review. The user can check their filtered folder at any time, rescue any message they want, and that sender is approved going forward. Unknown senders can also verify themselves through a small payment (set by the user) to have their email delivered directly.

	Traditional Email Security	Rythm
Approach	Probabilistic content analysis	Deterministic sender verification
What it catches	Known threats, spam patterns	All unknown senders (regardless of content)
False negatives	Yes (novel phishing gets through)	No (all unknown senders are separated)
Email content analysis	Yes (reads and scores content)	No (checks for one token format only)
Deployment	MX record change, gateway config, or API	OAuth connection, no infrastructure changes
Works alongside existing tools	Varies	Yes, always additive, never replacing

This is not a replacement pitch. Rythm does not compete with your gateway. It addresses a specific and costly gap: the phishing, BEC, and social engineering that gets past probabilistic filters because content analysis alone cannot reliably distinguish a well-crafted attack from a legitimate email. Rythm sidesteps that arms race entirely. Instead of trying to outscore attackers with better logic, it separates unknown senders deterministically, giving users a clear boundary between trusted and untrusted communication. That separation is the defense. A perfectly timed phishing email that makes it past every probabilistic filter still gets caught by Rythm, because the sender was unknown.

---

Part 2: The Questions Your Security Team Will Likely Want To Know

We have organized this section around the concerns that come up in every vendor security assessment. If you are working through a VSAQ, CAIQ, or internal security review, this should map directly to your evaluation framework.

2.1 — “What Data Will You Have Access To?”

This is the right first question. Here is the complete answer.

What Rythm accesses (in memory, during processing):

Data	Why	What happens to it
Sender email address	Guest list lookup (known vs. unknown)	Stored as SHA-256 hash in processing logs. Raw address stored only in guest list if user adds it.
Email body (text content)	Scanned for one pattern: a Cashu payment token string	Discarded from memory immediately after scan. Never written to any database, log, or file.
Email metadata (message ID, labels)	Apply labels, track processing state	Message ID stored for idempotency. Labels managed via provider API.
Google/Microsoft contacts and sent folder	One-time onboarding scan to build the user’s initial approved sender list	Email addresses from the user’s existing contacts and recent sent-folder recipients are imported into the user’s guest list in DynamoDB. The contacts data and sent folder content are not stored by Rythm. This scan runs once at signup so users start with a populated list rather than building it from scratch.

What Rythm stores persistently (in DynamoDB):

Data	Purpose	Retention
User profile (email address, provider, settings)	Account management	Until account deleted
Guest list (approved email addresses and domains)	Sender verification	Until account deleted
Lightning wallet address	Payment settlement	Until user removes it
Paywall settings (cover charge amount, custom rejection message)	Configuration	Until account deleted
OAuth tokens (access + refresh)	Email provider authentication	KMS-encrypted. Until disconnected or account deleted.
Processing logs (decision type, sender hash, timestamp)	Audit trail	90 days (auto-deleted via DynamoDB TTL)
Earnings logs (payment amounts, settlement references)	Revenue tracking	90 days (auto-deleted via DynamoDB TTL)
Subscription and billing metadata	Subscription management	Until account deleted
Provider-specific state (Gmail label IDs, Outlook folder IDs)	Integration state	Until account deleted

What Rythm never stores, anywhere, under any circumstance:

• Email bodies or message content
• Email subject lines (never logged or persisted in any form)
• Email attachments (never accessed; Rythm does not open or read attachments)
• Email headers beyond sender address
• Cashu payment tokens (validated and redeemed in memory, then discarded)
• Behavioral profiles, engagement data, or read/open tracking
• Anything that could be used to reconstruct the content of a message

The key takeaway for your risk assessment: The only PII Rythm persists long-term is the user’s email address, their guest list (which contains email addresses they chose to approve), and their Lightning wallet address. Everything else is either ephemeral (processed in memory and discarded) or short-lived (90-day TTL logs containing hashed identifiers, not raw data).

2.2 — “Does This Create a Honeypot for Attackers?”

This is the second question we hear most, and it deserves a thorough answer. You are right to ask it. Any tool that holds OAuth tokens to email accounts is a potential target. Here is how we address that risk.

The threat model: An attacker compromises Rythm’s infrastructure and gains access to OAuth tokens stored in DynamoDB. Those tokens could theoretically be used to access users’ email accounts.

Layer 1 — Encryption at rest (KMS)

All OAuth tokens (both access tokens and refresh tokens) are encrypted using AWS KMS before being written to DynamoDB. The encryption uses a customer-managed KMS key (CMK) with AES-256, and automatic annual key rotation is enabled. Old key material is retained indefinitely by AWS for transparent decryption of previously encrypted tokens.

The encryption happens at the application layer through a custom DynamoDB adapter that intercepts all token writes. There is no code path that writes an unencrypted token to the database. An attacker with direct DynamoDB access would see only KMS ciphertext blobs, useless without the corresponding KMS decrypt permission.

Layer 2 — Per-Lambda IAM isolation

The KMS decrypt permission is not granted broadly. Only the specific Lambda functions that need to refresh OAuth tokens have kms:Decrypt permission on the token encryption key. Every Lambda function runs under its own dedicated IAM role, each scoped to exactly the resources that function needs. The ingest handler (which receives webhooks) cannot decrypt tokens. The admin handler cannot decrypt tokens. The subscription handler cannot decrypt tokens.

An attacker who compromises a single Lambda function gains access only to the permissions of that function’s role, not the permissions of any other function. There are no wildcard resource permissions in any IAM role.

Layer 3 — Token lifecycle limits

• Google access tokens expire after 1 hour. Refresh tokens are stable but can be revoked instantly by the user from their Google Account security settings, or programmatically by Rythm via Google’s revocation endpoint.
• Microsoft access tokens typically expire within approximately 60 to 90 minutes (based on the provider’s token response). Refresh tokens are self-replacing: each use invalidates the previous token and issues a new one. Per Microsoft’s platform policy, refresh tokens also expire after 90 days of inactivity.

Even in a worst-case breach scenario where an attacker obtains decrypted tokens, the window of access is limited. And users can revoke access immediately from their own Google or Microsoft account security settings (a provider-level control, independent of Rythm) without needing Rythm to be involved.

Layer 4 — Scope limitation

Rythm requests the minimum OAuth scopes required:

Provider	Scopes	What this allows	What this does NOT allow
Google	gmail.modify, contacts.readonly, userinfo.email	Read messages, apply labels, read contacts	Cannot send email as user, cannot delete messages permanently, cannot access Drive/Calendar/other services
Microsoft	Mail.ReadWrite, Contacts.Read, User.Read, offline_access, openid, email, profile	Read/modify messages, read contacts, maintain session	Cannot send email as user, cannot access Teams/SharePoint/OneDrive, cannot manage organization

Critically: Rythm cannot send email from a user’s account. The gmail.modify scope allows reading and labeling, not sending. An attacker with Rythm’s tokens could read email but could not impersonate the user via email.

Layer 5 — Blast radius analysis

If Rythm’s entire infrastructure were compromised, what is the worst case?

• Accessible: Encrypted OAuth tokens (requires KMS access to use), user email addresses, guest lists, Lightning wallet addresses, hashed processing logs.
• Not accessible: Email content (never stored), email attachments (never accessed), payment tokens (never stored), passwords (Rythm uses OAuth, so no passwords exist in our system).
• Cannot do: Send email as users, permanently delete email, access non-email services (Drive, Calendar, Teams), access organization-wide admin.

Compare this to your existing email security vendor. Most enterprise email security tools require mail.google.com (full Gmail access) or equivalent admin-level scopes, process and often store email content for threat analysis, and maintain persistent copies of email data. Rythm’s blast radius is significantly smaller by design because it stores less data and requests narrower permissions.

2.3 — “How Do You Handle PII in Logs?”

All application logging passes through a centralized PII redaction layer that is enforced at the logger module level. Individual engineers cannot bypass it accidentally because every log call routes through the same redaction function before reaching any log destination.

How redaction works: All sensitive field types (covering identifiers, tokens, secrets, email content fields, network addresses, and admin fields) are defined in a single source-of-truth configuration file. When any of these field names appear in a log entry at any nesting depth, their values are replaced with a deterministic SHA-256 hash truncated to 12 hex characters.

What gets redacted: Email addresses, OAuth tokens, refresh tokens, access tokens, Cashu tokens, Lightning addresses, IP addresses, user IDs, email content fields (body, subject, snippet), API keys, and admin identifiers.

What the redaction looks like in practice:

{
  "timestamp": "2026-04-13T14:22:31.847Z",
  "level": "info",
  "message": "EMAIL_PROCESSED",
  "userId": "[REDACTED:a7f2c9e1b3d4]",
  "senderEmail": "[REDACTED:8e2f1a9c3b7d]",
  "provider": "gmail",
  "paywallDecision": "reject",
  "processingDurationMs": 247,
  "correlationId": "f3a2b1e9-7d4c-11ec-81d3-0242ac130003"
}

The hash is deterministic, meaning the same input always produces the same 12-character output. This enables audit queries (“find all log entries related to this user”) without exposing the underlying PII. The 12-character hex hash provides sufficient collision resistance for user populations well beyond our current scale.

Log retention and archival:

Log type	Retention	Storage	Encryption
Lambda execution logs	90 days (operational window)	CloudWatch Logs	AWS-managed encryption
CloudTrail API audit trail	1 year	S3 (with SSL enforcement, versioning)	SSE-S3
Archived application logs	30 days Standard → Infrequent Access at 30 days → Glacier at 180 days → expired at 365 days	S3 (lifecycle tiered)	SSE-S3
WAF logs	90 days	S3	SSE-S3

A daily log export Lambda runs at 2:00 AM UTC, shipping CloudWatch logs to S3 for long-term archival. CloudWatch provides the operational window for debugging. S3 provides the compliance window for audit.

2.4 — “What Happens if Rythm Goes Down?”

Short answer: Email works normally, and users are notified automatically.

Because Rythm operates post-delivery (it is not in the SMTP path), your email infrastructure has zero dependency on Rythm’s availability. Gmail and Outlook deliver email to the user’s inbox first, then send a webhook notification to Rythm. If Rythm is temporarily unavailable, email continues flowing to inboxes as usual. No email is lost, delayed, or bounced.

Rythm actively monitors its own health and communicates proactively with users when issues arise:

Automated monitoring and notification:

Failure scenario	What happens	User notification
Rythm’s ingest handler is temporarily unavailable	Email stays in inbox untouched. Provider retries the webhook when Rythm recovers.	If the outage persists, the cross-region health monitor (below) triggers automated notification.
Processing queue message fails	SQS retries automatically with configurable limits before routing to a dead-letter queue for triage.	No notification needed; retries resolve transparently.
Email is quarantined but processing crashes	An automated recovery job periodically detects emails stuck in processing and restores them to the inbox.	No notification needed; automated recovery.
Token validation or payment settlement fails	Email is delivered to inbox immediately (fail-open). Payment is retried asynchronously.	No notification needed; email delivered, payment handled in background.
OAuth token refresh fails	Email processing pauses for that user. Email delivers normally via their provider.	User receives an automated email from Rythm notifying them that their connection has expired and providing a one-click link to reconnect from their dashboard. This notification fires once, at the moment the failure is detected.
Rythm infrastructure is completely down	Email delivers normally (fail-open). Webhook queue buffers messages for when service resumes.	A cross-region health monitoring system (hosted on separate AWS infrastructure, independent of the primary stack) continuously monitors Rythm’s availability. When an outage is detected, it sends automated email notifications to all affected users informing them of the interruption. A follow-up recovery notification is sent when service is restored.

Dead-letter queue monitoring: Any message that exhausts its retry budget and lands in a dead-letter queue triggers an immediate alarm. DLQ messages are triaged by a dedicated handler that logs diagnostic context and alerts the engineering team.

The design principle: Email should always work as normal. In any failure scenario, users receive their email without interruption and are notified about the status of their Rythm service. Every failure mode in the pipeline resolves toward delivery, never toward blocking.

2.5 — “Can Your Employees Read Our Email?”

No. And not as a policy statement, but as an architectural constraint.

Email bodies are fetched from the provider’s API by automated Lambda functions, processed in memory (scanned for one string pattern), and discarded. The email content exists in Lambda execution memory for milliseconds to seconds, then is gone. There is:

• No database table that stores email content
• No S3 bucket that archives email content
• No admin interface that displays email content
• No log entry that contains email content (subject lines and bodies are never logged)
• No API endpoint that returns email content
• No way to reconstruct what was in an email after processing completes

Even if an employee had full administrative access to every AWS resource in our infrastructure, there would be no email content to find. The data simply does not exist after the processing window closes.

Infrastructure access is governed by per-function IAM roles with least-privilege scoping. No single role has broad access to the system. Production operations are audited via CloudTrail, and every Lambda invocation is traced via AWS X-Ray. There is no “customer support view” that displays email content because there is no email content to show.

2.6 — “What Third-Party Services Does Rythm Depend On?”

Every vendor introduces supply chain dependencies. Here are ours, and the risk profile of each:

Dependency	What it does	What if it fails	Data exposure
AWS (Lambda, DynamoDB, SQS, KMS, CloudFront, WAF)	Core infrastructure	Rythm is unavailable. Email delivers normally (fail-open).	AWS is the data processor. All data at rest is encrypted.
Vercel	Hosts the user dashboard (Next.js frontend)	Dashboard unavailable. Email processing continues (backend is on AWS).	Vercel sees frontend traffic only. No email content, no OAuth tokens.
Google APIs / Microsoft Graph	Email provider integration	Email processing pauses for affected provider. Email delivers normally.	Provider APIs are the source; they already have the data.
Public Cashu mints	Generate Lightning invoices for cover charges	Payment processing pauses. Emails from unknown senders are still filtered (just no payment option). Circuit breaker prevents cascade.	Mints see payment amounts only. No email content, no user identity.
Square	Subscription billing (card payments)	New subscriptions and renewals fail. Existing service continues.	Square handles card data in their PCI-DSS environment. Rythm stores only Square customer/subscription IDs.
Resend	Transactional email (rejection notices, outage notifications)	Rejection notices to unknown senders fail. Core email processing unaffected.	Resend sees recipient email and rejection message template. No inbox content.
User’s Lightning wallet provider (indirect)	Receives settled payments on behalf of the user	Payment settlement fails. Email is still delivered (fail-open). Payment retried asynchronously.	Rythm resolves the user’s Lightning address to generate invoices. The wallet provider receives the payment. Rythm does not have access to the user’s wallet.

No dependency failure causes email loss. Every failure mode resolves toward normal email delivery.

---

Part 3: Security Architecture (Controls in Depth)

3.1 — Network and Edge

• CloudFront with HTTPS-only enforcement (TLS 1.2+, no plaintext fallback). Origin failover configured with a secondary region.
• WAFv2 with five rule layers:
  1. AWS Common Rule Set (SQL injection, XSS, SSRF, file inclusion)
  2. Known Bad Inputs Rule Set (Log4j, path traversal, known exploit patterns)
  3. IP Reputation List (blocks IPs identified as bot/threat sources)
  4. Per-IP rate limiting
  5. Anonymous IP List (monitoring mode for VPNs, Tor, proxies)
• WAF logs are retained for 90 days in S3 with server-side encryption.

3.2 — Application Security

Input validation: Every API endpoint validates input against Zod schemas at the request boundary. Schemas enforce type checking, range constraints, format validation, and strict mode that rejects unknown properties. Invalid requests return 400 before reaching any business logic. Internal error messages and stack traces are never exposed in API responses; structured logging captures full diagnostics server-side while clients receive only generic error codes.

Authorization (BOLA prevention): All API endpoints that accept a user ID as a path parameter validate that the authenticated session’s user ID matches the requested resource. Mismatches are logged as security events and emit CloudWatch alarms. This prevents broken object-level authorization attacks where an attacker manipulates path parameters to access another user’s data.

SSRF protection: Any outbound URL constructed from user input (Lightning addresses resolve to URLs via the LNURL protocol) passes through an SSRF guard that:

• Restricts protocol to HTTPS only
• Blocks all private IPv4 and IPv6 ranges (loopback, RFC 1918, link-local, carrier-grade NAT, unique local)
• Blocks cloud metadata endpoints (AWS, Google Cloud)
• Performs fresh DNS resolution on every call (prevents DNS rebinding)
• Enforces strict timeouts with no DNS caching

Content Security Policy: Nonce-based CSP with strict-dynamic on all pages. No unsafe-eval in production (allowed only in development for Turbopack HMR, guarded by environment check). Script sources are locked to first-party origins and the Square payment SDK. CSP violations are reported to a dedicated monitoring endpoint.

Session security: Sessions expire after 24 hours. Sensitive operations (account deletion, paywall configuration changes, guest list wipes) require re-authentication within a 15-minute window. “Sign Out Everywhere” terminates all active sessions across devices by batch-deleting session records from DynamoDB.

Security headers: In addition to CSP, all responses include:

• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (2-year HSTS)
• X-Frame-Options: DENY (clickjacking prevention)
• X-Content-Type-Options: nosniff (MIME type sniffing prevention)
• Referrer-Policy: strict-origin-when-cross-origin (referrer leakage control)
• Permissions-Policy: camera=(), microphone=(), geolocation=() (explicit feature denial)

Webhook signature verification: All inbound webhooks (Gmail, Outlook, Square, and Strike) validate cryptographic signatures using timing-safe comparison functions to prevent both signature forgery and timing-based side-channel attacks.

3.3 — Encryption at Rest

All persistent data stores use encryption at rest:

• DynamoDB tables: AWS-managed encryption on all tables
• SQS queues: SQS-managed encryption on all queues (including dead-letter queues)
• S3 buckets: Server-side encryption (SSE-S3) on all log and archival buckets
• OAuth tokens: Application-layer KMS encryption (customer-managed key, AES-256) before DynamoDB write, layered on top of table-level encryption

3.4 — IAM and Access Control

Every Lambda function runs under its own dedicated IAM role. Each role is scoped to the specific DynamoDB tables, SQS queues, KMS keys, and other AWS resources that function requires. Examples:

• The ingest handler (receives webhooks) can read user profiles and push to the processing queue. It cannot decrypt OAuth tokens, cannot access the payments table, cannot write to the admin table.
• The payment processor can decrypt OAuth tokens (to fetch email content for token scanning) and read/write payment state. It cannot delete user accounts, cannot access the admin table, cannot publish to SNS.
• The admin handler can read user profiles and metrics. It cannot decrypt OAuth tokens, cannot modify user data, cannot access the processing queue.

No IAM role uses unscoped wildcard resource permissions. Where AWS requires wildcard resources (CloudWatch metrics and logs do not support resource-level filtering), access is constrained by namespace conditions.

3.5 — Observability

• AWS X-Ray: Distributed tracing enabled on all Lambda functions, providing end-to-end request tracing across the processing pipeline.
• Correlation IDs: Every email processing workflow is assigned a unique correlation ID that follows the request across Lambda invocations, SQS messages, and log entries, enabling full request reconstruction for debugging and audit.
• CloudWatch metrics: Custom metrics track processing latency, error rates, queue depth, rate limit events, and circuit breaker state per mint.

3.6 — Audit Trail

• CloudTrail: Multi-region trail with log file validation enabled. All AWS API calls are logged to S3 with 1-year retention. CloudWatch log group provides searchable access with 1-year retention.
• Application logs: Every email processing decision is logged with a correlation ID that enables end-to-end tracing across Lambda invocations. PII is auto-redacted before log entry is written.
• DynamoDB audit: Processing logs and earnings logs are stored with 90-day TTL for operational audit queries.

---

Part 4: The Email Processing Pipeline (Step by Step)

For the technically inclined, here is the exact processing flow for a single inbound email:

Step 1 — Webhook notification arrives. Gmail Pub/Sub or Microsoft Graph sends a push notification to Rythm’s ingest endpoint. The handler validates the webhook cryptographically: JWT verification (Google OIDC token from a trusted service account) for Gmail, HMAC-SHA256 with timing-safe comparison for Outlook. Outlook webhooks include replay protection via deduplication with automatic expiry. Invalid signatures are rejected. Valid webhooks are parsed with Zod schema validation, rate-limited per user, and pushed to the processing queue. The endpoint returns 200 immediately. All processing is asynchronous.

Step 2 — Message enters the processing queue. An SQS message is picked up by a Lambda worker. The worker refreshes the user’s OAuth access token (decrypting the refresh token from KMS), then fetches email metadata and content from the provider’s API.

Step 3 — Email is quarantined. The email is moved to a transient processing label to prevent the user from seeing an unprocessed message flash in their inbox. A tracking record is written for the automated recovery fail-safe.

Step 4 — Idempotency check. The system verifies this message has not already been processed (duplicate webhooks are common). Gmail uses its native message ID. Outlook uses the stable RFC 2822 internetMessageId because Microsoft Graph assigns new IDs when messages move between folders.

Step 5 — Guest list check. The sender’s email address is checked against the user’s guest list (stored in DynamoDB). If the sender is known, the email is delivered to the inbox immediately. The email body is still scanned for payment tokens (see Step 7), but no filtering or rejection occurs for known senders.

Step 6 — Global essential services check. A curated list of widely recognized service domains bypasses filtering for all users. This list currently covers approximately 250 domains across categories including major financial institutions, insurance providers, shipping carriers, healthcare systems, government domains (.gov, .mil, .gov.uk, etc.), travel services, legal notices, and common platforms. DKIM verification is required for these matches to prevent domain spoofing. If the domain matches but DKIM fails, the bypass does not apply and normal filtering continues.

Step 7 — Payment proof scan. The email body is scanned in memory for a Cashu payment token. This scan runs on all emails (including those from known senders) so that payment proofs are always processed if present. The scan is pattern matching for a specific string format (cashuA... or cashuB...), not content analysis. It begins with a quick reject: if the string “cashu” does not appear anywhere in the body (which is true for 99%+ of emails), the scan exits immediately. If a token candidate is found, it is size-validated, deduplicated, and passed to the validation step.

Step 8 — Disposition. Based on the result, the email is labeled and placed:

• Token found and valid: RYTHM: PAID, delivered to inbox, payment settled to user’s Lightning wallet
• Token found but validation fails: RYTHM: SCAN FAILED, delivered to inbox (fail-open), payment retried asynchronously
• No token: RYTHM: REJECTED, filed in the rejected folder, sender receives a notification with payment instructions

Step 9 — Cleanup. Email body, subject, snippet, and headers (beyond sender address) are discarded from Lambda execution memory after the disposition decision. They are never written to a database, a log, S3, or any persistent medium.

---

Part 5: Payment Architecture (Non-Custodial)

This section draws scrutiny in every security review, and it should. Any system that touches payments needs careful examination.

How the Payment Flow Works

When an unknown sender decides to pay the cover charge:

1. Sender visits the payment page linked in the rejection notice
2. A public Cashu mint generates a Lightning Network invoice for the cover charge amount
3. Sender pays the invoice using any Lightning-compatible wallet or app
4. The mint issues the sender a Cashu token (a cryptographic bearer proof of payment)
5. Sender includes the token in a follow-up email
6. Rythm detects the token in the email body, validates it with the issuing mint, and redeems it to the recipient’s Lightning wallet address
7. Payment settles to the recipient’s wallet. The token is discarded from memory.

At no point does Rythm hold, custody, transmit, or store funds. The payment moves from sender to mint to recipient’s wallet. Rythm automates the validation and redemption, performing the same steps the recipient could perform manually. This non-custodial design means Rythm has no money transmission exposure and users have no counterparty risk with Rythm for their earnings.

Payment Failure Handling

If a melt (token redemption) fails due to a transient error (network timeout, mint unavailability, or Lightning routing failure), the email is delivered to the inbox immediately with a RYTHM: SCAN FAILED label (fail-open), and the melt is queued for retry.

Retries follow an exponential backoff schedule over a multi-day window. If all retry attempts are exhausted, the token is abandoned. The email was already delivered to the inbox at the first failure.

Per-Mint Circuit Breaker

A circuit breaker monitors each Cashu mint independently. If a particular mint begins failing consistently, the circuit opens and Rythm stops sending requests to that mint until a health probe confirms recovery. This prevents a single unreliable mint from degrading the entire payment pipeline.

---

Part 6: Compliance Status (Honest Assessment)

What We Have

CASA (Cloud Application Security Assessment): All 39 test cases addressed.

Rythm has completed the CASA Tier-2 security audit (39 of 39 test cases passed). Key outcomes include:

• Nonce-based Content Security Policy with violation reporting
• Zod input validation on all API routes
• Per-Lambda IAM roles with least-privilege scoping (every function has its own role)
• SSRF guard on all outbound URL construction from user input
• Re-authentication guard (15-minute window) for destructive operations
• Session revocation (“Sign Out Everywhere”) across all devices
• PII auto-redaction in all application logs
• 90-day minimum log retention with 1-year S3 archival
• WAFv2 edge protection with five managed rule layers
• CloudTrail audit logging for all AWS API calls

What We Do Not Have

We would rather tell you what is missing than let you discover it after you have invested time evaluating:

• SOC 2 Type II certification. We have scoped the audit, identified gaps, and have a phased remediation plan. We follow SOC 2 principles in access control, logging, encryption, and change management. But the engagement has not been executed and we cannot claim certification.
• SSO / SCIM provisioning. Not available. Rythm currently supports individual Gmail and Outlook accounts. Organization-wide deployment tooling and centralized administration are on the roadmap.

What We Can Provide Today

• Architecture documentation (this guide, plus detailed internal docs on request)
• CASA evaluation details
• Data Processing Agreement (DPA) for organizations that require one
• Subprocessor list (published at app.rythm.xyz/sub-processors)
• Evidence of specific controls (KMS configuration, IAM policies, WAF rules, log samples) on request

---

Part 7: Vendor Risk Profile

Data Residency

All data processing and storage occurs in AWS us-east-1 (N. Virginia). Failover infrastructure exists in us-west-2 (Oregon). CloudFront edge caching distributes static assets globally but does not cache or store any user data or email content. Vercel (dashboard hosting) processes frontend requests through their global edge network but does not handle any email data or OAuth tokens.

No email content is transmitted to or processed in regions outside the United States. For organizations with EU data residency requirements, note that user email addresses and guest list data are stored in us-east-1.

What Happens if Rythm Shuts Down

This is a fair question for any startup vendor.

• Immediate: A user disconnects from their dashboard. Rythm revokes OAuth tokens (Google) or clears stored tokens (Microsoft). All user data is deleted from Rythm’s database. Labels created by Rythm (such as RYTHM: REJECTED) persist in the email provider but can be manually deleted by the user from their Gmail or Outlook settings.
• No data to migrate: Because Rythm never stores email content, there is no data to export or migrate beyond the guest list (which can be exported as JSON) and earnings history.
• No lock-in by design: Rythm does not change your MX records, does not require a new email address, and does not modify your email provider configuration. Removing Rythm is the reverse of adding it: revoke OAuth, done.
• Non-custodial means no funds at risk: Rythm never holds user funds. There is no balance to withdraw, no wallet to migrate. Payments settle directly to the user’s personal Lightning wallet in real time.

Incident Response

• Dead-letter queue alarms trigger immediately when messages land in any DLQ.
• Cross-region health monitoring continuously checks system health, with automated user notification when outages are detected.
• Circuit breakers prevent cascade failures across payment infrastructure.
• CloudTrail provides a complete audit trail of all infrastructure operations.
• Security events (auth failures, SSRF blocks, CSP violations, permission denials) are logged via a dedicated security event logger.

We do not currently have a published incident response policy document or a committed breach notification SLA. These are planned as part of our SOC 2 preparation. In practice, our monitoring detects issues within minutes and we communicate proactively with affected users.

---

Part 8: Getting Started (For Individual Evaluation)

If you want to evaluate Rythm hands-on before making an organizational decision:

1. Individual setup takes about 12 minutes. Sign in with Google or Outlook, subscribe, connect a Lightning wallet, and Rythm builds the guest list automatically through a five-phase scan: starred/flagged messages, contacts import, sent folder recipient extraction, inbox frequency analysis, and activity unification.

2. No IT department involvement required for individual accounts. Rythm connects via standard OAuth, the same authorization flow used by every Gmail/Outlook add-on. No MX record changes, no DNS modifications, no gateway configuration.

3. Disconnection is clean. Cancel from the dashboard. OAuth tokens are revoked, all user data is deleted from Rythm’s systems. Labels Rythm created in your email provider persist but can be manually deleted. No leftover data in Rythm’s infrastructure (beyond what is retained in logs for the 90-day compliance window).

4. Account deletion is complete. All DynamoDB records (profile, guest list, processing logs, earnings logs, subscription data, OAuth tokens) are deleted. Deletion is auditable via CloudTrail.

---

Questions We Have Not Answered

If your evaluation requires information we have not covered here (subprocessor details, specific control evidence, DPA review, architecture diagrams, or anything else), reach out directly at [email protected]. We would rather have the conversation than leave you guessing.

The architecture described in this guide is not static. We review processing logs, error rates, and system behavior continuously to identify areas for improvement. When we make material changes to our security posture or data handling, this guide will be updated with a revision date at the top.

Last updated: April, 2026