Aeion BaaS vs Firebase & PlayFab

PlayFab: 5-8% of virtual goods revenue. If you sell $100K/month in virtual currency and in-game items:

• PlayFab cost: $5,000-$8,000/month — forever
• This is on top of your AWS/Azure/GCP bill for the rest of your infrastructure

Firebase Game SDK: $0.05/MAU after the free tier (50K MAU). At 500K MAU:

• Firebase cost: $22,500/month — and you still need to build matchmaking, ratings, economy, anti-cheat yourself

Aeion BaaS: $49/mo flat. Your $100K/month game doesn't cost more because you're successful — no MAU meter, no revenue share, ever.

The comparison gets worse when you factor in what you're getting: PlayFab's built-in economy is a basic ledger. Aeion BaaS has a battle-tested double-entry currency ledger, a Glicko-2 rating engine, and a rule-based anti-cheat engine with 5 rule types. To replicate this on PlayFab or Firebase, you'd need a team of engineers for 6-12 months.

PlayFab uses ELO. ELO is a zero-sum rating system — your rating goes up when you win, down when you lose. It's what chess has used for 60 years.

The problem with ELO for games:

• It doesn't account for uncertainty. A player with 10 games at 1500 rating is treated the same as a player with 500 games at 1500 rating.
• It doesn't track volatility. A player who swings wildly between stomping and getting stomped is treated the same as a consistent player.
• It can't handle inactivity. A player who takes a 6-month break comes back with the same confidence as someone who plays daily.

Aeion BaaS uses Glicko-2, tracking rating, Rating Deviation (RD), and volatility per player:

• RD (Rating Deviation): New players start with RD=350 (high uncertainty). Active players have RD=50-100. Inactive players' RD grows over time — their rating becomes less certain, so they're matched more loosely when they return.
• Volatility: Tracks how much a player's performance swings. A consistent player has low volatility. A "coin flip" player has high volatility.
• Better matchmaking: Two players with the same ELO but different RDs get matched differently. A veteran at RD=50 is a known quantity. A new player at RD=350 is a wildcard — matched more loosely.

This is why games like Overwatch, Valorant, and League of Legends use variants of Glicko/Glicko-2. ELO is for chess. Games are messier.

The dupe exploit problem: Most game economies get wrecked by dupe exploits — players finding ways to grant themselves currency without a corresponding deduction. This happens because the economy is built on "balance" fields that get updated, not on immutable transaction logs.

PlayFab Economy v2: Basic ledger. When a player purchases currency, PlayFab increments their balance. When they spend it, PlayFab decrements it. If the increment and decrement happen simultaneously (race condition), both might succeed — and you've just created 500 soft currency out of nothing.

Aeion BaaS's currency ledger:

``` // Every transaction is double-entry — one debit, one credit, always balanced // There is NO balance field that gets arbitrarily updated. // Balance is always derived: SUM(credits) - SUM(debits) from transactions.

// Debiting an account is atomic: // 1. Lock the balance row // 2. Check balance >= amount // 3. Insert the debit transaction record // 4. Update the balance // All inside a single database transaction — a second concurrent debit // always sees the updated balance and fails cleanly rather than racing. ```

Every transaction is an append-only ledger entry. The balance is always re-derived from the transaction log. There is no way to change a balance without a corresponding transaction. Dupe exploits require finding a way to insert a credit without a debit — and the atomic transaction model prevents that at the database level.

This is the accounting principle applied to game economies. It's why real financial systems use double-entry bookkeeping — it makes it mathematically impossible to create money out of nothing.

PlayFab: Basic rules — ban player, unban player, add to ban list. When a new exploit emerges, you update the ban list. Players who find the exploit before you do get banned retroactively. The exploit has already done its damage.

Firebase: No anti-cheat. You build it yourself. By the time you've built a basic rate limiter, the exploit community has moved on.

Aeion BaaS's anti-cheat engine:

It's a rule engine, not a ban list:

typescript // Impossibility rule { ruleType: "impossibility", appliesTo: "score", config: { theoreticalMax: 10000, stdDeviations: 5, checkAgainstGlobalMean: true }, severity: "critical", action: "block", autoBanOnCritical: true }

When a new exploit is discovered:

1. Configure a new rule in the admin console (no code deployment, no app update)
2. Rule takes effect immediately across all players
3. Exploit attempts are blocked in real time, not banned retroactively
4. Evidence is logged for manual review of borderline cases

Rule types:

• rate_limit — Too many actions per time window
• impossibility — Score exceeds theoretical maximum or global mean + N standard deviations
• account_age — New accounts gated from high-value actions
• honeypot — Hidden fields that only bots fill
• custom — Arbitrary JS expression evaluated in sandbox

This is the difference between reactive (ban list) and proactive (rule engine).

PlayFab CloudScript: JavaScript functions that run in PlayFab's cloud. Limited API surface. Can't run arbitrary Node.js. Performance is opaque.

Firebase Cloud Functions: Full Node.js. But Firebase has no concept of game-specific APIs (currency, inventory, matchmaking, ratings). You'd be writing raw Firestore reads/writes — which means building the game logic yourself, on top of the "serverless" layer.

Aeion BaaS sandboxed function execution:

```typescript // Sandboxed QuickJS WASM // Fully isolated — no access to filesystem, network, process // Memory limit: 128MB (configurable) // Timeout: 5000ms (configurable)

// Injected Aeion API: ctx.db.find/create/update/delete() // Database ctx.currency.debit/credit() // Currency operations ctx.inventory.grant/revoke() // Item management ctx.ratings.update() // Glicko-2 rating updates ctx.log(level, msg, meta) // Structured logging → WebSocket broadcast ctx.raise(event, payload) // Emit game event ```

`ctx.log` → live clients via WebSocket: When a function runs, its console.log output is broadcast to connected game clients in real time. Use case: AI game masters, live debugging, streaming state updates.

TypeScript support: Functions written in TypeScript are transpiled on deploy. tsconfig.json respected. Type errors block deployment. This is not a "we support TypeScript syntax in JavaScript" — it's actual TypeScript.

Most game notification systems are fire-and-forget. Player earned a reward, notification sent, reward delivered. If the reward fails to deliver (database error, item doesn't exist, player banned mid-delivery), the notification has already fired and the reward is lost.

Aeion BaaS in-game inbox with transactional reward delivery:

The inbox uses two-phase reward delivery:

```typescript async sendWithRewards(input): Promise<InboxMessage> { // Phase 1: Create message in 'pending' state const message = await this.createMessage({ status: "pending" });

// Phase 2: Grant rewards try { await this.grantRewards(message.id, input.attachedRewards); // Phase 3: Mark as delivered await this.updateMessage(message.id, { status: "delivered" }); } catch (err) { // Reward failed — message stays 'pending', retryable await this.updateMessage(message.id, { status: "failed", error: err.message }); } } ```

If the database hiccups during reward delivery, the message is marked failed and retried automatically. The player never receives a notification for a reward they didn't get.

Push + Inbox mirror: push notifications can set mirrorToInbox: true — every push delivery also creates an in-game inbox message. Players who have push disabled still see the notification in their in-game inbox.