> For the complete documentation index, see [llms.txt](https://docs.tapzi.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tapzi.io/security-and-compliance.md). # Security, Compliance & Risk Controls
Security and compliance are ongoing operating responsibilities. They are not one-time certifications. Tapzi's infrastructure spans several different risk environments: * competitive gaming; * smart contracts; * digital assets; * player identity; * anti-cheat systems; * treasury operations; * developer integrations; * future merchant infrastructure. Each layer introduces different threats and therefore requires different controls. Tapzi's security philosophy is: > **Reduce risk through layered controls, verify what can be verified, and do not claim that any audit or technology eliminates risk completely.** *** ### 1. Security by Layer Tapzi's security architecture can be understood across several layers. ``` ┌─────────────────────────────────────┐ │ USER & IDENTITY │ │ Authentication · Eligibility · KYC │ └─────────────────┬───────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ APPLICATION SECURITY │ │ Sessions · APIs · Access Controls │ └─────────────────┬───────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ COMPETITIVE INTEGRITY │ │ Anti-Cheat · Replay · Reputation │ └─────────────────┬───────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ SMART CONTRACT LAYER │ │ Escrow · Settlement · Vesting │ └─────────────────┬───────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ TREASURY & KEY SECURITY │ │ Multisig · Permissions · Monitoring │ └─────────────────┬───────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ MONITORING & INCIDENT RESPONSE │ │ Alerts · Investigation · Recovery │ └─────────────────────────────────────┘ ``` No single control is treated as sufficient on its own. *** ### 2. Smart Contract Security Smart contracts can govern economically significant actions within the Tapzi ecosystem. Depending on the applicable contract, this may include: * token functionality; * vesting; * competition-related commitments; * settlement; * treasury-related controls; * future infrastructure. Smart contracts therefore require a different security process from ordinary application code. Tapzi's smart-contract security approach includes or is intended to include, where applicable: * internal code review; * automated testing; * permission analysis; * deployment verification; * independent audit; * monitoring; * responsible disclosure; * emergency procedures where appropriate. Only contracts and contract versions that have actually completed an independent review should be described as audited. *** ### 3. Independent Audits Tapzi maintains separate documentation for completed independent reviews. The [Audit & KYC](/audit-and-kyc.md) page and future **Proof Center** should remain the authoritative sources for: * audit provider; * audit date; * contract or code scope; * report link; * findings; * remediation status where disclosed. An audit confirms that a specific scope was reviewed at a specific point in time. It does not mean: * every future Tapzi contract has been audited; * the application cannot be compromised; * no smart-contract vulnerability exists; * future upgrades are automatically covered; * financial loss is impossible. Tapzi should therefore describe audits precisely according to their actual scope. *** ### 4. Contract-Version Integrity A security report is most useful when participants can determine whether the reviewed code corresponds to the deployed contract. Where technically possible, Tapzi should provide: * contract address; * network; * deployment date; * source-code verification; * audit report; * audited commit or version; * current status. If a production contract materially changes after an audit, the previous report should not automatically be represented as covering the new version. *** ### 5. Application Security Smart-contract security alone does not protect the entire platform. Tapzi also operates application infrastructure that may include: * web applications; * APIs; * authentication systems; * databases; * matchmaking infrastructure; * WebSocket services; * analytics; * administration interfaces; * developer tooling. Application-security controls may include: * authentication; * authorization; * role-based access; * session protection; * rate limiting; * input validation; * secure secrets management; * monitoring; * logging; * dependency management; * infrastructure isolation; * patch management. Security practices should evolve as Tapzi's architecture grows. *** ### 6. Authentication & Session Security A competitive network needs to protect both player accounts and the integrity of active sessions. Depending on the product surface, Tapzi may use: * account authentication; * wallet signatures; * signed messages; * session tokens; * device/session information; * additional verification for sensitive actions. High-risk actions should require stronger controls than ordinary browsing or practice gameplay. Examples may include: * wallet changes; * withdrawals or applicable settlement actions; * account recovery; * administrative actions; * high-value competition. *** ### 7. Wallet Security Tapzi should distinguish between platform security and user-controlled wallet security. For self-custodial wallets: * users control their private keys; * Tapzi does not recover lost seed phrases; * compromised user wallets may lead to unauthorized transactions. Tapzi should never request: * seed phrases; * private keys; * wallet recovery phrases. Users should verify official URLs and contract addresses through Tapzi-controlled documentation. The Proof Center should progressively provide a canonical reference for official contract information. *** ### 8. Non-Custodial Design Where Tapzi describes functionality as non-custodial, that term should be used precisely. Non-custodial generally means that Tapzi does not hold a user's private keys or maintain unilateral control over their wallet assets. However, non-custodial architecture does not eliminate: * smart-contract risk; * user signing errors; * wallet compromise; * phishing; * blockchain congestion; * malicious third-party applications. The benefit is reduced dependence on Tapzi as a custodian, not elimination of all transaction risk. *** ### 9. Competitive Integrity Security within Tapzi also includes protection of the competitive environment. A technically secure wallet does not mean a match is fair. Tapzi therefore separates: **Financial Security** Protection of assets and settlement. from **Competitive Integrity** Protection against manipulation of game outcomes. The latter requires systems such as: * authoritative game state; * legal-move validation; * behavioral analysis; * replay records; * suspicious-account detection; * dispute procedures; * reputation. For more detail, see **Competitive Integrity & Proof-of-Gameplay**. *** ### 10. Anti-Cheat Tapzi does not claim that cheating can be completely eliminated. Competitive abuse can include: * bots; * external engines; * scripted interaction; * client modification; * collusion; * multi-account abuse; * intentional disconnects; * manipulation attempts. Tapzi's anti-cheat approach is therefore layered. Potential signals include: * decision timing; * input patterns; * session behavior; * repeated opponent relationships; * account relationships; * abnormal gameplay patterns. Behavioral detection is probabilistic. A suspicious signal should not automatically be described as conclusive proof of misconduct. *** ### 11. Evidence & Dispute Resolution Where competitive decisions affect access or assets, enforcement should be tied to evidence. A mature dispute process may include: 1. anomaly detection; 2. match evidence collection; 3. temporary action where justified; 4. review; 5. participant appeal; 6. final resolution; 7. auditable outcome. Relevant evidence may include: * authenticated match state; * replay records; * timestamps; * transaction records; * integrity signals; * session logs. Tapzi should avoid irreversible automated penalties based solely on weak probabilistic indicators. *** ### 12. Treasury Security Treasury assets require controls separate from ordinary application operations. Tapzi's treasury framework should prioritize: * separation of duties; * multisignature authorization where implemented; * limited access; * transaction monitoring; * documented approval processes; * public verification where appropriate. No individual should be represented as unable to control treasury funds unless the actual technical configuration proves that statement. The specific treasury control structure should be disclosed through the Proof Center when implemented and verifiable. *** ### 13. Multisignature Controls Multisignature wallets can reduce the risk associated with a single compromised key. However, the existence of a multisig alone does not prove strong governance. Relevant questions include: * how many signers exist; * what threshold is required; * whether signers are independent; * how keys are protected; * what happens when a signer becomes unavailable; * whether emergency procedures exist. Tapzi should publish actual configurations rather than relying on generic claims of "multisig security." Whitepaper 3.0 does not claim a specific 3-of-5 model unless that structure is actually implemented. *** ### 14. Token Vesting & Treasury Controls Token vesting and treasury authorization serve different purposes. **Vesting** Controls when tokens become eligible for release. **Treasury Governance** Controls who can authorize the use of treasury-controlled assets. Whitepaper 3.0 does not change the existing token allocation or vesting schedules. The canonical: * [Token Allocation Breakdown](/tokenomics/token-allocation-breakdown.md) * [Vesting Schedule Overview](/tokenomics/vesting-schedule-overview.md) remain unchanged. Security improvements to treasury control do not alter those schedules. *** ### 15. Infrastructure Monitoring Tapzi should monitor critical infrastructure for abnormal behavior. Relevant monitoring may include: * application availability; * API failures; * authentication failures; * matchmaking errors; * settlement failures; * unusual transaction behavior; * contract events; * suspicious account activity; * infrastructure latency; * abnormal error rates. Monitoring supports both preventative security and incident investigation. *** ### 16. Incident Response Security incidents cannot always be prevented. A credible security program therefore requires a response process. Depending on the incident, the process may include: **Detection** Identify abnormal activity. **Containment** Limit further impact. **Investigation** Determine scope and cause. **Recovery** Restore affected systems safely. **Communication** Notify affected users or stakeholders where appropriate. **Remediation** Correct the underlying issue. **Post-Incident Review** Document lessons and improve controls. Material security incidents should not be silently removed from project history. *** ### 17. Responsible Disclosure Tapzi intends to maintain a process through which security researchers can responsibly report vulnerabilities. A mature responsible-disclosure framework should define: * reporting channel; * eligible systems; * expected researcher behavior; * response process; * confidentiality expectations; * potential bounty eligibility where offered. Any bug-bounty program should only be described as active when its scope and rules have actually been published. *** ### 18. Developer Security Tapzi Studio introduces additional security boundaries because third-party applications may interact with network infrastructure. Developer integrations should use controls such as: * scoped API credentials; * rate limits; * signed requests; * webhook verification; * permission separation; * environment separation; * audit logging. A third-party developer should not receive broader access than required for its integration. Compromise of one integration should be designed to minimize impact on the wider network. *** ### 19. Webhook & API Integrity Where Tapzi exposes APIs or webhooks, security may include: * authenticated requests; * signature verification; * replay protection; * timestamp validation; * rate limiting; * key rotation; * environment-specific credentials. Developer tooling should encourage secure integration by default. *** ### 20. GameBuilder Security Creator-generated content introduces different risks from professional developer integrations. Potential risks include: * malicious game logic; * misleading content; * exploitative mechanics; * abusive content; * manipulated economy settings; * unsafe external links. GameBuilder therefore requires a combination of: * technical sandboxing; * rules enforcement; * moderation; * publication controls; * review systems. GameBuilder should not be treated simply as an unrestricted prompt-to-code environment. *** ### 21. Tapzi Pay Security: Future Expansion Tapzi Pay introduces additional security requirements because merchant transactions differ from competitive match settlement. Potential controls may include: * merchant authentication; * address verification; * payment-intent integrity; * webhook verification; * transaction monitoring; * settlement confirmation; * reconciliation; * fraud controls. Tapzi Pay remains subject to actual implementation status. Security controls should be published when the product is sufficiently defined and operational. *** ### 22. Compliance Is Product-Specific Tapzi does not assume that one legal classification applies to every product surface. Different functionality may involve different requirements. Examples include: **Practice Gaming** Primarily a software-service environment. **Competitive Play** May involve jurisdiction-specific rules relating to contests or skill-based competition. **Digital Tokens** May be subject to differing digital-asset frameworks. **Developer Infrastructure** May introduce contractual, data, and platform obligations. **Merchant Payments** May introduce additional payment, financial-crime, and digital-asset requirements. Compliance analysis should therefore be based on the actual feature being offered. *** ### 23. Jurisdiction-Aware Availability A technically available feature does not automatically need to be offered globally. Tapzi may restrict functionality based on: * country; * region; * age; * identity status; * product type; * competition type; * transaction type; * risk assessment. This can include restrictions on: * value-based competitions; * specific token functionality; * merchant-payment functionality; * certain tournament formats. Tapzi should not describe a product as "globally legal" merely because it is accessible through the internet. *** ### 24. Tiered Identity Tapzi's identity model can scale with risk. | Participation Level | Potential Identity Controls | | --------------------------------- | ------------------------------------------------------------------- | | **Practice / Casual** | Basic account or low-friction authentication | | **Eligible Competitive Play** | Jurisdiction and eligibility checks | | **Higher-Value Competition** | Stronger identity assurance | | **Tournament / Higher-Risk Tier** | Age, location, fraud, and additional verification where applicable | | **Merchant Services** | Business/customer verification according to applicable requirements | This avoids applying maximum friction to every user while still allowing stronger controls where necessary. *** ### 25. Age Restrictions Some Tapzi functionality may require a minimum age based on: * jurisdiction; * competition format; * value involved; * payment functionality. Age requirements should be reflected consistently across: * product interfaces; * Terms of Service; * competition rules; * onboarding flows. Whitepaper 3.0 does not establish one universal global age threshold unless separately defined in Tapzi's legal documentation. *** ### 26. Geographic Restrictions Tapzi may use technical and procedural controls to limit certain functionality in restricted jurisdictions. Potential controls may include: * declared country; * IP/location signals; * identity verification; * wallet or payment restrictions; * service-specific rules. No location-control technology should be represented as impossible to bypass. The objective is reasonable enforcement of applicable platform restrictions. *** ### 27. KYC Tapzi has separately published information regarding third-party team KYC verification. Team KYC and user KYC are different concepts. **Team KYC** Provides independent identity verification of relevant project participants where completed. **User KYC** May be required for specific product functionality depending on jurisdiction, risk, or service type. The existence of team KYC does not automatically mean every user interaction requires identity verification. Likewise, completing KYC does not guarantee the success or integrity of a project. *** ### 28. AML & Sanctions Controls Certain future financial or payment functionality may require additional controls around: * sanctions; * suspicious transactions; * wallet risk; * financial-crime monitoring. These requirements are especially relevant to potential future Tapzi Pay functionality. Tapzi should not claim that specific AML or blockchain-intelligence integrations are active unless they are actually implemented. Where such services are required, details should be disclosed according to the product's production status. *** ### 29. Data Protection Security and compliance also include protection of personal and behavioral data. Potential Tapzi data may include: * account information; * wallet addresses; * game history; * ratings; * session information; * anti-cheat telemetry; * device or connection information; * tournament history. Future products such as: * Player Passport; * social login; * GameBuilder; * developer APIs; * Tapzi Pay; may introduce additional data requirements. Tapzi's Privacy Policy should be updated as actual production data practices evolve. Future functionality should not be described as current data collection before it is implemented. *** ### 30. Privacy & Competitive Integrity Anti-cheat systems can require behavioral information. This creates a need to balance: **Competitive Integrity** Enough information to identify abuse. with **Privacy** Avoid unnecessary collection and retention. Tapzi should apply principles such as: * data minimization; * access control; * defined retention; * purpose limitation; * secure storage. Only information reasonably necessary for legitimate operational, security, compliance, or analytics purposes should be collected. *** ### 31. Third-Party Risk Tapzi may depend on external systems such as: * blockchain networks; * wallet providers; * infrastructure providers; * security auditors; * identity providers; * future payment/on-ramp partners. Third-party failure can affect Tapzi even if Tapzi's own systems operate correctly. Tapzi therefore evaluates external dependencies as part of its risk framework. Use of a third-party provider should not be interpreted as an endorsement or guarantee by that provider unless a formal relationship exists. *** ### 32. Blockchain Risk Blockchain infrastructure introduces risks outside Tapzi's direct control. These may include: * network congestion; * validator issues; * chain reorganizations; * smart-contract interactions; * gas volatility; * bridge risk where applicable; * third-party wallet failures. Tapzi's architecture aims to reduce unnecessary blockchain dependence for real-time gameplay, but settlement still inherits risks from the underlying network. *** ### 33. Token Risk $TAPZI is a digital asset. Participation may involve risks including: * price volatility; * market liquidity changes; * exchange availability; * regulatory changes; * wallet loss; * smart-contract vulnerabilities. Tapzi does not guarantee: * token price; * token appreciation; * liquidity; * exchange listing; * trading volume. The token's existing fixed supply, allocation, and vesting architecture remain described in the canonical Tokenomics section. *** ### 34. Regulatory Risk Digital-asset and competition-related regulation continues to evolve. Requirements can differ substantially by jurisdiction. Tapzi therefore does not rely on statements such as: * "legal everywhere"; * "not gambling everywhere"; * "not a security in every jurisdiction"; * "fully compliant globally." Instead, Tapzi's approach is: > **Evaluate actual functionality against applicable requirements and restrict or modify availability where necessary.** Specialist legal advice should be obtained before activating functionality with material regulatory implications. *** ### 35. Future Products Require New Reviews Security and compliance approval for one Tapzi product does not automatically extend to every future product. For example: **Tapzi Studio** Requires developer-platform security. **GameBuilder** Requires creator moderation and sandboxing. **Tapzi Pay** Introduces payment and merchant requirements. **Dedicated Settlement Infrastructure** Would introduce bridge, sequencer, validator, and network-security considerations. **AI-Agent Infrastructure** May create new automated-transaction and identity risks. Each major expansion should undergo its own technical and compliance review. *** ### 36. Risk-Based Product Activation A new feature should not be activated simply because development is complete. Before production deployment, Tapzi should consider: **Technical Readiness** Does the feature work reliably? **Security Readiness** Has the relevant attack surface been evaluated? **Operational Readiness** Can Tapzi support and monitor it? **Legal Readiness** Can it be offered in the intended jurisdictions? **Evidence** Can Tapzi substantiate the claims being made publicly? This supports the broader Plan 3 principle: > **Expand when evidence justifies it.** *** ### 37. Proof Center Integration The Tapzi Proof Center should provide a central location for security and compliance evidence. Potential sections include: #### Smart Contracts Verified production addresses. #### Audits Completed independent security reports. #### KYC Applicable completed third-party verification. #### Product Status Live/Beta/Development/Designed/Research. #### Incident History Material disclosures where appropriate. #### Treasury Publicly verifiable control information where available. #### Token Canonical allocation and vesting. This allows users to evaluate evidence directly instead of relying only on security claims. *** ### 38. What Tapzi Does Not Claim For clarity, Tapzi does not claim that: * smart contracts are impossible to exploit; * audits eliminate security risk; * cheating can be completely eliminated; * user accounts cannot be compromised; * multisig eliminates treasury risk; * KYC guarantees project integrity; * blockchain settlement eliminates every dispute; * all Tapzi functionality is permitted in every jurisdiction; * future payment infrastructure is automatically compliant because it is non-custodial; * $TAPZI has a guaranteed value or return. The purpose of the security framework is to **identify, reduce, monitor, and respond to risk**. Not to pretend risk does not exist. *** ### 39. Security Principles Tapzi's security and compliance philosophy is built around eight principles. #### 1. Defense in Depth Do not rely on one security control. #### 2. Least Privilege Give systems and participants only the access they require. #### 3. Verification Provide evidence for security claims where practical. #### 4. Separation of Duties Separate operational, treasury, and administrative authority. #### 5. Continuous Monitoring Security continues after deployment. #### 6. Honest Limitations Do not describe probabilistic systems as guarantees. #### 7. Product-Specific Compliance Evaluate regulatory requirements according to actual functionality. #### 8. Security Before Scale Growth does not justify bypassing security or compliance requirements. *** ### 40. Security Is an Ongoing Process Tapzi's architecture will evolve. So will its threat model. As the ecosystem progresses from: **Skill Arena** ↓ **Tapzi Studio** ↓ **GameBuilder** ↓ **broader distribution** ↓ **Tapzi Pay** ↓ **future infrastructure** the security model must evolve with it. The core principle remains: > **Build securely. Verify independently where appropriate. Monitor continuously. Communicate limitations honestly.**