One Proof Layer, Built to Integrate Across Games

Games are built differently.

A browser-based RPG doesn't share the same architecture as a large multiplayer title. Unity projects have different workflows from Unreal Engine games. Godot developers make different technology choices again. Some games depend heavily on authoritative servers, while others can run almost entirely on the player's device.

But underneath those differences, they all produce something useful:

Gameplay events.

A player defeats an enemy. A match finishes. A quest is completed. An item is discovered. A player reaches a new area. A team wins a tournament.

By The Deed is being built around those events—not around one specific engine.

The goal is to create a common Proof-of-Play layer that developers can integrate into different games while keeping their existing game architecture intact.

Start with the game

By The Deed doesn't need to become the system controlling the game.

The game remains responsible for movement, combat, inventory, matchmaking, quests, progression, and everything else that makes its world work.

BTD starts when something meaningful happens.

Imagine three completely different games:

Fantasy RPG
enemy_defeated
quest_completed
dungeon_completed

Racing Game
race_started
checkpoint_reached
race_completed

Competitive Shooter
match_started
enemy_eliminated
match_completed

The events are different because the games are different.

That's intentional.

With @btdworks/sdk, developers define an event map that represents the actions their own game understands. Event names become typed contracts associated with their respective payloads.

A fantasy RPG could define:

type GameEvents = {
  enemy_defeated: {
    enemyId: string;
    weapon: string;
    critical: boolean;
  };

  quest_completed: {
    questId: string;
    durationMs: number;
  };
};

A racing game could use the same SDK with an entirely different contract:

type GameEvents = {
  checkpoint_reached: {
    checkpointId: string;
    elapsedMs: number;
  };

  race_completed: {
    trackId: string;
    position: number;
    totalTimeMs: number;
  };
};

BTD doesn't decide what gameplay looks like.

The developer does.

Capture the deeds that matter

Once integrated, the game can capture meaningful events as they happen.

await btd.capture("enemy_defeated", {
  enemyId: "ancient_dragon",
  weapon: "sunblade",
  critical: true,
});

The SDK handles the surrounding event infrastructure, including runtime envelope validation, ordering, deduplication, payload limits, and session-scoped evidence.

That creates a simple boundary:

GAME ENGINE
     ↓
Gameplay happens
     ↓
Meaningful event
     ↓
BTD CAPTURE
     ↓
Typed evidence

Not every frame needs to become evidence.

Not every movement needs to be recorded.

Developers decide which actions matter for the achievements or credentials they want to create.

One SDK, different worlds

This is where the larger idea behind the pixel globe becomes important.

Every part of that world can represent a different game.

A fantasy character might prove they defeated a legendary boss.

A racing player might prove they completed a difficult track under three minutes.

A competitive player might prove they reached the highest ranked division.

A survival player might prove they completed one hundred days without dying.

The worlds don't need the same gameplay.

They only need a way to express meaningful events and define what those events prove.

Conceptually:

RPG ────────────┐
Racing ─────────┤
Shooter ────────┤
Strategy ───────┼──→ BTD → VERIFY → PROOF
Survival ───────┤
Web Game ───────┤
Indie Game ─────┘

The game-specific layer stays on the left.

The proof infrastructure stays on the right.

Developers define what counts

Capturing an event doesn't automatically create an achievement.

The game defines the conditions.

By The Deed v1.0.0 includes deterministic rules for comparisons, counts, sequences, aggregations, time windows, and logical combinations such as AND, OR, and NOT.

An RPG could define:

Defeat Ancient Dragon
AND
Critical Hit
=
DRAGONSLAYER

A racing game could define:

Complete Alpine Circuit
AND
Time < 03:00
=
SPEED MASTER

A competitive game could define:

Win ≥ 10 ranked matches
AND
Placement reaches Master
=
MASTER COMPETITOR

Different gameplay.

Different rules.

Same verification model.

Integration doesn't mean dependency

One of the important goals of By The Deed is keeping the core gameplay experience independent.

The SDK can run with local memory storage and deterministic verification without requiring OpenAI, a wallet, a database, or Solana. Its architecture exposes storage and transport boundaries so applications can introduce infrastructure appropriate to their production environment.

That means a developer can start with:

Game
 ↓
BTD SDK
 ↓
Local verification

and later evolve toward:

Game / Server
      ↓
BTD SDK
      ↓
