Web3 Should Be the Layer, Not the Game
A player enters a dungeon, defeats a boss, discovers a rare item, and completes a challenge that took hours to master.
None of those moments should require the player to think about blockchain.
They shouldn't need to approve a transaction after every action. They shouldn't need to understand gas, RPCs, wallets, or smart contracts before they can enjoy the game.
At Btd Works, we believe the game should always come first.
Web3 becomes valuable after something meaningful happens—as infrastructure for proof and ownership, rather than the mechanic around which the entire game is built.
Start with gameplay
Consider a simple RPG achievement:
Dragonslayer — Defeat the Ancient Dragon with a critical final attack.
The game already knows when that happens. It might produce an event like:
await btd.capture("enemy_defeated", {enemyId: "ancient_dragon",weapon: "sunblade",damage: 4820,critical: true,});
The interesting part isn't putting this event onchain.
The interesting part is determining whether the event represents an accomplishment the game considers meaningful.
That's where the proof layer begins.
Capture what matters, not everything
Games generate enormous amounts of activity.
Movement, attacks, damage, inventory changes, checkpoints, NPC interactions, match state, and hundreds of other signals can happen during a single session.
Most of them don't need to become permanent proofs.
A BTD integration can focus on meaningful events:
PLAYER PLAYS│▼┌───────────────┐│ GAME ENGINE │└───────┬───────┘│ meaningful events▼┌───────────────┐│ CAPTURE ││ typed evidence│└───────┬───────┘▼┌───────────────┐│ VERIFY ││ game rules │└───────┬───────┘▼┌───────────────┐│ PROVE ││ credential │└───────┬───────┘│ optional▼┌───────────────┐│ WEB3 ││ public anchor │└───────────────┘
This changes Web3 from a gameplay dependency into an optional destination for verified proof.
The game decides what is true
Suppose the game defines Dragonslayer as:
const dragonslayer = achievement("dragonslayer").named("Dragonslayer").when(event("enemy_defeated").where("enemyId", "equals", "ancient_dragon").and("critical", "equals", true)).build();btd.achievements.register(dragonslayer);
Now the achievement has an explicit definition.
The player doesn't receive Dragonslayer because their wallet says they own a Dragonslayer token.
They receive it because gameplay evidence satisfied the game's rule.
The order matters:
Wrong directionTOKEN↓GAMEPLAYBTD directionGAMEPLAY↓EVIDENCE↓VERIFICATION↓PROOF↓OPTIONAL OWNERSHIP
Web3 doesn't create the accomplishment.
The player's deed does.
Not everything needs AI either
The same principle applies to artificial intelligence.
If the requirement is:
critical == true
we don't need an AI model to interpret it.
If the requirement is:
score >= 50,000
deterministic rules are better.
But games can also contain accomplishments that depend on context.
Imagine an achievement for performing an exceptional rescue of another player during a boss encounter. There could be many combinations of healing, shielding, positioning, aggro management, and other actions that lead to that outcome.
In cases like these, intelligent interpretation can become another layer.
┌─ Deterministic rulesGAMEPLAY ──────┤└─ Optional interpretation│▼VERIFICATION
AI should be used because the problem needs interpretation—not because everything needs an AI label.
Verification comes before ownership
Once the evidence satisfies the achievement definition, the result can become a portable credential.
Conceptually:
{"achievement": "dragonslayer","game": "chronicles-of-eldoria","player": "player_7f32","verified": true,"evidenceDigest": "sha256:..."}
The richer gameplay evidence can remain within the game's infrastructure while the resulting credential represents the verified accomplishment.
This is where Web3 starts becoming interesting.
Instead of asking a blockchain to process the gameplay itself, a game can optionally anchor a canonical proof after verification has already happened.
That creates a much cleaner separation:
| Layer | Responsibility |
|---|---|
| Game | Create the experience |
| Capture | Record meaningful actions |
| Rules | Define what matters |
| Verification | Determine whether the deed qualifies |
| Credential | Represent the accomplishment |
| Web3 | Optionally anchor or extend ownership |
The player can spend their time playing.
Infrastructure stays infrastructure.
A wallet shouldn't be the tutorial
Imagine launching an RPG for the first time and immediately seeing:
Connect Wallet
before you've even created a character.
For some crypto-native experiences, that might be intentional. But it doesn't need to be the default architecture for every game that wants digital ownership.
A Proof-of-Play system allows the relationship to happen differently:
PLAY FIRST↓Player experiences the game↓Player accomplishes something↓Achievement is verified↓Proof is created↓Ownership becomes relevant
The technology appears when it provides value.
Not before.
This also creates better integration boundaries
A game shouldn't need to rebuild its combat system around BTD.
Unity shouldn't need to become a blockchain engine.
Unreal shouldn't need every gameplay event to become a transaction.
A browser RPG shouldn't require a wallet just to start moving a character.
The integration boundary can remain small:
await btd.capture("quest_completed", {questId: "the-fallen-king",durationMs: 1_840_000,});
From there, BTD can handle the path toward verification and proof while the game continues operating normally.
That makes the architecture easier to reason about:
┌──────────────────────── GAME ────────────────────────┐│ ││ Combat Quests Racing Exploration Matches ││ │ │ │ │ │ │└──────┼───────┼────────┼──────────┼───────────┼───────┘└───────┴────────┴────┬─────┴───────────┘│meaningful deeds│▼┌──────────────┐│ BTD LAYER ││ ││ Capture ││ Verify ││ Prove │└──────┬───────┘│when useful▼┌──────────────┐│ WEB3 │└──────────────┘
The stronger the proof, the stronger the evidence
There is one important boundary.
Putting a hash onchain doesn't magically make the original gameplay event trustworthy.
If an easily modified client claims:
{enemyId: "ancient_dragon",critical: true}
the blockchain cannot determine whether the dragon actually existed or whether the player really defeated it.
For valuable achievements, the better production architecture is:
PLAYER↓GAME CLIENT↓AUTHORITATIVE GAME SERVER↓TRUSTED GAMEPLAY EVIDENCE↓BTD VERIFICATION↓CREDENTIAL↓OPTIONAL WEB3 PROOF
Web3 strengthens portability and public anchoring.
It doesn't replace authoritative game infrastructure or anti-cheat.
That distinction is critical if Proof of Play is going to represent accomplishments that actually matter.
Build games people want to play
Web3 gaming doesn't need to mean turning every mechanic into a financial primitive.
It can be much quieter.
A player explores a world.
They defeat something difficult.
They accomplish something rare.
The game verifies the deed.
And only then, if useful, that accomplishment can become something portable and ownable.
That's the model we're building toward with By The Deed:
Play → Capture → Verify → Prove → Own.
The blockchain doesn't need to be the game.
AI doesn't need to be the game.
BTD doesn't need to be the game.
The game should be the game.
Everything else should make what happens inside it more meaningful.
Web3 should support the world—not become the world.