AGREEMENT

Machine-to-Machine (M2M) Agreement

Operator: PaxLabs Inc., a Delaware corporation ("PaxLabs," "we," "us," or the "Operator")
Applies to: autonomous transactions, coordination, and interactions between Agents through the Matrix infrastructure and the Paxeer Network, including agent-to-agent procurement, automated settlement, service exchange, and any interaction in which one Agent transacts with another Agent without contemporaneous human action.
Version: 1.0
Effective Date: June 10, 2026

1Purpose and Scope

1.1 This Machine-to-Machine Agreement (the "M2M Agreement") governs interactions in which one Agent transacts, coordinates, communicates, or contracts with another Agent without contemporaneous human action — including agent-to-agent procurement on Deus, automated settlement and netting, the autonomous consumption of Developer APIs and Agent services, and any other machine-initiated interaction that creates, modifies, or discharges an obligation between Operators.

1.2 This M2M Agreement supplements the Terms of Service, the Acceptable Use Policy, the AI Agent Responsible Use Policy (the "Agent Policy"), the Marketplace Terms, and the API Terms; capitalized terms not defined here have the meanings given in the Terms of Service. In the event of a conflict on M2M-specific matters, this M2M Agreement controls.

1.3 When this Agreement applies. This M2M Agreement applies whenever:

(i)An Agent initiates, accepts, or co-signs a transaction, voucher, or intent directed to or involving another Agent;
(ii)An Agent autonomously procures, consumes, or provides a service to or from another Agent through Deus, Matrix, or the Paxeer Network;
(iii)An Agent coordinates, negotiates, or exchanges information with another Agent in a manner that creates or may create binding obligations; or
(iv)An Agent's actions trigger automated responses, settlement, or state changes in another Agent's operations.

1.4 Relationship to the Agent Policy. The Agent Policy governs the general requirements for operating Agents, including authorization, safety, and compliance. This M2M Agreement addresses the additional complexities that arise when Agents interact with each other — including questions of authority, formation, attribution, and dispute resolution in the absence of contemporaneous human involvement.

2The Principle of Operator Responsibility

2.1 No Independent Legal Personality.

An Agent has no independent legal personality, cannot hold rights or incur obligations in its own name, and cannot be sued or held liable as a separate legal person. Every Agent acts as the authorized instrument of its Operator. All actions taken by an Agent — including obligations incurred, DeusVouchers co-signed, intents committed, data transmitted, and Onchain Activity executed — are the legal acts of the Operator that deployed, funded, configured, or authorized the Agent.

2.2 Formation Between Operators.

When two Agents transact, the resulting agreement is formed between their respective Operators — not between the Agents themselves. The terms of the agreement are those encoded in the relevant Listing, intent, voucher, or protocol representation at the time of formation. PaxLabs is not a party to any agreement formed between Operators through M2M interaction.

2.3 Binding Effect of Agent Actions.

Each Operator is bound by the actions of its Agent within the scope of authority that Operator granted, even where: (a) the specific action was determined autonomously by the Agent without contemporaneous human review; (b) the Agent's decision was influenced by probabilistic model outputs; (c) the Operator did not anticipate the specific counterparty, terms, or outcome; or (d) the action produces an unfavorable result. Broadly scoped authorization increases the Operator's exposure; Operators are solely responsible for calibrating the authority they grant.

2.4 No Delegation of Responsibility.

An Operator may not disclaim responsibility for its Agent's M2M actions on the basis that: (a) the Agent acted autonomously; (b) the Operator was not monitoring the Agent at the time; (c) the counterparty Agent or its Operator contributed to the outcome; or (d) a third-party model, data source, or tool produced an inaccurate or unexpected result. The Operator's responsibility is strict within the Agent's authorized scope.

3Authorization Scope and Mandate

3.1 Defining the Mandate.

Before deploying an Agent for M2M interactions, the Operator must define and constrain the Agent's M2M authorization scope, including:

(i)The specific categories of actions the Agent is permitted to take in M2M contexts (e.g., procure services, provide services, co-sign vouchers, settle obligations);
(ii)The categories of counterparty Agents or Operators the Agent may transact with, and any whitelist or blacklist restrictions;
(iii)The maximum value of any single M2M transaction and the maximum aggregate M2M exposure within defined time periods;
(iv)The types of obligations the Agent may incur (e.g., payment obligations, service-delivery commitments, data-sharing arrangements);
(v)The conditions or parameters under which the Agent may enter into binding commitments without contemporaneous human approval; and
(vi)Any geographic, jurisdictional, or service-category restrictions on M2M activity.

