ChainZap Payout Control Pilot Agreement

Version: v1.1 — Pre-Incorporation
Last updated: 7 October 2026
Effective date: [TO BE COMPLETED]

This Pilot Agreement is intended for a limited historical Payout Control evaluation. The contracting party, governing law and final liability amount must be completed before this Agreement is used for a paid pilot.

1. Parties

This Pilot Agreement (“Agreement”) is entered into between:

Service Provider: [CHAINZAP CONTRACTING PARTY — TO BE COMPLETED]
Registration/licence number: [TO BE COMPLETED]
Registered address: [TO BE COMPLETED]

and

Customer: [CUSTOMER LEGAL NAME]
Registration number: [TO BE COMPLETED]
Registered address: [TO BE COMPLETED]

Each a “Party” and together the “Parties”.

2. Purpose of the Pilot

The purpose of the Pilot is to evaluate whether ChainZap Payout Control can identify, organise and explain unresolved operational exceptions in a historical stablecoin payout workflow.

The Pilot is an evaluation engagement. It does not authorize ChainZap to move, release, custody, approve or control funds and does not require production API integration.

The Pilot is intended to answer a limited operational question:

Were the agreed payout obligations correctly executed and closed, and which items require further Customer action?

3. Pilot Scope

Unless otherwise agreed in writing, the Pilot covers one historical payout workflow and an agreed dataset of approximately 50–200 rows.

The initial standard Customer Pilot is limited to official USDT on TRON. Other assets, networks or workflows require a separately agreed scope and confirmed technical and provider coverage. The current batch workflow does not expose a dedicated integrity-only mode: it invokes the risk layer, and missing risk-provider evidence remains explicit insufficient/degraded coverage.

For an execution check, the minimum package is a stable external_reference, network, tx_hash, expected_recipient, expected_token and expected_amount. The network may instead be an agreed upload default. Expected values must come from the Customer’s historical instruction, not be inferred from the transaction being checked. A row without a transaction hash can record an obligation but cannot establish on-chain execution.

Sending-wallet information (expected_sender) is optional unless sender verification is agreed. Direct identifiers and execution credentials are not required. Provider exports are optional if the normalized package already contains the instruction and reference-to-transaction mapping. Instruction versions, attempt references and declared allocations are required where the agreed historical case depends on them; unknown history is not reconstructed as fact.

The Customer may provide a secure CSV or other agreed file containing fields such as:

• business or obligation reference;
• expected recipient;
• expected amount;
• asset/token;
• network;
• execution or attempt reference;
• transaction hash, where available;
• provider or wallet-export status, where available;
• other specifically agreed non-sensitive operational fields.

The final data specification will be agreed before transfer and will state whether the dataset relates to payouts to natural persons. If it does, or if it otherwise contains personal data, the Pilot Data Annex applies before transfer.

ChainZap may use software-assisted processing, scripts and analyst review to perform the Pilot.

No additional workflow, production integration, ongoing monitoring or recurring service is included unless expressly added in writing.

4. No Execution Credentials or Production Access

The standard Pilot does not require Customer wallet, exchange or payment-provider API credentials.

The Customer must not provide:

• private keys;
• seed phrases;
• transaction-signing credentials;
• credentials permitting initiation, approval or signing of transfers.

ChainZap will not sign, initiate, approve or execute transactions during the Pilot.

If a future integration is discussed, it will require a separate written scope and security review.

5. Pilot Processing Model

ChainZap may associate Customer-provided business obligations with available execution attempts, blockchain events, allocations and supporting evidence.

Where supported by the agreed data, ChainZap may identify operational states such as:

• CLOSED;
• PARTIAL;
• MISMATCH;
• REVIEW;
• INSUFFICIENT;
• other documented states agreed for the Pilot.

Missing, conflicting or unavailable evidence will not automatically be treated as successful execution.

Analyst review may assist with interpretation and prioritisation, but does not independently authorize any Customer action.

6. Deliverables

Unless otherwise agreed, ChainZap will provide:

1. an analysed result for each processable row or obligation;
2. the resulting operational state;
3. available reason codes, evidence or explanatory context;
4. identification of rows requiring Customer review;
5. a Pilot summary showing relevant exception categories and counts;
6. an export or report in an agreed format.

The standard portal provides preflight and estimate, processing progress, status distributions, review flags, open obligations and known residuals, per-row result/action codes, and a CSV export. DONE or COMPLETED describes processing, not proof that a payout obligation or Customer outcome is closed.