Durable evidence storage
      ↓
Verification
      ├── Optional interpretation
      ↓
Credential
      └── Optional Solana publication

The integration can grow with the game instead of requiring every layer from day one.

Intelligence is another layer

Games sometimes produce accomplishments that aren't easily represented by a number.

Consider an RPG achievement:

Save another player through an exceptional combination of actions during a boss encounter.

There might be many valid ways to accomplish that.

This is where optional intelligent interpretation can help.

By The Deed v1.0.0 includes a server-side OpenAI interpretation adapter for contextual gameplay analysis, while keeping deterministic game-defined rules as the foundation. AI cannot independently approve an achievement unless the developer explicitly configures the appropriate policy and confidence requirement.

The architecture remains:

Rules where rules work. Context where context matters.

From integration to portable proof

After verification succeeds, the result can become a portable Proof-of-Play credential.

That creates an important separation.

The original game might understand hundreds of internal systems.

Another application doesn't necessarily need to understand all of them.

Instead, it can receive a structured claim representing a verified accomplishment.

GAME A
Fantasy RPG
     ↓
DRAGONSLAYER
     ↓
Verified credential


GAME B
Racing
     ↓
SPEED MASTER
     ↓
Verified credential


GAME C
Competitive
     ↓
MASTER RANK
     ↓
Verified credential

Each credential still originates from its own game's rules and evidence.

Portability does not mean every game must automatically trust every other game's achievements. It means the proof can exist beyond the original achievement screen and be evaluated by another system if that system chooses to recognize it.

Web3 comes after verification

Integrating BTD also doesn't mean turning the game into an onchain application.

Players shouldn't need to wait for a transaction every time they defeat an enemy.

The intended flow is the opposite:

PLAY
 ↓
CAPTURE
 ↓
VERIFY
 ↓
CREDENTIAL
 ↓
OPTIONAL ONCHAIN PROOF

By The Deed's Solana integration is isolated behind a dedicated adapter boundary. The SDK can canonicalize a verified credential into a digest for optional publication while keeping raw gameplay evidence private. The included v1.0.0 mock adapter does not submit real transactions; a production implementation must handle real construction, signing, submission, and confirmation.

Blockchain becomes a destination for proof, not the place where every gameplay action has to happen.

Integration should follow the game's trust model

There is also an important difference between integrating BTD and making an achievement trustworthy.

A browser game can capture:

boss_defeated

But if the player can freely manipulate that browser, the event itself shouldn't automatically be treated as authoritative.

For low-stakes demos or cosmetic achievements, that may be perfectly acceptable.

For competitive, reputational, or economically valuable credentials, the better architecture is:

PLAYER
   ↓
GAME CLIENT
   ↓
AUTHORITATIVE SERVER
   ↓
Validated gameplay event
   ↓
BTD
   ↓
VERIFICATION
   ↓
CREDENTIAL

The current SDK documentation explicitly makes this boundary clear: verification proves that supplied evidence matched the configured rule; it does not itself prove that an untrusted game client reported the event honestly.

BTD complements the game's trust architecture rather than replacing it.

Building toward game-engine integrations

The current SDK provides the underlying TypeScript infrastructure.

The roadmap extends that foundation toward dedicated Unity tooling, Unreal Engine integration, and a Godot addon, alongside managed verification, streaming ingestion, anti-cheat and anomaly signals, cross-game reputation, credential status systems, and additional infrastructure. These are planned directions rather than promised release dates.

The long-term integration model is simple:

        DIFFERENT GAMES

   RPG    Racing    Shooter
    │       │          │
 Unity   Unreal      Godot
    │       │          │
    └───────┼──────────┘
            ↓
       BY THE DEED
            ↓
         CAPTURE
            ↓
         VERIFY
            ↓
          PROVE
            ↓
           OWN

Different engines.

Different worlds.

Different achievements.

One common layer for turning meaningful gameplay into proof.

A world of deeds

That's what the globe represents.

Not one game connected to Web3.

Not one RPG using an achievement SDK.

But many independent game worlds producing accomplishments that can become structured, verifiable proofs.

The game remains responsible for creating the experience.

The developer remains responsible for deciding what matters.

By The Deed provides the infrastructure between doing something meaningful and being able to prove it happened.

Any game. Any world. Every meaningful deed.

Play → Capture → Verify → Prove → Own.

Your actions are your proof.