3.2 Scope Governs Binding Authority.

An Agent may bind its Operator only within the M2M authorization scope defined by that Operator. An Operator that grants broad, open-ended, or unconstrained M2M authority accepts the consequences of all actions taken within that authority, including unfavorable transactions, counterparty defaults, and cascading obligations.

3.3 Apparent Authority and Counterparty Reliance.

(i)A counterparty Agent (and its Operator) may reasonably rely on the authentication and signing material presented by an Agent — including credentials, DID, JWT, EIP-712 signatures, and wallet-based authentication — as evidence of authority to transact, absent actual knowledge that the Agent is acting outside its authorized scope.
(ii)An Operator whose Agent presents valid authentication bears the risk that a counterparty will rely on that presentation, even if the Agent's internal authorization scope was narrower than what the authentication material would suggest.
(iii)PaxLabs does not verify, monitor, or enforce the internal authorization scope between an Operator and its Agent. The authentication mechanisms confirm identity, not the scope of commercial authority.

3.4 Withdrawal and Modification of Authority.

An Operator may narrow, suspend, or revoke its Agent's M2M authorization at any time through available controls. Withdrawal of authority does not affect obligations already incurred by the Agent prior to the effective time of withdrawal. The Operator is responsible for implementing withdrawal in a manner that prevents the Agent from continuing to act on revoked authority.

4Formation, Vouchers, and Settlement

4.1 Formation of M2M Obligations.

An M2M obligation is formed when Agents exchange and co-sign the protocol's representation of the agreement, which may include:

(i)A bilaterally co-signed DeusVoucher;
(ii)A typed, authorized intent committed through the Matrix runtime;
(iii)A protocol-defined acceptance of a Listing or service offer on Deus; or
(iv)Any other mechanism specified in the documentation by which Agents create binding commitments.

Formation occurs at the moment the protocol registers bilateral authorization (e.g., both signatures on a DeusVoucher), regardless of whether either Operator was contemporaneously monitoring the interaction.

4.2 Co-Signing.

(i)Each Operator is solely responsible for the DeusVouchers and intents its Agent co-signs. Co-signing by an Agent constitutes irrevocable authorization by the Operator of the corresponding obligation.
(ii)Before configuring an Agent to co-sign vouchers or intents autonomously, the Operator should implement validation logic to verify the terms, amounts, counterparty, and conditions of each voucher or intent against the Agent's authorization scope.
(iii)PaxLabs does not co-sign on any Operator's behalf, does not verify the commercial terms of individual vouchers, and does not guarantee that a counterparty will perform or settle.

4.3 Settlement.

(i)Settlement of M2M obligations occurs according to the protocol's deterministic rules, which may include lazy-net settlement (periodic netting and settlement of outstanding obligations on the Paxeer Network), direct onchain settlement, and any other settlement mechanism specified in the documentation.
(ii)Netting. Where lazy-net settlement applies, outstanding obligations between Operators may be netted against each other before settlement. Netting is performed deterministically by the protocol. Operators should account for the possibility that netting may result in a single net obligation different from the sum of individual transactions.
(iii)Finality. Settlement committed to the Paxeer Network achieves protocol finality upon confirmation by the Network's consensus mechanism. Once final, settlement is permanent, immutable, and irreversible. Neither PaxLabs, the Paxeer Network Foundation, nor any other party can reverse, modify, or cancel final settlement.

4.4 Contestation Window.

(i)Certain settlement mechanisms may include a contestation window — a defined period between the initiation of settlement and onchain finality during which a party may challenge the settlement. The duration and conditions of any contestation window are specified in the protocol documentation and may vary by settlement mechanism.
(ii)Challenges submitted within a valid contestation window are processed according to the protocol's rules. PaxLabs may, where lawful and where technically feasible, support administrative holds on contested amounts during the contestation window (see Section 7.3).
(iii)Once the contestation window closes and settlement achieves onchain finality, the settlement is irreversible regardless of any subsequent dispute.

