Why Btd Works: Because Gameplay Should Mean More

Games are full of moments that matter.

A difficult boss defeated after hours of attempts. A perfect race. A rare challenge completed. A competitive milestone reached. A decision that changes the direction of a world.

Players earn these accomplishments through real actions, but most of them ultimately become a badge, an entry in a database, or a notification that disappears seconds later.

At Btd Works, we think those actions can become something more.

Gameplay already creates valuable evidence

Every game produces a continuous stream of events.

A player defeats an enemy. A match ends. A quest is completed. An item is discovered. A score crosses a threshold. A sequence of actions happens within a specific amount of time.

Games already understand these events internally. The missing piece is a simple way to turn meaningful combinations of them into verifiable Proof of Play.

That is what By The Deed is being built for.

Instead of asking developers to redesign their games around blockchain or external infrastructure, By The Deed starts with the game itself:

Play → Capture → Verify → Prove → Own

Because an achievement should be more than a boolean

Traditional achievement systems often end with something similar to:

achievement_unlocked = true

That works perfectly well for displaying a badge inside a game.

But it says very little about why the achievement was earned.

By The Deed takes a different approach. Developers define the conditions that matter, gameplay events provide the evidence, and those conditions are evaluated before a proof is created.

A developer might define:

Defeat Ancient Dragon
+
Heroic difficulty
+
Critical final attack
=
Dragonslayer

The important part isn't the name Dragonslayer.

It's the deed behind it.

Rules first. Intelligence when it matters.

Not every gameplay accomplishment needs AI.

If an achievement requires a score above 50,000, deterministic code should verify it. If a player needs to defeat ten enemies within five minutes, rules can determine whether that happened.

But games also contain situations that are difficult to express as simple numbers and conditions.

Maybe an achievement depends on whether a player performed an exceptional rescue, completed an encounter in an unusual way, or demonstrated a meaningful combination of actions.

That's where intelligent interpretation can complement deterministic verification.

The goal isn't to let AI decide everything.

It's to use rules for what can be proven directly and interpretation for context that actually needs understanding.

Web3 should come after the game

We also don't believe every gameplay event belongs onchain.

Putting every attack, movement, quest event, or inventory change onto a blockchain would add complexity where games don't need it.

By The Deed approaches Web3 from the opposite direction.

Gameplay
↓
Evidence
↓
Verification
↓
Credential
↓
Optional onchain proof

The game remains the game.

Only after something meaningful has been verified does blockchain become useful as an optional layer for portability and public proof.

That keeps Web3 out of the critical gameplay loop while still giving developers a path toward player-owned achievements.

Proof should travel further than the achievement screen

Imagine completing one of the hardest challenges in a game.

Today, that accomplishment usually lives wherever the developer decides to store it. If the service disappears or another game wants to recognize the achievement, there isn't necessarily a portable representation of what you accomplished.

Proof of Play creates another possibility.

A verified accomplishment can become a credential that represents:

who issued it, what was accomplished, what rules were satisfied, and what evidence was used to verify it.

That doesn't mean every game needs to trust every credential automatically.

It means the accomplishment can exist beyond the moment when an achievement notification appears on screen.

Built for developers, not around them

For Proof of Play to work, integration has to fit into existing development workflows.

A game studio shouldn't need to rebuild its architecture just to experiment with verifiable achievements.

That's why we're building Btd Works around a developer-first model: capture gameplay events from existing game systems, define verification rules, optionally interpret complex context, issue credentials, and connect additional infrastructure only when needed.

Start with the game.

Everything else is a layer.

Why Btd Works?

Because games are becoming persistent worlds where players invest increasingly meaningful amounts of time, skill, creativity, and identity.

Yet much of what players accomplish remains trapped inside isolated systems.

We want to build infrastructure that gives developers another option.

Not every action needs proof.

Not every achievement needs to be onchain.

Not every game needs AI.

But when a deed genuinely matters, developers should have the tools to capture it, verify it, and turn it into something the player can carry forward.

That's the idea behind By The Deed.

The game creates the moment.
The deed creates the evidence.
Btd Works turns it into proof.

Your actions are your proof.