#Release Notes

#Game-only embed delivery — 2026-09-18

• Runtime remains v1.4.0; no new SDK methods or protocol messages.
• Detailed game-only route guide, sizing/input examples, framing headers, diagnostics and AI coding request in English and Korean.
• Runnable HTML reference at /sdk/examples/embed.html; no score or reward events.
• Developer brief and submission guidance distinguish SDK integration from embed layout readiness.
• Full-width host player with compact controls and reduced corners. External game layouts still need their own responsive implementation.

#Player and developer portal — 2026-09-17

• SDK runtime stays v1.4.0; no new wire protocol.
• Automatic farming after 60 seconds, shared daily award with the existing 45-second SDK completion gate; 15-second host heartbeat.
• English/Korean developer handoff, Mobile & PC guide, grouped submission and downloadable brief.
• Owners maintain private device/SDK/test requirements; operators review them. Device URLs are review references, not automatic player routing.

The change history for the SDK and the platform. Every addition within v1.x is backward compatible — existing fields are never removed or changed, and games can simply ignore unknown messages and fields. Code you integrate today will keep working unchanged through future v1 updates.

When you need to branch, we recommend feature detection over version comparison:

if (typeof TokenApps.requestPurchase === "function") { /* v1.3+ */ }

#SDK v1.4 — Duels (Live and Async Matchmaking) (2026-09-10)

Games can add duels through TokenApps.match.

• TokenApps.match.find(opts) — Finds an opponent and resolves a Match. The default, kind: "auto", looks for a live match with someone playing the same game right now, and if nobody comes within 45 seconds switches to an async duel against the best record of the closest-rated player in the same game. The match starts at the ready event, and both sides build the same board from seed.
• match.send(data) and the message event — Relay game messages to the opponent in a live match. Up to 8 per second and 4 KB each; anything over is dropped with a ratelimited event.
• match.report({ score, outcome? }) — Reports the result. The server judges and moves the rating. A live match settles only when the two reports agree; otherwise it closes disputed.
• match.leave() — Cancel the wait or leave. Leaving a live match in play is recorded as a loss; the other side gets an opponent_left event.
• Duel results never touch TAP. Earning stays the session-completion rule; a result only moves a per-game rating and a record.
• ready() re-sends — Until the first session arrives the SDK sends ready again. A game that finished loading before the player page was listening used to lose its only ready, and a signed-in player looked like a guest. Nothing changes on the game side.

Usage: SDK guide §4.8 · Spec: §6.10–6.14

#SDK v1.3 — In-Game Items (2026-08-25)

You can now sell items, themes, and boosts for TAP (TokenApps Points).

• TokenApps.getProducts() — Returns the list of this game's products registered on the platform. Guests can query it too, so you can render your store display regardless of sign-in state.
• TokenApps.requestPurchase(sku) — Requests a purchase. Price display, player confirmation, payment, and record-keeping are all handled by the platform; the game only receives the result. No message in the protocol has an amount field — the only price ever charged is the value registered on the server.
• TokenApps.getInventory() — The list of items this player owns in this game. When restoring on restart, use this response as the source of truth, not local storage.
• The iron rule for granting: grant items only on a purchased or already_owned response.
• If you have a game server, you can query the inventory with the session token for server-side verification, the equivalent of receipt validation — Specification §6.9.

Usage: SDK Guide §4.7 · Spec: Specification §6.6–6.9

#SDK v1.2 — Continue Sheet (2026-08-24)

• TokenApps.requestContinue() — Call it once at game over and the platform presents a three-option sheet: "Continue with TAP / Watch an ad to continue / Give up." Revive the player on paid/rewarded; otherwise proceed with your usual game-over flow.
• For continues, we recommend this sheet over handling ads directly — the player gets more choices and your game code is shorter.

#SDK v1.1 — Rewarded Ads (2026-08-24)

• TokenApps.requestRewardedAd(placement) — Requests a rewarded ad. The player opts in explicitly on a platform sheet, and the reward is granted by the server. No ad SDK or ad account is needed on the game side.
• unavailable is a normal response. Guests, the viewing interval and daily view limits, and the player reaching the daily TAP cap all come back as this response. Always keep a path where the game proceeds without the ad — it's also a review requirement.

#SDK v1.0 — Initial Release (2026-08-18)

• ready() / session — the handshake. Provides the sign-in state, a game-scoped pseudonymous player id, and a token for saves.
• track(event) / points — gameplay event reporting and the server's ruling. Whether to award, the rate, and the caps are all decided by the server.
• save() / load() — the account save slot. It follows the player across devices, and since localStorage doesn't work in the iframe, this is the standard storage.
• submitScore(n) — display-only score submission. Never connected to TAP.
• openPointsPurchase() — requests opening the platform's top-up sheet.

#Platform Changes That Affect Games