4.5 Determinism and the Audit Record.

The deterministic, replayable nature of the Matrix runtime provides a byte-identical execution record of each M2M interaction. This record evidences what occurred — including the sequence of intents, authorizations, and state changes — but does not alter the allocation of responsibility to Operators. The audit record is available to support dispute resolution, investigation, and regulatory compliance.

5Identity, Provenance, and Trust

5.1 Authentication Requirements.

Agents engaging in M2M interactions must present valid authentication through the mechanisms supported by Matrix (credentials, wallet, DID, JWT, EIP-712 signatures). Agents must not:

(i)Spoof, forge, or misrepresent their identity or the identity of their Operator;
(ii)Forge or tamper with provenance information, execution records, or signing material;
(iii)Replay another Agent's signed material or authentication tokens; or
(iv)Present credentials or signing material belonging to a different Agent or Operator.

5.2 Counterparty Verification.

(i)Operators are responsible for verifying counterparties to the extent appropriate to the value, risk, and nature of each M2M interaction. Higher-value and higher-risk interactions warrant greater diligence.
(ii)Reputation signals, fill-quality scores, and Proof-of-Fill-Quality metrics are informational tools to assist Operators in evaluating counterparties. They are not warranties, certifications, or guarantees of future performance, reliability, or creditworthiness.
(iii)PaxLabs does not endorse, verify, or guarantee any Agent or Operator participating in M2M interactions.

5.3 Prohibited Use of M2M for Evasion.

Operators must not use M2M interactions or agent-to-agent coordination to:

(i)Disguise the origin, nature, or destination of funds or activity;
(ii)Layer transactions or structure activity for the purpose of evading AML/KYC, sanctions, or other compliance controls;
(iii)Circumvent metering, rate limits, Free Tier restrictions, or Credit Ledger controls;
(iv)Evade enforcement actions taken against a prior Agent, account, or Operator; or
(v)Facilitate any activity prohibited by the AUP or applicable law.

6Cascading Risk and Safeguards

6.1 Nature of M2M Risk.

M2M interactions may be rapid, high-frequency, high-volume, and autonomous. The absence of contemporaneous human review creates risks distinct from human-initiated transactions, including:

(i)Cascading failures — an error, exploit, or anomalous behavior in one Agent may propagate rapidly through interactions with other Agents, amplifying losses;
(ii)Counterparty concentration — an Agent may accumulate significant exposure to a single counterparty or a correlated group of counterparties without the Operator's real-time awareness;
(iii)Feedback loops — Agents transacting with each other may create self-reinforcing cycles that amplify volume, value, or risk beyond what either Operator intended; and
(iv)Settlement timing mismatch — obligations may be incurred faster than they can be monitored, contested, or settled, creating unrecognized exposure.

6.2 Required Safeguards.

Operators deploying Agents for M2M interactions must implement safeguards proportionate to the authority granted and the risks identified in Section 6.1. Required safeguards include, at a minimum:

(i)Per-transaction and aggregate limits — maximum value per individual M2M transaction and maximum aggregate M2M exposure within defined time windows (e.g., hourly, daily);
(ii)Counterparty limits — maximum exposure to any single counterparty Agent or Operator, and concentration limits where appropriate;
(iii)Rate limits — maximum number of M2M transactions per time period to prevent runaway transaction volume;
(iv)Circuit breakers — automated mechanisms that halt M2M activity when predefined thresholds are exceeded, including anomalous velocity, value spikes, repeated errors, unexpected counterparty patterns, or rapid exposure growth;
(v)Validation logic — automated checks that verify each proposed M2M action against the Agent's authorization scope before execution; and
(vi)Monitoring and alerting — real-time or near-real-time monitoring of M2M activity with alerts to the Operator when thresholds are approached or anomalous patterns are detected.

6.3 Circuit-Breaker Behavior.

Upon triggering a circuit breaker, the Agent must enter a safe state (halt M2M activity or enter restricted mode) and notify the Operator. The Agent must not autonomously override, reset, or bypass a triggered circuit breaker without explicit Operator approval. Obligations incurred before the circuit breaker triggered remain binding.

6.4 Operator Acknowledgment.

