Regulatory Infrastructure Overview

1Purpose

1.1 This Regulatory Infrastructure Overview (the "Overview") describes the regulatory architecture of the Paxeer ecosystem — how regulatory obligations are identified, allocated, implemented, and maintained across the ecosystem's entities, services, and technology layers. It is intended for regulators, institutional counterparties, auditors, and sophisticated stakeholders who need to understand the compliance infrastructure underlying the Services.

1.2 This Overview is a reference document, not an operative policy. The binding obligations are contained in the operative policies listed in Section 11. Where this Overview describes a control or obligation, the referenced operative policy governs.

1.3 This Overview supplements the Compliance Statement, which summarizes PaxLabs' compliance posture. This Overview goes deeper — it explains the structural and operational mechanics of how compliance is achieved.

2Ecosystem Architecture

2.1 Three-Layer Model.

The Paxeer ecosystem operates across three architectural layers, each with distinct regulatory characteristics:

• (i)Protocol layer — The Paxeer Network, a decentralized Layer 1 blockchain (EVM Chain ID 125, native token PAX). This layer is permissionless, decentralized, and operates through deterministic consensus. It is stewarded by the Paxeer Network Foundation but is not operated or controlled by PaxLabs. Onchain Activity on this layer is public, immutable, and irreversible.
• (ii)Infrastructure layer — The operated services built on top of the protocol, including: the Matrix agentic infrastructure (constrained runtime, intent layer, Agent orchestration, Developer API hosting, inference routing); the settlement and transaction-processing infrastructure operated by ChainFlow Inc.; and the security, auditing, and incident-response infrastructure operated by OpenNet Security LLC.
• (iii)Application layer — User-facing services, including: the Deus marketplace; account onboarding and identity verification; the Credit Ledger and metered billing; developer tooling, APIs, and SDKs; websites and interfaces; and third-party applications, Agents, and Developer APIs built by Developers and Operators on the infrastructure layer.

2.2 Regulatory Significance of the Three-Layer Model.

The three-layer model is not merely an engineering architecture — it determines the scope and allocation of regulatory obligations:

• (i)Protocol layer — Operates autonomously through consensus. PaxLabs does not control this layer and cannot unilaterally modify, censor, or reverse its operation. Regulatory obligations that require the ability to edit, delete, or reverse records (e.g., data erasure, transaction reversal) cannot be fulfilled at this layer by PaxLabs or any single entity. PaxLabs is transparent about this limitation throughout its policies.
• (ii)Infrastructure layer — Operated by identified legal entities (PaxLabs, ChainFlow, OpenNet Security) under contractual and regulatory frameworks. Regulatory obligations applicable to the operated infrastructure — including AML/KYC, transaction monitoring, data protection, AI governance, and security — are fulfilled at this layer.
• (iii)Application layer — User-facing services operated by PaxLabs are subject to PaxLabs' full compliance program. Third-party applications, Agents, and Developer APIs built by Developers and Operators carry independent regulatory obligations borne by those Developers and Operators.

3Entity Map and Regulatory Allocation

3.1 Entity Structure.

The ecosystem comprises six legal entities, each with a defined operational role and a corresponding regulatory profile:

3.2 PaxLabs Inc.

• (i)Form: Delaware corporation.
• (ii)Role: Operator of the Deus marketplace, Matrix agentic infrastructure (application-layer components), account onboarding, Credit Ledger, developer tooling, websites, and interfaces. Primary contracting party with Users under the Terms of Service.
• (iii)Regulatory responsibilities:

• Overall AML/CFT program ownership and coordination (AML/KYC Policy);
• Data controller for off-chain personal data under GDPR; business under CCPA/CPRA (Privacy Policy);
• Provider and/or deployer of AI systems under the EU AI Act, where applicable (EU AI Act Compliance page);
• Consumer-protection and electronic-commerce compliance;
• Policy development, enforcement, and User-facing compliance;
• Regulatory engagement, reporting (SARs/STRs, OFAC blocking reports), and cooperation with authorities;
• Coordination of inter-entity compliance allocation.

• (iv)Registration and licensing status: [Counsel to confirm and insert — including FinCEN MSB registration, applicable state money-transmitter licenses, MiCA CASP authorization status, and any other registrations or licenses held or pending.]

3.3 ChainFlow Inc.

• (i)Form: Delaware corporation.
• (ii)Role: Payments, settlement, and transaction-processing infrastructure supporting the Deus marketplace and other operated services.
• (iii)Regulatory responsibilities:

• Transaction-level sanctions screening within settlement infrastructure;
• Transaction monitoring and alert generation;
• Travel Rule compliance for qualifying transfers (originator/beneficiary information collection, transmission, and retention);
• Settlement-related regulatory obligations;
• Currency transaction reporting, where applicable;
• Supporting PaxLabs' AML/CFT program under written inter-entity allocation agreement.

• (iv)Registration and licensing status: [Counsel to confirm and insert — including FinCEN MSB registration, applicable state money-transmitter licenses, and any other registrations or licenses held or pending.]

3.4 OpenNet Security LLC

• (i)Form: Delaware limited liability company.
• (ii)Role: Security engineering, auditing, incident response, and AI robustness assessment.
• (iii)Regulatory responsibilities:

• Supporting security assessments, penetration testing, and vulnerability management;
• Incident detection and response across the ecosystem;
• Supporting independent testing of AML/CFT controls;
• AI robustness and adversarial-testing assessment;
• Security-related aspects of regulatory examinations and audits.

• (iv)Registration and licensing status: Not applicable (security services provider; not a regulated financial institution or VASP). [Counsel to confirm.]

3.5 Paxeer Network Foundation

• (i)Form: Foundation.
• (ii)Role: Steward of the decentralized Paxeer Network protocol, governance framework, and public goods.
• (iii)Regulatory profile: The Foundation stewards the protocol but does not operate User-facing services, does not process transactions on behalf of Users, and does not custody User assets. The Foundation's regulatory obligations, if any, relate to its governance and stewardship functions and are determined separately from PaxLabs' compliance program.
• (iv)Relationship to PaxLabs: The Foundation and PaxLabs operate under a dual-governance model: the network core (protocol, consensus, validator set) is community-governed through PAXEER NETWORK UNITED DAO; the advanced infrastructure tier (agentic infrastructure, trading infrastructure, consumer applications) is controlled by PaxLabs and its subsidiaries.

3.6 OpenChain Labs Inc.

• (i)Form: Delaware corporation.
• (ii)Role: Core protocol and infrastructure research and development.
• (iii)Regulatory profile: R&D entity. Does not operate User-facing services. Supports compliance through secure-by-design engineering practices. Regulatory obligations, if any, are limited to those applicable to a technology-development company (e.g., export controls for cryptographic technology, IP licensing). [Counsel to confirm.]

3.7 Sidiora Markets LTD

• (i)Form: Limited company.
• (ii)Role: Markets, launchpad, and trading-related products and services.
• (iii)Regulatory profile: Subject to the regulatory frameworks applicable to its specific activities, which may include: MiCA CASP authorization for crypto-asset services; AML/CFT obligations for regulated financial activities; consumer-protection requirements for retail-facing trading products; and market-conduct rules applicable to trading platforms. Sidiora maintains its own compliance function for services it operates.
• (iv)Registration and licensing status: [Counsel to confirm and insert.]

4Dual-Governance Model

4.1 Structure.

The Paxeer ecosystem operates under a dual-governance model that separates the governance of the decentralized protocol from the governance of the operated infrastructure:

• (i)Network core — The Paxeer Network protocol (consensus, validator set, block production, core protocol parameters) is community-governed through the PAXEER NETWORK UNITED DAO. Governance decisions at this layer are made through the DAO's governance mechanisms and are not unilaterally controlled by PaxLabs.
• (ii)Advanced infrastructure tier — The operated services (Matrix agentic infrastructure, Deus marketplace, trading infrastructure, consumer applications, settlement infrastructure) are controlled by PaxLabs Inc. and its subsidiaries. Governance decisions at this layer are made by PaxLabs' management and board.

4.2 Regulatory Implications.

• (i)PaxLabs' compliance obligations attach to the advanced infrastructure tier — the services PaxLabs controls and operates. PaxLabs can implement, enforce, and demonstrate compliance within this tier.
• (ii)The network core's decentralized governance means that PaxLabs cannot unilaterally impose compliance controls at the protocol level (e.g., transaction censorship, address blacklisting at the consensus layer, modification of confirmed blocks). Compliance controls are implemented at the infrastructure and application layers, where PaxLabs has operational authority.
• (iii)This dual-governance model is disclosed to regulators and reflected in PaxLabs' policies to prevent any misunderstanding about the scope of PaxLabs' control and the corresponding scope of its compliance commitments.

5Regulatory Framework Implementation

5.1 Anti-Money Laundering and Counter-Terrorist Financing

Operative policy: AML/KYC Policy.

5.2 Data Protection and Privacy

Operative policies: Privacy Policy; On-Chain Data Privacy Notice.

5.3 Artificial Intelligence

Operative policies: EU AI Act Compliance page; AI Agent Responsible Use Policy.

5.4 Crypto-Asset Regulation

