Case Study: From Boss Kill to Verifiable Proof of Play
How By The Deed can turn a meaningful in-game achievement into portable player-owned proof
A player enters a difficult raid.
They spend forty minutes progressing through the encounter, defeat dozens of enemies, reach the final boss, and land the critical hit that completes the run.
Inside the game, the achievement appears:
Boss Breaker — Defeat the boss critically.
The player earned it.
But outside that game's database, what does that achievement actually mean?
A screenshot can be edited. A profile page depends on the game's servers. A client-side achievement flag can be manipulated. And publishing an entire gameplay history publicly would create unnecessary privacy and infrastructure problems.
This case study explores how By The Deed SDK v1.0.0 approaches that problem.
Instead of treating an achievement as a badge that a game simply declares, By The Deed treats gameplay as evidence that can be evaluated against explicit rules.
The resulting flow is:
Play → Capture → Verify → Prove → Own
For this case study, we'll follow a fictional RPG called Chronicles of Eldoria and one of its achievements from the moment a player enters the game to the moment a portable Proof-of-Play credential can be created. The capabilities described here are grounded in the current v1.0.0 SDK; the game and scenario themselves are illustrative.
The scenario
Chronicles of Eldoria contains a difficult encounter against the Ancient Dragon.
The studio wants to introduce a special achievement:
Dragonslayer
Defeat the Ancient Dragon with a critical final attack during a valid gameplay session.
The studio doesn't want this achievement to be granted merely because a client sends:
{ "achievement": "dragonslayer", "unlocked": true }
Instead, it wants the achievement to be derived from gameplay evidence.
The game already knows when enemies are defeated, which enemy was involved, what weapon was used, how much damage was dealt, and whether the attack was critical.
Those events can become the evidence.
1. Defining the game's event contract
Integration begins with the events the game considers meaningful.
By The Deed uses a generic TypeScript event map as the contract between game code and the SDK. Event names become literal types, with each event paired with its own payload structure.
Chronicles of Eldoria might define:
type EldoriaEvents = { raid_started: { raidId: string; difficulty: "normal" | "heroic"; }; enemy_defeated: { enemyId: string; weapon: string; damage: number; critical: boolean; }; item_collected: { itemId: string; rarity: "common" | "rare" | "legendary"; }; raid_completed: { raidId: string; durationMs: number; }; };
The game then initializes its BTD client:
const btd = new BtdClient<EldoriaEvents>({ gameId: "chronicles-of-eldoria", environment: "production", });
This gives developers compile-time protection against malformed calls from their own TypeScript integration.
For example:
await btd.capture("enemy_defeated", { enemyId: "ancient_dragon", weapon: "sunblade", damage: 4820, critical: true, });
The SDK's event envelope is also runtime validated. If payloads originate from outside trusted game code, however, v1.0.0 recommends validating those payloads separately—such as with the game's own Zod schema—before capture.
This distinction is important.
By The Deed isn't asking developers to replace their game's event system.
It provides a typed verification layer on top of the gameplay signals the game already understands.
2. Starting a verifiable gameplay session
Before the raid begins, the game creates a session for the player.
const session = await btd.sessions.start({ playerId: "player_7f32", });
The player identifier can remain opaque.
By The Deed's production guidance recommends keeping personally identifying information outside gameplay payloads wherever possible.
Now gameplay events have a session boundary.
Conceptually:
Player ↓ Session starts ↓ Raid starts ↓ Combat events ↓ Ancient Dragon defeated ↓ Raid completes ↓ Session ends
Sessions give verification a defined body of evidence rather than asking the verifier to search indefinitely through a player's entire history.
v1.0.0 also handles concerns around event ordering, deduplication, payload limits, and event-buffer limits.
3. Capturing the deed
The player now enters the raid.
Instead of immediately creating a blockchain transaction for every attack, movement, or enemy defeat, the game captures relevant events through the SDK.
For example:
await btd.capture("raid_started", { raidId: "dragon_lair", difficulty: "heroic", }); await btd.capture("enemy_defeated", { enemyId: "dragon_guardian_01", weapon: "sunblade", damage: 1920, critical: false, }); await btd.capture("enemy_defeated", { enemyId: "ancient_dragon", weapon: "sunblade", damage: 4820, critical: true, }); await btd.capture("raid_completed", { raidId: "dragon_lair", durationMs: 2_340_000, });
The important architectural idea is that gameplay comes first.
The player doesn't play "on the blockchain."
They play the game.
By The Deed observes the evidence that the game chooses to provide.
That keeps the gameplay loop independent from optional blockchain publication.
4. Defining what Dragonslayer actually means
Capturing events alone doesn't establish an achievement.
The game must define what counts.
By The Deed v1.0.0 provides serializable rule builders supporting event comparisons and logical composition such as AND, OR, and NOT, along with counts, sequences, windows, and aggregations.
A simplified Dragonslayer definition could be:
const dragonslayer = achievement("dragonslayer") .named("Dragonslayer") .describedAs( "Defeat the Ancient Dragon with a critical final attack." ) .versioned(1) .when( event("enemy_defeated") .where("enemyId", "equals", "ancient_dragon") .and("critical", "equals", true) ) .build(); btd.achievements.register(dragonslayer);
This matters because the meaning of the credential is no longer hidden in application code.
There is a rule.
That rule can be serialized.
It can be tested.
It can be reviewed.
And it can be versioned.
The README specifically describes achievement definitions as versioned rule trees and recommends publishing a new immutable version when achievement semantics change.
So if Dragonslayer v2 later requires heroic difficulty, the developer doesn't need to silently redefine what an old credential meant.
A new rule version can represent the new standard.
5. Verification
The boss is dead.
Now the game asks By The Deed whether the achievement was actually satisfied.
const verification = await btd.verify("dragonslayer", { playerId: "player_7f32", sessionId: session.sessionId, });
The verification engine evaluates the registered rule against the evidence associated with the session.
The output is more useful than a simple boolean.
According to the v1.0.0 design, deterministic verification can provide the rule result, matched event IDs, reason codes, confidence, and a SHA-256 evidence digest.
A successful result can therefore communicate:
Achievement Dragonslayer Result VERIFIED Matched evidence enemy_defeated → ancient_dragon Critical true Evidence digest SHA-256(...) Verified ✓
A failed result is useful too.
Developers can inspect which rule branch failed and which events were considered.
This makes the system useful during development and testing, not just credential issuance.
6. Why deterministic verification comes first
By The Deed's architecture makes an important choice:
OpenAI is optional.
A boss identifier doesn't need an AI model to determine whether:
enemyId == ancient_dragon
And an AI model shouldn't decide whether:
critical == true
Those are deterministic conditions.
Putting a model in the middle would make something simple less predictable.
By The Deed therefore keeps game-defined deterministic rules in the core verification path.
For our Dragonslayer example, the standard achievement can be verified locally without calling an external AI provider.
That also means the core SDK can operate offline.
7. Where intelligent interpretation becomes useful
Now imagine Chronicles of Eldoria introduces a different achievement:
Guardian of Eldoria
Perform an exceptional act that directly saves another player during a major encounter.
That's harder.
There may be many valid sequences:
Player revives teammate
or:
Player draws boss aggro → teammate escapes lethal attack
or:
Player uses shield → absorbs incoming damage → teammate survives
A rigid rule tree could become cumbersome.
This is where the optional interpretation layer becomes interesting.
v1.0.0 provides a server-side OpenAIInterpreter using structured output, bounded timeouts/retries, metadata redaction, and an approach that treats event content as untrusted.
The developer can inject it:
const interpreter = new OpenAIInterpreter( new OpenAI({ apiKey: process.env.OPENAI_API_KEY, }), { model: process.env.OPENAI_MODEL ?? "gpt-5-mini", timeoutMs: 10_000, retries: 2, }, );
The model can help interpret complex gameplay context.
But there is a deliberate boundary:
AI does not automatically become authority.
Interpretation is supplementary by default, and an interpretation result can only independently satisfy an achievement if the achievement explicitly allows that policy and the configured confidence requirement is met.
So the architecture becomes:
Simple objective condition ↓ Deterministic rule ↓ Verification Complex contextual condition ↓ Minimized gameplay context ↓ Optional interpretation ↓ Configured policy ↓ Verification
Rules remain the foundation.
Intelligence handles ambiguity where it actually adds value.
8. Turning verification into a credential
Dragonslayer has been verified.
Now it can become something portable.
if (!verification.verified) { throw new Error("Achievement not verified."); } const credential = await btd.credentials.issue(verification);
The SDK refuses credential issuance for unverified results.
Conceptually, our credential could represent:
BTD CREDENTIAL ✓ VERIFIED DRAGONSLAYER Defeat the Ancient Dragon with a critical final attack. Player player_7f32 Game Chronicles of Eldoria Achievement dragonslayer Evidence SHA-256(...) Issuer did:btd:local
The actual v1.0.0 credential format is JSON-friendly and inspired by verifiable credential data models, but the project explicitly does not claim full W3C Verifiable Credentials compliance.
Without an injected signer, issuance produces a transparent DigestProof.
A production environment can instead inject protected signing infrastructure.
This separates two concepts that are often mixed together:
Verification asks: did the evidence satisfy the rule?
Issuance asks: how do we package the verified result into a portable claim?
9. Publishing proof without publishing gameplay
Chronicles of Eldoria also wants players to optionally establish that their credential existed outside the game's own database.
This is where Solana can enter the architecture.
But the studio doesn't need to upload:
- every combat event,
- the player's complete session,
- raw behavioral telemetry,
- AI prompts,
- private account information,
- or the entire credential.
Instead, By The Deed's Solana flow canonicalizes the credential and builds a digest suitable for publication.
const builder = new SolanaProofBuilder("devnet"); const publicationPayload = await builder.build( credential );
Conceptually:
Raw gameplay ↓ Private evidence ↓ Verification ↓ Credential ↓ Canonicalization ↓ Hash ↓ Solana
The public layer can therefore contain the commitment while richer gameplay evidence stays elsewhere.
v1.0.0 explicitly recommends publishing only canonical digests to public chains unless players clearly consent to something more.
10. What Solana does—and doesn't—do
The blockchain is not determining whether the player killed the Ancient Dragon.
The game and verification system already handled that.
Solana provides an optional publication layer for the resulting proof.
This distinction keeps the architecture much simpler:
GAME knows what happened ↓ BTD determines whether the evidence satisfies the achievement ↓ CREDENTIAL represents the verified result ↓ SOLANA optionally anchors the proof
The included MockSolanaAdapter in v1.0.0 does not send a real transaction. Production applications need a real adapter responsible for constructing, signing, submitting, and confirming publication before returning a confirmed result.
That makes Solana support explicit rather than pretending the base SDK performs production blockchain submission automatically.
11. The trust boundary
Now we reach the most important limitation of the case study.
Suppose a modified client sends:
{ "enemyId": "ancient_dragon", "critical": true }
when the player never fought the dragon.
The rule could still match.
Why?
Because valid evidence is not necessarily honest evidence.
By The Deed v1.0.0 explicitly acknowledges this boundary: the evidence digest commits to normalized event identity, type, timestamp, sequence, and payload, but does not prove that the game client was honest. Authoritative telemetry and anti-cheat remain deployment responsibilities.
For a cosmetic achievement, client evidence might be acceptable.
For something carrying economic, competitive, or reputational value, Chronicles of Eldoria should instead capture authoritative events from trusted game infrastructure.
For example:
Player client ↓ Game server ↓ Server validates boss state ↓ Server confirms final damage ↓ Trusted gameplay event ↓ BTD capture ↓ Verification
The stronger the source of evidence, the stronger the meaning of the resulting credential.
12. Storage without locking the game to one database
Chronicles of Eldoria may already use Redis, PostgreSQL, DynamoDB, or another backend.
By The Deed doesn't require replacing it.
v1.0.0 exposes a small storage adapter boundary, with built-in memory/browser-oriented options and support for custom implementations.
A game could implement:
export class RedisStorage implements StorageAdapter { constructor(private readonly redis: RedisClient) {} get(key: string): Promise<string | null> { return this.redis.get(`btd:${key}`); } async set( key: string, value: string ): Promise<void> { await this.redis.set(`btd:${key}`, value); } async delete(key: string): Promise<void> { await this.redis.del(`btd:${key}`); } }
That adapter-oriented approach also appears elsewhere in the SDK.
Storage can be replaced.
Transport can be replaced.
Interpretation is injected.
Signing can be injected.
Solana publication is isolated.
The verification system therefore doesn't need to own the game's entire infrastructure.
13. The complete Dragonslayer journey
We can now follow the complete achievement from beginning to end.
Step 1 — Play
The player enters the Dragon's Lair.
Chronicles of Eldoria Dragon's Lair Heroic difficulty
Step 2 — Capture
The trusted game integration captures meaningful events.
raid_started enemy_defeated enemy_defeated ancient_dragon defeated raid_completed
Step 3 — Verify
The achievement rule checks:
enemyId == ancient_dragon AND critical == true
Result:
VERIFIED
Step 4 — Prove
The verified result becomes a credential containing a digest of the supporting evidence.
DRAGONSLAYER ✓ VERIFIED
The credential can optionally be signed.
Its canonical digest can optionally be prepared for publication on Solana.
Step 5 — Own
The credential can exist independently from the transient UI moment when the achievement originally appeared.
The conceptual result is:
The player didn't receive proof because they claimed the achievement.
They received proof because their captured deed satisfied the game's definition of the achievement.
14. Why this model matters beyond achievements
Dragonslayer is deliberately simple.
The same architecture can represent more complex claims.
A competitive game could verify:
Finish a ranked season in the top division.
A racing game could verify:
Complete a specific track under a defined time.
A survival game could verify:
Survive 100 in-game days without dying.
An RPG could verify:
Complete every encounter in a dungeon within thirty minutes.
A multiplayer title could verify:
Win ten matches while satisfying defined participation requirements.
Because v1.0.0 supports counts, sequences, time windows, comparisons, aggregation, and composable logical rules, these kinds of requirements can be represented as structured achievement definitions rather than arbitrary code paths.
The credential becomes the output.
The deed remains the source.
15. Why not just mint an NFT?
Because ownership and verification solve different problems.
Minting something onchain can establish ownership of the token.
It does not automatically establish that the player actually performed the gameplay accomplishment represented by it.
By The Deed focuses first on:
What happened? ↓ What evidence exists? ↓ What does the game require? ↓ Does the evidence satisfy it? ↓ What claim can now be issued?
Only after that does optional blockchain publication enter the flow.
This makes Web3 an output layer rather than the gameplay engine.
16. Why not make everything AI-powered?
For the same reason.
An AI model can interpret ambiguity.
It doesn't need to decide whether:
score >= 50_000
or:
enemyId == "ancient_dragon"
or:
critical == true
By The Deed's architecture allows deterministic conditions to stay deterministic while making contextual interpretation available where rigid rules are insufficient.
That creates a cleaner separation:
Rules = objective requirements AI = contextual interpretation Credential = verified claim Solana = optional public anchoring
Each layer has one job.
17. Privacy by minimization
Proof of Play doesn't require turning a player's entire gaming history into public data.
In fact, By The Deed's v1.0.0 guidance recommends opaque player IDs, server-side secrets, minimized AI context, and canonical digests for public-chain publication.
For our fictional player, the public proof doesn't need to expose:
Every enemy they fought Every item they collected Every position they visited Their chat messages Their account email Their IP address Their complete session
The system can instead work toward proving one narrow statement:
The defined Dragonslayer achievement was successfully verified.
That's a much better boundary for portable gameplay credentials.
18. From one game to a broader Proof-of-Play layer
v1.0.0 focuses on the SDK foundation.
The project's roadmap points toward dedicated Unity, Unreal, and Godot tooling, managed verification, hosted rule management, batch and streaming ingestion, anti-cheat/anomaly signals, cross-game reputation, credential revocation/status, wallet identity, compressed Solana credentials, more chain/storage adapters, realtime subscriptions, analytics, organization controls, and schema tooling. These are planned directions, not promised dates.
If those layers develop over time, the same Dragonslayer credential could eventually participate in a broader ecosystem.
Not because every game agrees that defeating a dragon means the same thing.
But because every credential can carry a clear relationship between:
game → achievement definition → evidence → verification → issuer → proof
That provenance is more important than pretending all gameplay is universally comparable.
Conclusion
The Dragonslayer case study begins with something games have done for decades:
A player defeats a boss.
The difference is what happens afterward.
Instead of reducing the accomplishment to a boolean stored in one game's database, By The Deed provides infrastructure for turning the underlying gameplay evidence into a structured verification result and, after successful verification, a portable credential.
The game still defines what matters.
The game still controls its gameplay.
The game still determines which evidence is trustworthy.
By The Deed sits between gameplay and proof:
PLAYER ↓ plays GAME ↓ captures BTD ↓ verifies CREDENTIAL ↓ proves PLAYER ↓ owns
AI can help when interpretation is genuinely needed.
Solana can provide an optional publication layer.
Neither needs to replace deterministic game logic.
That is the foundation established by By The Deed SDK v1.0.0: typed gameplay evidence, game-defined verification, portable credentials, and optional intelligence and blockchain integrations.
Play → Capture → Verify → Prove → Own.
Your actions are your proof.