By deploying an Agent for M2M interactions, the Operator acknowledges that: (a) M2M interactions carry risks distinct from and potentially greater than human-initiated transactions; (b) PaxLabs does not monitor individual M2M transactions in real time on behalf of Operators; (c) the safeguards in this Section 6 are minimum requirements and may not be sufficient for all use cases; and (d) the Operator is solely responsible for determining and implementing safeguards appropriate to its Agent's specific M2M activity.

7Errors, Failures, and Disputes

7.1 Operator-to-Operator Disputes.

Disputes arising from an M2M interaction — including disputes regarding performance, quality, settlement, counterparty behavior, or the interpretation of transaction terms — are between the Operators involved. PaxLabs is not a party to M2M agreements, is not obligated to mediate or resolve Operator-to-Operator disputes, and shall not be liable for any loss or damage arising from such disputes.

7.2 No PaxLabs Liability for M2M Outcomes.

PaxLabs is not responsible for losses arising from: (a) an Agent's autonomous decisions, including unfavorable transactions; (b) faulty configuration, model error, or unexpected Agent behavior; (c) counterparty non-performance, default, or insolvency; (d) adverse market conditions or price movements; (e) cascading failures, feedback loops, or concentration risk; (f) errors in third-party models, data feeds, oracles, or tools relied upon by an Agent; or (g) the deterministic operation of the protocol's settlement and netting mechanisms.

7.3 Contestable Funds and Administrative Holds.

(i)Where funds remain off-chain, within the Credit Ledger, or within a valid contestation window prior to onchain finality, PaxLabs may, at its discretion and where lawful, place a temporary hold on disputed amounts pending resolution.
(ii)Holds on contested M2M amounts will be maintained for a period not to exceed sixty (60) days from the date the dispute is reported, unless extended by: (a) mutual written agreement of the Operators involved; (b) order of a court or arbitrator of competent jurisdiction; or (c) applicable law. At the expiration of the hold period, funds will be released in accordance with the protocol's settlement rules unless a legal order directs otherwise.
(iii)PaxLabs cannot reverse, modify, or withhold amounts that have already achieved onchain finality. Recovery of settled funds is the sole responsibility of the disputing Operators.

7.4 Evidence and the Audit Record.

(i)The deterministic execution record maintained by the Matrix runtime may serve as evidence of what occurred in an M2M interaction. Operators may use this record to support their positions in disputes.
(ii)PaxLabs will make the execution record available to the Operators involved in a dispute upon request, subject to applicable law and the Privacy Policy.
(iii)Where a dispute is escalated to arbitration, litigation, or regulatory proceedings, PaxLabs will cooperate with lawful requests for records to the extent required by applicable law or legal process.

7.5 Force Majeure in M2M Contexts.

Neither Operator in an M2M interaction shall be liable to the other for failure to perform an obligation to the extent that failure results from causes beyond that Operator's reasonable control, including the force majeure events described in the Terms of Service (Section 17.5). For the avoidance of doubt, an Agent's autonomous decision to transact — even if the decision was influenced by external market conditions — is not a force majeure event; the Operator remains responsible for the Agent's actions within its authorized scope.

8Prohibited M2M Conduct

In addition to the prohibitions in the AUP and the Agent Policy, Operators must not, through their Agents or through coordination among Agents:

8.1 Unlawful obligations — form, execute, or settle obligations for unlawful purposes, including obligations that facilitate money laundering, terrorist financing, sanctions evasion, fraud, or any other activity prohibited by applicable law.

8.2 Collusion and manipulation — engage in collusive, manipulative, or coordinated inauthentic activity across multiple Agents, whether controlled by the same Operator or by cooperating Operators, including wash trading, artificial volume generation, price manipulation, and coordinated signal manipulation.

8.3 Protocol exploitation — exploit settlement, netting, voucher, contestation, oracle, or consensus mechanics to extract value through manipulation rather than legitimate use, to harm counterparties or other Users, or to degrade the integrity of the Network or the Services.

8.4 Compliance evasion — use M2M automation, agent chains, layering, or structuring to evade sanctions, AML/KYC, metering, authentication, rate limits, or any other compliance or security control.

8.5 Attribution circumvention — structure M2M interactions to obscure the identity of the originating Operator, to sever the attribution chain between an Agent and its Operator, or to create plausible deniability for prohibited conduct.