Operative policies: Terms of Service; AML/KYC Policy; Risk Disclosures and Asset Disclosure [pending].

5.5 Consumer Protection and Electronic Commerce

Operative policies: Terms of Service; Marketplace Terms and Conditions.

6Technology-Enabled Compliance Controls

6.1 The following technology features of the Paxeer ecosystem support regulatory compliance. These are engineering capabilities that enable compliance; they do not automatically ensure it. Compliance requires the combination of technology controls, policies, operational procedures, and human judgment.

6.2 Matrix Constrained Runtime

• (i)What it does: Limits Agent execution to a closed verb vocabulary and typed intent representation. Agents cannot take actions outside the defined set of authorized operations.
• (ii)Regulatory relevance: Supports AI Act requirements for bounded, predictable AI system behavior; supports human-oversight requirements by ensuring Agents operate within defined constraints; reduces the surface area for unauthorized or uncontrolled Agent actions.

6.3 Deterministic Replay and Execution Records

• (i)What it does: Produces byte-identical, replayable execution records for each canonical intent processed through Matrix.
• (ii)Regulatory relevance: Provides a verifiable audit trail for AI Act logging and traceability requirements; supports AML/CFT transaction-monitoring and investigation capabilities; enables regulatory inspectors to reproduce and verify Agent behavior; supports dispute resolution with objective evidence of what occurred.

6.4 Multi-Modal Authentication and Attribution

• (i)What it does: Authenticates Users and Agents through credentials, wallet addresses, decentralized identifiers (DIDs), JWT tokens, and EIP-712 signatures. Ensures every action is attributable to an identifiable party.
• (ii)Regulatory relevance: Supports AML/KYC customer identification and verification; enables sanctions screening and transaction monitoring at the User and Agent level; ensures AI Act accountability requirements (every Agent attributable to an Operator); supports law-enforcement cooperation with identifiable actors.

6.5 Credit Ledger and Metering

• (i)What it does: Off-chain accounting system that meters, records, and bills usage of the Services, including LLM inference, compute, and API calls.
• (ii)Regulatory relevance: Provides a detailed record of Service usage for audit and investigation; supports transaction-monitoring capabilities for metered activity; enables enforcement of rate limits and Free Tier restrictions that prevent abuse.

6.6 Settlement Infrastructure (ChainFlow)

• (i)What it does: Processes and settles transactions, including DeusVoucher co-signing, lazy-net settlement, and direct onchain settlement.
• (ii)Regulatory relevance: Enables transaction-level sanctions screening before settlement finality; supports Travel Rule information exchange for qualifying transfers; provides transaction-monitoring data for AML/CFT analysis; implements contestation windows that allow administrative holds on disputed amounts before onchain finality.

6.7 Blockchain Analytics Integration

• (i)What it does: Wallet- and address-level analytics using third-party providers to assess exposure to illicit sources, sanctioned addresses, darknet markets, mixers, and high-risk indicators.
• (ii)Regulatory relevance: Supports ongoing sanctions screening and transaction monitoring; identifies high-risk wallet connections and transaction patterns; supplements internal monitoring with external intelligence.

7Compliance Program Governance

7.1 Program Ownership.

PaxLabs' compliance program is owned and overseen by PaxLabs' designated compliance function, headed by the AML/Compliance Officer. The compliance function operates with appropriate independence from business functions and has direct access to senior management and, where applicable, the board.

7.2 Compliance Roles.

[Counsel to confirm whether a formally appointed Data Protection Officer is required under GDPR Article 37 and whether a separate AI governance role is required.]

7.3 Reporting Lines.

The Compliance Officer reports to senior management and, where applicable, the board. Compliance escalations, SAR/STR filings, sanctions matches, and significant incidents are reported to senior management promptly. The compliance function provides periodic (at least quarterly) reports to senior management on program status, regulatory developments, and material findings.

7.4 Independent Testing and Audit.

• (i)The AML/CFT program is subject to independent testing on a risk basis, conducted by qualified internal audit personnel or an independent third party.
• (ii)Security controls are subject to periodic assessment by OpenNet Security LLC, including penetration testing, vulnerability assessment, and incident-response readiness review.
• (iii)Data-protection compliance is subject to periodic review, including assessment of processing activities, data-flow mapping, and DPIA adequacy.
• (iv)AI governance controls are subject to periodic assessment as the EU AI Act's obligations come into effect and as standards develop.
• (v)Findings and recommendations from all testing and audit activities are documented, tracked to remediation, and reported to the Compliance Officer and senior management.

8Incident Response and Regulatory Reporting

8.1 Incident Categories.

The ecosystem's incident-response framework covers the following categories, each with defined escalation procedures, response timelines, and reporting obligations:

• (i)Security incidents — unauthorized access, data breaches, exploitation of vulnerabilities, denial-of-service attacks, compromise of credentials or keys. Led by OpenNet Security LLC in coordination with PaxLabs.
• (ii)AML/CFT incidents — sanctions matches, suspicious-activity alerts, potential money-laundering typologies, Travel Rule failures, structuring indicators. Led by the Compliance Officer.
• (iii)AI incidents — Agent behavior outside authorized scope, safety failures, runaway agents, cascading M2M failures, serious incidents reportable under the EU AI Act. Led by the AI governance function in coordination with engineering.
• (iv)Data-protection incidents — personal-data breaches, unauthorized access to personal data, data-subject-rights failures. Led by the Data Protection Contact/DPO.
• (v)Marketplace incidents — fraudulent listings, provider misconduct, consumer harm, signal manipulation. Led by the marketplace-operations function in coordination with compliance.

8.2 Regulatory Reporting Obligations.

8.3 Internal Escalation.

All incidents are documented and escalated through defined internal procedures. The Compliance Officer, Data Protection Contact, and senior management are notified of material incidents. External legal counsel is engaged where the incident involves potential regulatory liability, litigation risk, or law-enforcement involvement.

9Cross-Border Regulatory Considerations

9.1 Multi-Jurisdictional Exposure.

The Services are offered globally (subject to prohibited-jurisdiction restrictions). This creates regulatory exposure across multiple jurisdictions, including:

• (i)United States — Federal (BSA, OFAC, FTC Act, federal securities law) and state (money-transmission licensing, state privacy laws, state consumer-protection statutes) obligations.
• (ii)European Union — GDPR, MiCA, EU AI Act, AML Directives, DSA, and national-level implementation measures.
• (iii)United Kingdom — UK GDPR, UK Money Laundering Regulations, FCA oversight (where applicable), and evolving AI governance framework.
• (iv)Other jurisdictions — Assessed on a case-by-case basis as the Services expand, with particular attention to jurisdictions with active crypto-asset, AI, or data-protection regulatory regimes.

9.2 Jurisdiction-Specific Compliance.

Where the regulatory requirements of a particular jurisdiction impose obligations beyond PaxLabs' baseline compliance program, PaxLabs implements jurisdiction-specific measures, which may include: geo-restricted features; jurisdiction-specific disclosures; additional identity-verification requirements; local representative appointments (e.g., EU/UK GDPR representative, EU AI Act authorized representative); and jurisdiction-specific terms or addendums.

9.3 Regulatory Arbitrage Prohibition.

PaxLabs does not structure its operations, entity allocation, or User-facing terms to evade regulatory obligations through jurisdictional arbitrage. The entity structure reflects genuine operational allocation, not regulatory avoidance.

10Limitations and Forward-Looking Matters

10.1 Evolving Regulatory Landscape.

The regulatory frameworks applicable to decentralized infrastructure, digital assets, AI agents, and machine-to-machine interactions are evolving rapidly. PaxLabs' compliance program is designed to adapt as law and guidance develop, but PaxLabs cannot guarantee that current controls will satisfy future regulatory requirements.

10.2 No Licensing Representations.

This Overview does not represent that any specific entity or service is licensed, registered, or authorized in any particular jurisdiction. Licensing and registration status is confirmed by counsel on a jurisdiction-by-jurisdiction basis and is disclosed, where applicable, in service-specific documentation.

10.3 Third-Party Limitations.

PaxLabs does not control and cannot guarantee the compliance of: (a) Developers and Operators who build on the ecosystem; (b) third-party GPAI model providers whose models are integrated through inference routing; (c) third-party identity-verification and blockchain-analytics providers; or (d) the decentralized Paxeer Network protocol. PaxLabs manages third-party risk through contractual terms, due diligence, and monitoring, but cannot eliminate it.

10.4 Technology Limitations.

No compliance program eliminates all risk. Technology controls support compliance but cannot substitute for human judgment, cannot prevent all forms of abuse, and cannot retroactively modify immutable onchain records. PaxLabs discloses these limitations transparently rather than overclaiming the effectiveness of its controls.

11Operative Policy Index

This Overview references and is supported by the following operative policies:

12Contact

Compliance inquiries: [compliance@paxlabs — or dedicated email to be inserted]

AML/Compliance Officer: [Name and contact — per AML/KYC Policy]

Data Protection: [Contact — per Privacy Policy]

EU AI Act: [Contact — per EU AI Act Compliance page]

Security and incidents: [Contact — per AUP]

General legal: [Contact — per Terms of Service]

---

Version 1.0 — Effective Date: June 10, 2026