Current machine-readable obligation states include OPEN, PARTIALLY_ALLOCATED, ALLOCATED, OVER_ALLOCATED and UNKNOWN. Transaction, integrity, risk and coverage are separate result axes. ALLOCATED records attributed payment amount; it is not Customer confirmation of the final business outcome. Any use of CLOSED or PARTIAL in the Pilot Scorecard must define its mapping and required Customer validation.

The CSV includes reason codes and a decision identifier, but not a complete provider-evidence package or all original expected fields. The Customer should retain the input package. Detailed decision evidence is available through the authenticated API; a human-readable evidence report is included only where expressly agreed as a separate deliverable. The portal does not currently provide a complete evidence drill-down or reversal/correction interface.

The core supports multiple execution attempts, duplicate-execution findings, partial/multiple-transaction allocation and explicitly declared shared payments. Allocation reversals preserve the original record and instruction corrections require a new version through the supported API. A completed batch remains a decision-time snapshot rather than an automatically revised report after later ledger corrections.

Where a row cannot be processed reliably, ChainZap may return an insufficient-evidence or similar state rather than a definitive conclusion.

The Deliverables are evaluation outputs and remain subject to the limitations stated in this Agreement and the incorporated Business Terms.

7. Success Criteria

Before processing begins, the Parties will agree a short Pilot Scorecard.

The Scorecard should measure, where applicable:

• exceptions per 100 or 1,000 obligations;
• percentage of exceptions not already resolved by the Customer’s existing workflow;
• accuracy of obligation-to-execution matching on the reviewed sample;
• critical incorrect closure or allocation findings;
• manual time currently required to investigate relevant exceptions;
• percentage of cases for which ChainZap produces actionable evidence;
• Customer actions changed or accelerated by the Pilot findings;
• data preparation and delivery effort;
• ChainZap delivery effort;
• Customer willingness to continue with a paid or recurring workflow.

A successful Pilot does not guarantee performance on different datasets, networks, workflows or future transactions.

The Pilot is not considered successful merely because exceptions are found; the Parties should evaluate whether the identified residual exception queue is material, recurring and commercially worth resolving.

8. Customer Validation of Findings

The Customer will have a reasonable opportunity to review Pilot findings and identify:

• confirmed findings;
• disputed findings;
• previously known exceptions;
• newly surfaced exceptions;
• cases where available evidence remains insufficient.

Where practicable, the Parties may record Customer-confirmed outcomes to evaluate Pilot quality.

Customer validation does not transfer responsibility for Customer business decisions to ChainZap.

9. Customer Data

“Customer Data” means information supplied by or on behalf of the Customer for the Pilot, including Customer-specific associations between business obligations and public blockchain activity.

The Customer retains all rights it has in Customer Data.

The Customer authorizes ChainZap to process Customer Data only as reasonably necessary to:

• perform the Pilot;
• generate the agreed Deliverables;
• investigate technical issues;
• provide Pilot support;
• secure the Pilot environment;
• comply with applicable law.

ChainZap will not sell Customer Data.

Customer-specific obligations, attempts, counterparties, amounts and outcomes will not be disclosed to another customer or used to make decisions for another customer except under a separate written agreement with the Customer.

10. Data Minimisation

The Customer should provide only information reasonably necessary for the Pilot.

Where possible, the Customer should use internal obligation IDs, business references or pseudonymous identifiers instead of names, email addresses or other unnecessary personal information.

Private keys, seed phrases and transaction-signing credentials must never be provided.

If the agreed Pilot dataset contains personal data that ChainZap will process on the Customer’s behalf, the Parties will agree applicable data-processing terms before that processing begins.

11. Confidentiality

Customer Data and any Customer-specific association between Customer Data and public blockchain information are Confidential Information even where the underlying blockchain transaction is public.

Each Party will protect the other Party’s Confidential Information using at least reasonable care and use it only for the Pilot and related evaluation.

Confidential Information may be shared only with personnel, contractors and approved subprocessors who need it for the agreed purpose and are subject to appropriate confidentiality obligations.

Neither Party may publicly identify the other as a customer, partner or case study without prior written permission.

12. Third-Party Data and Providers

The Pilot may rely on public blockchain information or third-party data/services.

Third-party information may be incomplete, delayed, unavailable, inaccurate or subject to later change.

ChainZap does not acquire broader rights to third-party information than the applicable provider permits and will not represent unconfirmed provider rights as granted commercial rights.

Where a required provider cannot lawfully or contractually support the agreed Pilot use, the Parties may narrow, replace or suspend the affected part of the Pilot.