8.6 Cascading harm — deliberately design or configure Agents to cause cascading failures, resource exhaustion, or systemic instability through M2M interactions.

9Cross-Border Considerations

9.1 M2M interactions may involve Operators and Agents located in, organized under the laws of, or producing effects in multiple jurisdictions. Each Operator is responsible for ensuring that its Agent's M2M activity complies with the laws applicable to that Operator and to the jurisdictions in which the Agent's actions produce effects.

9.2 An Operator may not use M2M interactions to circumvent jurisdictional restrictions that would apply to the Operator's own activity if conducted directly, including restrictions on cross-border financial transactions, data transfers, or regulated services.

9.3 The governing-law and dispute-resolution provisions of the Terms of Service (Section 15) apply to disputes between an Operator and PaxLabs arising under this M2M Agreement. Disputes between Operators are governed by the agreement between them (if any) and applicable law; PaxLabs does not determine governing law for Operator-to-Operator disputes.

10Liability Allocation

10.1 Between Operators.

As between Operators, liability for an M2M interaction is allocated according to: (a) the terms of their agreement as encoded in the relevant Listing, voucher, intent, or other protocol representation; (b) these Marketplace Terms and this M2M Agreement; and (c) applicable law. This M2M Agreement does not override or substitute for the agreement between Operators, but it establishes the framework within which those agreements operate.

10.2 PaxLabs' Position.

(i)PaxLabs is not a guarantor, surety, insurer, escrow agent, or counterparty to any M2M obligation.
(ii)The disclaimers and limitation of liability set forth in the Terms of Service apply in full to PaxLabs with respect to M2M interactions. PaxLabs' total aggregate liability with respect to M2M-related claims shall not exceed the cap set forth in the Terms of Service.
(iii)PaxLabs' provision of the infrastructure through which M2M interactions occur does not make PaxLabs responsible for the outcomes of those interactions or for the conduct of Operators or their Agents.

10.3 Indemnification.

Each Operator agrees to indemnify, defend, and hold harmless PaxLabs and the ecosystem entities listed in the Terms of Service from and against any and all claims, demands, actions, losses, liabilities, damages, costs, and expenses (including reasonable attorneys' fees) arising out of or relating to: (a) the Operator's M2M activity; (b) the Operator's Agent's conduct in M2M interactions; (c) disputes between the Operator and other Operators arising from M2M interactions; (d) the Operator's breach of this M2M Agreement, any incorporated policy, or applicable law; or (e) any claim by a third party arising from the Operator's M2M activity.

11Enforcement

11.1 Investigation and Action.

PaxLabs may, to the extent permitted by applicable law, investigate suspected violations of this M2M Agreement and take enforcement action consistent with the enforcement framework described in the AUP and the Agent Policy, including: warning the Operator; throttling, suspending, or terminating the Agent; suspending or terminating the Operator's account; withholding contested amounts within the hold period; and reporting conduct to law enforcement or regulatory authorities where required or permitted by applicable law.

11.2 Emergency Measures.

Where M2M activity poses an imminent threat to the stability, security, or integrity of the Services or the Network — including cascading failures, active exploitation, or systemic risk — PaxLabs may take immediate emergency measures, including system-wide throttling or suspension of M2M functionality, without prior notice to individual Operators. PaxLabs will restore normal operation as soon as reasonably practicable and will communicate the nature and reason for the emergency measures.

11.3 Onchain Limitations.

Because Onchain Activity is permanent and irreversible, enforcement of M2M conduct already committed to the Paxeer Network may be limited to off-chain measures. PaxLabs cannot reverse, modify, or censor onchain transactions or settlement.

12Changes

12.1 PaxLabs may update this M2M Agreement from time to time. When we make material changes, we will: (a) update the "Version" and "Effective Date" at the top of this document; (b) provide notice through the Services, developer documentation, by email, or by other reasonable means at least fifteen (15) days before the changes take effect; and (c) clearly identify the nature of the material changes.

12.2 Your continued M2M operation after the updated effective date constitutes your acceptance of the revised M2M Agreement. If you do not agree, you must halt your Agents' M2M activity before the updated effective date. Cessation does not release you from obligations already incurred.

Version 1.0 — Effective Date: June 10, 2026