# 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: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_