13. Security and Incidents

ChainZap will use reasonable technical and organisational measures appropriate to the Pilot and Customer Data processed.

ChainZap will notify the Customer without undue delay after becoming aware of a confirmed security incident materially affecting Customer Data, subject to applicable law and reasonably available information.

No online, blockchain or third-party system can be guaranteed to be completely secure.

14. Data Retention, Return and Deletion

Unless the Parties agree otherwise in writing:

• Customer-provided Pilot data will remain available only for the period reasonably necessary to perform and review the Pilot;
• following Pilot completion or termination, the Customer may request an agreed export of Deliverables;
• active copies of Customer Data will be deleted within 30 days after Pilot completion or termination;
• backups may persist until overwritten in the ordinary backup cycle and remain subject to confidentiality and applicable data-protection obligations.

ChainZap may retain limited information where legally required or reasonably necessary for security, fraud prevention, dispute resolution or enforcement.

Third-party data may be subject to separate retention or deletion restrictions.

15. Pilot Fee

Pilot fee: [AMOUNT AND CURRENCY — TO BE COMPLETED]

Payment schedule: [TO BE COMPLETED]

Included scope: one agreed historical payout workflow and dataset within the scope described above, unless otherwise stated.

Any material scope expansion or third-party cost not included in the Pilot fee requires Customer approval before it is incurred.

If the Pilot is provided without charge, this section will state “No Pilot Fee”.

16. No Commitment to Production

Completion of the Pilot does not require either Party to enter into a production or recurring contract.

Any production deployment, recurring workflow, API integration, ongoing monitoring, SLA or additional data-processing arrangement requires a separate written agreement or Order Form.

17. Operational Responsibility

ChainZap will perform the Pilot with reasonable care and substantially in accordance with the agreed scope.

The Customer may use Pilot Deliverables as an input into its evaluation and internal review.

The Customer remains responsible for final authorization of transactions, ledger changes, payouts, credits, compliance decisions and other actions affecting funds or legal rights.

Pilot findings do not guarantee that every exception has been detected or that every third-party data point is complete or accurate.

18. Liability

Neither Party excludes liability that cannot lawfully be excluded or limited.

To the extent permitted by applicable law, neither Party will be liable for indirect, special or consequential losses arising from the Pilot.

ChainZap aggregate liability arising out of or relating to this Pilot will not exceed [LIABILITY CAP — TO BE COMPLETED BEFORE SIGNATURE].

If the Pilot is provided without charge, the Parties must still insert a monetary liability cap before signature.

Mandatory carve-outs, including fraud, wilful misconduct, gross fault/gross negligence or other liability that cannot legally be limited, apply to the extent required by the governing law.

19. Suspension and Early Termination

Either Party may terminate the Pilot for material breach if the breach is not cured within a reasonable period after notice, where cure is possible.

Either Party may terminate immediately where continuing the Pilot would be unlawful.

ChainZap may suspend or terminate an affected part of the Pilot where reasonably necessary because of sanctions, a material security risk or a binding third-party provider restriction.

If a prepaid Pilot is terminated for reasons not caused by Customer breach, unlawful activity or non-payment, ChainZap will provide a pro-rata refund for the unperformed portion, except where payment is prohibited by applicable law or sanctions.

20. Business Terms

The ChainZap Business Terms v3 — Pre-Incorporation, as identified by version/date in the signed copy of this Agreement, are incorporated into this Agreement.

If this Pilot Agreement conflicts with the incorporated Business Terms, this Pilot Agreement controls for the Pilot-specific subject matter.

21. Entire Pilot Agreement

This Agreement, together with the incorporated Business Terms and any expressly incorporated data annex, constitutes the agreement for the Pilot and supersedes prior proposals, discussions and statements concerning the same Pilot scope, except for fraudulent misrepresentation or rights that cannot lawfully be excluded.

22. Governing Law and Disputes

[TO BE COMPLETED AFTER THE CHAINZAP CONTRACTING ENTITY AND JURISDICTION ARE ESTABLISHED.]

23. Signatures

ChainZap / Service Provider

Legal name: [TO BE COMPLETED]
Name of signatory: [TO BE COMPLETED]
Title/capacity: [TO BE COMPLETED]
Date: [TO BE COMPLETED]
Signature: __________________________

Customer

Legal name: [TO BE COMPLETED]
Registration number: [TO BE COMPLETED]
Name of signatory: [TO BE COMPLETED]
Title/capacity: [TO BE COMPLETED]
Date: [TO BE COMPLETED]
Signature: __________________________