Technical Architecture
Tapzi uses a hybrid architecture designed around a simple principle:
Use real-time infrastructure where speed matters, and blockchain infrastructure where verifiability and settlement matter.
Competitive games require low latency.
Requiring every move, timer update, matchmaking event, or game-state transition to execute directly on-chain would introduce unnecessary cost and delay.
At the same time, economically significant actions such as match commitments and settlement benefit from transparent and programmable infrastructure.
Tapzi therefore separates gameplay execution from settlement while connecting the two through authenticated match records.
1. Architecture Overview
At a high level, Tapzi is organized into several interconnected layers:
The exact implementation of individual components can evolve as Tapzi scales.
The architectural separation between real-time execution and verifiable settlement remains fundamental.
2. Client & Interface Layer
The interface layer is how users and third-party applications interact with Tapzi.
Current and future surfaces may include:
Tapzi web application;
mobile-responsive interfaces;
third-party games using Tapzi Studio;
creator-generated experiences;
partner integrations;
eligible social or mini-app environments.
These surfaces should connect to shared Tapzi infrastructure wherever practical rather than creating independent player databases, ratings, or settlement systems.
The long-term objective is:
Multiple interfaces, one competitive network.
3. Identity & Access Layer
Every competitive system needs a reliable way to identify participants and maintain session integrity.
Tapzi's identity architecture can support different levels of assurance depending on the activity being performed.
Potential identity methods include:
platform accounts;
compatible self-custodial wallets;
wallet signatures;
session authentication;
future social or email authentication;
embedded smart accounts where implemented.
Identity requirements can increase for higher-risk activity.
For example:
Practice Play
May require only basic account authentication.
Competitive Play
May require additional wallet, eligibility, or jurisdiction checks.
Higher-Value Competition
May require stronger identity assurance.
Restricted or Regulated Functionality
May require additional verification where applicable.
Identity architecture is therefore designed to support both low-friction onboarding and stronger assurance when necessary.
4. Player Identity vs Wallet Identity
A blockchain wallet is not, by itself, a complete competitive identity.
A single user may:
use more than one wallet;
change wallets;
reconnect from different devices;
participate across multiple games.
Tapzi therefore distinguishes between:
Wallet Identity
The blockchain address used for applicable transactions.
and
Tapzi Player Identity
The persistent competitive account used for:
matchmaking;
ratings;
match history;
tournaments;
reputation;
future Player Passport functionality.
This distinction allows competitive history to become more useful than a raw wallet address alone.
5. Matchmaking Layer
Tapzi's matchmaking infrastructure is responsible for creating appropriate competitive sessions.
Depending on the game and match type, matchmaking may consider signals such as:
game selection;
competitive rating;
queue time;
availability;
match configuration;
tournament eligibility;
region or latency;
competition rules.
The objective is not simply to find any opponent.
The objective is to create matches that are:
technically viable;
competitively appropriate;
compliant with the relevant game or tournament rules.
6. Competitive Ratings
Tapzi uses rating systems to represent player performance across supported competitive games.
Ratings are intended to support:
skill-aware matchmaking;
ranked ladders;
tournament qualification;
player progression.
Skill ratings should remain game-specific where the games measure different capabilities.
A player's Chess rating, for example, should not automatically become their rating in another strategy title.
This is different from network reputation, which may include broader signals such as match completion and fair-play history.
7. Real-Time Game Infrastructure
Gameplay requires response times that traditional blockchain execution is not designed to provide efficiently.
Tapzi therefore processes latency-sensitive gameplay through real-time infrastructure.
Depending on the game, this layer may manage:
game rules;
authoritative game state;
move validation;
timers;
session state;
player connections;
reconnection;
forfeiture conditions;
match completion;
game events;
replay data.
For supported titles, the server acts as the authoritative source of game state.
This reduces reliance on untrusted client software.
8. Server-Authoritative State
A client should not be able to simply report:
"I won."
The game infrastructure needs an independently maintained record of the match.
In a server-authoritative model:
players submit valid actions;
the server validates those actions against game rules;
the authoritative state is updated;
both participants receive the updated state;
the server determines when the game reaches a valid terminal condition.
This helps reduce manipulation of:
game state;
timers;
illegal moves;
completion conditions.
Server authority does not eliminate all forms of cheating.
It provides a trusted game-state foundation on top of which other integrity controls can operate.
9. Match Event Record
Important match events can be recorded throughout a competitive session.
Depending on the game, these may include:
match creation;
participant identities;
starting conditions;
moves or actions;
timestamps;
reconnect events;
timeout events;
surrender or forfeiture;
final state;
winner;
integrity signals.
These records can support:
result verification;
replay;
debugging;
dispute resolution;
anti-cheat analysis.
The precise information retained should follow applicable privacy, security, and operational requirements.
10. Cryptographic Result Authentication
When a match finishes, the result needs to be linked reliably to the session that produced it.
Tapzi can use cryptographic authentication to bind information such as:
match identifier;
participants;
final state;
winner;
timestamp;
settlement parameters.
Cryptographic signatures can make unauthorized alteration easier to detect.
Where implemented, signed match results can then be used by settlement infrastructure to determine whether predefined conditions have been met.
Cryptographic authentication does not prove that a human made every decision during the game.
That problem belongs to the competitive-integrity layer.
11. Competitive Integrity Layer
Tapzi treats competitive integrity as a multi-layer system.
The architecture may combine:
Server-Side Rule Enforcement
Prevent illegal game-state transitions.
Cryptographic Authentication
Protect the integrity of important match records.
Behavioral Analysis
Identify suspicious player behavior.
Replay Evidence
Provide records for investigation.
Reputation
Use historical behavior as an additional risk signal.
Dispute Procedures
Provide a review path where automated evidence is not sufficient.
This layer is discussed in greater detail in the dedicated Competitive Integrity section.
12. Escrow Architecture
For supported value-based competitive formats, applicable participant commitments can be governed through smart-contract infrastructure.
The objective of escrow is to ensure that:
applicable match commitments are confirmed before competition begins;
one participant cannot unilaterally remove committed assets during the match;
settlement occurs according to predefined match rules after a valid result.
The exact match economics remain governed by Tapzi's published competition rules.
Whitepaper 3.0 does not introduce a new protocol rake or modify existing tokenomics.
13. Settlement Layer
Once the system establishes that a match has completed under the applicable rules, settlement instructions can be submitted to the relevant smart contract.
The settlement layer may verify information including:
match identifier;
participant addresses;
authenticated match result;
settlement status;
replay protection;
applicable match configuration.
Following successful validation, the contract executes the applicable settlement.
This architecture separates:
Determining what happened
from
Moving value based on what happened.
That separation is important for both performance and security.
14. Replay Protection
Settlement infrastructure must prevent the same valid result from being processed repeatedly.
Replay protections may include:
unique match identifiers;
settlement-state tracking;
cryptographic nonces;
signatures;
one-time execution conditions.
Once a match is finalized and settled, repeated settlement attempts should be rejected.
15. Hybrid Off-Chain / On-Chain Model
Tapzi does not attempt to place every application action on-chain.
Instead:
Off-Chain
Best suited for:
matchmaking;
game state;
timers;
real-time events;
telemetry;
replay records;
analytics;
behavioral anti-cheat.
On-Chain
Best suited for applicable:
token transfers;
escrow;
settlement;
verifiable contract execution;
publicly auditable transaction records.
This hybrid model aims to combine:
performance
verifiability
without paying blockchain costs for operations that do not benefit from blockchain execution.
16. Data & Persistence Layer
Competitive infrastructure requires persistent data beyond blockchain transactions.
Depending on implementation, Tapzi systems may maintain data such as:
player profiles;
matchmaking information;
rating history;
game sessions;
replay information;
tournament state;
integrity events;
dispute records;
application analytics.
Blockchain transaction history and application data serve different purposes.
Not every internal application record should be stored on-chain.
17. Analytics Layer
Tapzi's infrastructure is designed to produce operating information that can improve the network.
Potential metrics include:
active players;
queue times;
matchmaking success;
match completion;
session failures;
reconnect frequency;
average match duration;
dispute frequency;
suspicious behavior;
settlement success;
infrastructure latency.
As Tapzi Studio develops, selected analytics may also become available to third-party developers.
18. Developer/API Layer
The same capabilities used by first-party Tapzi games can progressively be exposed through developer interfaces.
Future Tapzi Studio APIs may include services for:
authentication;
player identity;
matchmaking;
competitive ratings;
tournament management;
match sessions;
settlement;
replay;
reputation;
integrity signals;
analytics.
The API layer should abstract unnecessary blockchain complexity from developers wherever appropriate.
Developers should be able to integrate competitive infrastructure without needing to recreate every underlying service.
19. Tapzi Studio Architecture
A future Tapzi Studio integration could conceptually follow this flow:
Exact SDK modules and supported game engines should only be described as production-ready when publicly available.
20. GameBuilder Architecture
Tapzi GameBuilder is intended to sit above the same underlying competition infrastructure.
Rather than generating an entirely independent backend for every creator game, a compatible experience could potentially inherit:
identity;
matchmaking;
rankings;
tournament functionality;
analytics;
eligible settlement services.
This is one reason the Competition Protocol is strategically important.
The creator layer can focus increasingly on:
game logic;
presentation;
content;
rules;
while Tapzi provides reusable competitive infrastructure.
GameBuilder remains subject to its actual published product status.
21. Tournament Architecture
Tournament infrastructure introduces additional state beyond ordinary matchmaking.
Potential components include:
tournament creation;
participant eligibility;
brackets;
seeding;
rounds;
progression;
results;
qualification;
leaderboard state;
prize configuration.
Tournament Cloud is intended to expose these capabilities to first-party and eventually third-party experiences.
22. Reputation Architecture
Skill ratings answer:
How well does this player perform in this game?
Reputation can answer broader questions such as:
How reliably does this participant behave across the network?
Potential reputation signals may include:
completed matches;
abandoned matches;
confirmed integrity violations;
tournament participation;
dispute outcomes.
Reputation mechanisms require careful handling to avoid unfairly penalizing users based on inaccurate or incomplete data.
Where implemented, players should have appropriate visibility into material reputation-related actions.
23. Blockchain Layer
$TAPZI is initially deployed on BNB Smart Chain using the BEP-20 standard.
BNB Smart Chain provides:
EVM compatibility;
established wallet support;
established developer tooling;
comparatively low transaction costs.
Tapzi's hybrid architecture is designed so that network growth does not require every gameplay event to execute directly on BNB Smart Chain.
Future support for additional networks should be based on technical or commercial requirements rather than chain count as a marketing metric.
24. Multi-Chain Strategy
Multi-chain functionality may become useful for specific future products such as merchant settlement or broader interoperability.
However, Whitepaper 3.0 does not assume that every Tapzi product must operate on every supported chain.
Chain expansion should be justified by factors such as:
user demand;
merchant demand;
liquidity;
settlement assets;
cost;
security;
developer ecosystem.
$TAPZI's existing token architecture remains unchanged.
25. Account Abstraction & Web2.5 UX
Tapzi's long-term user-experience direction includes reducing unnecessary Web3 friction.
Where implemented, account-abstraction technologies may support:
embedded accounts;
sponsored transactions;
gas abstraction;
simplified signing;
social or email onboarding.
On EVM-compatible networks, technologies such as ERC-4337 may provide part of this infrastructure.
Other chains may use different native mechanisms.
Tapzi should therefore describe account abstraction according to the actual chain and implementation rather than applying one technical standard universally.
26. Security Boundaries
A hybrid system contains multiple trust and security boundaries.
These include:
Client Boundary
User-controlled software should not be trusted as the sole source of match truth.
Server Boundary
Backend services require access control, monitoring, and secure deployment.
Signing Boundary
Keys used for authenticated result handling must be appropriately protected.
Smart-Contract Boundary
Contracts require testing, review, and appropriate permissions.
Treasury Boundary
Treasury authority should remain separated from routine game infrastructure.
Developer Boundary
Third-party applications should receive only the permissions required for their integration.
Security architecture should minimize the damage a compromise in one component can cause elsewhere.
27. Smart Contract Security
Tapzi smart contracts should follow practices appropriate to their function, potentially including:
independent audits;
code review;
automated testing;
access-control analysis;
upgradeability review where applicable;
pause/emergency controls where justified;
deployment verification;
responsible disclosure.
Only contracts that have actually completed an audit should be described as audited.
Historical audits remain available through the Audit & KYC / Proof Center documentation.
28. Smart Contract Registry
Tapzi should maintain a canonical registry of production smart contracts.
Where available, the registry should provide:
Contract Name
Human-readable identifier
Network
Deployment network
Address
Verified blockchain address
Purpose
Contract responsibility
Status
Live / Beta / Deprecated
Source
Verified source-code location where public
Audit
Relevant audit report
Deployment Date
Production deployment date
Users should not have to locate contract addresses through marketing posts or third-party sources.
29. Monitoring & Observability
Reliable competitive infrastructure requires continuous monitoring.
Relevant monitoring may include:
service uptime;
API latency;
matchmaking latency;
WebSocket/session health;
transaction failures;
settlement failures;
error rates;
suspicious activity;
contract events.
Monitoring supports both reliability and incident response.
30. Failure Handling
Distributed systems fail.
A credible architecture must account for:
player disconnects;
server failures;
delayed transactions;
chain congestion;
wallet failures;
invalid signatures;
duplicated requests;
interrupted settlement;
disputed game results.
Tapzi's infrastructure should therefore favor deterministic recovery paths rather than assuming every session completes normally.
31. Reconnection & Match Recovery
For eligible games, temporary connectivity loss should not automatically destroy a valid match where recovery is possible.
The system may maintain sufficient session state to support:
reconnect windows;
authoritative state restoration;
timer handling;
abandonment rules;
match continuation.
Exact recovery behavior depends on the game and competition format.
32. Dispute Infrastructure
Some incidents cannot be resolved through automated logic alone.
Dispute infrastructure may therefore include:
match evidence;
authenticated events;
replay information;
transaction records;
integrity flags;
review status;
appeal outcome.
The goal is to make dispute decisions based on recorded evidence wherever possible.
33. Privacy by Architecture
Competitive-integrity systems can generate sensitive behavioral data.
Tapzi should therefore collect only information reasonably required for:
operating the product;
security;
integrity;
analytics;
legal or compliance requirements.
Retention and access should be governed by the applicable Privacy Policy and internal security controls.
Future Player Passport, anti-cheat, social-login, and merchant infrastructure may introduce additional data requirements and should be reflected in privacy documentation when implemented.
34. Scalability Strategy
Tapzi's scaling philosophy is:
Scale the existing architecture before introducing unnecessary blockchain complexity.
Scaling may involve improvements such as:
application caching;
asynchronous processing;
database optimization;
horizontal backend scaling;
regional infrastructure;
queue systems;
batching where appropriate;
smart-contract optimization.
Only after existing architecture creates measurable limits should deeper settlement infrastructure be considered.
35. Dedicated Settlement Infrastructure: Conditional
A dedicated Layer-3, rollup, or application-specific settlement network is not required for Tapzi's current architecture.
Such infrastructure becomes relevant only if measurable network activity creates persistent constraints in areas such as:
throughput;
gas cost;
latency;
transaction volume;
cross-game settlement;
interoperability.
Until those thresholds exist, dedicated settlement infrastructure remains:
🟣 RESEARCH / CONDITIONAL
It should not be represented as deployed infrastructure.
36. AI Agent Infrastructure: Research
The Competition Protocol may eventually support machine participants or autonomous economic agents.
Potential areas of research include:
Agent-vs-Agent competitions;
model benchmarking;
autonomous tournament participation;
machine-to-machine payments.
These possibilities do not alter the current core architecture.
They remain:
🟣 RESEARCH
until product demand and technical requirements justify implementation.
37. Technology Principles
Tapzi's technical architecture follows several principles.
1. Real-Time Where Speed Matters
Gameplay should not become slower merely to place unnecessary actions on-chain.
2. Verifiable Where Value Moves
Economically significant settlement should use transparent and programmable infrastructure where appropriate.
3. Server Authority Over Client Trust
Untrusted clients should not be the sole source of competitive truth.
4. Layered Competitive Integrity
No single anti-cheat technology is sufficient.
5. Modular Infrastructure
Components should become reusable across Tapzi products.
6. Least Privilege
Applications and services should receive only the access they require.
7. Evidence Before Claims
A technology is described as deployed, audited, or operational only when supporting evidence exists.
8. Scale Before Dedicated Chain Infrastructure
Tapzi should build deeper blockchain infrastructure only when usage demonstrates the need.
38. Architecture in One View
This foundation supports the Tapzi Skill Arena today and is designed to progressively support the broader Tapzi ecosystem as its individual components mature.
Fast where gameplay requires it. Verifiable where value requires it. Modular where the network requires it.
Was this helpful?